Skip to content

OS X Server SUS Hack

I’ve been having a problem with the Software Update Server on OS X, it never generates the catalog files. As far as I can tell, the swupd_syncd process seems to get “stuck” and never generate the catalog file.

Here’s how I “fixed” it. I added the following to root’s crontab:

17 3 * * * /bin/cat /var/db/swupd/html/content/catalogs/ | /usr/bin/sed 's/' > /var/db/swupd/html/content/catalogs/index.sucatalog
19 3 * * * /bin/cat /var/db/swupd/html/content/catalogs/ | /usr/bin/sed 's/' > /var/db/swupd/html/content/catalogs/index-leopard.merged-1.sucatalog
23 3 * * * /bin/cat /var/db/swupd/html/content/catalogs/ | /usr/bin/sed 's/' > /var/db/swupd/html/content/catalogs/index-leopard-snowleopard.merged-1.sucatalog

Keep in mind this is the crontab for the root user (I used sudo crontab -e), not the system crontab, which is normally located in /etc/crontab. Speaking of which, where the hell did that go?

Seriously, Apple, WTF? Why is it so friggin’ hard to make a service that pulls a bunch of files off the web and generates an XML file? If I weren’t pressed for time, I’d replace swupd_syncd with a hundred lines of Ruby code.

When it comes to OS X Server, I’m aghast at how difficult it is to get the simplest things to work. The “enterprisey” Apple stuff is awesome in theory, but horrible in practice. It took days to get the OpenDirectory stuff to work properly.

Even still I have all kinds of problems. For some reason OpenDirectory decides it’s just going to take a nap, and it will take three minutes (or more) for anyone on the network to do anything. Imagine how fun it is trying to change tabs in Workgroup Manager and it takes three minutes between each mouse click.

Here’s another: periodically OpenDirectory will decide to disable a mobile user. For those of you who’ve never experienced this, when that happens, the client machine will disable the local user account. And good luck getting that re-enabled (after you enable it in WGM). You can run this command a bunch of times:

sudo pwpolicy -a LOCAL_ADMIN_SHORTNAME -n /Local/Default -u USER_SHORTNAME -enableuser

But it only works 25% of the time. The rest of the time you get messages about user not being disabled or not having a shadowhash. Sometimes if you just reset the user’s password that will re-enable the account. Otherwise reboot it a whole bunch of times until it finally figures out the account is enabled in OpenDirectory.

Posted in OS X, Rant, Tips and Tricks.

0 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

Some HTML is OK

or, reply to this post via trackback.