NetSUS off-network failover to Apple?

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

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!

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.

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).

?

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.

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.

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.

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.

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

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.

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...

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.

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.

<Fat thumbs accidentally posted>

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.

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?

@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!

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.

@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?

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.

stevewood: You are not wrong.

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.

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.

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.

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.