NetSUS off-network failover to Apple?

andyinindy
Contributor II

At a recent CCA training session, it was mentioned that the software update catalog from the JAMF NetSUS appliance allows off-network users to retrieve approved updates from Apple. This would be fantastic for us, as our faculty (who will soon leave for the summer) are all set to use our internal SUS, which isn't available outside our firewall.

Can anyone that uses the NetSUS appliance confirm that this it allows for graceful failover to Apple's software update servers?

Thanks!

-Andy

33 REPLIES 33

rockpapergoat
Contributor III

to the best of my knowledge, it doesn't work that way.

if you point the CatalogURL on your clients to your internal server, you'll need to manage that via mcx or other means to ensure the clients can still check for updates off the lan.

for documentation of how reposado works, check here:

https://github.com/wdas/reposado

andyinindy
Contributor II

Bummer. I was hoping that this would be something that was part of the default capabilities of Reposado. As it stands now, I built a policy that sets the SUS to apple.com if the network range is anything except our campus IP range. Hopefully this will work!

stevewood
Honored Contributor II
Honored Contributor II

I know a trick others have mentioned here before is to spoof the apple.com update servers DNS address in your DNS server.

So if you have control of your internal DNS server, setting "update.apple.com" (I do not recall off the top of my head what the Apple update server address is) in your internal DNS server to point at your internal SUS server.

Then when users are off network, they would resolve the Apple server using a different DNS server that had the right info. Make sense? Not sure how to do it, but I know it can be done.

jarednichols
Honored Contributor

Andy-
Perhaps what was meant is that while you can be the gate for your clients (they look to you for the catalog) the updates themselves can come from Apple (instead of hosting them on the NetSUS appliance).

?

daworley
Contributor II

What you might be thinking of is scoping the Managed Preference Profile in the JSS. This has similar logic to a deployment policy.

By defining the MCX Profile to a particular subnet, you can enforce execution of a particular setting like Software Update Servers based on subnets or what have you. This way, in theory, when your users are in the office on the company network they will pull updates from the local SUS server, but when not on the company network, it should revert back to Apple's servers.

This will take a bit of work to get all of your company's subnets into the JSS, and hopefully your home users do not coincidentally have the same IP range at home. Also, lots and lots of testing.

mm2270
Legendary Contributor III

If I'm not mistaken though, settings like a SUS will not revert back to the defaults when a Mac is off a companies network, even if scoped by Network Segment. Since MCX settings are applied to the local domain, they remain in place when disconnected. If I am mistaken in my thinking and experience here, I would love to be corrected.
But if I'm right, you'd need an offline policy applied to the systems that does the SUS reversion, or just runs a 'jamf removeSWUSettings' command. That will take care of pointing the clients back at Apple's servers.

rockpapergoat
Contributor III

the two different methods i've used before are:

  1. redirect apple's update servers in local dns on the lan, so you don't need to manage the client side. if you want to restrict/approve updates, that will work on the lan but not outside.

  2. use munki and define a local sus catalog in its prefs, leaving the system sus prefs unmanaged, but disable automatic checks. this has the advantage of doing what you want while on the lan while still allowing users to run updates (from apple) when away.

it sounds like you misunderstood the "graceful failover bit," as it's not part of reposado. maybe you were thinking of another casper feature, not reposado.

jafuller
Contributor

Can Reposado manage the "approved" updates and then point to apple to DL them? Then the client just has to be told what is OK to DL and what is not OK by Reposado.

It would be ideal for off-network updates but still maintaining compliance with current supported updates.

rockpapergoat
Contributor III

i don't think reposado does that, though greg can chime in here to clarify.

the server side preferences are documented here:

https://github.com/wdas/reposado/blob/master/docs/reposado_preferences.txt

jarednichols
Honored Contributor

Reposado can either host the updates or not. If it's not hosting the updates, it's just the "gatekeeper" and clients still go out to Apple for the update bits themselves.

andyinindy
Contributor II

FYI, the policy I created to switch the SUS to Apple for off-campus users works. However, users are no longer restricted to our list of approved updates, which is not good. Looks like I will need to poke a hole in the firewall for our internal SUS...

gregneagle
Valued Contributor

If you wanted your clients to have software update catalogs that you control, but always d/l the actual updates themselves from Apple, you could set up Reposado to manage catalogs only but not replicate updates.

You'd then need a script that periodically copied the appropriate sucatalog from the Reposado server to the client.

Finally, you'd point the client to the local copy of the sucatalog:

file:///path/to/some.sucatalog

With this approach the client would always use the sucatalog you manage, whether or not the client was on your network.

bentoms
Release Candidate Programs Tester

My JSS is clustered so my clients off-wan can contact my JSS.

The server that is clustered & externally accessible also runs ASUS as a replica from my internal master.

I then have an network segment for all external IP's that points the clients to that server for SUS when off-WAN.

Works well enough for me.

bentoms
Release Candidate Programs Tester

<Fat thumbs accidentally posted>

