[pteeter]

Best to use a launchdaemon or loginhook to establish the AD bind.

[pteeter]

I haven’t deployed it or tested it yet but my rule of thumb with MS updates, even MPKG/PKG format is simple…

logGen+pkgGen+Iceberg

Just repackage it.

[pteeter]

If you need to build multiple images for your company / school / lab /etc. – InstaUp2Date is *the* way to go.

It works. It takes only a little bit of understanding beyond grasping InstaDMG. The developer of it is receptive and helpful…thanks larkost.

[pteeter]

I’ll try to get those catalog files to you today. I’m pre-downloading all of the updates, so the sha-1’s are for PKG installers only. That decrease the usability of what I have?

Well, I’m glad getting your job done has resulted in this tool b/c it really works. If I think of it I’ll harass Josh & Mike (& Joel) about the benefits of InstaUp2Date.

[pteeter]

[color=Blue]Nope, you can continue to do exactly that. But take a look at the vanilla catalog file. One of the central ideas in this for me is that we can all share that file and it will take a vanilla retail disk (as in one you buy at the store) and bring it up to the latest version of everything that Software Update would add for you. When a change happens only one of us has to update the vanilla file and everyone else gets the benefits.

For the moment that person is me, but I will gladly accept submissions from others. And once we get out of the starting blocks I can see there being a collective that would contribute catalog files for things that are openly available (Firefox, AdiumX, etc). Part of the point of this is that if we can get a good structure that is widely applicable, then we have a lot of people all testing the same base image. If there is a problem someone will fix it, and we can all have more confidence in our base images, and concentrate on the things that make our installations unique.[/color]

I think what you’re aiming for with the vanilla.catalog file is admirable, and easier with Leopard too.

I believe I could fairly easily compile my Tiger-ppc and Tiger-x86 ‘vanilla’ catalog files for use like this. It was tricky at first b/c both architecture’s have separate patch groups for the OS, Safari, Java, and Airport. I’m pretty sure they are static now, save hardware specific updates. Where should I submit these for inclusion?

[color=Blue]I should also mention that I made a little change in how things work: If you give InstaUp2Date multiple catalog file it will assume that you want to setup for InstaDMG multiple times. So it will setup for one (presumably run InstaDMG), tear-down, then setup for the next run. Once for each file you give it. I am a little torn on whether I should put in logic that if it detects you have multiple files that would present an error if you don’t have the –process option selected.

I also think that there should be another option that would allow you to add a catalog file (or maybe a dmg/pkg or http reference) manually. The thought of taking in a catlog file on standard input has also gone through my head (think automated build systems). But I don’t need that yet, so it will be a while.[/color]

Both cool ideas. I have spent a good amount of time inbetween runs of InstaUpToDate (old-style) + Instamdmg cleaning up, more or less. I’ll be sure to try the multiple catalog + –process option next weekend.

[color=Blue]I added that to InstaDMG. It makes the 45 minutes or so of Base OS install into 6 minute process (after the first run with that image/installerchoices file). I got tired of the long wait through that while testing, so scratched that itch. There are a few other ideas like that might get implemented sometime.[/color]

You’re right on about the delay, a great addition. Again, I’ll try that this weekend when I build for sure.

larkost – I have to ask…are you (the creator) and me the only people using InstaUp2Date?

[pteeter]

Good stuff larkost.

1. I / we will look for updates in the SVN repository then.

2. I’m a little fuzzy on dmgs vs. pkgs. I’ve always run checksum.py aganst pkg installers and only referred to pkg’s in my catalog files. Will that change now or not?

3. A welcome addition to both tools – output DMG file name customization. Woohoo.

4. Ok, this for me is the biggest change. The InstaDMG + InstatUp2Date dir structure now looks like this…

[code]
AddOns

—->InstaUp2Date

———>CatalogFiles

———>checksum.py

———>instaUpToDate.py

Caches

—->BaseImageCache

—->InstaUp2DateCache

instadmg.bash

InstallerFiles

—->BaseOS

—->BaseUpdates

—->CustomPKG

—->InstaUp2DatePackages

Logs

OutputFiles
[/code]

A few questions arise…

Can all .catalog files be stored in the CatalogFiles directory?
I assume the InstaUp2DateCache folder holds all DMGs and PKGs that will be linked into the BaseUpdates & CustomPKG folders?
What’s the InstaUp2DatePackages directory for now?
Which tool – instadmg or instaUp2Date – leverages the BaseOS image caching?

