Apple Software Update options

UPDATE: It is now possible to use munki to allow non-admin users to install Apple Software Updates — either from your server or Apple’s. See here for more information.

At work, I’ve been working on a solution for handling Apple Software Updates for non-administrative users. Each approach I’ve tried has serious obstacles. Here’s a brief history of what I’ve tried and what worked and what didn’t.

First, a little background: Apple provides a Software Update Server as part of Mac OS X Server. This allows you to cache Apple’s updates on a local server for more efficient use of Internet bandwidth, and more importantly, a local Software Update Server allows you to choose which items you want to make available to your organization — for example, you can choose to not make an update available to machines in your organization until after you’ve finished testing it in your environment.

But hosting a local Software Update Server does not solve a fundamental problem: how to get the updates onto a machine without requiring administrator privileges for the machine’s user(s). Hosting a local Software Update Server is no different than relying on Apple’s servers in this regard; someone must authorize Software Update.app with administrative credentials.

So if you want to use Software Update to distribute updates to your machine, this means either providing all your users with administrative credentials, or having admins visit each machine. It would be better if we could find a way to install updates without requiring a user to type in an admin password.

If you are using a third-party solution for installing software and handling non-Apple updates, something like radmind, LANrev, FileWave, or Casper, these products may have their own mechanisms for handling Apple Software Updates. If they don’t, you always have the option of downloading the updates from Apple and importing them into your management system just as you would any third-party software.

But a downside to doing this is that you may lose the logic Apple uses to determine which updates are applicable to each machine. You may find yourself having to replicate this logic in some way. The larger the number of unique hardware and software configurations you have, the harder and more tedious this becomes. So you may want to find a way to leverage Apple’s tools.

The obvious first approach: as root (via cron, launchd, ARD or ssh), run the command-line Software Update tool:

/usr/sbin/softwareupdate -i -a

This is simple, but has several problems:

1. The only safe time to do this is when no-one is logged in, since a restart may be required, or applications that are in use might be updated. But if you do it when no-one is logged in, and you provide no user feedback as to what is happening, you run the risk that the user will shutdown, restart, or log in while the process is happening. The first two could cause you to have an unbootable machine; a user logging in could be a problem if a restart is required or the user attempts to use applications that are being updated.
2. Since a user might be waiting to use the machine while this process is happening, ideally you’d want to have some sort of progress indicator, and also you’d like to do the downloads separately from the install so that the time your users are forced to be logged out is minimized. But /usr/sbin/softwareupdate‘s output is almost impossible to use to construct meaningful progress info, and it has no way to download items in advance.
3. You are thinking “But what about softwareupdate -d -a? Doesn’t that download all the available updates?” Why yes, it does. Unfortunately, there’s no way to tell softwareupdate to use those downloads, if you later run softwareupdate -i -a, it will download them all over again.

If you are willing to make the user wait for the entire download and install process while the machine is logged out with no real progress feedback, then this approach might work. If you have a bunch of desktop machines that will be on (or can be set to wake up/power up) in the wee hours of the morning, this approach might work, as the lengthy updating can happen when no-one is around. If, on the other hand, you have a large number of laptop machines, this approach is less likely to be accepted by your users. They’ll have to participate in the updating of their machines, and won’t like having no indication of how long an update might take. They are more likely to get annoyed or impatient and simply turn off the machine in the middle of the update, because it may appear that the machine is locked up.

So that brings us to the next approach: again, with a script running as root, use softwareupdate -d -a to find and download the available updates, then use /usr/sbin/installer to install them. This seems promising, because /usr/sbin/installer gives reasonable progress feedback that you could then pass to the user.

Unfortunately, not everything downloaded via softwareupdate -d -a is in a format that /usr/sbin/installer knows how to install. And so far, I haven’t been able to preflight these items to know in advance what can be successfully installed and what cannot — you just have to try and see if /usr/sbin/installer throws an installation error back at you. So unless we can figure out how to detect and deal with the “broken” downloads, this is not an ideal solution, as there will be updates that are not installable via this method.

Now for the third approach.

