Improving Apple Software Update in a corporate environment

July 23, 2009

Lately I’ve been struggling to find some elegant way to put apple software updates into some sort of patch management process (by definition centrally managed), while keeping the process as simple/cost-effective as possible. Actually, what I was trying to achieve is a way to centrally manage and approve the update packages, and make them automagically applied to the clients, considering that the end users are standard users (non admin), which prevents the chance of having the end user invoke the software update at all (admin privileges required).

Here is the starting environment:
– 10.4.x and 10.5.x clients
– end users are non-admin
– clients are joined to a win2k8 a.d. Domain (not very important in this case, while useful).

And this is what I managed to create so far (with a 2day investment šŸ™‚ ) :

Since I had a spare leopard osx server not doing much , I configured and started the software update service. This allowed me to centrally download and cache all updates from apple, and also solves the need to manually enable/allow only selected updates for the involved clients.

Then I followed some tips found on the web and managed to trick the clients into thinking that swscan.apple.com (official apple update site(s)) is actually my leopard server (using some dumb dns redirect or something like that…). Actually there is a ‘more official way’ of instructing the clients into using a custom update server (modifying ‘defaults’ on each client), but I preferred the tricky way for a couple of reasons:

1 – easier to implement and change overtime
2 – allows for fallback to the official apple servers whenever I need this feature (roaming/mobile users, etc).

The tricky solution actually needed some more work, since there are a couple of undocumented web redirects that are needed in order for the trick to work. Let me say that apple’s docs about the software update service are poor to say the least. Also, the service itself is poor: it downloads packages, it allows you to choose which to enable, but there are no useful logs (and you sit there wondering what the hell it is doing, just to discover that some uber-gig package is being silently downloaded). Moreover, there is NO WAY of fine graining the selection of updates: a package is enabled for everyone or for none… No groups or the equivalent of MS SCCM ‘collections’. Very much ‘SOHO oriented’, if you ask me.

Anyway, if you’re willing (and can) adapt your patch management process to this ‘all or nothing’ constraint, the software update service does its job.

Now on the VERY tricky part: how do you manage to push/force/publish/you name it the packages to the clients so that the user (not admin, remember!) gets his updates without much ado?

I seriously googled for some official or semi-official way to do this, but found nothing really enlightning.

So I ended up building a client-side shell script that:
– invokes the ‘softwareupdate -l’ command and parses the results to see if there are updates available, and if one or more of them require a reboot.
– downloads the packages and installs them
– if needed, it reboots the client.

Doing the updates while the user is working (open files/apps) may be a LOT dangerous, and a hell for the IT support, so I tried to find some ‘safe zone’ that allows to ensure that the updates are actually triggered, without risking to scramble the poor user’s machine.

Shame on Apple nr.2: I ended up thinking of a pre-shutdown update-trigger script (I’ve built tons on my *nix servers for ages), but apple decided that rc.* was too simple, and drove us into using the superperfect launchd, which happens imho to be a real mess, and more important doesn’t offer ONE SINGLE way of intercepting a shutdown/reboot event. No comment šŸ˜¦

At least, they allowed for the so-called ‘loginwindow hooks’, which provide (simply put) some sort of flexibility in triggering actions on user login and logout. Luckily, the logout hook came to the rescue, since it’s triggered on logout (doh, who could have guessed? šŸ˜‰ ), and shutdown/reboot.

This is cool as it provides the ‘safe zone’ I needed to trigger the updates w/o worrying that the user has open files/apps and even worse that he could get stuck because my updates on his mac require a reboot.

So I hooked my logout hook šŸ˜‰ to loginwindow, and automagically it started to behave as expected.

Now I found the need to provide some feedback to the user during the update process, since the background script left him with a dumb wallpaper and no further info.
And I found the excellent tool iHook (really, that’s its name! šŸ™‚ ), which allowed me to show a nice cocoa dialog that I can populate with warnings, progress bar (how cool is that) and even a background image (!!! šŸ™‚ ), just by adding some echos to my bash script.

The result (still a work in progress) is a user friendly updates-trigger process that automagically applies updates on my behalf, without requiring user intervention or other major issues.

The thing needs some cleanup and tweaks, but the whole process is running pretty good!
Things to fix asap are:
– provide an installer script that sets up the necessary packages and config files on the client side (nearly done), and chooses among the iHook for leopard vs tiger (sgrunt šŸ˜¦ ).
– provide an autoescape in the hook so that if a mobile user accesses the internet avoiding my tricky diversion, it simply quits without accessing the official apple update server.
– some more informative displays in the iHook dialog, so that the user is not driven into thinking that the mac is hung (the softwareupdate -i -a process could last looooong).

So far, so good… Considering the starting point.. I’m pretty satisfied with this setup, as it lowers the burden on IT staff and give all users something automated, user friendly, and sleek :-).

I’ll let you know as soon as I roll it out in production šŸ™‚

Advertisements

One Response to “Improving Apple Software Update in a corporate environment”

  1. Roy Chean Says:

    Hi there,

    i am wondering if you have roll your solution to production and whether is it possible to have a copy of the solution as here in University of Melbourne , we are trying to develop the similar solution to improve the apple software update.

    hope to hear from you soon

    Cheers
    Roy Chean
    Desktop Infrastructure Support
    User Services

    Information Technology Services
    Level 2, 258 Queensberry St.
    The University of Melbourne
    Parkville, Melbourne, Vic, 3010
    T: +61 3 83448300
    M 0401693156
    F: +61 3 83442765
    E: rchean@unimelb.edu.au


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: