[pteeter]

Interesting to know about the ‘targetdisk’ option in kickstart. Not sure why/how I missed it before.

Another task that I wonder how people deploy is printer configuration.

Is it possible to control with MCX? I’m thinking no…

My initial thoughts were to ensure the proper drivers are installed – either by default OS install or with PKG installer of organization specific drivers.

Then use lpadmin in shell script to configure all printers.

Such a task could be a first boot item, with a self-cleaning launch daemon.

Anyone care to comment?

[pteeter]

I’ve spun home brew packages for Office 2008, the first test (really small) update, and the significant 12.0.1 update.

I have had little difficulty installing and then working with the applications after the install.

My packaging method involves logGen for system snapshots, pkgGen for collecting the files, then PackageMaker for building the PKG installer.

I am building on Tiger now. I have not explicitly tested by Office 2008 pkgs on Leopard.

I use an MPKG to install the base application suite, update 1, then the 12.0.1 update.

Not sure about what Josh mentions. I do know the first update replaces the Auto Update utility, found in /Library/Application Support/Microsoft. (They call it MAU 2.0 now.)

Does this information help?

[pteeter]

I see what you are saying but maybe what I’m hoping for is a way to enable a flag within the instadmg script that will allow us to have 1, 2, 3 , etc. build options.

Each option denotes a different application group, etc.

So maybe to follow up on your comment, elaborate on what you mean by ‘client management system’? ARD / JAMF / etc.?

[pteeter]

Ok, here’s a first stab at listing these tasks and how they might best be accomplished…

TASK / OS VERSION / METHOD

create local admin / 10.4 / launch daemon, shell script (dscl, etc.)
create local admin / 10.5 / InstaDMG workflow, pkg install
ARD kickstart / 10.4, 10.5 / launch daemon, shell script
enable root account / 10.4, 10.5 / launch daemon, shell script (dsenableroot)
timezone, ntp / 10.4, 10.5 / launch daemon, shell script (systemsetup) ***
disable registration/movie / 10.4, 10.5 / InstaDMG workflow, pkg install
energy management / 10.4, 10.5 / launch daemon, shell script (pmset) ***
rename boot disk / 10.4, 10.5 / NetRestore post-action
network: appletalk, dns / 10.4, 10.5 / launch daemon, shell script (systemsetup) ***
directory binding / 10.4, 10.5 / launch daemon, shell script (dsconfigad, dsconfigldap, etc.)
ssh enable / 10.5 / launch daemon, shell script (systemsetup)
ssh enable / 10.4 / launch daemon?, (/S/L/CoreServices/RemMngmt/ARDAgent.app/Contents/Support/systemsetup)

*** seems like these settings could be managed better via MCX, depends on your environment?

Please pick this list apart, let’s quantify all the steps that one might want to accomplish post InstaDMG – pre boot.

[pteeter]

Because xargs scares me…not really. This is just another way to do the same thing…

[code]find /Applications -type f -name flashplayer.xpt -exec cp -Rfp /Library/Internet\ Plug-Ins/flashplayer.xpt {} \;[/code]

Will test today and fill in results.

[pteeter]

Nigel Kersten brought this up on the MacEnterprise mailing list:

> >There are some exceptions though. Some Firefox apps come with a
> >flashplayer.xpt bundled inside the app itself, and this is what the Adobe
> >installer usually fails on with network/mobile accounts due to dropping
> >admin privileges and assuming the user has write permissions to the app
> >bundle.
> >
> >We resolve this with this postflight script.

[code]#!/bin/sh

PATH=/usr/bin:/bin

find /Applications -type f -name flashplayer.xpt -print0 | xargs -0 -J % -n
1 cp -Rfp /Library/Internet\ Plug-Ins/flashplayer.xpt “%”
[/code]

I haven’t investigated personally, but I’m sure Nigel is right.

[pteeter]

Here’s the kickstart script I’m using, storing it in /Library/Scripts/”your company name”/

[code]#!/bin/sh

kick=”/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart”
launchdaemon=”/Library/LaunchDaemons/com.”your company name”.ARD.kickstart.plist”

### configure ARD

$kick -configure -users “your local admin user” -privs -mask 255
$kick -activate -configure -access -on -restart -agent

### remove launch daemon for all future system boots
rm -f $launchdaemon

exit 0[/code]

