Some questions about InstaUp2Date config

[jdyck]

Hey all,

Slowly getting InstaDMG / InstaUp2Date figured out, one quick question though. I’ve put some custom installers directly into the /Installers/InstaUp2DatePackages/ folder and referred to them in the catalog file like so:
[code]System Settings:
Create admin user createUser-admin.pkg sha1:hash goes here[/code]
This works. However, now I want to install MS Office with an InstallerChoices.xml file. I’ve put a numbered folder into the /Installers/InstaUp2DatePackages/ folder, and in the catalog file I’ve tried several ways to reference this, such as:
[code] Office 2008 Office Installer.mpkg sha1:9be4f981cbb2a8812d230c487d1a40cda715b28b
Office 2008 05/Office Installer.mpkg sha1:9be4f981cbb2a8812d230c487d1a40cda715b28b
Office 2008 /Volumes/EXT-Data/InstaDMG_1.4b4/InstallerFiles/INstaUp2DatePackages/Office Installer.mpkg sha1:9be4f981cbb2a8812d230c487d1a40cda715b28b
[/code]
But ever ytime I try to run instaUp2Date I get errors like the following:
[code]Looking for Office Installer.mpkg in cache folder
Did not find Office Installer.mpkg in archive
Traceback (most recent call last):
File “/Volumes/EXT-Data/InstaDMG_1.4b4/AddOns/InstaUp2Date/instaUp2Date.py”, line 930, in
main()
File “/Volumes/EXT-Data/InstaDMG_1.4b4/AddOns/InstaUp2Date/instaUp2Date.py”, line 921, in main
thisController.parseFile(inputFilePath, topLevel=True)
File “/Volumes/EXT-Data/InstaDMG_1.4b4/AddOns/InstaUp2Date/instaUp2Date.py”, line 221, in parseFile
thisPackage = installerPackage( simpleLineMatch.group(“prettyName”), simpleLineMatch.group(“archiveLocation”),
simpleLineMatch.group(“archiveChecksum”), simpleLineMatch.group(“packageLocation”), simpleLineMatch.group(“packageChecksum”) )
File “/Volumes/EXT-Data/InstaDMG_1.4b4/AddOns/InstaUp2Date/instaUp2Date.py”, line 543, in __init__
raise Exception(‘Unable to find package: %s’ % self.name) # TODO: better errors
Exception: Unable to find package: Office 2008[/code]
Is there a known good way to reference something like this?

And related, can I have a folder of pkg installers, for example I usually create an admin and an ard user, so have two createUser.pkgs – can I put these into one folder and call it something like createUsers and then just call that folder? I’m having a hard time thinking these all through and how / whether they can be done.

Also, I saw an earlier post (from April-ish I believe) in the forums that mentioned it should be possible to have numbered/named folders in the build (but this was before instaUp2Date and the main instaDMG has changed a bit since then also) – is this still possible? By which I mean, instead of having numbered folders such as 01, 02, 03, etc, it would be nice to have something like 01-SetupUsers, 02-MSOffice08, 03-iLifeUpdaters, etc. Is this possible?

Anyway, looking forward to learning more about this tool.

Thanks in advance.

[larkost]

The solution I am using to handle Office 2008 is that I make a disk image with the installer and the InstallerChoices.xml file in it, and then reference that. At one point I had folders in there, but that got bumped out when DMG’s got bumped in. I have some ideas about how to handle things so that things like this would be possible, but those are a long way off.

[jdyck]

Thanks larkost, that makes sense and I will try it next.

A few more clarification questions as I try to figure out best practices and limitations…

While I’m not that organized in real life, when it comes to computers I’m a bit picky, so have a hard time with one massive folder of PKG installers and DMGs… To help me keep my sanity, is there a proper way to reference a pkg or dmg file within the /InstaDMG/Installers/InstaUp2DateInstallers folder?

Kind of what I envision is having folders to contain major ‘components,’ ie: MS Office, ilife, iWork, OS Updates, System Config pkgs, etc. If nothing else it would make me feel much more on top of this ;).

Also, is it appropriate to build a bunch of .catalog “building blocks”, ie:

• An MS Office 08 catalog file, which would contain the config lines necessary to install the base package, each update, and a registration installer.

• iLife 08, which again would contain the base package and all updaters and registration files as needed.

Then I could have “Master files” that would mostly use include directives to build the image I want., for example:
[code]include-file: 10-5-5.catalog
include-file: MS_Office_08.catalog
include-file: iLife_08.catalog
etc.[/code]
Seems like this would allow me to build several “Build” trains, and as long as I focus on keeping each “building block” up to date all I need to do to update all my images is re-run instaUp2Date on the different “master” catalog files.

Am I approaching this correctly, or am I just dreaming :).

Thanks again,

Jeff

[larkost]

At this point I am still using the InstaUp2DateInstallers as a flat repository. It might be (but I have not tried this at all, and was not thinking this direction when writing code) that you could just use relative references (ie: “bob/filename.dmg”). At one point I was using some absolute references for things, but that was a lot of versions of code ago.

And the building blocks idea is exactly what I had in mind, and exactly the way I am using it. I have multiple build trains that reference the “Base” catalog file, and that in turn references the vanilla.catalog that is included. When I add something to the Base image it is easy (but takes a long time) to kick off the production on all the others.

