post configuration of InstaDMG created images – best practice

[pteeter]

We’ve had a lot of discussion about instauser, ARD kickstarting, eliminating the install video, eliminating the registration screens, enabling the root account, even directory binding on this forum.

I’ve seen a few comments about using StartupItems and others about launch agents to accomplish these goals.

Can we start some discussion about best practice, standardizing methods, etc?

For example, I have a shell script I use to kickstart ARD. I want to implement it for running the first time a newly imaged machine boots. My questions about this would be…

1. StartupItem vs. launch agent? I think the answer is obvious. StartupItems are almost deprecated, so launch agent it is. Even if I’m making 10.4 images, it seems short sighted to spend time on a StartupItem.

2. What is the best method for creating the launch agent plist file – manually, Lingon, something else? What are people using to do this?

3. If most of these tasks are to be accomplished via shell script, what location is best for storing the scripts? /Library/Scripts/ ? Someplace else like /etc or /var?

Hopefully these queries will spark some debate. Let’s define these things, no?

[akinspe]

Well first I think it’s important to define what needs to run on first boot and what does not. For instance. You can make yourself an ARD Client Install package and alleviate any need to do anything manual yourself. Many things can be done prior to booting and therefore don’t require any special launch agents or startupitems.

Really about the only things that would require that would be:
a) Things that alter files that aren’t present until the machine first boots
b) Things that set values based on the exact hardware found
c) Things that generate unique identities that shouldn’t be duplicated
d) Packages that don’t work well when they aren’t on the boot volume (hopefully these would be repackaged, if possible)

Am I missing something?

Although StartupItems are/may be deprecated, they still have one feature that launchd items don’t: clear dependancies. For example you may have certain items that can’t run until there’s an available network.And let’s face it. They still exist and will continue to exist for another few years even if 10.6 does away with them.

I had actually created a generic FirstBoot package that ran all scripts/packages in a certain folder and then removed itself afterwards. This was mostly because I have a script that sets the computer name based on the serial number (although WGM will change it if it’s already in the OD, of course), and also I still can’t get KeyAccess to work properly unless it’s run on the same volume. But I’m still looking itno that. And Office 2008 updater is REALLY stupid. The “package” just moves all the stuff into a temp folder and then a bunch of scripts move the files. I’ll probably have to repackage that.

Anyway. It’s an interesting question. Some standardization might be in order. Perhaps a folder to put packages that need to be installed, and perhaps a folder of scripts that should be run.

[Patrick Fergus]

Great topic.

Right now, we’re using a StartupItem because it was already written and vetted a while ago. One feature we’re using that I think a generic, standard method should have available is rudimentary installation ordering options. We use a pipe-separated text file with a list of packages.

I’ll post the full list of what we’re doing at first boot on Monday when I get back to the office. However, regarding ARD I [i]think[/i] the way a customized ARD client installer is written you can’t install it on a non-boot volume and expect the customizations (rights, accounts creation, etc) to work because of the way the postflight/kicker script works. I think it calls the local copy of the ARD kicker and sets the options on the startup disk.

I’d love to be proved wrong.

– Patrick

