preload
Mar 29

The problem: Suddenly, your Server Admin and Workgroup Manager applications are unresponsive or extremely sluggish, taking many seconds to simply switch between tasks, or up to a minute to launch.

The solutions & explanation: While this issue existed sporadically in Tiger Server, it’s really come to the front with Leopard Server because the latter is now much more picky about having properly-configured DNS for your server. If this is happening to you, here’s a checklist to help you solve the problem:

1) Have you recently changed IP numbers on your server? If so, did you use the changeip command? (man changeip to read about this tool). Run this command to determine whether anything needs to be fixed on your server:

sudo changeip -checkhostname

If your DNS is configured properly, the result should read something like:

Primary address     = 209.250.250.98

Current HostName    = macshelf.com
DNS HostName        = macshelf.com

The names match. There is nothing to change.

If you get anything other than this match, you’ll need to run the changeip command to get the configuration on your server aligned.

If you’re not hosting your own DNS, then you may need your ISP to create a PTR record for your server’s domain name so that both forward and reverse DNS lookups are valid. This is especially important if you’re hosting email on this server, as many email servers are configured to reject mail coming from a server without 100% correct DNS.

2) Ok, so you’ve verified your DNS settings are correct. If you had to execute the changeip command to make changes, make sure you’ve rebooted the server.

3) If you’re still having issues with Server Admin and WGM being slow, try removing their preference files (com.apple.ServerAdmin.plist and com.apple.WorkgroupManager.plist) that reside in ~/Library/Preferences. When you relaunch Server Admin and/or WGM, you can re-enter your server’s address (either its domain name, its IP number, its local Bonjour name, or its loopback address (127.0.0.1); they all will work)).

4) If you’re still having problems with unresponsive Server tools, try unloading and then reloading the servermgrd process.

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.servermgrd.plist

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.servermgrd.plist

These are the steps I followed in resolving this issue on several of the Mac OS X Servers that I manage. Your mileage, of course, may vary. I culled most of this information from the Apple Discussion Boards and the Mac OS X Server and MacEnterprise mailing lists. Good luck!

Tagged with:
Mar 04

Today, we had a catastrophic data failure on our Wiki server, hosted on a Mac OS X Server. We had two backups, a Carbon Copy Clone from over a year ago, and a Retrospect backup from a few weeks ago. Clearly, the CCC backup was pretty much unusable (ancient content), and so we pulled our newest Wiki content from the Retrospect backup, and suddenly hit a wall. I needed to slip the “new” content into a freshly-restored Leopard server. But how?

Unfortunately, Apple’s Leopard Server documentation doesn’t say much about migrating from one Wiki server to another, but it turns out that it’s not such a difficult process. I found this Apple Discussion post that helped me to understand the process for restoring the content into a newly-rebuilt Leopard Server OS. Here are my notes from doing this:

  1. Reinstall Leopard Server OS. Rebuild Users & Groups, rejoin to ODM, if necessary.
  2. Pull Wiki content from Retrospect backup.
  3. Turn off Web services, if you haven’t already done so.
  4. Move the restored content into /Library/Collaboration
  5. chown -R _teamsserver:_teamsserver /Library/Collaboration
  6. Rename index.db to index.bak on each workgroup/wiki. Each index.db will be rebuilt when you restart the Web services.
  7. Turn web services back on. Verify that index.db is rebuilt for each workgroup/wiki
  8. Load your wiki in web browser and voila!, all your content is back.

And that’s it. I was pleasantly surprised at how easy this was to restore a wiki from backup. Migrating a wiki from one server to another would use this same process.

Note: Retrospect doesn’t honor perimssions during a restore process, which necessitated step number 5 above. Normally, you’d just be able to tar or zip your content and cp or ditto it from one location to another, which would preserve your permissions.

Mar 04

Rumors abound that Snow Leopard’s Mail server will use Dovecot instead of Cyrus. This is excellent news.

According to the Dovecot project’s web site, the software is also “among the highest performing IMAP servers,” using self optimizing, transparent indexing of mail folders that support modification by multiple concurrent users. The software also supports IMAP extensions including IDLE push notifications, and provides plugins for handling ACL support and quota limitations. Apple is also expect to tout improvements of its own, including support for server side email rules and vacation messages.