NetSUS: Setting branch as root branch

[thegooch49]

Hello, I'm having an issue integrating the NetSUS applicance with our JSS. The appliance is storing updates. I have a single branch, called production. On the SUS, I set it as 'root branch'. On the JSS, I added the server with the FQDN, on port 80. I then created a policy for a test host to run SW updates agains the NetSUS appliance. From the documentation, this should pull updates from my 'production' branch, and not the main repository. It appears that when the policy is executed, it's pulling from the 'main' repo with all updates, and not the 'production' branch (that is set as root branch) as it should. As an example, iTunes 11.02 is not enabled on the production branch. But it was installed when the policy was ran from the JSS.

I know my branch and catalogs are good. When I set my host manually to look at the production branch, I do NOT get iTunes 11.02 listed as an available update. When I set my host manually to look at the main index, I do see iTunes as available. So, the branch looks fine when manually fed into a host (using sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL). When run from the JSS my log from the policy shows:

Setting Software Update Server to http://sus.mycompany.corp:80/index.sucatalog for root...

Question: Since my production branch is set to be the root branch, should this be setting it to http://sus.mycompany.corp:80/index_production.sucatalog ? Or does it still set it as http://sus.mycompany.corp:80/index.sucatalog, and use re-writes to make it hit the branch?

Second Question: What exactly is 'set root branch' doing under the hood? Is it doing Apache re-writes, or something else? I'm wondering if I can look at some of the apache settings to confirm what's going on. Setting a root branch doesn't seem to be anywhere in the reposado documentation, and it appears specific to the implementation of NetSUS.

I currently do not have any managed preferences setting anything, so I'm relying solely on the JSS to set the sever. I understood from the document, that managed preferences are not necessary to use a branch if I set my branch as root (please correct me if I'm wrong).

Thanks for the help!

[JPDyson]

My understanding is that when you use the JAMF NetBoot/SUS Appliance (or indeed, Reposado itself), you don't get the "centralized" catalog URL that you get with a true OS X Software Update Server. So, you have to manually supply the catalog URL via Managed Preferences or Configuration Profiles (setting it under Settings - Servers - Software Update Servers isn't enough). And since each OS version has its own catalog, you have a different MCX/CP for each OS.

[mm2270]

JPDyson is correct. While the NetSUS appliance is great (we have one set up too) the necessary URLs to get clients to properly pull updates down isn't well explained in the included documentation. I'll say the same thing I say to everyone that has run into this, which is to take a look at the documentation on the Reposado pages, as it does a much better job of explaining the proper URLs each client OS needs.

As for how to get your Macs to use those addresses, take your pick - MCX, Config Profiles, scripted with defaults. Any will work, just depends on your preference.

[thegooch49]

Thanks for the replies. I completely understand the different URLs for the different OS versions (and have read the specific documentation from Reposado). From the documentation on the NetSUS, they make it sounds like this is possible without the need for MCX, Profiles, etc.

*Pointing Clients at a SUS Branch
There are several methods for pointing clients at a SUS branch:

Make a branch the root branch and add it to the JSS—You can make a branch the root branch using the Appliance web application. Then, add the root branch to the JSS and use Casper Remote or a policy to point clients at the root branch.*

So it seems that one of the methods is to make the branch the 'root branch', put the server in the JSS, and execute via Policy. Other methods include setting MCX, Policy, or executing a command to set the plist. I'll also mention that I have done the Apache re-writes so that I have a unified URL that will serve the updates to all darwin versions from a single URL. That all works flawlessly (tested by setting with the defaults write on the plist file). The last step is integrating into the JSS (which is where I am at now).

So if the answer is that I need to set this via MCX, Policy, or command, that's the way we will go. But it seems from the documentation that this is not necessary. What else would the 'set as root branch' do if it wasn't for this purpose?

Thanks again for the help.

[Josh_S]

You may have to clear out the SUS settings on the client machine, or image a new machine to test this, after removing an available update from the SUS branch. In my experience, if a computer checks in with the SUS and sees an available update and doesn't do it, the next time the computer checks for updates it will report that it still needs to do that update even if the SUS is no longer advertising it.

This may only be the case if you have "Download newly available updates in the background", in the Software Update System Preference pane, checked on the client. In this case, the client machine has already downloaded the update so it doesn't need the SUS to say that it's available. However, I didn't test extensively to see if this was the case.

[JPDyson · Accepted solution]

Gooch, I agree that the documentation implies you could do what you described. I've just never witnessed it working. When I brought it up in training, I was told to set the catalog URL's with MCX or manually use them in policies.