I’d like to add some logging to this, just so I can grep syslog to verify the script fired off as expected.

I used Lingon to create the LaunchDaemon plist file. Made the process ridiculously easy.

I’ve bundled this in a package, tested it via direct install on 1-2 test machines. I also deployed it via NetRestore post-action to via an image that already has a local admin user built-in. Hope to test with InstaDMG created image tomorrow.

Hope this helps.

[pteeter]

I agree that the ARD client can be ‘updated’ with an installer package. Either via ARD or the typical – snapshot, pkgGen, PackageMaker, steps.

But I’m with Patrick that kickstarting ARD isn’t possible via an installer package. Speaking strictly in terms of InstaDMG deployment, kickstarting ARD requires that some account exists on the machine and the binary that is used *lives* on the target volume/machine boot volume. I use a shellscript…or a payload free package with just a postflight script.

Glad you guys are intrigued. I’ve been planning and considering and rethinking how to build these images via InstaDMG. This topic is the one that has the most grey area in my mind.

Installation ordering:

I’m thinking about it like this, in no concrete order yet, 3rd party utils (live in /Applications/Utilities), 3rd party apps (live in /Applications), 3rd party license apps (live in /Applications, have company specific volume serial numbers/activations), company specific settings/files/tweaks (a little vague now but things like PPDs we use, fonts we use, etc.), first boot configurations (instauser, root enable, ARD kickstart, etc.), loginhook or user-specific actions (if necessary)

First boot:

PFergus – I’m very curious to see/learn what you guys do, how you do it, and in what order.

Going forward, I’m going to try to use launch agents and avoid StartupItems. We’ll see how well it works / long it lasts.

Keep the comments coming.

[pteeter]

I know for certain that my first update pkg, current to 2-29-08, required a postflight script to remove *a lot* of files.

I also have a second pkg current to 3-19-08.

I suppose the update process of making new pkgs will continue until CS4 releases.

[pteeter]

I have successfully used logGen / pkgGen / PackageMaker to create a CS base installer.

I have also successfully used that set of tools to create update packages, the caveat being a preflight script was required to remove specific files.

I’ve tested it on PPC, x86, Tiger, & Leopard.

I am probably going to modify the pkg so that each CS3 component installs separately, i.e.

pkg for Photoshop
pkg for Illustrator
pkg for InDesign
pkg for Dreamweaver
pkg for Flash
pkg for all updates
etc.

Borrowing from PFergus, this type of modular approach is more in the spirit of InstaDMG I think.

[pteeter]

Thanks for commenting guys.

I’m going to try preflight scripting the cleanup of all three Flash files. I figure removal of the Flash Player Enabler.plugin item will harmlessly error out on Intel.

I am intrigued about the UB nature of the Patrick’s installer.

So, the same installer (as in one instance of Flash Player.plugin and one instance of flashplayer.xpt) is used for 10.4 – PPC + x86 AND 10.5 – PPC + x86?

UPDATE: apparently the answer is a great big YES. Built the PKG on x86. Ran it on PPC. Plugin works on both, preflight script works too. So why the heck does Adobe make such a big deal about downloading different PowerPC and Intel installers for Flash? Do they know something we don’t or are they just being overly cautious? Or, as Josh suggested, obtuse for no good reason.

😉

[pteeter]

Agreed and verified today.

So long as one keeps the order correct – software, then updates – MPKGs just add more steps to the process.

Good to know it is an option.

Thanks Josh.

[pteeter]

One thing I just thought of…you know how logGen includes a number of files that aren’t really necessary when creating a package?

Perhaps we ought to define a standard for what to omit from the file listing?

.DS_Store file
any cache file

etc.

Or just insist on people submitting file listings with no modifications?

Just a thought.

[pteeter]

Brilliant idea, really. Can’t believe no one suggested it sooner.

I knew I should have been saving those Package Maker project files and logGen diff files.

I *will* certainly hold onto them now.

I’ve mostly completed our ‘3rd party licensed applications’ packages. And will begin work on shareware/freeware ‘3rd party applications’ this week.

I bet PFergus has info to contribute to this too.

[pteeter]

I’ll test the CLI idea for sure.

I think I’m having some weird NetRestore 3.4.3 issues that may be effecting this process.

But that…is for another forum perhaps.

Investigating it now.

Thanks for commenting.

[Author]

Posts