Alex headshot

AlBlue’s Blog

Macs, Modularity and More

Poor support for server

2008, mac, rant

Each time Mac OS X is released, a corresponding version of Mac OS X server is released as well. Roughly speaking, they’re cut from the same cloth; they both use the same kernel, supported libraries etc. — however, the server version ships with some standard supported features like a mail server, file server, directory services and so on. (In fact, not a lot of people know that Mac OS X server was the first shipping version of Mac OS X; for more information, read the roughly drafted article.) For a point-and-click, it’s pretty easy to set up and use; I’ve been using it since 10.3 days for hosting my internal network.

The thing that really gets me down is Apple’s pathetic support for intermingling with old/new clients. Server 10.4 only speaks to 10.4 clients; 10.5 only speaks to 10.5 clients. Got a mix? Sorry, no can do. It really makes me wonder whether there are people using Mac OS X commercially to host systems; the indication seems to be that when you want to upgrade, you need to upgrade all your servers and clients in lock-step.

Now, there have been a bunch of changes over the years in the way that Mac OS X works, so you might think it’s excusable that the versions don’t match. However, in reality, whilst some of the changes have been structural (launchd, automount, migration from NetInfo to LDAP), there’s nothing that really stops a suitably decent server providing capabilities that are available for both old and new clients at the same time. Kerberos has support for dealing with older or newer versions; LDAP is exactly the same and can support older clients; and whatever ‘new’ features may have been added, there’s no reason why the older ones can’t be supported as well.

Nowhere is this more apparent than the software update server. Changes to the way that the software update worked on the clients meant that they would consult the user-defined locations in 10.4 but only the server-defined location in 10.5. That meant using sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://server:8088/ instead of defaults write com.apple.SoftwareUpdate CatalogURL http://server:8088/, as helpfully explained in article 305584 (note the change from 10.4, although it’s still wrong for the 10.5 version of the same document).

However, that’s not the only change; the software update server for the 10.4 server only looks for 10.4 updates, even if 10.5 clients are connecting. This is helpfully explained in article 306732, but perhaps not as explicitly; despite the fact that 10.5.1 and the Security Update 2007-009 (and 009b) were released for 10.5 clients, my internal software update server was still adamantly telling me that my clients were up-to-date. So, I removed the internal update server, ran software update again, and now I’m back to where I need to be.

Why the heck do I need to do this? In fact, why is the software update service so bad? All the catalog lists is a set of updates and pointers to a plist called index.sucatalog containing pointers to swcdn.apple.com, like the like the SecUpd2007-009.pkg mentioned previously. Is there any reason why the server can’t just be an http cache, like squid or mod_cache? In fact, is there any sensible reason why the software update uses the crapola plist format anyway, and doesn’t use Atom instead? Let’s face it, with an atom feed instead, you’d be able to potentially subscribe to many different update services and update lots of different sorts of packages instead of only the Apple blessed ones.

The real problem is that it’s not possible in any meaningful way to mix 10.4 and 10.5 clients together on the same network. And whilst it’s fairly easy to roll-back a single workstation in the case of wanting to roll back a server is somewhat a difficult challenge; not so much the on-disk representation (i.e. take a backup …) but rather how you deal with keeping the services up and running during the switch over.

Now that Apple has finally moved off of NetInfo to Directory Services (or more generally, the LDAP under the covers), each Mac has its own LDAP service running on it. Unfortunately, the Workgroup Manager.app only comes with the server admin tools, as now it’s impossible to edit the directory locally. I predict that there will be a business opportunity for someone to provide a workgroup-manager like feature for maintaining a small network with a much cheaper price tag than the Mac OS X Server product. Mind you, if Apple starts selling bundled copies of Mac OS X Server with the Mac OS X Family Pack, then maybe the existence of Server will start to spread further.

Anyway, the underlying kernel for 10.5 isn’t solid enough yet for people to really want to base servers on, and I don’t see that changing in the next couple of months. Even then, the fact that Server 10.4 and 10.5 are so horribly incompatible with each other means that most organisations will probably wait for some down-time in order to move from one to the other; there’s no real pressing advantage that 10.5 has. In fact, about the only reason for wanting to move to 10.5 is in order to support 10.5 clients; but as my last post shows, 10.5 isn’t ready for production use yet.

Unfortunately, I think we’re seeing a repeating pattern here. Each time a new version of Server comes out, it’s hideously incompatible with the previous version; and clients only speak to the specific instance of server that they’re based on. Methinks there’s not enough of an abstract protocol between the two; they’re tied by implementation, not interface.