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.
The Procedure
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://17.250.248.95/content/meta/mirror-config-1.plist
- Pattern: /content/catalogs/index.sucatalog
- Path: http://17.250.248.95/content/catalogs/index.sucatalog
- Pattern: /content/catalogs/others/index-windows-1.sucatalog
- Path: http://17.250.248.95/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.
17.250.248.95 swscan.apple.com
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.
Hello my xserve is ignoring the /etc/hosts file. Not sure why but it is. All my clients get their updates fine from the server but the server keeps looking to itself? And I can no longer get updates on the server from Apple.
Any help or direction would be awesome.
It’s difficult to say what’s going on – using /etc/hosts is a bit of a hack and is only done as a last resort here.
Some tools on OS X will ignore it and some will use it so it can be tricky to tell if it’s actually working or not.
Reboot everything, then double-check the details provided – this is exactly what I’ve done on 10.6 Snow Leopard server and it works for me.
dscacheutil -flushcache is handy to use, it flushes OS X’s dns cache.
I just edited my hosts file on Lion Server, and the real IP for Apple’s Software Update server was already there. My particular server was an upgrade from Snow Leopard, and while it is possible that the admin before me made the same change, when I came in, Software Update Server was not running and there was no evidence that it ever had.
I’m curious to find out from someone with a clean or factory Lion Server install if the entry is there or not. If they have one in the local store (I doubt it) I’ll try it next time I’m in.
That’s strange – I’m sure it would have had to be placed there manually at some stage.
I’ve checked on a recently built Mac mini Server with Lion Server and there were just the default localhost type entries in /etc/hosts
Apple recommend not using the hosts file for name resolution as not everything on Mac OS X will refer to the hosts file, so I can’t see them putting the software update servers into the hosts file.
do you by chance know the steps to get this to work in Lion Server? Since server admin does not have the redirect feature I don’t know what files to edit.
Hi Andy,
I’m not sure – I’m planning to upgrade my server to Lion at some stage over the Christmas break, but haven’t done so yet. The Server Admin in Lion is brain-dead compared to the Snow Leopard version, and in particular the web services admin has been gimped pretty severely. At a guess, I’d say you’ll need to edit apache .conf files by hand (and there are plenty of good guides on this out there on the Internet).
I’ll post an update to this story when I’ve got it all working on Lion.
will test this on lion 10.7.x server. but…..we useing a proxy server at our school.
maybe the host entry dosen´t work with this config?
This is going to work less and less in the future as Apple move to delivering software updates via HTTPS.
If you want to play around with creating a self-signed certificate authority and installing the root trust certificate on all your Macs, then with some more tweaking it might work – although I’d not count on it.
Time to look for another solution – I’m going to use Munki internally to do this task…
Can you add at the top of the post that this is obsolete?