Skip to content
Thoughtful, detailed coverage of everything Apple for 34 years
and the TidBITS Content Network for Apple professionals
10 comments

Take Control of OS X Server, Chapter 12: Software Updates

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 Chapter 1: Introducing OS X Server, and Chapter 2: Choosing Server Hardware, these chapters are available only to TidBITS members; see “Take Control of OS X Server” Streaming in TidBITS for details.


Software Updates

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:

  • Limit bandwidth usage: Software updates keep increasing in size, with major updates to OS X and iOS hitting multiple gigabytes. iOS apps and Mac apps from the Mac App Store are also an issue, given the number that users download and the frequency with which they’re updated. All that data adds up, and while you can’t avoid downloading one copy of each item, if you have a few devices in a household, or a number of users in an office or school, there’s no reason to tax your Internet connection downloading multiple copies of each item simultaneously as users update en masse.
  • Control update distribution: Although Apple and independent developers always intend for their updates to address bugs, it’s not uncommon for an update to cause its own unanticipated problems. I’ve seen OS X and security updates break printing, prevent certain fonts from displaying, and cause certain apps to crash on launch. In each case, a subsequent update resolved the problems, but if you support numerous users, vetting updates before allowing them to be installed can save you significant headaches.

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.

Decide Which Update Services to Use

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.

About the Caching Service

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:

  • OS X and iOS updates
  • Mac apps purchased from the Mac App Store and updates
  • iOS apps and updates
  • Books purchased from the iBooks Store
  • Apps and books from iTunes U
  • Internet Recovery software

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.

About 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:

  • Software Update cannot be configured to serve update packages from other vendors, such as Microsoft and Adobe. If you rely on Microsoft Office or the Adobe Creative Suite and want to centralize those updates, Software Update won’t help.
  • You can’t release updates to only a group of Macs, making it hard to maintain a testing group.
  • Although this isn’t OS X Server’s fault, many Apple updates require that the user enter an administrative password to install. If you haven’t given your users administrator-level accounts on their Macs, you’ll have to turn to another tool (including Apple’s own Apple Remote Desktop) to install automatically.

Many organizations have addressed these issues by relying on third-party solutions, such as the comprehensive Absolute Manage, FileWave, and JAMF’s Casper Suite, all of which are commercial software and offer a wide variety of features. On the open-source side, there’s Reposado, 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.

Differences between Caching and Software Update

Let’s summarize the differences between the Caching and Software Update services:

  • The Caching service caches updates and most purchases for both Macs and iOS devices. In contrast, the Software Update service caches only Mac updates.
  • The Caching service requires no client-side configuration; Macs and iOS devices use it automatically if it’s available on the local network. The Software Update service requires that you configure each client Mac to use it manually.
  • The Software Update service enables administrators to restrict which updates are made available to users. The Caching service offers no such capability.
  • The Caching service downloads updates over time, based on device requests, whereas the Software Update service downloads and caches all available updates when it first starts up.

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.

Note: If you turn on both, Software Update takes precedence over Caching, which makes sense, since administrators wouldn’t want Mac users getting inappropriate updates, and Caching offers no update management controls.

Configure the Caching Service

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.

Note: If you move the cached data, you’ll see a /Library/Server/Caching/Data directory appear in the new location. The contents of that directory aren’t human-readable, so there’s nothing useful you can do with them.

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.

Note: Should you want to reclaim the space used by the Caching server temporarily, click the Reset button to the right of the Cache Used statistic. There’s no harm—apart from a little wasted bandwidth—in doing this since the Caching service will download necessary updates again automatically.

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.

Figure 1: Configure the Caching service by choosing a destination and setting a cache size.

Figure 1: Configure the Caching service by choosing a destination and setting a cache size.

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!

Note: Because no configuration is necessary for client Macs and iOS devices, when they’re away from your network, they’ll get updates directly from Apple.

Configure the Software Update Service

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).

Figure 2: Run the Software Update service in manual mode to gain full control over which updates are offered to your users.

Figure 2: Run the Software Update service in manual mode to gain full control over which updates are offered to your users.

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.

