Volume Number: 24 (2008)
Issue Number: 03
Column Tag: MacEnterprise
By Philip Rinehart, Yale University
In the System Imaging and Deployment Power Tools session at Macworld this year, there was a large amount of time spent discussing system imaging. How does it work? What are best practices? Are there best practices? How do you deal with new hardware, and more were asked. I thought it would be useful this month to reexamine the practice of image creation. Let's start by looking at what we mean by an image.
In traditional Macintosh system administration, an image is a base operating system plus some amount of software that is applied to one or more machines. In general, the nirvana has been to create a single image that can be applied to many different models of Mac machines. Is this goal achievable, or is it like Buddhism, in which the journey is more important?
The first rule of system imaging is that an image must be created from the most current model of Macintosh in any deployment. Typically this image is created from the installation media that was shipped with the hardware. For example, if your deployment includes a quad core Intel machine, then create the image from that disc. Is this rule inviolable? No.
How do you update an existing image? Wait until the dot release update. That is, if your image was created on 10.4.10, update your image for new hardware at 10.4.11. There is some debate about using a combo updater or a delta. Generally, I prefer to use the combo updater, as each and every update from the Gold Master is applied. This method can be used to update existing images pretty reliably. There are of course exceptions, but now that a universal operating system is available, Leopard, this method should work in most cases.
The second rule of thumb in system imaging is how to create a default template. Note that this method applies to local accounts, not network accounts. First, create a template user using system preferences. Next, login as that user, and run each application that it is important to configure. Common configuration items include web browsers, word processing applications, or site-specific applications that need consistent settings. There are a couple of gotchas though.
First, for the template user, don't store anything in the keychain. When the template is copied over any item stored in the keychain will be inaccessible to the new account. It is safe to delete the keychain after finishing custom configuration as well. Secondly, be certain to set the proper downloads folder for each web browser. In Tiger, if the Safari download folder were not set, a copied template would contain an inaccessible path. The last gotcha is for any preferences that are machine specific. This type of preference is usually stored in ~/Library/Preferences/ByHost. Common items here include iTunes preferences, screensaver preferences, and others. A hardware address is embedded in the preference file name. It can be corrected with a loginhook.
Before applying any image, it is important to do some basic cleanup. What should be cleaned up though? There are a few obvious things to remove for initial cleanup. Get rid of any Cache files stored in /Library/Caches, and /System/Library/Caches. Next, remove both swap files and sleep images. These are located in the directory /var/vm, and can be significant in size. One other cache can also be removed, the BootCache.playlist located in /private/var/db.
What about other types of files? Generally, I would recommend moving the Network Interfaces plist in /Library/Preferences/SystemConfiguration. In general, these files are machine specific, and will get recreated by the operating system on first boot. This also removes any possible conflict if an image has a different network interface configuration then its target.
System wide, these files are ignored by Time Machine, and can probably be eliminated from any image.
/.Spotlight-V100
/.Trashes
/.fseventsd
/.hotfiles.btree
/Backups.backupdb
/Desktop DB
/Desktop DF
/Network/Servers
/Previous Systems
/Users/Shared/SC Info
/Users/Guest
/dev
/home
/net
/private/var/db/Spotlight
/private/var/db/Spotlight-V100
Note that most of these files are fairly logical to be excluded. The operating system will recreate any of these files at first boot.
Clean up of the User Template can also be a little more complete as well. Here are the files that can be excluded from the User Template. Most are related to browsers and rss feeds.
Library/Application Support/MobileSync
Library/Application Support/SyncServices
Library/Caches
Library/Logs
Library/Mail/Envelope Index
Library/Mail/AvailableFeeds
Library/Mirrors
Library/PubSub/Database
Library/PubSub/Downloads
Library/PubSub/Feeds
Library/Safari/Icons.db
Library/Safari/HistoryIndex.sk
The last thing to eliminate is any Log files, both in /Library/Logs and /private/var/log. No need to have any of these items on an image! Note that the cleanup process is best scripted, as no one really wants to remember all of these steps!
Now that you have created your "perfect" image, it is time to get it ready for deployment. Are there best practices here? I think so. First, it is best to boot from an alternate volume. This volume can be a separate partition, or an external drive. Once booted the steps are pretty straightforward.
1. Open Disk Utility
2. Select the drive or partition that is the model for imaging
3. Select "Image from Folder" and select the hard drive and wait. A long time.
4. Select "Scan Image for Restore" and scan the newly created dmg file.
That's it! You then have an image that is ready for deployment via whatever method you have in place to put an image on a machine via multicast ASR, NetRestore, or any other method you have of getting the image on the machine. One important note though, it is generally best to have at least twice the amount of space needed to create an image on your external drive. If your drive has any less than that, the imaging operation may fail.
The method I have just described is the "Classic" way of creating methods and is fairly tried and true. However, it isn't really very scalable, or flexible as the image is a point in time snapshot. The way of the future can be seen in two areas, the new System Imaging Utility in Leopard and InstaDMG from afp548.com. Both take the idea of monolithic image creation, and move it to a more modular approach. Ultimately this approach is far more flexible, allowing updating any image at a moments notice. It also makes it easier to be extremely flexible and adaptable, which is a good thing in today's fast moving environments. It was good to see all at Macworld this year, until next month see you on the lists!
Philip Rinehart is co-chair of the steering committee leading the Mac OS X Enterprise Project (macenterprise.org) and is the Lead Mac Analyst at Yale University. He has been using Macintosh Computers since the days of the Macintosh SE, and Mac OS X since its Developer Preview Release. Before coming to Yale, he worked as a Unix system administrator for a dot-com company. He can be reached at: philip.rinehart@yale.edu. The MacEnterprise project is a community of IT professionals sharing information and solutions to support Macs in an enterprise. We collaborate on the deployment, management, and integration of Mac OS X client and server computers into multi-platform computing environments.
