instaDMG & software update servers

[themacdweeb]

I’ve not seen documentation on this so forgive me if I’ve missed something but… It strikes me that I can save time by having instaUp2Date grab Apple download/checksums from our own hosted Software Update Server. Does the software have that capability? I’ve run a few searches here in the forum and not seen anything. I’ve also looked at the code but I’m not a python-er, so my cursory look at the code didn’t turn up much. Figured I’d ask if others in the community have a solution that works.

Cheers,

David Koff
Systems Admin
The J. Paul Getty Trust

[larkost]

No, it doesn’t. I did put in the local http server where it can try and find the updates, but it requires that the updates have exactly the same names as the updates on support.apple.com, and because Software Update Server serves out the non-combo versions of things, I would bet you that at least the big files are not identical.

You can try it with Instaup2Date by adding a call to ‘–add-source-folder’ with the http url to a folder full of updates. It will try each item to see if it can match the name, and then download it to checksum it to see if it is the same. But I am not going to make a lot of bets there. I put it there more so that some organizations that have multiple image creation computers could centralize things.

My few experiments with trying to work with SUS left me with so many things that I could not automate between the two.

[Allister Banks]

Hey Mr. Koff,

DeployStudio has a post-restore SoftwareUpdate-checking task you can add to your workflow, including a field for your local SUS’s base URL. Munki also has a first-boot run option you can trigger, and it can point to a local SUS(perhaps one hosted by [url]http://github.com/wdas/reposado[/url]?) as well.

larkosts point is that using hardware-specific packages(since your hardware model gets sent to the software update server when you run it) has less of a chance of giving you patches that will work for any piece of hardware you restore the resultant image to. It’s best practices(well, at least better than we did yesterday practices) to use the publicly-available patches you download in DMG format from Apple’s support/downloads site in your instadmg build train.

Allister

[themacdweeb]

Thanks, gents:

@ larkost: didn’t think it would play well with a hosted SuS but glad to see this verified by some of the work you’ve done.

@ allister: we use casper, we have scripts that point to our hosted SuS, but that wasn’t the point of my post. i’m trying to reduce the amount of time instaDMG takes to run its process and create a baseOS image. i thought that instead of reading a catalog and then downloading each file and update from apple’s servers that we might, instead, point it to our internal SuS to help save download/processing time for instaDMG.

(also been experimenting with reposado, BTW. cewl tewl…)

d

[Tim Sutton]

[QUOTE][u]Quote by: themacdweeb[/u][p]Thanks, gents:

@ allister: we use casper, we have scripts that point to our hosted SuS, but that wasn’t the point of my post. i’m trying to reduce the amount of time instaDMG takes to run its process and create a baseOS image. i thought that instead of reading a catalog and then downloading each file and update from apple’s servers that we might, instead, point it to our internal SuS to help save download/processing time for instaDMG.

d[/p][/QUOTE]

You’re free to download and host the Apple support downloads internally, if the bandwidth savings are crucial, but since instaUp2Date will cache your checksummed downloads, it’s rare that you would download an update more than a couple of times. Unless you’re building on a cluster of machines, the next time your instaUp2Date cache is empty is probably the time when all of the typical updates have been incremented at least once.

[themacdweeb]

actually, as combo updaters are now regularly over 1GB in file size, any savings of time would help. just my two cents.

[Tim Sutton]

[QUOTE][u]Quote by: themacdweeb[/u][p]actually, as combo updaters are now regularly over 1GB in file size, any savings of time would help. just my two cents.[/p][/QUOTE]

Sure. But since it has to be downloaded at least once, for most people the instaUp2Date cache folder will take care of never having to download it again. If you’re constantly building on fresh machines, then you can copy the cached dmgs to your internal web server. Having the checksum placed automatically in the filename may be helpful, as a check for the occasional time when Apple decides to update the distrubution file wihout incrementing the version number.

[themacdweeb]

yes AND that’s all well and fine for images that never change. which isn’t how we work here. yes, your shortcuts are all time-savers to be sure but it skips our issue: if i’m looking to always have a current baseline image, then i’m always going to be downloading the latest and greatest updaters from apple as it’s made available. if i have a local SuS internally, it’d sure be nice to point to that instead of apple’s servers and save the download time for the OS, iLife, security updates, patches, etc.

[Tim Sutton]

I guess I’m not following. Either your SUS downloads an update once or instaUp2Date downloads an update once, or both. To save time maintaining images, point the newly-imaged machine to your SUS and/or Munki repo. To save time on reimaging, keep your .catalogs up to date.

I iterate build tests on a daily-to-weekly basis, and there are no download time issues because no scenario involves downloading an update from Apple more than once, except for that in which I bootstrap a new machine as my next build station, which is rare. If download time savings were crucial I could even copy the cache to the next build machine to avoid another download from Apple.

If you’re wondering about the possibility of building the updates into the caches BaseOS install (and I did at first), it isn’t possible. But as even the smallest update can affect core components, I think it’s a healthy level of paranoia, and you can always be guaranteed that your cache is an installed system from a specific disc with specific installer choices, independent of whatever sets of updates you may be testing.

To improve on speed, a couple hundred $$ on several fast cheap drives in RAID 0 will go a long way.

[Author]

Posts