Update – Jan 2013 – this is quickly going to become obsolete, with Apple’s release of Server.app version 2.2 for Mountain Lion, this enables a transparent caching service. If you network clients are running Mountain Lion (maybe Lion as well, I don’t know) and you are on a proper private LAN address (ie, an RFC 1918 address range) then you’re better off using the Caching service as you just have to turn it on and it magically works. You don’t need to prime your software update repository with over 100GB of downloaded updates and it caches App Store downloads as well.
[this is now working – see the update below]
[this is either not working at present, or will not continue to work in the future – see the second update below]
This post is a condensed version of the information gleaned from a Mac OS X Hints article and my own research. It’s not quite working yet so still needs some more tweaking, but is almost there.
When the procedure below is followed, your Mac OS X Server will transparently deliver Apple Software Updates to networked clients with no additional configuration required on the individual client machines – this is great if you’re, for example, building client machines and want to get updates from your own server, not down over the Internet each time.
Where it all falls down is that in a single-server environment (more technically, if you only have one internal DNS server) then the Software Update server will refer to itself when it should be checking Apple for new software updates to cache. I’m pretty close to having a workaround for this but it’s not quite there.
Set up Mac OS X Server
I’m going to have to assume you have a working Mac OS X Server – setting one up from scratch is outside the scope of this article.
Turn on Software Update in Mac OS X Server
In Server Admin, enable Software Update. Leave most of the settings on their default. Tell Software Update to copy all updates from Apple. If you want a maintenance-free solution, also tick the Automatically enable copied updates checkbox. You may also tell it to not Delete outdated software updates if you want to keep copies of old software updates. This can be handy in situations where, for example, Apple push out a new update that breaks things and you then have the ability to (kind-of) roll back.
Ensure that Software Update has performed a full sync
This is going to take some time and download quite a decent amount of data – 30GB or more. You can watch the log in Server Admin > Software Update to check it’s progress. When it’s completed it’s initial sync, you can proceed.
Create a new zone in DNS
As Mac OS X Server doesn’t include a DNS Masquerade service that allows you to just override individual hostnames in a DNS zone, we need to make a new zone. We don’t want to make an authoritative zone for the whole of apple.com so we make a zone for just the machine record that we want to impersonate.
Create a new zone in Server Admin > DNS called swscan.apple.com. and don’t forget the full stop at the end of the name to fully qualify it. In this zone, create one machine record, also called swscan.apple.com. (remember the full stop at the end here too) and set it’s IP address to be that of your Mac OS X Server.
Set up a virtual host in Apache
If you’ve got multiple web sites on your OS X Server, you can create a virtual host for the Software Update service. Set it’s host name to swscan.apple.com and ensure it’s listening on the standard port 80. Untick all the checkboxes in the Options tab.
On the Aliases tab, delete the redirects that are pre-configured. Add the redirects listed below.
If you’re not running any web sites yet on your OS X machine, you can leave the configuration for the default site as it is and just add the following redirects. Make sure they are configured as redirects, not aliases.
In the following examples, replace swupd.automatica.internal with the hostname of your OS X Server.
- Pattern: /content/catalogs/index-1.sucatalog
- Path: http://swupd.automatica.internal:8088/index.sucatalog
- Pattern: /content/catalogs/others/index-leopard.merged-1.sucatalog
- Path: http://swupd.automatica.internal:8088/index-leopard.merged-1.sucatalog
- Pattern: /content/catalogs/others/index-leopard-snowleopard.merged-1.sucatalog
- Path: http://swupd.automatica.internal:8088/index-leopard-snowleopard.merged-1.sucatalog
- Pattern: /content/meta/mirror-config-1.plist
- Path: http://220.127.116.11/content/meta/mirror-config-1.plist
- Pattern: /content/catalogs/index.sucatalog
- Path: http://18.104.22.168/content/catalogs/index.sucatalog
- Pattern: /content/catalogs/others/index-windows-1.sucatalog
- Path: http://22.214.171.124/content/catalogs/others/index-windows-1.sucatalog
The first three entries are to perform the redirection for the Software Update client software. The last three redirects are supposed to do the redirections so that swupd_syncd can still get it’s updates from Apple, but it’s not working.
*** UPDATE ***
Tweak the hosts file on the OS X Server
The final piece of the puzzle, thanks to my good mate Charlie at eWhizz, is to tweak the hosts file on the server. What we do is put an entry for swscan.apple.com in /etc/hosts on the OS X Server machine so that it can see the real IP address of Apple’s software update server. Bind will not look in the hosts file for it’s name resolution, so all machines on the network that are using the server for DNS will see the internal IP address in DNS whereas the server will query the hosts file before it does a DNS lookup and it will still get the real IP for Apple’s server.
Add the following lines to the end of /etc/hosts
# this is so that the transparent Software Update server works
# but swupd_syncd can get updates from Apple.
Run Software Update on a client machine
In theory, the above procedure should all work. In practice, the client machines seem to get their updates from the internal Software Update server just fine but the internal Software Update server has issues getting the real updates from Apple.
If you want to put this in place, then what you’ll need to do is whenever you want to sync with Apple for new updates, disable the DNS entry for swscan.apple.com and let the server do it’s update. Then, re-enable the DNS entry and you’re good to go.
*** UPDATE 2 ***
Apple have apparently Software Update in Mountain Lion to use https instead of http to retrieve the updates. This means that it breaks any upstream caching of updates you might have enjoyed (for instance with Squid) and it also means that DNS trickery like this then becomes a lot harder. If you’re willing to set up a self-signed certificate authority on your OS X Server and push out the root cert as trusted to all your workstations, then you might be able to get around it, but this is a really bad hack and ultimately it isn’t then 100% transparent.
I’m going to be using managed software updates via something like Munki from now on and am not going to be putting any more effort into getting this working on Mountain Lion as it’s a dead-end.