mm2270
Legendary Contributor III
If you wanted your clients to have software update catalogs that you control, but always d/l the actual updates themselves from Apple, you could set up Reposado to manage catalogs only but not replicate updates. You'd then need a script that periodically copied the appropriate sucatalog from the Reposado server to the client. Finally, you'd point the client to the local copy of the sucatalog: file:///path/to/some.sucatalog With this approach the client would always use the sucatalog you manage, whether or not the client was on your network.

This sounds quite interesting. I wasn't aware Reposado had that ability. Is this also something that can be done within the NetSUS appliance? If so, we may actually explore this option.
I assume though, that with this setup you lose the ability to control network bandwidth, since I'm guessing any Mac that is also on your network will be pulling the updates down from Apple anyway. With things like the recent 10.7.4 update, which measured in between 700 MBs and 1.5 GBs depending on which one you got directed to, that's going to mean a whole lot of network usage. Still, it warrants looking at it.
I suppose an offline policy may be able to update the CatalogURL for a Mac not on the network to point to the local sucatalog. Hmmm.

andyinindy
Contributor II
you could set up Reposado to manage catalogs only but not replicate updates

OK, so how does one accomplish this? I am using the JAMF appliance, and I deselected the checkbox for "Store software updates on this SUS", but how do I then configure & populate the branches?

Theoretically I could use a combined approach, and point on-campus users to a reposado instance that replicates updates (thus saving bandwidth), and set up a policy to point off-campus users to a local catalog file (assuming I can figure out how to build one). Does this make sense?

mm2270
Legendary Contributor III

@Andy, I was thinking the same thing, a two pronged approach. We already use several Apple SUS servers to point our Macs internally to those, but when off the network, these users cannot run Software Update. Exposing our SUS's to the outside world is not an option, and not everyone gets on VPN all the time. If I could somehow make use of a Reposado instance to copy the catalog url down to them and then use an offline policy that directs them to that when not on the network, that would be pretty sweet.
All theoretical of course, but it sounds good!

gregneagle
Valued Contributor
OK, so how does one accomplish this? I am using the JAMF appliance, and I deselected the checkbox for "Store software updates on this SUS", but how do I then configure & populate the branches?

I don't use NetSUS, but I don't think it's any different to configure & populate the branches whether or not you locally replicate the updates. If you are using the reposado command-line tools there's no difference.

Theoretically I could use a combined approach, and point on-campus users to a reposado instance that replicates updates (thus saving bandwidth), and set up a policy to point off-campus users to a local catalog file (assuming I can figure out how to build one).

You don't have to build one. The software update server has done that for you.

You want a local copy of Apple's sucatalog for Snow Leopard?

curl http://swscan.apple.com/content/catalogs/others/index-leopard-snowleopard.merged-1.sucatalog > /Users/Shared/apple.sucatalog

Done.

Substitute a different URL for your NetSUS's catalog.

mm2270
Legendary Contributor III

@Greg- what you're saying with the curl command to download a local copy makes perfect sense to me. However, the part that seems to elude me with this is how I would get the Mac clients to look at the local copy of the catalog for "approved" updates, but actually pull the updates themselves from Apple's servers. In theory, if I use either MCX or just a defaults write command to set the CatalogURL, am I not telling the client to use that URL for both the catalog AND for where to grab the updates from? Is there some additional syntax we need to split this up, a) look at the sucatalog in /Users/Shared/ but b) pull the updates from http://swscan.apple.com/blah-blah?

stevewood
Honored Contributor II
Honored Contributor II

I think what Greg is suggesting is that you setup your Reposado, or JAMF NetSUS, to not download the updates, but simply manage (create branches) what downloads are available to your clients. Once you've done that copy the appropriate .sucatalog file to your client computers and point the Software Update utility at that .sucatalog file on the local machine. The client computers will then use that as the catalog, but download the files from Apple.

As an example, I copied my .sucatalog file from my NetSUS device and placed it in /Users/Shared for testing. I then used my browser to verify the file was there with this URL:

file:///users/Shared/index-lion-snowleopard-leopard.merged-1_integer.sucatalog

I saw the proper output of the catalog in the browser. The next step would be to tell SoftwareUpdate to use that catalog. I'd do that with the following:

defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL file:///users/Shared/index-lion-snowleopard-leopard.merged-1_integer.sucatalog

My machine would now use the local copy of the catalog, but pull the actual updates down from Apple. Pretty brilliant if you ask me.

Greg correct me if I'm wrong.

gregneagle
Valued Contributor

stevewood: You are not wrong.

gregneagle
Valued Contributor

Do be aware that if you do this, the responsibility is now yours to keep the local copy of the sucatalog updated. IOW, you'll need to periodically copy this file from your software update server to the local client.

A script that uses curl to do so should work.

mm2270
Legendary Contributor III

