I just switched our ISP to Speakeasy, who use the Spam Assassin spam filter. I wanted to have them pre-filter our mail. I listed them as the only mail exchangers for our domain. I then used Fetchmail to transfer the messages via POP3 to my server's mail transfer agent (MTA), Postfix. The benefits are:
Greatly reduced load on my server. No more handling all the domain email traffic (and the mountains of spam that clog up our 768K dsl line)
I don't have to monkey with configuring Spam assassin.
I don't have to monkey with configuring a vacation message module- that's built-in to the Speakeasy webmail interface.
When my server is down, we use Speakeasy webmail as a fallback.
So far I am very happy with the performance, and people have found navigating the spam settings and auto-reply features on the webmail interface easy to work with. Fetchmail 6.2.5 is already included in Panther 10.3.5, so you don't have to build it from scratch. Here are the instructions I followed for setting up Fetchmail. There is also some good info for workstation users here.
The only glitch I haven't figured out yet is that an account has to be logged in on the server to make it work. The file that tells Fetchmail what server to look for and what accounts to query (.fetchmailrc) has to be located at the root level of the the logged-in user's home folder. I also would like to prevent my server from responding to smtp requests from spammers who somehow know there is a mail server at my location, even though the mail exchangers make no mention of my server.
I had a hard time finding any reference to it, until I found (via Google) this blog entry. It contains a link to this thorough discussion on Apple's Discussion site, which contains a complete walk through on repairing this issue and recovering your mailboxes.
If you are running Panther Server's built-in mailing list 'Mailman,' be sure to have a mailing list called "Mailman" enabled in the list menu. Otherwise you can get get odd reporting (and odd effects) from the Panther Mailman application and Server Admin. With the resulting "mailman" list created you can, via this link, set the visibility of the list to invisible, but this way the mailing list software is reported accurately to be 'enabled' in the 'overview' tab of server admin:
Obviously, replace servername.com with your own domain info. Kudos to Richard Barret from the Mailman-User's list for pointing out the pertinent Python.org mailman FAQ entry, and the subsequent explanatory note.
Choose the name of your server lists carefully. You can only rename them by changing the case of the letters. No spaces are allowed, and once the list is created, it cannot be renamed without deletion and re-creation of the list. i.e. list "test" can be renamed to "Test" or "TEST" etc., but cannot be renamed to "test one."
Repair Permissions and Panther Server 10.3.5: Contrary to this article in Apple's Knowledge base, this problem still remains under 10.3.5. The solution is, in the Terminal, to type the following command:
sudo /usr/share/mailman/bin/check_perms -f
These hints should help you keep Mailman running well...
The Mail Service Administration manual gets it wrong when it tells you how to repair an IMAP database on OS X Server. Here's one "right way" to do it. As root, type:
sudo -u cyrus /usr/bin/cyrus/bin/reconstruct -r -f user/xxx
where xxx is the name of the user whose IMAP database you want to rebuild. This differs not only from what it says in the manual, but from standard Cyrus behavior (which would use user.xxx instead of user/xxx).
Astonished at the lack of drives available for the old G4 Xserves from Apple, I decided to tear one apart and see what the big deal was. It took 30 seconds to realize that we are dealing with a regular old Ultra-ATA drive! Apple is still getting $499 for the old drives, and if you can find one elsewhere, they are often "used."
Having eight Xserves, all with four 60GB drives in them, I went off to BestBuy and bought all 30 of the 250GB drives they had on sale for $125 each, went back to my data center, and started work on moving them over. Here comes the tip...
Usind an old hint that I found, I downloaded psync to start the transfer on one of the boot drives on a spare server. After psync did its thing, I then cracked open the Terminal to 'bless the new drive:'
$ bless -folder /System/Library/CoreServices
You DO NOT need to bless it for OS 9, as the Xserve won't boot into it. I put the new sled in, and presto ... all 35GB of data was over, and I had about 200GB free now. So for the cost of roughly six sleds, I was able to update all 30. I know most people don't have Xserves, or eight of them, but this is one of those hints I wish I'd have found six months ago.
If you are managing a server running Mac OS X Server 10.2, you don't have to stick with the 10.2 Admin tools. Although Apple doesn't mention it, the 10.3 Admin tools will (for the most part) allow you to manage older servers. Workgroup Manager in particular is significantly improved over its 10.2 incarnation. Server Admin 10.3 will start and stop services on 10.2 Server, but to configure settings, you will still need to use Server Settings 10.2.
The 10.3 Admin tools do require 10.3 on the client side. They can be downloaded for free from Apple's site.
I have just completed my first really challenging (for me) UNIX shell script and I'm quite proud of myself. I run the Mac section of a very cross-platform lab at an art school in New York. We have all the Macs using network home accounts authenticating on a Mac OS X Server and mounting on an NFS mount point run from a Linux box (it's a long story). Sometimes, it's really convenient for me to have a standard flat BSD passwd file to give to the UNIX SysAdmin so we can sync up the user data between Mac and UNIX. The flat file is also very handy to have around if anything goes wrong with your user database. It can be used to very easily rebuild that database in the event of a catasrophe. Or if you just want to rebuild your server for fun without re-entering all the users and their passwords by hand.
Back in the NetInfo days this was no problem -- use nidump to generate just such a file directly from the NetInfo DB. As of Panther, however, Mac OS X Server uses LDAP exclusively for network home accounts. But I still need that flat file. Apple provides a command-line command called dscl, which will output certain data from the LDAP database, but it will not simply create a flat file like nidump would. So, I've written a script that uses dscl, foreach and (of all things) awk to create a passwd file from the LDAP database. I realize it's very sloppy (I'm sorry, but awk is INSANE) but hey, it works. And like I said I'm proud. Maybe someone else can use it. Or perhaps it's possible that I'm the only person in the world who needs to do this.
To use the script, view the source, then copy and paste all of it into a plain text file. Save it somewhere handy. Make it executable (chmod 755 /Path/To/File). Then just drag it into a Terminal window, hit return and type your password. If you have a large LDAP database, it will take a few minutes ... but when it's done, there will be a file on your Desktop called UserList-FINAL.txt. That's your passwd file!
I found that when using Apple's Address Book to access their Open Directory that it wouldn't show the city. The LDAP standard for the city is the "l" attribute or "localityName". You have to add the "l" attribute via LDAP as when you try to add the city attribute in the Workgroup Manager, it will give you an error when saving. I noticed article on Apple's support site regarding a similar error in Workgroup Manager, and they mention remapping the Open Directory attributes.
If you change the LDAP Directory Mappings from Open Directory to Custom and edit them, you will find that the User -> City attribute is mapped to 'locality,' which is not a valid LDAP attribute. Changing the value to 'l' allowed my Address Book to see the City.
This didn't have any effect on Workgroup Manager, however, but changing the value on the server itself might.
I've been trying for quite some time to fix this problem one software vendor at a time, but then thought the Mac OS X Hints would probably be a good way to get the attention of many software developers all at once.
When I download a .dmg file from someone's web site, about 25% of the time my browser loads the binary file as text to a window instead of saving the file to disk. The reason this happens is that their web server is not configured properly. The problem has persisted for a long time because the two biggest Mac browser (Safari and IE) disregard the server settings and download the file anyway. You may have experienced a similar problem (even with Safari or IE) when downloading .gz or .sitx files.
So, if you manage a web site, please add the following to your site's .htaccess or httpd.conf file:
The other way to fix it is to change your server's default type, which would mean all unknown file types would be downloaded (and wouldn't that make a whole lot of sense?).
Applying one of these fixes avoids the annoying occurrence of having your users' browsers get hung for 5 minutes while they try to render 20MB of binary data as text (and would thus help to improve the overall Mac experience)!
[robg adds: I've put this in the OS X Server category, but it obviously applies to anyone running a server on any platform...]