[pteeter]

jdyck:

I can vouch for your ‘nested’ catalog file idea.

I’ve been using it and deploying images based on it for a few months.

Some of my catalog files reference 7-8 other catalog files.

I’m maintaining build trains for Tiger X86, Tiger PPC, and Leopard.

Beneath each of those OS-HW classifications, I build 5-10 different image types. The difference between each being how much or how little software is installed.

[jdyck]

Hey,

I’ve been playing around with this again today, trying to massage things into place and building different catalog files for different packages.

I really like the core ideas surrounding this development package…

However, I’m still trying to figure out how to keep my custom packages more organized into folders, which I’m having difficulty doing…

Perhaps I’m just being perfectionist, but in my case I’m a contractor – one of my main clients is a French School District, while my other clients are all English, so for something like MS Office I’m facing difficulties in that all the updates are language specific, but have the same filenames… I could perhaps just rename the files, but I did that with my last modular system and found there were some errors caused with incorrectly named installer receipts.

I’m hoping to have a folder structure something like:
[code]MS-Office08-French
–MSOffice08-French.dmg
–Office 2008 2P1 Update (12.1.0).mpkg
–Office 2008 12.1.1 Update.mpkg
–Office 2008 12.1.2 Update.mpkg (these are the french updaters, which unfortunately have the same filename as the English ones)

MS-Office08-English
–MSOffice08-English.dmg
–Office 2008 2P1 Update (12.1.0).mpkg
–Office 2008 12.1.1 Update.mpkg
–Office 2008 12.1.2 Update.mpkg (these are the english updaters, which unfortunately have the same filename as the French ones)

Client-Customizations
–Misc customer-specific installers
–ThisCustomersMSLicense
–etc[/code]
This way I could have a catalog file that did something like:
[code]Third Party Software:
Office 2008 MSOffice08-English.dmg hash
Office SP1 Update OfficeUpdates-English/Office 2008 SP1 Update (12.1.0).mpkg hash
Office 12.1.1 Update OfficeUpdates-English/Office 2008 12.1.1 Update.mpkg hash
Office 12.1.2 Update OfficeUpdates-English/Office 2008 12.1.2 Update.mpkg hash[/code]
Which is what larkost above suggested I try, but alas as soon as I add the “OfficeUpdates-French/” part the script dies.

Like I said, I love the modular methodology and I really like the direction InstaDMG/InstaUp2Date is taking, just want it to take that extra step.

Perhaps if adding some kind of recursion or whatever to get away from the flat repository is difficult, another option might be to allow a catalog file to temporarily override the userSuppliedPKGFolder variable? That way in my example Office-English.catalog file I could just have a line at the top something like “userSuppliedPKGFolder = MSOffice08-English” and the remainder of that catalog would pull from the specified folder?

Maybe time for me to learn python or something so I can stop yelling suggestions from the sidelines and start contributing :).

[pteeter]

jdyck…

While I don’t have to worry about the language specific versions of Office08 (thankfully), I do deploy Office08.

In discussions with pfergus, a real InstaDMG guru, who uses Filewave ([url]http://www.filewave.com[/url]) to manage software on his client machines, I ended up with this method for deploying Office 08…

1. take before snapshot of system
2. install Office 08
3. install all current updates to Office 08
4. take after snapshot
5. package up necessary components for deployment
6. integrate new PKG into InstaDMG/InstaUp2Date build train

I personally don’t trust the PKG’s that MS releases, but I’m paranoid and enjoy the tedium of rolling my own PKG installers. 😉

I also seem to recall that the PKGs and MPKGs from MS have some preflight scripts that make a CLI/automated install difficult.

Yes, every time MS releases a new update I have to make a new PKG…but I’d have to do that anyway AND that update PKG would typically have to have a preflight script to delete whatever the MS MPKG deletes.

Just one man’s opinion but it might help.

[jdyck]

Hmmmm… I was hoping to try using the Office Update Patcher from this thread: https://www.afp548.com/forum/viewtopic.php?forum=45&showtopic=21882&highlight=office

I’ve been doing pretty much what you are suggesting, but really want to get away from it as much as possible as it reduces maintainability. I was using PKG-Image before, mostly chose it because (1) it had a nice GUI and (2) it imaged direct to a machine and is much faster at doing that than InstaDMG…

However, I was finding I had to rebuild most of the update packages from Apple (QuickTime, iLife updaters, others) and having to create my own base DMG for the OS (which often had to rebuilt for new hardware), both of which were very time consuming and started making me wonder if it was worth the effort.

So really really really looking forward to getting away from as much of the custom repackaging as possible (fingers crossed).

[pteeter]

Good stuff…I posted to that thread way earlier and let it get away from me.

I may play around with the droplet/converter tool.

Perhaps I’m a masochist, but I enjoy the process of rolling my own PKGs b/c then I really know what files compose what app.

[knowmad]

pteeter, i too was of the opinion (noted in the other office thread) that rolling my own was better…. then I played with the droplet… it works and it makes life easier and less time consuming because, although the updates take forever to run, they do indeed work and I can do other things while they work.
Plus they all take choices files which makes fine tuning simple.
give it a whirl, you might find it simplifies things in the long run.
knowmad

[Author]

Posts