post configuration of InstaDMG created images – best practice

[cooperkevind]

Thanks for the response . I got if finally (rubbing sore forehead from bouncing it on my desk)

[Patrick Fergus]

[u]Quote by: thespider[/u]
> 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.

Or installing a blank, touched file to /private/tmp. I have a half-dozen packages that do nothing more than run scripts.

[alantrewartha]

Revive. Where do YOU stop ‘baking stuff into’ the ASR-ready DMG? i’m guessing that best practice advice here will vary a lot depending on user-base and ‘image variety’.

here we have ~100 macs with all but a handful using apps not in a core image, so we make 1 image and do some ad-hoc installs – mostly with PKGs – afterwards as needed (and some pre-serialised executables copied in place)

what’s in the instadmg CustomPKG ‘chain’:

clearReg.pkg (standard afp548 download to stop the never-happens intro-movie and registration app)
createUser.pkg (ditto – to make a standard admin user)
activate_ssh_ard.pkg (did i make this from scripts scavenged here? – does what you might think)
stop_NBR_error.pkg (another postflight-only script to stop NBR complaining it can’t tell what the system version is)

then various ‘core’ application installers – mostly standard install (a couple with InstallerChoices.xml, and some home-rolled for this and spot ARD installs)

we use bombich NBRrestore to image clients using this generic DMG. The NBR Post-actions contains a couple of PKGs to customise the system for our infrastructure – one to do the main custom tweaks, and one extra copy of createUser set up to make a new local user not in the main image (a new requirement after a recent catastrophic network failure that left all users unable to login and work.)

the main custom PKG has a sprinkle of files in the BOM (the first_boot startupitem, a CUPS backend, main DS config files – it’s quicker than writing via plistbuddy) and then a large postinstall script to (from comments):

# Regionalise — International prefpane settings
# Set timezone, timeserver, timesync=YES
# turn off password SSH
# Drop in admin user public key instead
# Disable software update
# let users set DVD region initially
# loginwindow set to name and password
# set login/out hooks
# periodic events on friday afternoons plz
# Quark fiddling – disable XTs, make help multiuser, make local preview cache folder
# delete CS3s ‘quality’ joboptions as they are far from that
# hide unwanted applications
# drop in the first_boot script

oh and some misc plistbuddy and AD credentials shenanigans. what’s your setup?

[Patrick Fergus]

We have the blessing of being able to use FileWave for our application deployment. We can divide our OS from our apps.

Anything that can be reasonably done [i]cleanly[/i] from either MCX or FileWave lives in MCX or FileWave. Then it doesn’t depend on modifying build trains, and any new app updates (e.g. Adobe CS3 updates) get applied to new and old clients equally.

Anything that would be more painful or touchy gets in the InstaDMG build (enabling AppleTalk via a script, setting the time zone via a script). Also, anything that makes initial setup easier for an admin gets into the InstaDMG build (binding to AD, enabling ARD DirectoryService-based authentication–put those two together and you have an image that you can set up without having to be on-site and you can start thinking about 100% script-based setup).

A [i]lot[/i] of the choices about where the various tweaks/apps/updates go is based on gut feeling and experience. Nothing helps you think clearer than having an update go awry (we once sent about 600 machines into repeated reboot loop for about three hours one evening), but people on this forum hope to help you not encounter that. We offer our guts and experience.

If you want to know a specific tweak and where it lies (or where we’d put it) in our build, ask away–I think I’ve laundry listed our tweaks elsewhere on the forum.

– Patrick

[jcontessa]

Hello. I know this post is a little old, but I am new to the InstaDMG idea and have it working well with DeployStudio in a fully automated restore. The only issues I have are all within this thread: Setting the Time Zone, Activating ARD and SSH, and enabling root. I would love to have all this automated to fully complete my deployment scheme but am not savvy with the programming part or what shell to use. Has anyone come up with a solution to these issues that can be placed in one file or package?

Here’s what I have so far:

/usr/sbin/systemsetup -settimezone America/New_York

/System/Library/CoreServices/RemoteMangement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -on -users admin -privs all -restart -agent -menu

dsenableroot -u admin -p ***** -r *******

For the SSH, I’m sure there is a way to remove the following from the /System/Library/LaunchDaemons/ssh.plist:
Disbaled

Is there a way to package all this into a launch daemon to run on first boot or login and then delete itself? That would be most desirable I would imagine.

Thanks for any help. It is MUCH appreciated!!! 😀

[Rusty Myers]

jcontessa,

I run a system modification script at boot. It sets all of these settings. I install the script to /Library/Scripts/ETC (ETC being the department I work in). Then I use a launchd item to run the script. I used Lingon to make my launchd item.

Here’s a good thread on the commands to run in your script.
https://www.afp548.com/forum/viewtopic.php?forum=45&showtopic=22379&highlight=systemsetup

I can share my script if you want to check it out, email me.

[jcontessa]

that program looks great. should make it real easy. thanks for the referral

[alantrewartha]

“Setting the Time Zone, Activating ARD and SSH, and enabling root”

i never enable root, so can’t help you there, but activating ARD and SSH can be done in a simple script or script only installer PKG. Time zone i think ditto.

i will dig out my scripts at work tomorrow

[Rusty Myers]

Check out this thread:

https://www.afp548.com/forum/viewtopic.php?showtopic=23151

[alantrewartha]

ok, just checked for sure, and we’ve reduced ‘first boot script’ down to just AD binding and enabling appletalk! (which isn’t even working well on our network 🙁 — but our next step is to dump appletalk by ensuring all our printers accept IPP printing anyway)

everything else is in script-only PKGs. we use a standard ‘activate ARD and SSH’ PKG (script only) that is baked into our standard DMG and keep other custom settings in one ‘customising’ PKG that is run at image time

here’s the script from the ARD/SSH PKG
[code]/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart \
-targetdisk “$3” -activate -configure -access -on -users admin_user_name -privs -all -restart -agent

/usr/libexec/PlistBuddy -c “Delete Disabled” “$3″/System/Library/LaunchDaemons/ssh.plist
[/code]

and here’s the script we use for timezone setting in the customising PKG

[code]# Set timezone, timeserver, timesync=YES
timezone=’Europe/London’
timeserver=ourtimeserver.fully.qualified.domain
TARGET=”$3”
target_volume=`echo ${TARGET} | sed ‘s/\/$//’` # Remove trailing slash from target_volume (if there is one)
ln -sf “${target_volume}/usr/share/zoneinfo/${timezone}” “${target_volume}/etc/localtime” # Set timezone by creating a symbolic link
echo “server ${timeserver} iburst” > “${target_volume}/private/etc/ntp.conf” # Create an appropriate ntpd.conf file
sed -i .bak ‘s/TIMESYNC=-NO-/TIMESYNC=-YES-/’ “${target_volume}/etc/hostconfig” # Update the hostconfig file to use NTP
[/code]

[Author]

Posts