Image Creation Revolution

Image creation is one of the few things on Mac OS X that has been around long enough to be considered a time honored tradition. In fact, the first article I wrote for the site after the redesign was Disk Imaging for Mac OS X Made Easy and after nearly a quarter of a million reads it is our most popular article. There is a problem though. In the three years since I wrote that piece I've built hundreds, if not thousands of asr images, and I've been doing it wrong the whole time.

Odds are you've been doing it wrong too and once you read this two part series on imaging you will never return to building images the old way. The future is now and there is a better way.

Read on for more... 

The Problem

This isn't to say that everything in my previous article is wrong. It is the documented way to create an image from an existing Mac and therein lays the rub. This whole time we've been imaging existing Macs and that is just a bad way to do things. When you image an existing Mac you get existing cruft. Things like the NetworkInterfaces.plist are created on first boot and they contain information about the Mac that is currently booting.

I recently saw this cause an issue when an image created on a Mac Pro was deployed to anything with an AirPort card. Since the Mac Pro has two ethernet interfaces it assigned en1 to one of these. When a machine with a single NIC and an AirPort booted the image the AirPort was braindead as the system assumed that en1 was a gigabit ethernet NIC. Sure a solution could be to remove the NetworkInterfaces.plist before you image the drive, but that's a pain and is easy to forget. You also end up with things like .DS_Store files all over the place, Spotlight indexes, and other stuff that ideally shouldn't be sent out for deployment.

Even worse is when you live on the image for a while to test it first. You can forget all sorts of stuff and even worse not realize what is left behind. I've seen deployment images go out with interesting browser histories, or hundreds of MB in caches in the local admin account. This is all stuff you want to avoid on all sorts of levels.

Apple knows this is an issue and the scrub functionality of hdiutil helps out greatly, but it won't catch everything. That leaves it to the sysadmin to catch everything and that's just more work for you.

Let me tell you how I used to build images and see if this sounds familiar:

1. I create a "prefect" Mac.
2. I use it for a while to make sure it all works.
3. When I'm ready I trigger a cleanup script that removes all the Machine and user specific files I can think of.
4. I image that drive and deploy it to a pilot group.

Wrong, wrong, wrong. And I'll show you a better way in just a few moments.

More Problems

While the above might seem like a big deal it's not the worst of it. A huge problem in the above workflow is the amount of work that it takes. What happens when the next SecUpd comes out or the new seemingly bi-weekly Office patch is released? You go through that whole procedure again. Often you can skip a step and just image a fresh workstation, but it's still a pain to do and even worse, a pain to document.

Quick! Tell me every non-Apple application you have on your deployment image. How about every configuration change? How about the GUID of the local admin user? If the auditors demanded it by close of business could you provide a list of every file that has been added or modified beyond the Apple defaults? Some of you can probably do this. You are probably also using radmind and spend your days hunkered over a glowing LCD. I know, I used to be there too. I'm now a member of the Reformed radmind Admin Club.

If you are like most of us out there with monolithic deployment images you really have no idea what is in that image. You know you installed CS3 and Office, but what does that mean? SOX auditors aren't known for thier funny side at work and they don't like vague descriptions of what is on a disk.

The Solution (Seriously)

This is going to sound like a joke to many of you, but here it is. Use installer packages. No, really. Use installer packages when creating your images.

There are some really good reasons to move to a pkg based system:

• Packages are a standard format
• Packages can be installed with a variety of tools
• Packages can run scripts
• Packages are auditable.

What I'm proposing you do is move to a fully packaged based install. No more manual tweaks to files; no more scripts run by hand. Put it all in packages. When you do this you modularize the imaging process. No longer do you need to remember what tweaks you do where. You simply put it in a package.

A nice benefit to all of this is that you can now push these updates with all sorts of tools to your existing deployments or migrate to other deployment tools with great ease. What do NetInstall, Casper, puppet, ARD, and FileWave all have in common? They can use the pkg format. If you already have all of your deployment in pkg form then you are ready to go if you move to one of those systems. Even better, Apple's CSS Group (Custom Software Solutions) can take all of those packages and then deliver pre-imaged Macs to your door. If this sounds nice ask your SE for more details.

To create all these packages you have a bunch of options these days. The most popular three seem to be PackageMaker, Composer, and Iceberg. My recommendation is to use a combination of the first two. Between the two of them you can get everything bundled up pretty quickly.

PackageMaker is Apple's official packaging tool and for sysadmin types it allows us to create very specific packages to run a script or to drop a few files here and there.

Composer is from JAMF Software and is now available separately from the Casper Suite. Composer is a snapshot based tool for creating packages of application installs. I know that PackageMaker has some snapshotting tools at the command line, but Composer is just so easy to use that it's well worth the purchase. (Here's a quick tip. You can purchase Composer for half-price if you have an ARD license.)

Another advantage of packages is that they are easy to audit too. With a package based install you are a simple lsbom run, or even Show Files... in the Installer, away from knowing every single file you have installed or modified on the deployment image.

So now we have the understanding that packages create a modular, repeatable, auditable source for creating a deployment image. The question you now have though is how to use all these packages to your advantage and avoid the lived-in image problem?

Stay on Target

One of the nice features of the Apple Installer is that we can target just about any volume we choose. All you need to do is pick the target and let fly with all of your packages, in order, to a volume. Then image that and you have your never booted Mac OS X image. Clean and tasty.

Your first thought may be to target an external drive, but Mac OS X is more flexible than that. The ideal target is a disk image since it requires no extra hardware. Now for those of us with single disk systems this can create a host of performance issues due to IO contention. But what do you care about that if it happens while you sleep?

The Big Tease

You read that right, while you sleep. Perhaps the greatest advantage to all of this is that a fully package based install can be fully automated. Part two of the series is going to cover this in detail, but I'll give you a tease now.

In order to automate your ASR image creation you only need to do the following:

1. Create three folders. One contains the OS install, one the Apple Updates, and one your custom packages.
2. Write a script to install all of these, in the correct order, and then spit out an ASR image.

Luckily we have done step two for you. We call it InstaDMG and it is going to change the way you image forever.

I'm putting the final cleanup tweaks on the script now, and will release it soon, but you can already see the advantages this is going to bring.

Imagine that you have created and populated the three folders. Now schedule InstaDMG to run every night and every morning you have a fresh image waiting to be tested. The next time an update comes out all you need to do is drop it in the correct folder and wait. The most effort you will ever need to put forth is to package an update that didn't come in a pkg. As more developers adopt the package format even that is a dwindling task.

InstaDMG promises to deliver fully-automated nightly builds of deployment images and free you from system building drudgery.

But Wait There's More...

InstaDMG is just one part of the suite of tools designed to make your life easier. Since we are fully automating the image creation process we might as well automate first round QA testing as well.

After InstaDMG creates the image we can have it blast it onto another partition and reboot. Once that is done we can then turn to a tool like Redstone's Eggplant to automate all of the basic testing that we need to pass the SLA (Service Level Agreement) we have with the users. Having that SLA allows us to stop feature creep in our images and it allows you to define what is considered a "good" image and what is not.

Using Eggplant you can create a test suite that validates the basic SLA that has been established. Things like does Word launch, can Safari log into the intranet sites, do all my Photoshop actions work, things like that. This SLA is a contract with the user base that if each point on the checklist works, it's a good image.

If everything passes the Eggplant suite then you are ready to push the image or updates to your pilot group. Remember that all of this has been automated for you during the night. All you need to do is sleep.

Part two is coming soon, and then InstaDMG can be yours as well. Stay tuned...