5. YES, one line to add to the catalog file. Nice.
6. Useful, will help with full automation when I get to doing that…if I get to doing that. javascript:emoticon(‘;)’)

Again, thanks. Your tool makes my build process far more elegant.

😉

[pteeter]

It seems that if I update the appleUpdatesFolder setting with the proper directory, BaseUpdates, instaUpToDate is happy enough.

Looking forward to your mods in InstaDMG.

[pteeter]

I haven’t gone thru your script yet but I’d guess we’ll need to change references to AppleUpdates over to BaseUpdates with Josh’s change to the InstaDMG directory framework.

No?

[pteeter]

You want to give us an ls -la listing of your build train directory, maybe an ls -laR?

Also, you think maybe you could limit the log snippet to the crucial details?

I love reading reading InstaDMG logs as much as the next guy but…

[pteeter]

You know, b/c of the heirarchy of overrides…I’m writing a self cleaning launch daemon to configure this on first boot.

Then I can use the same script to fix the preference if it breaks…and re-deploy the pkg installer if the server hostname/port changes.

[pteeter]

For some reason I’m revisiting this issue.

To control /Library/Preferences/com.apple.SoftwareUpdate CatalogURL (software update server for every user on the machine) must the managed preference be configured for a machine account?

Or can this be applied, through OD, via a user/group login managed preference?

[pteeter]

So I tried this with SP1.

1. Create payload free package to delete all files deleted by SP1 installer, postflight script accomplishes.
2. pkg for Application files
3. pkg for Library/Automator files
4. pkg for Library non-Automator files

Sadly, same behavior. Excel, PPT, E’rage seem to work just fine. Word = no love. Will not quit cleanly, appears to have trouble saving Normal.dot…even if I pre-create the file in the users MUD directory. Word will save rtf, doc, txt, etc. formats but any attempt to save to docx forces Word to crash.

I could post the MS Word Error Report but don’t want to post gobs of MS-stack trace gunk.

I even tried swapping in a copy of the Word.app file from a known working instance of Office 2008 SP1. Still no dice.

Fun and way too time consuming.

Has anyone found a way to re-package SP1 successfully?

[pteeter]

So, coming late to this party b/c I thought I had a good pkg installer earlier.

I’ve broken up the Office 08 base installer into 3 parts (using volume-license installer, so no s/n stuff to worry about, sorry to those of you who have to deal with s/n)…

1. Shared Files – Library files, etc.
2. Applications
3. Fonts – with preflight to move stuff around as MS wants

These seem to work just fine.

I converted the AutoUpdate 2.1.1 update to pkg no problem with logGen/pkgGen/PackageMaker.

I am struggling with the SP1 mpkg. As the last poster suggested, it won’t work ‘out of the box’ – command line attempts error out, some ps nonsense most likely to ensure all apps are shutdown and only a few of the enclosed pkg’s actually run.

I re-pkg’d SP1 with a preflight script to delete what the installer removes.

All apps work except Word is giving me fits. Won’t quit cleanly, won’t save to DOCX format. Very odd behavior.

Anyone have thoughts on this?

I can post my SP1 diff file it might help.

[pteeter]

Makes sense.

Thanks for the heads up.

[pteeter]

Thanks for the reply.

I sort of accidentally ran the checksum.py script on my G5/Tiger xserve last night. It failed but no worries. I’ll test populating my Tiger InstaDMG environment on Leopard and see how it goes. I think it should still work.

I’m storing all of my image building materials on an XserveRAID with a folder shared out over AFP/SMB/NFS. One of those protocols ought to let me mount the share to a Leopard client for running InstaUpToDate, maybe.

I populated a sample InstaDMG environment last night via InstaUpToDate using nested catalog files. Worked great for me. The messages that display on the command line are informative. I suppose I’d like a log file to tail and to check at the end, but that’s a minor detail. I also want to collect my catalog files in a Catalog folder, I’ll try this and see if InstaUpToDate behaves.

I hope to run a Tiger populating test later today.

The more I use InstaDMG (and InstaUpToDate), the more it would help me if I could execute from a network shared folder.

Joel suggested, a week or so back, that NFS might work with InstaDMG. I haven’t had any luck myself but I didn’t investigate that deeply.

Good stuff larkhost. Your tool is going to help me a ton.

[Author]

Posts