Moving Service Data

If you need to store Software Update data somewhere other than on the current service data drive, click the name of your server at the top of the sidebar in Server, click the Settings tab, and click the Edit button next to Service Data. Choose a drive with sufficient free space, and wait for the service data to be moved before continuing.

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.

Figure 3: Work with individual updates in the Updates tab.

Figure 3: Work with individual updates in the Updates tab.

Each individual update can have one of four statuses:

  • Available: If “Automatically download new updates” isn’t selected, this status means that the update is available to download, but isn’t currently stored locally.
  • Waiting: While an update is downloading, the status changes to Waiting. You’re more likely to see it for large updates.
  • Enabled: When an update’s status is Enabled, it has been downloaded and is available for users to install.
  • Disabled: An update with the Disabled status remains local, but isn’t available for users to install.

To change these statuses and control the storage of each individual update, you have the following options, available from the gear menu at the bottom of the screen and from the pop-up menu to the right of each item.

  • Download: For updates whose status is Available, you can download them manually; they remain disabled after downloading and must be enabled separately.
  • Download and Enable: This option downloads and enables available updates in one action.
  • Enable: Updates that have been downloaded and are disabled can be made available to users with this command.
  • Disable: If you want to prevent users from accessing an update that was previously enabled, choose Disable.
Note: If you chose Automatic mode in the Settings screen instead of Manual mode, Disable is the only option available.

  • Remove: To reclaim the space used by an update, whether it’s enabled or disabled, choose Remove. Needless to say, removing an update disables it as well.
  • View Update: To read the release notes for a selected update, choose View Update (or just press Return). The status and gear menu are replicated in the Update Summary view (Figure 4).
    Figure 4: Learn more about individual updates by selecting them and pressing Return.

    Figure 4: Learn more about individual updates by selecting them and pressing Return.

Tip: You can select multiple updates in the list and choose an option from the gear menu to work on them all at once.

Note: There’s one more item in the gear menu: Check for Updates. When you’re working in Manual mode, if a new update doesn’t appear in the list automatically, choose Check for Updates to force a check.

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.

Point Clients at the Software Update Service

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.

Configure Software Update with a profile

If you haven’t already, run through the steps in Chapter 9, Mobile Device Management, to Enable Profile Manager and Enroll Devices. Then, follow the instructions in Manage Devices to edit the settings for the appropriate group, after which you can follow these steps, clicking OK and then Save to save your changes.

  1. Scroll to the bottom of the list of settings, and click Custom Settings.
  2. In the Configure Custom Settings screen, click Configure.
  3. In the Preference Domain field, enter com.apple.SoftwareUpdate.
  4. Click Add Item to add a key/value pair.
  5. In the Key field, change New Item to CatalogURL.
  6. Leave the Type pop-up menu set to String.
  7. In the Value field, enter the URL of your server, on port 8080 and with index.sucatalog appended, as in http://mavserver.pretendco.lan:8080/index.sucatalog (Figure 5).
    Figure 5: Use a custom setting to point Macs at your Software Update server using a profile.

    Figure 5: Use a custom setting to point Macs at your Software Update server using a profile.

Note: The 8080 port is essential; Software Update runs on that port.

Configure Software Update via the Command Line

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: About | Chapter 1 | Chapter 2 | Chapter 3 | Chapter 4 | Chapter 5 | Chapter 6 | Chapter 7 | Chapter 8 | Chapter 9 | Chapter 10 | Chapter 11 | Chapter 12 | Chapter 13 | Chapter 14

Subscribe today so you don’t miss any TidBITS articles!

Every week you’ll get tech tips, in-depth reviews, and insightful news analysis for discerning Apple users. For over 33 years, we’ve published professional, member-supported tech journalism that makes you smarter.

Registration confirmation will be emailed to you.

This site is protected by reCAPTCHA. The Google Privacy Policy and Terms of Service apply.

Comments About Take Control of OS X Server, Chapter 12: Software Updates

Start the discussion in the TidBITS Discourse forum