Enabling serial console with Panther Server is very easy ... if you know where to look. Start by reading this file: /System -> Library -> StartupItems -> SerialTerminalSupport -> SerialTerminalSupport. It has lots of information about the serial port. After reading it, enter:
This should enable console access. However, it didn't in my case. I have to connect through a console server at my colo facility, which operates at 9600 baud. Apple enables a 57600 baudrate by default. So I had to do:
I changed this line:
tty.serial "/usr/libexec/getty serial.57600" vt100 on secure
tty.serial "/usr/libexec/getty serial.9600" vt100 on secure
Finally, I used this command to restart the console support:
And I was able to connect. If I had discovered the above earlier, I would had saved myself for driving to my colo server room a couple weeks ago when I made a mistake with remotely configuring my en0 interface!
OS X Server port forwarding can't be configured with the GUI, as natd.conf is erased by default by the GUI Admin program. So labo-Apple.com has written a small tutorial on how to edit the natd.plist used by Server Admin to forward port with NATD.
I haven't tried this, as I have no need for it (nor do I have OS X Server), but if you'd like a network monitoring tool on your Server box, this seems like a good one (check their stats page for some data on who's using their tools).
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!