HOWTO: Create a transparent local Apple software update server
posted by Nick Bonadies 
on May 29, 2009 at 09:02 AM
filed under: Software, Developers, Barbarian Labs, and The Networks and the Internet
Nick Bonadies
IT Specialist : Boston
topics: Barbarian Labs, Games, PHP, Rock and Roll, and Internet Culture
filed under: Software, Developers, Barbarian Labs, and The Networks and the Internet
If the benefit isn’t clearly obvious from the title, let me explain why you would want to set up something like this in your office network. Bandwidth is expensive. Especially if you need a bunch of it and require a solid SLA. Apple updates can be HUGE; the most recent Mac OS 10.5.7 combo update clocked in at a whopping 729MB. Now imagine you have an office of 20 people all using the same internet connection to download the same package from the same place. Madness right?
They’ve just saturated your inbound link and business is grinding to a halt! If you’re in this position you’re already too late, and you’ll have to make up for it using some fancy QoS rules or blocking traffic from the Apple software update servers all together. Don’t live in fear of the next Mac OS update because now you have time to set up your very own Apple software update server!
This guide assumes you have an Apple Leopard Server; you’ll need Leopard Server to configure the Software Update Service (SUS). You’ll also need a decent router, firewall, or internal DNS server.
The major goal here is to make it so our SUS is completely transparent to the client machines on our network; we want them to think they are talking straight up with Apple. This is key because we don’t want to change our client configurations at all. Why? well because if we changed the way our client machines update their computers, the system would likely breakdown or become too resource expensive to operate (when clients were out of the office they would be looking into the office for updates). We want our client machines to update no matter where they are, but if they happen to be in an office we want them to download locally from us because it is relatively cheap in regard to network resources.
We need to first figure out how we’re going to point our clients transparently at our SUS for updates. I can think of two ways to do this, with some internal DNS changes or using DNAT.
I’ll quickly cover both.
DNS is probably the simplest route. In your internal DNS you would set swquery.apple.com, swcdn.apple.com, and swscan.apple.com as CNAMEs for the server running SUS. If you want go to the NAT route you would simply DNAT those hosts from clients in your internal network to your server running SUS. If you are running a DMZ you want to make sure the servers in your DMZ are NOT looking at your SUS for updates.
Now we’ve got all our update traffic pointed square at our SUS lets configure it! In server admin, enable Software Update and Web from the settings tab. After both are enabled click on Software Update in the list of available services. Within the service, click the settings tab. You should see a place to set a custom port, I left it as the default 8088. You’ll also notice some other configuration options, but I won’t go into that here RTFM for that.
Now that our SUS is configured and we know what port it will be running on click the Web service in the list of available services. In the Sites tab click on your default site. The window pane below will then activate and you’ll have even more tabs to choose from, click the Aliases tab. What we need to do here is tell our web server to redirect all traffic looking for Apple updates to the correct place. Remember how we wanted to avoid client configuration and keep all this transparent? Click the plus sign under the box for URL Aliases and Redirects. The type you’re creating is a straight up redirect. For pattern input: /content/catalogs/others/index-leopard.merged-1.sucatalog (this assumes all your clients are running Leopard) and the path you want to input would look something like: http://your.server.com:8088/content/catalogs/index.sucatalog.apple where your.server.com is the DNS name for your server.
You may be thinking that this redirect doesn’t look awesome, and you’d be right. Its not awesome and it could break with a future Mac OS update. But luckily it doesn’t matter if it breaks! Clients will silently fail to check for updates until we fix it.
Finally, fire up the Web and Software Update services we just configured and run Software Update on a client machine. If it doesn’t complain you’ve probably succeeded! Good job, go grab a beer or something. If you just can’t believe it was that easy, fire up Safari and try this url if you’ve done a good job it should get immediately redirected to your SUS and you should see an awesome PLIST file full of updates! Delicious.
Thanks to Ian
!
Ian Westcott
IT Manager : New York
topics: Mobile, Metrics and Analytics, Art, Lunch, and Snacks and Beverages
UPDATE:
We ran into a little issue with this, if you check your apache logs you’ll probably find a lot of errors similar to this: “File does not exist: /Library/WebServer/Documents/content.” To fix this problem we’ll add a little symlink from our content store in SUS to the Documents folder in our webserver, so do “sudo ln -s /usr/share/swupd/html/content /Library/WebServer/Documents/content”
We ran into a little issue with this, if you check your apache logs you’ll probably find a lot of errors similar to this: “File does not exist: /Library/WebServer/Documents/content.” To fix this problem we’ll add a little symlink from our content store in SUS to the Documents folder in our webserver, so do “sudo ln -s /usr/share/swupd/html/content /Library/WebServer/Documents/content”
You’ll probably also see some errors like: “File does not exist: /Library/WebServer/Documents/WebObjects/SoftwareUpdatesStats.” Lets fix this similarly by making a simlink to the correct resource on our SUS like: “sudo ln -s /usr/share/swupd/cgi-bin/SoftwareUpdateServerStats /Library/WebServer/Documents/WebObjects/SoftwareUpdatesStats”
And thats it!
photo by joyosity
adapted from this post
8 comments
The web redirect configuration here assumes all clients as running leopard, correct? What if we had some Tiger clients on our network, like some emacs. Any ways of doing an 'additional' redirect just for those tiger clients and what would that configuration be?
*Even if a new mac update breaks this web redirect, I am hoping we would still be able to use the same DNS route for SUS?
And thanks for the very helpful post!
This at least shuts up Snow Leopard updates... however, I don't know if it is downloading SL updates (I'll let you know after 10.6..1). The reason I thing Leopard server isn't downloading SL updates is I didn't get an update for the 10.6 server admin tools... had to download them manually. (Needed the new ones on SL to make a NetInstall of the SL DVD, even the server is 10.5 Server)
Without the redirect, it doesn't fail silently... it says it could not find "/content/catalogs/others/index-leopard-snowleopard.merged-1.sucatalog" which is extremely handy from an admin perspective, but rather cryptic to users who think this stuff just works.
Cheers
William
The issue appears to be that the redirect isn't working, but I'm not sure what else I might need to do to get it up and running properly.
Any ideas would be much appreciated.
Thanks!
1. Set up Mac OS X Server, and enable the Software Update, Web, and DNS services.
2. In the DNS service, add a master zone named "swscan.apple.com." (with the trailing dot!)
3. Create an A (machine) record that maps "swscan.apple.com." (with the trailing dot!) to the IP of your Mac OS X Server.
4. Create two CNAME (alias) records that point "swcdn.apple.com." and "swquery.apple.com." to "swscan.apple.com." (with the trailing dots!)
5. In a terminal window, run the following script to create all the necessary directories and symlinks:
# Create required directory for 10.5.x/10.6.x catalogs
sudo mkdir /usr/share/swupd/html/content/catalogs/others/ # Add symlink for 10.6.x updates
sudo ln -s /usr/share/swupd/html/content/catalogs/index.sucatalog /usr/share/swupd/html/content/catalogs/others/index-leopard-snowleopard.merged-1.sucatalog # Add symlink for 10.5.x updates
sudo ln -s /usr/share/swupd/html/content/catalogs/index.sucatalog /usr/share/swupd/html/content/catalogs/others/index-leopard.merged-1.sucatalog # Add symlink for 10.4.x updates
sudo ln -s /usr/share/swupd/html/content/catalogs/index.sucatalog /usr/share/swupd/html/content/catalogs/index-1.sucatalog # Add swupd symlink to default webserver directory
sudo ln -s /usr/share/swupd/html/content /Library/WebServer/Documents/content # Add symlink for stats engine
sudo ln -s /usr/share/swupd/cgi-bin/SoftwareUpdateServerStats /Library/WebServer/Documents/WebObjects/SoftwareUpdatesStats