OK, makes sense. I guess the part I was wondering was if anything other than using the defaults write command was needed to make sure the clients actually pulled the updates from Apple. Form what you're saying, it doesn't appear so.
So, in essence, this functionality is only available when using either Reposado, or perhaps the NetSUS appliance. That's perfectly fine, as I'm sure we'd have no issues spinning up a VM instance to stand up a NetSUS (if I can indeed use that).

This would be a massive win for us, since currently, we have a requirement to control the update process, well, at least via Software Update.app. Clients are all local admins so they can still get standalone updaters from apple.com if they really wanted to. But with this restriction in place, anyone working from home is cut off from installing any software updates. Not very end user friendly to say the least. The above would seem to be a really nice solution to this problem.

I'll have to give this a go.

gregneagle
Valued Contributor
I guess the part I was wondering was if anything other than using the defaults write command was needed to make sure the clients actually pulled the updates from Apple.

Where the updates are pulled from is controlled by the contents of the sucatalog -- if it has URLs pointing to your internal server, that's where updates will be pulled from. If it has URLs pointing to Apple's servers, updates will be pulled from Apple's servers.

mm2270
Legendary Contributor III

Well, I almost have this working. I have a NetSUS instance up (easy) and updates enabled/disabled (also easy) I got the branch created, which I originally misread on how to do that, but its working now and I can point any Mac to it with the OS specific URL and Software Update.app will correctly report any available updates for those Macs.
What I cannot get working properly is pointing a client to the local copy placed in /Users/Shared. I used basically the exact same syntax that Steve posted in pointing a client to the local file after I copied it down with curl-

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL file:///users/Shared/index-lion-snowleopard-leopard.merged-1_integer.sucatalog

Yet, the results I get when I run Software Update is that, it checks the catalog (doesn't error) but then the Software Update window vanishes. The app is still running; Its in my dock and I can select the menus, but nothing is displayed. Quitting it and retrying gets me the same odd results.
As a next step I tried from the command line- 'sudo softwareupdate -l' and it reports "No new software available" I also tried doing:

sudo softwareupdate -l --CatalogURL file:///users/Shared/index-lion-snowleopard-leopard.merged-1.sucatalog

for kicks and get the same "No new software available" ?? I'm not sure what I'm doing wrong here but feel I'm close.

Any pointers from the community would be greatly appreciated.

rockpapergoat
Contributor III

capitalize the "u" in "users," maybe…

mm2270
Legendary Contributor III

Nate, I thought of that as well and removed the entry and retried the defaults command with a capital U. In fact, I let auto complete take over when entering the path to the file in in the command to be sure I wasn't fat fingering something. Same results though, Software Update opens, scans the catalog, then vanishes, though still running.
I have been testing this on 10.7.4, so I don't know if that makes a difference., Perhaps an older rev of Lion behaves differently, which I can and will test tomorrow. Other than that, not sure what else it could be.

Thanks.

stevewood
Honored Contributor II
Honored Contributor II

Mike can you post the defaults command that you are using? Just want to make sure syntax is correct.

[EDIT]

By that, I mean can you post exactly what you are typing in so we can see the branch information. You can make the server portion generic if you need to.

mm2270
Legendary Contributor III

Sure Steve, I had it in my above post, but here it is again for clarity sake:

Curl command used to download local copy of the catalog-

curl http://ip.add.re.ss/content/catalogs/others/index-lion-snowleopard-leopard.merged-1_testing.sucatalog > /Users/Shared/index-lion-snowleopard-leopard.merged-1_testing.sucatalog

The URL above incidentally is perfectly readable in a browser on my Mac (which is not running the NetSUS), so I can definitely see the catalog file at that address.

Now the defaults command to point my Mac to it-

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL file:///Users/Shared/index-lion-snowleopard-leopard.merged-1_testing.sucatalog

I just tried this all again, just to be doubly sure I have done exactly as I'm outlining here. Waited a few minutes and tried Software Update.app again, and no go. Runs, then vanishes. Pretty strange.

stevewood
Honored Contributor II
Honored Contributor II

The defaults command you had in the previous had the URL I sent in it, which was my branch here, so I just wanted to make sure you weren't making a simple mistake like I would by leaving that in.

I'll do some more testing tomorrow and see what results I get from this.

mm2270
Legendary Contributor III

Thanks, much appreciated. Let me know what you find.

As a last note for today, I just tried all the same on a 10.7.2 MacBook Pro and had the same issue, so older versions of Lion are exhibiting the same behavior for me. I will give this a shot with a 10.6 Mac tomorrow at some point to see if this is an issue with Lion only. It could also be something in our environment, but I can't for the life of me imagine what would cause Software Update to act like that.

gregneagle
Valued Contributor

I can reproduce the issue of the Software Update window going away mid-run. The fix is to specify the CatalogURL in this format:

file://localhost/path/to/local.sucatalog

and not

file:///path/to/local.sucatalog

/usr/sbin/softwareupdate doesn't seem to care, but the Software Update application does.

mm2270
Legendary Contributor III

@Greg- awesome!! Thank you much for the fix. It does indeed work when specified that way. This is great!