Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

When deploying system software with disk images, it is helpful to have various checkpoint images that you can revert to while you’re building up a fully-fledged template computer. This is something they teach you in school (really, I was taught it in a systems administration class) and it’s more or less encoded in the solution accelerator documentation for Microsoft’s Business Desktop Deployment 2007 for Windows.

However, if you’re updating images, keeping the base and intermediate images can strain your storage capacity. Mac OS X lacks the compelling live editing features of Microsoft’s new WIM image format — which if it had appeared first on the Mac, I’d be trumpeting loudly, so I feel compelled to at least give a nod to Microsoft here.

Since I’m always struggling with storage capacity and I prefer having an up-to-date base image, I thought about this problem a bit in the context of Mac OS X imaging and have come upon what seems to be a unique solution: the use of shadow files.

Here’s the basic idea:

1. Create a base operating system install on a partition of your template computer’s disk
2. Capture a compressed, read-only image of it immediately (go wild, save the extra percent or two, and compress it with the Tiger-only bzip2 scheme … you can afford to do this if you have time and are only deploying with a Tiger startup disk)
3. Scan the base image for Apple Software Restore’s block-level checksums
4. Attach that base image to the filesystem — honoring ownership and specifying a shadow file — so that it acts as if it is writable, using hdiutil
5. Install the latest Mac OS X combo update on it
6. Create a new read-only compressed image of the mounted volume
7. Prep the new updated base image for ASR.

Congratulate yourself on this use of shadow files, because you’ve saved at least one intermediate step and the space required for a full read-write disk image — or worse, an extra local partition needed only for restoration and updating the base image.

Unmount that volume and throw away the shadow file at this point if you want, because you’ve now got two system images ready for deployment. One has the base system software, and serves as a checkpoint that you can return to later; it’s the base for all future updates of that major revision of Mac OS X. The other image has the latest version of Mac OS X. If you’re deploying that image with ASR, the result will be a more secure system because it’s closer to being fully patched — and it should take less time to update it with the additional security updates and application installs — whether you use installers or Radmind or another solution — because you’ve got the bulk of the operating system done.

Unfortunately, many updates can only be installed on the startup disk and thus cannot be included in the updated base image. Beyond the combo operating system updates, few of Apple’s other installers will work on a non-startup volume. But you can install them after deploying the updated base image, using your tool of choice. For reasons like this, Geoff doesn’t see updating the base image as valuable, but in some IT environments, it may be very worthwhile.

My next step is to script this process and tie it to a watched folder. Imagine dropping a combo update into a watched folder … and letting a script generate the new, updated image for you.