The software patching configuration built into most operating systems is configured to open a box at home, join your network and start using the computer right away. As environments grow from homes to offices and then offices grow into enterprises, at some point software updates and patches need to be managed centrally. Mountain Lion, as with its OS X Server predecessors has a Software Update service. The service in the Server app is known as Software Update and from the command line is known as swupdate.
The Software Update service, by default, stores each update in the /var/db/swupd directory. The Software Update servie is actually comprised of three components. The first is an Apache server, invoked by the /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.host.plist LaunchDaemon. This LaunchDaemon invokes a httpd process and clients access updates from the server based on a manifest of updates available in the sucatalog. These are synchronized with Apple Software Updates via /Applications/Server.app/Contents/ServerRoot/usr/sbin/swupd_syncd, the LaunchDaemon for swupdate at /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.sync.plist. The Apache version is now Apache/2.2.22.
Clients can be pointed at the server then via a Profile or using the defaults command to edit the /Library/Preferences/com.apple.SoftwareUpdate.plist file. The contents of this file can be read using the following command:
defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist
To point a client to a server via the command line, use a command such as the following:
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://updates.krypted.com:8088/index.sucatalog
But first, you’ll need to configure and start the Software Update service. Lucky you, it’s quick (although quick in a hurry up and wait kind of way). To get started, open the Server app and then click on the Software Update service.
By default, updates are set to simply mirror the Apple servers, by default, enabling each update that Apple publishes, effectively proxying updates. You can use the Manual button if you would like to configure updates to either manually be approved and manually synchronized or just manually approved but automatically copied from Apple. Otherwise click on the ON button and wait for the updates to cache to simply mirror the Apple servers.
If you would like to manually configure updates, click on the Manual option and then click on the Updates tab.
The first item in the Updates tab is the “Austomatically download new updates” checkbox. This option downloads all of the updates but does not enable them. The Updates tab also displays all available updates. click on one and then click on the cog-wheel icon towards the bottom of the screen to configure its behavior (Download, Enable, Disable, Remove and View Update).
Note: The only option for updates in an Automatic configuration environment is disable.
The service can be managed using serveradmin. To start Software Update, use the start option, followed by the swupdate service identifier:
sudo serveradmin start swupdate
To stop the service, replace start with stop:
sudo serveradmin stop swupdate
To see the status of the service, including the location of updates, the paths to log files, when the service was started and the number of updates running, use the fullstatus option:
sudo serveradmin fullstatus swupdate
The output of which appears as follows:
swupdate:state = "RUNNING"
swupdate:lastChecktime = 2012-08-04 17:04:45 +0000
swupdate:syncStatus = "DONE"
swupdate:syncServiceState = "RUNNING"
swupdate:setStateVersion = 1
swupdate:lastProductsUpdate = 2012-08-04 17:07:10 +0000
swupdate:logPaths:swupdateAccessLog = "/var/log/swupd/swupd_access_log"
swupdate:logPaths:swupdateErrorLog = "/var/log/swupd/swupd_error_log"
swupdate:logPaths:swupdateServiceLog = "/var/log/swupd/swupd_syncd_log"
swupdate:readWriteSettingsVersion = 1
swupdate:checkError = no
swupdate:pluginVers = "10.8.91 (91)"
swupdate:updatesDocRoot = "/var/db/swupd/"
swupdate:hostServiceState = "RUNNING"
swupdate:autoMirror = no
swupdate:numOfEnabledPkg = 0
swupdate:servicePortsAreRestricted = "NO"
swupdate:numOfMirroredPkg = 0
swupdate:autoMirrorOnlyNew = no
swupdate:startTime = 2012-08-04 17:04:45 +0000
swupdate:autoEnable = no
There are also a number of options available using the serveradmin settings that aren’t exposed to the Server app. These include a feature I used to use a lot in the beginning of deployments with poor bandwidth, only mirroring new updates, which is available to swupdate via the autoMirrorOnlyNew option. To configure:
sudo serveradmin settings swupdate:autoMirrorOnlyNew = yes
Also, the service can throttle bandwidth for clients. To use this option, run the following command:
sudo serveradmin settings swupdate:limitBandwidth = yes
And configure bandwidth using the syncBandwidth option, as follows:
sudo serveradmin settings swupdate:syncBandwidth = 10
To automatically sync updates but not enable them (as the checkboxes allow for in the Server app, use the following command:
sudo serveradmin settings swupdate:autoEnable = no
The port (by default 8088) can be managed using the portToUse option, here being used to set it to 80 (clients need this in their catalog URL from here on out):
sudo serveradmin settings swupdate:portToUse = 80
Finally, administrators can purge old packages that are no longer needed using the PurgeUnused option:
sudo serveradmin swupdate:PurgeUnused = yes
One of the biggest drawbacks of the Software Update service in OS X Mountain Lion Server in my opinion is the fact that it does not allow for serving 3rd party packages, from vendors such as Microsoft or Adobe. To provide those vendors with a manifest file and a quick little path option to add those manifest files, a nice middle ground could be found between the Mac App Store and the built in software update options in OS X. But then, we wouldn’t want to make it too easy.
Another issue many have had is that users need administrative passwords to run updates and don’t have them (technically this isn’t a problem with the OS X Server part of the stack, but it’s related). While many options have come up for this, one is to just run the softwareupdate command for clients via ARD or a similar tool.
Many environments have used these issues to look at tools such as reposado or third party patch management tools such as JAMF Software’s the Casper Suite (JAMF also makes a reposado-based VM that mimics the swupdate options), FileWave, Absolute Manage and others. Overall, the update service in Mountain Lion is easily configured, easily managed and easily deployed to clients. It is what it needs to be for a large percentage of OS X Mountain Lion (10.8) Server administrators. This makes it a very viable option and if you’ve already got a Mountain Lion computer sitting around with clients not yet using a centralized update server, well worth enabling.
Note: Managing multiple Software Update Servers has changed in OS X Mountain Lion Server, see my previous post for more information on these changes.

Don’t let the theft of the Paternoville sign fool ya’, State College is as safe as ever. That is, until a bunch of Mac guys descend on the Nittany Lion Shrine. Yes, it’s that time of the year again when Mac guys from around the world (and yes, all of the speakers are male) descend upon Pennsylvania State University from throughout the Big 10 and beyond to discuss the Penn State mascot, the Nittany Lion. Actually, it’s a mountain lion, so we can’t discuss it quite yet at that point, but we can talk about a slightly bigger cat: Lion.

Lion deployment, scripted tools, Munki, InstaDMG, Puppet, migrations, “postPC,” PSU Blast, Dual Boot, NetBoot, reboot (just threw that in there because it sounded like it fit, but I’m sure much rebooting will be done anyway) and even iOS. Oh, and don’t forget lecture capture, launchd, monitoring, scripting, Boot Camp via BitTorrent (wait, what?), Damn Logs, Subversion (long live git), IPv6 (long live IPv4), DeployStudio (long live the French), Reposado (long live the mouse), Luggage, Casper (long live Minnesota!), ARD (long live the friggin’ App Store), troubleshooting, FileVault (long live Howard Hughes’ legacy), Tivoli (long live that 1984 video), Munki (crap, I already said that) and even iPad (which runs iOS I think).
Overall, the lineup is superb and looking at it, I am honored to be giving a session on Lion Server amidst all the cool stuff going on around me. I’m very impressed with the number and level of speakers and very excited to be a part of it. I’m also excited to be participating with Allister Banks, a cohort from 318, who will be giving talks on InstaDMG and Munki. Overall, it is sure to be a great conference and I look forward to hopefully seeing you all there if I don’t get arrested at the airport for wearing University of Minnesota socks.
Speaking of the Big 10. Did you know there are 12 teams in the Big 10? Did you know the Big East now has teams in Idaho and California? Did you know that the Big 12 has 10 teams? Did you know that the Pac 12 has 4 teams in 3 states that don’t touch the Pacific ocean? What does all this mean? No, it does not mean that we will discuss basic arithmetic and geography at the conference; however, we might show off some apps that can help the math professors at the member institutions of these higher education conferences teach these basic subjects a bit better. Disclaimer: I went to the University of Georgia and am required by having done so to poke fun at other conferences whenever it is possible. Having said that: how many Georgia programmers does it take to change a light bulb?
…
…
They can’t, it’s a hardware problem! OK, terrible joke. So here’s a picture of the Georgia mascot chomping down on an opposing (Auburn) player.
Seems like I’m going through football season withdrawals all of a sudden… Point of all this, go to the conference. It’s sure to be a hoot, and I’m sure there will be plenty of talk about football, er, I mean Mountain Lions, er, wait, I mean Mac OS X and iOS!