[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.

[amsterdam]

Two things that I’m using StartupItems for:

– binding to our OD
– setting the timezone, and ntp server

I tried to do it with a launch daemon, but it didn’t work because of the whole dependency issue. Right now, I’m tackling the ARD issue. I was using a “no local user” system, and only using a admin from OD. It was working great, but our support people didn’t like not having a local admin in case things didn’t work. So, I’m using the createUser script that was posed here. It’s working well, but I’m now running up agains the ARD issue again. I’ll be interested to see what you all find works best.

[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.

[Patrick Fergus]

We are doing the following for our NetBoot build (although I stole pteeter’s “kick” variable):

[code]kick=”/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart”

#Disable system sleep, display sleep, and hard drive spindown
/usr/bin/pmset -a sleep 0 displaysleep 0 disksleep 0

#Enable ARD and set options
#The periods should be replaced with whatever you want your privileges to be
$kick -activate -configure -clientopts …
$kick -configure -users ‘admin’ -access -on -privs …
$kick -restart -agent -menu

#Rename the startup disk to “Leopard NetBoot”
diskutil rename / “Leopard NetBoot”[/code]

And we’re doing the following in our standard build (the certificate is being installed by one of the packages):

[code]#Enable AppleTalk
firstEthernet=`/usr/sbin/networksetup -listallnetworkservices | /usr/bin/grep -m 1 Ethernet`
/usr/sbin/networksetup -setappletalk “$firstEthernet” on

#Enable and configure Apple Remote Desktop
#Like the above, a few different options but the same idea

#Setup NTP server and enable network time
/usr/sbin/systemsetup -setnetworktimeserver our.ntp.server.com
/usr/sbin/systemsetup -setusingnetworktime on

#Add Company’s Root CA
/usr/bin/security add-trusted-cert -d -r trustRoot -k “/Library/Keychains/System.keychain” /private/tmp/ourInternalCA.pem

#Rename the startup disk to “Macintosh HD”
/usr/sbin/diskutil rename / “Macintosh HD”

#Setting the time zone
#We have code that determines the second octet of the IP to figure out where the machine is booting up.
#It’s 95% true that the machine stays where it’s built
centralTime=”America/Chicago”
/usr/sbin/systemsetup -settimezone $centralTime[/code]

[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.

[cooperkevind]

Great presentation the other day Josh 😉

I am setting up the Launchdeamon pointed to a script and then package it and put it in my package train. Which works but seems over complicated? Isn’t there just a way to package a bash script? I have tried many attempts and my pea brain isn’t grasping it. Wouldn’t that take a couple steps out of this process.

Just trying to simplify a process.

Thanks for the help

Kevin

[akinspe]

Admin User
If you don’t want to use a first boot thing for 10.5, then please try out my createUser.pkg You CAN create a user before first boot on 10.4 by running nicl in raw mode

ARD:
I use a Custom ARD Installer made from ARD and it works perfectly. Since the kickstart script is made to work on non-startup volumes (there is a -targetdisk option in kickstart that makes this all work), I’m curious why you it won’t “just work” for some of you? Are you doing something unusual that can’t be applied?

Enable Root:
I’m not sure, but I thought it just created a hash for the fixed GUID of the root account (FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000000), so it could in theory be done at creation time. that way you’re not sticking the password in a script. But if there’s more than that I’d like to know.

TimeZone/ntp
I actually just drop the /etc/ntp.conf file and alter /etc/hostconfig to enable ntp. creating a symlink from /usr/share/zoneinfo/XX/XXXX to /etc/localtime does it for timezone. i.e.
ln -s /usr/share/zoneinfo/US/Eastern “$3/etc/localtime” in a postflight script does the job.

Registration/movie
there is now a package available to disable the registration/movie

Directory Services:
I actually created a package with the appropriate /L/P/DirectoryService/*.plist files for our OD, but then again we don’t do authenticated binds, so that’s no biggie

SSH:
You could just remove the disabled flag of /S/L/LaunchDaemons/ssh.plist

At this point I have very few “FirstBoot” tasks. I wrote a StartupItem that would execute a series of scripts in a known folder and then erase itself. Certainly a launchd item would work as well and probably would be future resistant. The idea is that the master script is generic, but then you can “package” the other scripts as components and they just get installed in the folder. This makes it more modular.

But very few of these NEED to be FirstBoot.

[Patrick Fergus]

> ARD: I use a Custom ARD Installer made from ARD and it works perfectly.
> Since the kickstart script is made to work on non-startup volumes (there
> is a -targetdisk option in kickstart that makes this all work), I’m
> curious why you it won’t “just work” for some of you? Are you doing
> something unusual that can’t be applied?

I’m not doing anything unusual, but could you confirm this is the right syntax to set ARD rights/configuration to a non-boot disk? I just pulled it out of an Apple mailing list (never considered it could be set on a non-boot disk):

[code]sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -targetdisk / -configure -clientopts -setdirlogins -dirlogins yes -setdirgroups -dirgroups ard_admin,ard_interact,ard_manage,ard_reports[/code]

> Enable Root: I’m not sure, but I thought it just created a hash for the
> fixed GUID of the root account (FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000000),
> so it could in theory be done at creation time. that way you’re not
> sticking the password in a script. But if there’s more than that I’d
> like to know.

My root enabling is just dropping the hash and editing the admin dslocal group on the target disk to append root onto the “users” array (which is what Directory Utility does).

> TimeZone/ntp I actually just drop the /etc/ntp.conf file and alter
> /etc/hostconfig to enable ntp. creating a symlink from
> /usr/share/zoneinfo/XX/XXXX to /etc/localtime does it for timezone. i.e.
> ln -s /usr/share/zoneinfo/US/Eastern “$3/etc/localtime” in a postflight
> script does the job.

Ours needs to be done at boot time since our standard build is made in one time zone and restored onto machines in multiple time zones.

– Patrick

[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?

[cooperkevind]

[quote]If you make a package that only has a postflight script in it you can apply that with the installer…[/quote]

Dumb question how do I go about doing this? I have tried Many different approaches. I just want on bash script that has a few lines in it applied on my instadmg image.

Thanks for the help.

Kevin

[pteeter]

It’s called a payload free package.

Look all over this forum for discussion, step by step, etc.

Basically – have your script act in a postflight capacity, install a dummy file with the PKG installer, then have the postflight script’s last action be deleting that dummy file.

[url]http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_4.html[/url]

There may be more elegant ways of doing it.

But that’s the basic concept.

HTH.

[Rusty Myers]

[QUOTE][u]Quote by: cooperkevind[/u][p][quote]If you make a package that only has a postflight script in it you can apply that with the installer…[/quote]

Dumb question how do I go about doing this? I have tried Many different approaches. I just want on bash script that has a few lines in it applied on my instadmg image.

Thanks for the help.

Kevin [/p][/QUOTE]

What I would do is use the terminal to touch a file called foo. Then in my pkg, I would install the foo file to /dev/null and fun the postflight script. I think that would work.

Can anyone tell me if this would work. Honestly I haven’t tried it yet.

[Author]

Posts