It is possible to trigger the process that downloads updates in the background into /Library/Updates/ — the same one that, when updates are available, then opens the Software Update.app and prompts you to install them. (On Snow Leopard, this is essentially the same thing as running softwareupdate -d -a; on Leopard, softwareupdate -d -a does something different, downloading them into the Downloads directory of the current user.)

Once these items are staged in /Library/Updates, you can re-write the /Library/Updates/index.plist and touch a file to tell Software Update to install these upon restart; this is a variation of the built-in behavior when you use the Software Update app and choose to install items that require a restart – you are logged out, the items are installed, and then the machine is restarted.

Here’s a shell script that gets the basic steps done:

#!/bin/sh

defaults -currentHost write com.apple.SoftwareUpdate AgreedToLicenseAgrement -bool YES
defaults -currentHost write com.apple.SoftwareUpdate AutomaticDownload -bool YES
defaults -currentHost write com.apple.SoftwareUpdate LaunchAppInBackground -bool YES

#Take away execute & read rights so Software Update doesn't open during a user session
chmod 700 /System/Library/CoreServices/Software\ Update.app
#Check for new updates
/System/Library/CoreServices/Software\ Update.app/Contents/Resources/SoftwareUpdateCheck
#Put execute and read rights back
chmod 755 /System/Library/CoreServices/Software\ Update.app

#This sets up all the files so that it will install on restart
installarray=`defaults read /Library/Updates/index ProductPaths | grep -v "[{}]" | awk -F "=" '{print $1}' | grep -o "[^\" ]\+"`
defaults write /Library/Updates/index InstallAtLogout -array "$installarray"
touch /var/db/.SoftwareUpdateAtLogout
chmod og-r /var/db/.SoftwareUpdateAtLogout

Leveraging this has several attractions: you are using Apple’s processes and logic for installing updates; you get progress feedback for free, since you are using Apple’s tools, and the updates can be downloaded in advance, minimizing the time required at logout to install the updates.

There are some drawbacks:

• You have to trigger a restart to initiate the install; even for items that don’t require a restart.
• When the restart is triggered, a dialog appears telling the user there are updates to be installed and giving them two choices “Restart”, or “Install and Restart”. While it’s good to have the choice, it’s an additional bit of noise if you’ve already asked them to restart to install the updates.
• And the big one: there’s no clean, Apple-supported way to programmatically trigger the install if you are already sitting at the loginwindow.

  If a user is logged in, you can do this:

  osascript -e 'tell application "System Events" to restart

  But if no user is logged in, the above doesn’t work. If you do shutdown -r now, the machine just restarts without installing. If you click the Restart button in the loginwindow, you are prompted to allow the installs to happen, which is what we want. It turns out that in Leopard and Snow Leopard, after a little setup, we can do just that programmatically with:

  osascript -e 'tell application "System Events" to tell process "SecurityAgent" to click button "Restart" of window 1'

  This doesn’t work, obviously, if the administrator (or user!) has disabled the Restart button from appearing in the loginwindow, so it’s not particularly robust, but it’s the best we have right now.

A fourth approach:

A script running as root launches the Software Update.app:

#/bin/sh
/System/Library/CoreServices/Software\ Update.app/Contents/MacOS/Software\ Update

Ideally, you’d use a launchd job that watched a path writable by non-privileged users. When that path was modified, the launchd job would fire, launching Software Update as root.

Advantages:

• Once Software Update is running as root, the user can download and install anything Software Update makes available without having to enter administrative credentials.
• You’re using even more of Apple’s code and relying less on your own, making this a robust solution.

Possible disadvantages:

• The user can choose to not install some items — this could make it more difficult to apply Security Updates in a timely manner
• Since Software Update.app is running as root, there are potential security risks; it might be possible to use a flaw in Software Update.app to can root privileges elsewhere.
• This approach doesn’t help you install updates when no-one is logged in; it only works with user involvement and cooperation.

So there you are. Four ways to get Apple Software Updates installed on machines without requiring your end users have administrative credentials.

No one approach works in all situations, but perhaps one of these approaches will work for you.

Advertisement