InstaDMG & Casper postmortem

milesleacy
Valued Contributor

Hi all,

I thought I'd share some thoughts after exploring InstaDMG. I assume that
those of you who are familiar with both Casper and InstaDMG will probably
agree, the two tools have a certain similarity in approach to the problem of
imaging. There was something about InstaDMG that caught my attention and
interest, so I decided to investigate. Here's what I found.

The reason I wanted to explore InstaDMG was that some of the concepts that
Josh Wisenbaker put forth as reasons for creating the project made sense to
me, namely avoiding so called "boot cruft" and "testing cruft".

Boot cruft (and I'm paraphrasing and interpreting here) is the collection of
files, settings and configurations that get created when you boot an OS for
the first time. The worst of these, in my opinion, are duplicate and
dead-end network settings.

Test cruft would be things like browser histories and other bits, typically
found in the admin and/or generic user account(s) after doing a "burn-in"
test of the image.

The idea of a never-booted base OS image that lacked this "cruft", and from
which to build my configurations in Casper Admin, was very appealing.

So I read up on InstaDMG, watched Mr. Wisenbaker's archived webcast,
downloaded the tool and started experimenting. What I found was the
following (and these are just my opinions and observations):

InstaDMG is intended for people who are still building monolithic images and
do not use a system management & deployment suite such as Casper. In "Image
Creation Revolution" (
http://www.afp548.com/article.php?story=ImageCreationRevolution), Mr.
Wisenbaker talks about modularizing your deployments via packages in order
to simplify altering and/or updating your deployments. If you're using the
Casper Suite, I imagine you're probably already doing that. In addition,
the InstaDMG implementation (numbered folders, building payload-free
packages to deploy scripts) seems clunky compared to Casper.

Boot cruft and test cruft can be undesirable, but it can also be excised via
scripting. In fact, nearly anything on a Mac OS X system can be scripted,
and those scripts can be added to Casper and used in Configurations and/or
Policies. networksetup, systemsetup, defaults, plistbuddy and the standard
BSD tools allow you to alter just about any setting you'd need to via
scripting. Add Applescript to that and I'd say there's very little you
can't do via some form of scripting.

As for potentially "bad" things appearing in browser histories, the
pragmatic lifelong Brooklynite in me wants to say, "if your techs are
browsing questionable material when they're testing an image, then maybe
they shouldn't be techs and maybe a social problem shouldn't be solved with
technology." However, the reality is, it could happen, and who wants to
explain to the CIO, School Board, or whomever you ultimately report to that
"Dopey the technician" put naughty content on the iMacs? Scripting can save
you here too.

I have an even broader, sweeping, foolproof (if it works) idea on
eliminating these unwanted account settings... build your base image, then
enable root, and delete all local accounts other than root. Create all
local accounts via Casper Imaging at deployment, or via Policy or Casper
Remote once deployed. If there's no account present, it can't have cruft in
it. I haven't tried this yet, but I will and I'll let you know if I
discover any reason not to go this route.

Another option I'm considering is creating an Apple Netinstall image of the
OSX Install Disc and using the automator workflows built into System Image
Utility to add your own Casper QuickAdd.pkg The benefit here is that you
know you have a clean installation, and the contents of a retail install are
known, so you can customize to your heart's content by scripting any changes
to or removal of items and packaging any additions. You would also need to
suppress the Setup Assistant and script the initial naming of the computer
unless you want to have a local admin account created at first boot. In
this scenario, I might give all machines the same name and scope a smart
group to that computer name to install all company-wide software and
configurations. Another option could be autorun data that specifies an
OS-free configuration.

All in all, InstaDMG is an interesting idea. In fact, InstaDMG reminds me
of a set of scripts I was using before I first purchased Casper. I was also
reminded why I abandoned homebrew scripts in favor of the Casper Suite. I
believe that as Casper users, we have a better tool (dare I say best of
breed?), with top-notch customer service, that can achieve the same goals
for us with less work. Not to mention that imaging is just one piece of the
Casper pie that also comes with Inventory, A policy engine, ongoing
deployment & maintenance and a logged VNC solution.

These are just my thoughts and observations. Test, test and re-test
anything and everything before using it in production. Only you know your
own environment and only you can say what is acceptable in that environment. If you take any of my ideas into a production environment, I take no
responsibility for anything that might go wrong up to and including loss of
data, termination of employment and the destruction of the known universe.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

0 REPLIES 0