I can’t believe I never wrote this up, but I’ve been using the Software Update Server included with Mac OS X Leopard Server since I upgraded the servers at my old job. If your network — or Apple’s servers — are ever slow to get updates, having your own centralized SU Server can make a world of difference. But it’s most useful when you have a bunch of Macs you need to update all at once. Try doing ten or so over the Internet at the same time. You’ll get errors and failures, and you’ll kill your network pretty quickly as all those updates come in at once. But updating a lab full of Macs from your own dedicated Software Update Server will not only not fail, it’ll actually be quite fast since your using only internal bandwidth, of which you should have plenty. Setting one of these up is pretty easy, but there are a couple gotchas I always have to remember. So here we go.
- Activate the service in Server Admin.
Activate Software Update Service
- Configure the service. I like to configure the SU Server to “Automatically copy all new updates from Apple.” This is the easiest, and I like things easy. But otherwise I use the default settings.
Configure General Options
- Start the service and list the updates. And here’s one of the gotchas: when you first start the service there is no indication that anything is happening. There is no progress bar and nothing will appear in the list of updates. But in fact the SU Server is downloading all the updates (several Gigs) in the background. The easiest way to prove that this is actually happening is to run the df command, then run it again. You should see your root drive getting gradually fuller as the server downloads the updates. This first download will take a long time. I like to let it go overnight.
Updates
- When you return the next morning, the list should be populated with all the available updates, as seen above. (Also, you see about 10-15 GBs of data in the Software Update Server’s data store, which is here: /usr/share/swupd/html/content/downloads/.) The last step then — and the thing I often forget — is to tell your client Macs where to get their Software Updates. To do this you’ll need a computer list in Workgroup Manager. Add any computers you want to use your SU Server to the list. Then go to the Preferences pane for the group and select Software Update. Set the URL for the SU Server to: http://server.domain.com:8088/index.sucatalog
Create Computer Group
- After saving that configuration, logging out and logging back in should be all you need to do on your clients to pick up the server. After doing so, run Software Update and you’ll see the name of your SU Server in the menubar of the interface. This confirms you’re successfully getting updates from the server.
It Works!
Congrats! You’re not a total moron. Enjoy!
UPDATE:
Reader Dennis points out in the comments that individual clients can be configured to look to the SUServer for updates without being part of a WGM group or managed by the server at all. This is done by modifying a preference on the client system, which you would do thusly:
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL "http://systemsboy.su.server.com:8088/"That command can, of course, be sent en masses using Apple Remote Desktop’s “Send Unix Command” directive.
And, if you want to revert to the standard method of checking for updates, looking at Apple’s servers, delete the “CatalogURL” entry in the preference file by running:
sudo defaults delete /Library/Preferences/com.apple.SoftwareUpdate CatalogURLThanks for the tip, Dennis!
18 Comments
another way to set the clients up is from the command line by using the defaults command. Very easily done with the ARD “Send Unix Command” option.
defaults write com.apple.SoftwareUpdate CatalogURL http://your.server.url:8080
Dennis,
My understanding is that this approach only works in Mac OS 10.4. I have tried it in 10.5 and it does not appear to do anything. Please let me know if I am mistaken.
Thanks.
-systemsboy
Oops..Time to update my documentation! This should work with 10.5.
defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL “http://your.server.url:8088/index.sucatalog”
Ah! That did it. I’ll add this to the post, as well as how to remove the preference.
Thanks!
-systemsboy
if you run your own internal DNS, you can point everyone to your local software update server when they are really looking for Apple’s. It works a treat and no changes need to be made on the client machine.
http://www.macosxhints.com/article.php?story=20071009082248452&query=software%2Bupdate%2Bserver
Right, that is a clever trick. But managing the client machine from the OD/SU Server, and there telling it to get updates from said server, also requires no changes on the client machine. It’s my preferred method as it’s A) the Apple-sanctioned way; and B) is a lot easier than mucking around with the DNS records, which, honestly, seems like a bit of a kludge when there’s already a proper and supported method.
I’m not sure what the advantage of the DNS method is.
But still, good to know!
-systemsboy
The DNS method is great for repair shops where machines come and go all the time, and never become part of the network.
Ah, yes. That would be advantageous.
-systemsboy
Could someone describe how to change a client’s catalog URL back to the default?
mjg,
That information is listed in the article. To reiterate, in Terminal run the command:
sudo defaults delete /Library/Preferences/com.apple.SoftwareUpdate CatalogURL
That should be all that’s needed, but if the change isn’t instantaneous, try a reboot.
-systemsboy
THe DNS method also works well if your Mac clients are not always in the office. Some users may want to be able to download updates while at home and not connected to the VPN. Of course now you’ve lost ability to manage and restrict updates.
I thing the best solution when not using MCX (for example in a reapir shop), is to create a little app with applescript and use it to point the clients to the internal SUS and then pointing them back to the Apple’s defaults.
Kostas
For me I have a probleme with the httpd server. In fact all services are not located at the default path, but in a special disk. /Volumes/Datas/ServiceData/SoftwareUpdates/html …
When the client try to connect to our server I can see on the SWUPD log this :
Attempt to serve directory: /Volumes/Datas/ServiceData/SoftwareUpdate/html/
[error] [client 192.168.10.26] File does not exist: /Volumes/Datas/ServiceData/SoftwareUpdate/html/favicon.ico, referer: http://xxx.XXX.com:8088/
[error] [client 192.168.10.26] Symbolic link not allowed or link target not accessible: /Volumes/Datas/ServiceData/SoftwareUpdate/html/index.sucatalog
But when I look at these, all is OK
/etc/swupd/swupd.conf seems ok, index.sucatalog is a symlinks and it points to a real dir. All access are set ok
Any ideas ?
Hi Guys
Hoping someone can help. I have managed to copy the content of the swupd folder from a friend (avoiding the 80 gig download). How do I go about syncing the software update server to recognise the copied content? I have run repair disk permissions to ensure I have read/write access to the files. Any suggestions welcomed.
Thanks Brad
Sorry forgot to mention running LION server 10.7.2
Well, I really couldn’t say for certain. I would think that simply placing the updates in the swupdate folder would do the trick, but perhaps the server needs something a bit more definitive.
Sorry I can’t be more helpful; I’m not really doing Mac OS X Server much lately.
Perhaps another reader might know?
-systemsboy
Is there a way to have all your clients install the said updates from your internal SU Server without any interaction? Similar to Windows SUS server. This would be a better approch then logging into each machine and checking for updates. I am a MAC newbie and trying to make things easier for a small team with a lot of macs.
Thanks
I don’t believe there’s a way to do truly unattended, scheduled updates on the Mac. This is likely a safeguard as some updates require at least minimal interaction (like reboots and such). I believe, however, that Apple Remote Desktop can provide some relief, and should let you at least batch update systems remotely, possibly more. It’s been a while since I’ve used ARD, but I seem to remember it was extremely helpful for software updates:
http://www.apple.com/remotedesktop/
-systemsboy