public facing reposado catalogs from Apple

[Lachlan Stewart]

Hi all,

Is anyone running reposado in this configuration?

I'd like to offer up staged updates to Macs that are off the network, but NOT deliver these updates from my own infrastructure and point them at Apple.

My thoughts are, offer up my branches on a public facing webserver - reposado having a blank local catalog URL so that download URLs point at Apple... but obviously this introduces a problem when update are deprecated. How much a problem when most of my online clients will be checking and caching update locally?

There will be issues during times where I haven't vetted Apple's catalogs, and clients have missed downloading updates when offline. When a client is pointed at a branch with a non-reachable product download, how does softwareupdate behave?

---------------
2x instances:

reposado_apple:
- branching done here
- LocalCatalogURL blank, downloads point to Apple.
- catalogs are public facing

reposado_local:
- AppleCatlalogURLs pointed direct at http://reposado_apple/....catalogs/index..._1_branchname.sucatalog
- LocalCatlogURL: http://reposado_local, reposado wiil download catalogs from reposado_apple, and products from Apple.
- traditional reposado, no problems with deprecated updates.


Nightly sync order
------------------------
reposado_apple
reposado_local

So the fork changes are released next day to on network clients, and the local

How quickly are Apple dropping the deprecated products from the servers?


If this is the completely wrong approach, is anyone else doing anything similar via another config? I am testing it now, and apart from the cavaets mentioned, it might be viable.

Or do I just drop the whole idea and point my "off netwwork" clients direct at Apple and hope they don't botch any patches?

[Gregory Neagle]

On Feb 10, 2015, at 10:42 PM, Lachlan Stewart <la...@rehrehreh.com> wrote:

> Hi all,
>
> Is anyone running reposado in this configuration?
>
> I'd like to offer up staged updates to Macs that are off the network, but NOT deliver these updates from my own infrastructure and point them at Apple.
>
> My thoughts are, offer up my branches on a public facing webserver - reposado having a blank local catalog URL so that download URLs point at Apple... but obviously this introduces a problem when update are deprecated.

Right -- you cannot count on successfully offering deprecated updates in this configuration, as Apple may remove them from both the catalogs and from their download locations.

> How much a problem when most of my online clients will be checking and caching update locally?
>
> There will be issues during times where I haven't vetted Apple's catalogs, and clients have missed downloading updates when offline. When a client is pointed at a branch with a non-reachable product download, how does softwareupdate behave?

Easy enough to test: modify the dist and pkg download URLs in a reposado catalog to point to something non-existent. I'm guessing softwareupdate will complain about the specific update it can't download, but move on.

>
> ---------------
> 2x instances:
>
> reposado_apple:
> - branching done here
> - LocalCatalogURL blank, downloads point to Apple.
> - catalogs are public facing
>
> reposado_local:
> - AppleCatlalogURLs pointed direct at http://reposado_apple/....catalogs/index..._1_branchname.sucatalog
> - LocalCatlogURL: http://reposado_local, reposado wiil download catalogs from reposado_apple, and products from Apple.
> - traditional reposado, no problems with deprecated updates.
>
>
> Nightly sync order
> ------------------------
> reposado_apple
> reposado_local
>
> So the fork changes are released next day to on network clients, and the local
>
> How quickly are Apple dropping the deprecated products from the servers?
>
>
> If this is the completely wrong approach, is anyone else doing anything similar via another config? I am testing it now, and apart from the cavaets mentioned, it might be viable.
>
> Or do I just drop the whole idea and point my "off netwwork" clients direct at Apple and hope they don't botch any patches?
>

> --
> You received this message because you are subscribed to the Google Groups "reposado" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to reposado+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Brian Best]

I had this problem when setting up Mac-MSP Gruntwork: The public-facing server instances we use are too small to handle the full Apple catalog. Sounds like we were after the same thing you want: my catalogs, I'll host the deprecated updates, go get the rest from Apple.

The challenge is that split of getting catalogs and deprecated items from our server and getting the current products from Apple direct.

I made a fork of reposado that shows the code changes I made so that it will build the catalogs with two different servers (yours and Apple's). The part that I left off is that there needs to be a master server that runs reposado conventionally. It runs a script to capture the deprecated items that you want to keep and rsync them to your public facing server.

If I'm right that this is what you're after I'll gladly post that piece for you.

[Lachlan Stewart]

Thanks Greg,

I will do some more testing around this. My thoughts are it's acceptable (assuming softwareupdate just moves on - to be tested) in these grey areas where some off network Macs may not be able to receive updates that have been deprecated. I don't plan on holding on to deprecated updates for long periods unless absolutely necessary, and move quickly shifting current apple updates to beta branches weekly, prod the following week.

And in most cases 90% of the clients are on network, it's just for those very few telecommuters we have.

I was interested if anyone has tried this approach, but it seems not. I will do some more testing and report back here.

Thanks again for an awesome tool.

Cheers,

Lach

[Lachlan Stewart]

Thanks Brian I'd be interested in looking at this technique.

I am not that fussed about hosting deprecated updates for external users as 95% will be on internal network. I still haven't tested how software update behaves when an expected update isn't available for download anymore.

Nor have I got a feel for how long the deprecated updates hang around on Apple's servers. Waiting for some new releases.

I do plan on moving stuff through the testing beta staged pretty nimbly.

Share away would be good to see this approach!

Lach

[G Sterritt]

Lachlan, I'm interested to see how this turned out for you. I similarly have an issue where I have some servers that host "reposadories" that are similarly space constrained. It'd be great to send them to Apple for some things (non-standard printer drivers, speech/language packs) while ensuring they've been provided local access to core OS updates, security patches, and reliability fixes. 

I can tell you, I don't think deprecated updates hang out on Apple's servers at all. A deprecated update is one that your reposadory knows about that's no longer listed with Apple.