Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Apple > Operating Systems

  • Print
  • + Share This
This chapter is from the book

Cloned Image: Clean Up System

After you have completed all your model system customizations, you need to purge the model system volume of any items that should not be deployed to multiple computers, such as computer- and user-specific preferences and cache files that are not appropriate for other systems.

Once you have cleaned up the model system, be sure not to reboot it, otherwise many of the files you have purged will be re-created. If you must reboot the model system to make a correction, you will have to clean the system again. In fact, any time in the future when you need to update the cloned system image, you will have to reclean the model system volume before you can create a new cloned system image.

Working from the Creation System

It’s easiest to properly clean your model system volume from your creation system.

  1. Whether you’re using two separate Macs or two bootable volumes, shut down the model system.
  2. Now start using the creation system. You will need administrative access on the creation system.
  3. Mount the model system volume on the creation system.
    • If you’re using two separate Macs, restart the Mac with the model system volume in target mode by clicking the Target Disk Mode button in the Startup Disk system preference. Using a FireWire cable, plug the Mac with the model system into the booted Mac that will act as the creation system.
    • If you’re using a single Mac, use the Startup Disk system preference to set the creation system volume as the startup volume and restart the Mac.
  4. With the model system volume mounted on your creation system, rename the model system volume in the Finder. When you create a deployable system image, the name of the system volume will persist through the entire deployment to each system, so choose a name wisely.

    You could stick with the default Macintosh HD name, but to prevent accidentally targeting the wrong volume, and to further designate this as a custom system, you should change the model system volume name to something organization specific.

Removing User-Specific Files

Remove from your model system volume any user-specific files that are not necessary or are tied to computer-specific settings. In most cases the only local account left on your model system volume at this point is an administrator account. If you do have multiple local user accounts still on your model system volume, you will need to clean out each individual user’s home folder.

The following example presents a list of the user-specific files that should be removed from the model system volume. This example assumes the model system volume is mounted to a creation system and is named PretendcoHD, and that the only local user account on the model system is Michelle. The only command needed is sudo rm -rf, so you could enter all these items in a single command, but they are on separate lines here for easier reading.

sudo rm /Volumes/PretendcoHD/Users/michelle/Send Registration
sudo rm –rf /Volumes/PretendcoHD/Users/michelle/Desktop/*
sudo rm –rf /Volumes/PretendcoHD/Users/michelle/Downloads/*
sudo rm –rf /Volumes/PretendcoHD/Users/michelle/Library/Caches/*

Removing Computer-Specific Files

You should also remove from your model system volume any computer-specific files that are not necessary. The following example presents a list of the computer-specific files that should be removed from the model system. This example assumes the model system volume is mounted to a creation system and is named PretendcoHD. Again, the only command needed is sudo rm -rf, so you could put all these items in a single command, but they are on separate lines here for easier reading.

sudo rm -rf /Volumes/PretendcoHD/Documentation/old_*
sudo rm –rf /Volumes/PretendcoHD/Library/Caches/*
sudo rm –rf /Volumes/PretendcoHD/System/Library/Caches/*
sudo rm –rf /Volumes/PretendcoHD/Library/Managed\ Preferences/*
sudo rm –rf /Volumes/PretendcoHD/Users/Shared/*
sudo rm -rf /Volumes/PretendcoHD/private/etc/ssh_host*
sudo rm -rf /Volumes/PretendcoHD/private/var/db/volinfo.database
sudo rm -rf /Volumes/PretendcoHD/private/var/vm/swap*
sudo rm -rf /Volumes/PretendcoHD/private/var/vm/sleepimage

If you plan to use computer-based managed preferences, perform authenticated binding to an Open Directory server, or take advantage of other local Kerberos authentication features, then you will also need to reset the Local Kerberos Distribution Center (LKDC). The following commands present the easiest method to remove the current model’s LKDC and force it to rebuild on the next startup:

sudo rm -rf /Volumes/PretendcoHD/private/var/db/.configureLocalKDC
sudo rm -rf /Volumes/PretendcoHD/private/var/db/krb5kdc
sudo rm -rf /Volumes/PretendcoHD/private/etc/krb5.keytab
sudo rm -rf /Volumes/PretendcoHD/Keychains/System.keychain

There are several folders of computer-specific preferences that may also cause you problems when deploying to different types of hardware or computers destined for users with different levels of managed preference settings. Whether you have to remove files from these folders depends on your specific deployment scenario. In some cases you may have to modify these items after system deployment, as covered in Chapter 6, “Postimaging Deployment Considerations.”

However, if you experience configuration problems when testing your deployment, these folders will contain your primary suspects:

  • ~/Library/ByHost/—This folder is in every user’s home folder and holds preference files that are both user specific and computer specific. By design, none of these preferences will work on other systems.

  • /Library/Preferences/SystemConfiguration—This folder contains fundamental system configuration information, such as power management and network settings. Many of these settings don’t translate to systems with different hardware configurations.

  • /Library/Preferences/DirectoryService—This folder contains all the Directory Service settings. In general, if you do any sort of authenticated binding, including Active Directory binding, these items do not work when deployed to multiple systems.

  • + Share This
  • 🔖 Save To Your Account