Let’s say you work in an environment where you’re running reposado. Let’s also say that your environment consists of several locations with relatively slow WAN links between them. Additionally, let’s say that some of your users roam between locations, and before they move, they just put their MacBooks (or Airs or Pros) to sleep instead of shutting down (because who shuts their machine down every time they’re not using their machine?)
In an ideal world, you want to point the machine to the reposado server, but you don’t want the machine to download updates over the slow WAN link, and while you could run a reposado server at each location, but by configuring the machine to look at an onsite reposado server, the machine will likely move to another location before softwareupdate checks for updates.
You’re running munki and have it set to install Apple software updates? Awesome. You could set the appropriate
CatalogURL in your
preflight script, but that means that you have to maintain catalog files on several reposado servers, and who wants to do that? (Ok, you could just clone the master reposado server, including the catalog files to get around that last part.)
But what happens if the user has the ability to install Apple software updates via Software Update from the Apple menu (or by running
softwareupdate itself)? Their machine might have their previous location’s
What do you do?
/Library/Preferences/com.apple.SoftwareUpdate.plist doesn’t allow you to configure a
PkgURL like munki does, everything goes to the server that the catalog file defined by
CatalogURL goes to. But that’s the problem.
The workaround? You set up redirects on the master reposado server based on the client’s IP address. It seems simple, but I haven’t found any references to anyone else doing this. Interested? Great. Let’s set it up.