This article is a pre-release chapter in the upcoming “Take Control of OS X Server,” by Charles Edge, scheduled for public release later in 2014. Apart from, and , these chapters are available only to ; see  for details.
Frequent software updates have become a fact of life, thanks to Apple continually rolling out new versions of the software that runs your devices in order to fix bugs and plug security holes. Apple has put a great deal of effort into making it easier for Macs and iOS devices to discover, download, and install various updates, for both individuals and groups.
In this chapter, I’ll focus on groups, since OS X Server contains a pair of services that help you manage these updates for your home, office, or entire organization. In particular, OS X Server aims to give administrators two important capabilities:
These ideas—caching software updates to reduce bandwidth usage and giving administrators control over which updates are made available to users—underpin two services in OS X Server: Caching and Software Update. They do roughly similar things, but don’t overlap entirely, so you may wish to run one, the other, or both, depending on your needs.
Both the Caching service and the Software Update service are designed to download updates from Apple and provide them to users on your local network. But that’s where the similarities end, so let’s look at each in turn so you can decide which to run.
OS X Server’s Caching service is one of the easiest to configure and provides an immediate benefit to any network that hosts Apple devices. The Caching service does just what you’d expect from the name—it caches all updates from Apple on your server, and all Macs and iOS devices download from your server rather than directly from Apple. This offers two big benefits: reduced bandwidth and faster updating for users.
Bandwidth usage goes down because the Caching server downloads only a single copy of each update, and each device that needs the update gets it from the server rather than going back to Apple. So if Apple releases a new version of iOS or an update to the iWork apps for OS X, your Internet connection won’t be bogged down as each device struggles to download those large updates from Apple.
Similarly, because each device gets updates from the server over the fast local network rather than over your much slower Internet connection, users shouldn’t have to wait nearly as long for the updates to download.
Other than music and video purchased from the iTunes Store, the Caching service makes a local copy of nearly everything a Mac or iOS device can download from Apple, including:
Running the Caching service is a no-brainer, since any home, school, or company with more than a couple of Apple devices will benefit, and it takes only moments to set up. The only thing the Caching service doesn’t do is let you choose which updates your users see; for that, turn to the Software Update service.
It’s less clear that you should run the Software Update service, since it works only with Mac software from Apple (not apps from the Mac App Store) and requires more configuration, both in terms of choosing which updates to release on the server and in pointing client devices at the server.
The main reason to run the Software Update service is if you want more control over which Mac updates are made available to users on your network. This likely isn’t important in a home environment, and might not be worth the effort in a small office, but once you’re at the enterprise level, it’s essential for ensuring that users don’t install an update before you’ve had a chance to vet it.
That said, if you’re serious about wanting to centralize software updates for your organization, you may wish to investigate a third-party option. In my experience, the Software Update service has three limitations:
Many organizations have addressed these issues by relying on third-party solutions, such as the comprehensive, , and JAMF’s , all of which are commercial software and offer a wide variety of features. On the open-source side, there’s , a replacement for Software Update that can run on any Unix-based hardware and lets you create an unstable/testing/release workflow.
But don’t get me wrong. Overall, the Software Update service is easily configured and managed, and works well for deploying updates to client Macs. It is what it needs to be for a large percentage of OS X Server administrators.
So which should you use? Everyone should enable the Caching service, but only those who need to approve Mac updates before they’re presented to users need to turn on Software Update.
To get started with configuring the Caching service, open the Server app and click Caching in the sidebar. There are only three settings: where the cached data should live, how large the cache should be, and whether or not to cache content for users on subnets. Configure them before you click the ON button.
First, decide if you want the cached data to live on the volume that contains service data for OS X Server (generally the startup drive). If not, click the Edit button to the right of Volume, and choose a new volume for the cached content.
I recommend choosing a drive with plenty of free space, since your cache size should be at least 100 GB. It’s best to do this before turning the Caching service on, to avoid needing to move gigabytes of data.
Once you’ve chosen the appropriate destination, drag the Cache Size slider to the desired amount of space. Allot at least 100 GB, but since the slider doesn’t allow for much precision, you may not be able to choose the exact size you want. The smaller the cache, the more likely older updates will be deleted to make room for new ones, forcing the Caching service to download them again when requested. Don’t worry too much about the cache size right now, since you can always increase it later, as long as there’s room on the drive.
Most people should leave the “Only cache content for local networks” checkbox selected; deselect it only if you have a complex local network with subnets and you want to provide cached content for users on those subnets.
That’s it. Click the ON button to enable the Caching service, and it will start downloading updates and purchases from Apple (Figure 1). It doesn’t do so right away, but instead waits until a particular update has been requested by a device, after which it makes that update available to all other devices on the network.
Nothing needs to be done to alert Macs and iOS devices on the network to the presence of the Caching server; they use it automatically, taking advantage of high-performance Wi-Fi and Ethernet connections and leaving your Internet connection free for what’s important: Netflix!
Enabling the Software Update service isn’t significantly more difficult than the Caching service, but it requires a bit more thought, and potentially quite a bit more time.
To get started, open the Server app and click the Software Update service. By default, Software Updates is set to work in Automatic mode, where it simply mirrors Apple update servers, making every update that Apple publishes available to your users unless you disable a specific update manually. Plus, when updates are no longer supported by Apple, they’re removed automatically, which often isn’t desirable (since you likely wish to keep an older update available while you test the new one).
Instead, I assume you want more control which updates are offered to your users, and to get that control, select Manual. That done, click the ON button to enable the service and start downloading the list of updates (Figure 2).
Click the Updates tab to see them, but don’t expect anything to appear right away. It can take 15–30 minutes to download just the list of updates from Apple, even with a decently fast Internet connection, so go read your email or get a cup of coffee. I’ll wait.
Once the Updates tab has populated with the list of updates from Apple (there are a lot—773 as of this writing!), you need to decide if you want to store them all locally or not. If so, select the “Automatically download new updates” checkbox, but read on before you do.
The problem is that Software Update needs a lot of space—assume at least several hundred gigabytes—and you can’t easily control how much space is used. Annoyingly, unlike the Caching service, you can’t relocate just the Software Update data; instead, you must relocate all the service data for OS X Server as a whole.
Now it’s time to work with individual updates (Figure 3). With so many items, it’s essential to remember that you can sort the list by clicking the header of any of the columns: Name, Version, Date, Size, and Status. Click the column header a second time to reverse the sort. Equally as useful is the Filter Updates field, which limits the updates listed to those that match an entered search term.
Each individual update can have one of four statuses:
To change these statuses and control the storage of each individual update, you have the following options, available from the gearmenu at the bottom of the screen and from the pop-up menu to the right of each item.
Once you’ve configured all the appropriate updates as desired (and this is what takes time, since there are a lot to go through), it’s time to configure client Macs.
There are two ways to configure client Macs to look to your Software Update server instead of Apple’s, but neither is particularly pretty. If you’re using Profile Manager and distributing profiles to each Mac, the best approach is to add a custom setting to the profile. If that’s not possible, you’ll have to resort to the command line on each client Mac.
If you haven’t already, run through the steps in Chapter 9,, to  and . Then, follow the instructions in  to edit the settings for the appropriate group, after which you can follow these steps, clicking OK and then Save to save your changes.
index.sucatalogappended, as in
This approach is conceptually simpler, but requires touching each individual Mac. Open Terminal and enter a command like this one, replacing
mavserver.pretendco.lan with the hostname of your server.
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://mavserver.pretendco.lan:8080/index.sucatalog
To verify that you entered the right information, check your work with this command:
defaults read /Library/Preferences/com.apple.SoftwareUpdate CatalogURL
If you want to switch back to using Apple’s default Software Update server again, enter this command:
sudo defaults delete /Library/Preferences/com.apple.SoftwareUpdate CatalogURL
Once all this is done, open the App Store app and click Updates to see the updates that you’ve made available for that particular Mac. Remember that only those that are necessary for that Mac will appear, so if it was up to date before you set up the Software Update service, you may not see anything until a new update appears.
Read More: Chapter 12 |  |  |  |  |  |  |  |  |  |  |  |  |  |