This chapter is from the book
This chapter is from the book
This chapter is from the book
Creating a Cloned System Image
Creation of a cloned system image suitable for deployment involves just a few main steps:
- On a model system, install and update all necessary software, configure system settings, and perform any additional customizations.
- Purge the model system of files not suited for deployment.
- Copy the model system to a read-only (optionally compressed) disk image.
- Prepare the system image for deployment.
Required Equipment
To create a cloned system image, you need either two Mac computers or one Mac with two bootable volumes that have Mac OS X v10.5 installed. If you have two Mac computers, one will be used to build the model system, and the second will be used to create the cloned system image. If you are using one Mac with two separate bootable volumes, one volume will be used to build the model system, and the other volume will be used to create the cloned system image.
If you are using two separate Macs, you will also need a FireWire cable to connect the two so you can clone the model system to the creation system.
In either case, make sure that both the model and creation volumes have enough room to build your cloned system image. The model volume needs enough room to install the system and any additional items you intend to deploy, and the creation volume needs roughly twice the available space used on the model volume. Thus, if your model volume uses 10 GB of storage space, your creation volume needs 20 GB of available space.
Customizing the Model System
Your first step is to create and customize your ideal model system, installing and updating all necessary system software, application software, and support software and configuring as many settings and preferences as possible.
Assuming you meet the prerequisite level of knowledge suggested by this guide, equivalent to the requirements for Apple Certified Technical Coordinator certification, you should already have a good idea of how to configure your model system. In this section, you will learn to perform advanced customizations to further optimize your system image for deployment.
Each custom configuration demonstrated in this section can be used individually, but when combined, they allow you to present the user with a system that is tightly integrated with your organization and its policies.
Restarting the Setup Assistant
The Setup Assistant is the first interface most Mac OS X users see when they start a new Mac for the first time. The Setup Assistant guides the user through the process of configuring initial settings, including the creation of an administrative user account. However, after this initial setup is complete, the Setup Assistant no longer appears at startup. You can force the Startup Assistant to run at the next system startup to give users some control over their own computers, including the ability to create their own user accounts.
If you want to make the Startup Assistant run at the next system startup, simply remove the /var/db/.AppleSetupDone file. This file is protected by root access, so the quickest method to remove this file is to enter sudo rm /var/db/.AppleSetupDone at the command line. When a user restarts the computer, the Setup Assistant will launch, allowing the user to make several configuration changes. This potentially includes changes that are not ideal for your deployment, including the following:
- The user will be allowed to set the default keyboard and language, enter registration information, their Apple ID, and .Mac information, and reset the time zone.
- If networking is already set up, the user will not be allowed to configure any network settings at this point.
- The user will be able to create an additional administrative user account.
- The Setup Assistant will enable automatic login for the newly created user.
- The Setup Assistant will change the computer’s name using the following convention: new user’s name followed by the computer model.
)
Unfortunately, you cannot limit what the Setup Assistant allows the user to configure. If you still want to use the Setup Assistant but you need to limit the changes, you can implement a script to automatically reset some of these items after the Setup Assistant finishes. Techniques for implementing such a script is covered in Chapter 6, “Postimaging Deployment Considerations.” If you change your mind about restarting the Setup Assistant, you can easily replace the appropriate file by entering sudo touch /var/db/.AppleSetupDone at the command line.
Customizing the Setup Assistant
To customize your users’ new Mac experience, you can change the QuickTime video and MP3 audio files played at the introduction of the Setup Assistant. You can use any content-creation tool you like to create custom organization-specific replacements for these files. For instance, you could create a movie that reminds the user of your organization’s usage policies, or you could create replacements that essentially play nothing. When creating your custom introduction media, keep in mind that the video and audio files start playing simultaneously, but the video ends before the audio file to allow the user to continue the setup process accompanied by background music.
The files you must replace are located inside the Setup Assistant package, in the /System/Library/CoreServices/Setup Assistant.app/Contents/Resources/TransitionSection.bundle/Contents/Resources folder. In this folder you will need to replace the intro.mov and intro-sound.mp3 files. These files are protected by root access, and you should back them up just in case you need to return the Setup Assistant to its original state.
In the following example, Michelle uses the command line to back up the original audio and video files, and then replace them with two custom files that she has created on her desktop. Michelle first navigates to the appropriate folder inside the Setup Assistant package. Notice that she uses the sudo command to bypass the file system permissions.
MyMac:~ michelle$ cd "/System/Library/CoreServices/Setup Assistant.app/Contents/ Resources/TransitionSection.bundle/Contents/Resources" MyMac:Resources michelle$ sudo mv intro.mov intro.mov.old MyMac:Resources michelle$ sudo mv intro-sound.mp3 intro-sound.mp3.old MyMac:Resources michelle$ sudo cp /Users/michelle/Desktop/custommoive.mov intro.mov MyMac:Resources michelle$ sudo cp /Users/michelle/Desktop/customsong.mp3 intro-sound.mp3
Customizing the Login Window Message
You can also customize the login window to meet your organization’s deployment needs; for instance, display information such as usage policies. Ideally, you should configure custom login window settings using MCX settings hosted on a directory server. However, if you don’t have a directory service capable of hosting MCX settings, you can enable these settings on your model system and make them part of your system image deployment.
The login window is managed by the loginwindow process, which references settings located in the /Library/Preferences/com.apple.loginwindow.plist preference file. You could edit this file using the Property List Editor application included with the Xcode Tools suite, but it’s much quicker to use the defaults write command to add the necessary customizations to this file. Because this file is protected by root permissions, you would use the sudo command to bypass those restrictions.
Using the defaults command, you must add a new property key, LoginwindowText, to the loginwindow preference file. The value for this new key will be the string of text you want shown at the login window inside quotation marks. For example, to customize the login window text with a usage policy notice, you would enter the following at the command line:
sudo defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "By logging in to this computer you are agreeing to the usage policies found in Pretendco document UP-1052. Thank you, and have a nice day."
To test your custom configuration, log out of your current session and observe the login window.
)
Customizing the User Template
Whenever a local or mobile user account is created, the system also creates a local home folder for that user. The contents of these created home folders are based on the system’s user template. You can customize this user template to prepopulate new users’ home folders with any items, including preference settings.
For example, you can customize the user template to set a default background for every user, perhaps presenting usage policies or help information for novice users. However, the desktop background is saved as a per-user setting, and the user can change it at any time from the Desktop & Screen Saver preference or iPhoto.
Ideally, to set and lock specific user settings, you should use MCX settings hosted on a directory server. However, if you don’t have a directory service capable of hosting MCX settings, you can place user-specific preference files containing the settings in the user template on your model system and make them part of your system image deployment.
To set the desktop background using the user template:
- Log in to your model computer with an administrative account.
- Place the image file you want to set as the desktop background in a location that all users will be able to access, such as the /Library/Desktop Pictures folder.
- Open the Desktop & Screen Saver preference and set the desktop background for the administrative account to the desired image file. You will have to drag the image file from the desktop into the image well area at the upper-left corner of the preference pane.
- Set any additional desktop background features, and then close the Desktop & Screen Saver preference.
This creates a properly formatted desktop property list preference file in the administrator’s home folder.
- Copy the com.apple.desktop.plist file from the administrative account’s ~/Library/Preferences folder to the appropriate folder
in the user template: /System/Library/User Template/English.lproj/Library/Preferences/.
This folder is protected by root access, so you will have to use the command line to copy this file into the appropriate location. In the following example, Michelle uses her administrative account to copy the desktop preference file into the user template.
MyMac:~ michelle$ sudo cp "/Users/michelle/Library/Preferences/com.apple.desktop.plist" "/System/Library/User Template/English.lproj/Library/Preferences/"
- Protect the desktop image file and desktop preference file from modification. This requires changing the files’ ownership
and permissions to be writable only by root but still readable by everyone else, and then setting the lock flag.
Again, because these items will have root permissions, the quickest method is to use the command line. In the following example, Michelle changes the ownership, permissions, and lock flag for the pretendco.jpg image file and the desktop preference file inside the user template.
MyMac:~ michelle$ sudo chown root:wheel "/Library/Desktop Pictures /pretendco.jpg" "/System/Library/User Template/English.lproj /Library/Preferences/com.apple.desktop.plist" MyMac:~ michelle$ sudo chmod 644 "/Library/Desktop Pictures /pretendco.jpg" "/System/Library/User Template/English.lproj /Library/Preferences/com.apple.desktop.plist" MyMac:~ michelle$ sudo chflags uchg "/Library/Desktop Pictures /pretendco.jpg" "/System/Library/User Template/English.lproj /Library/Preferences/com.apple.desktop.plist"
)
Normally when the user template items are copied to create the new user’s home folder, the ownership and permissions are set so the items belong to the user. However, because you set the lock flag, the copied desktop preference file will retain the original ownership and permissions you have set here. Thus, users will not be allowed to change the desktop background setting even if they have access to the Desktop & Screen Saver preference. The system preference will still remain active and allow the user to interact with the settings, but the desktop background will never change.
Creating a Hidden Administrator
Perhaps the cleverest advanced customization you can make to your model image is hiding the local administrative user’s account from the primary users of the computer. If the administrator’s account isn’t hidden, users can view the local user list at the login window, the fast user switching menu, and the Accounts preference; they can also see other users’ home folders in the /Users folder from the Finder and command line and when connecting remotely to a Mac that has file-sharing services enabled.
The technique covered here will hide all these clues from every user and will even hide the account from other administrative users. Although an administrative user who knows exactly what to look for can easily uncover and delete your hidden administrator, the vast majority of users will have no idea that the account is even there.
To create a local hidden administrative account:
- Log in to your model computer with an administrative account.
- Open the Accounts system preference, click the Login Options button, and set “Display login window as” to “Name and password.” Disable automatic login if you haven’t done so already.
- While still in the Accounts system preference, create a new administrative user account. Make sure to choose an appropriate short name as that will be this user’s primary login name. Also, do not activate FileVault for this user. Click Create Account when you are done.
- In the accounts list, right-click or Control-click the entry for your new administrative account and choose Advanced Options from the shortcut menu.
- In the Advanced Options dialog, change the user ID to 499 and the home directory location to any path that an average user would never navigate to. For instance, you could choose
any folder normally hidden in the Finder. Then click OK.
A good location to store the hidden administrator’s home folder is inside the /var folder. You can further “hide” the home folder by giving the home folder a name that begins with a period. For example, if your hidden administrator’s short name is hadmin, a good hidden home folder path would be /var/.hadmin.
- Move and rename the hidden administrator’s home folder and set the appropriate ownership.
Step 5 changed the hidden administrator’s user record, but in doing so you effectively removed access to this account’s original home folder. You must move the original home folder to the new path you chose in step 5 and correct the ownership for the home folder items.
Because you’re modifying another user’s home folder, the fastest method to restore access is to use the command line. In the following example, Michelle will move and rename the hidden administrator’s home folder, and then set the appropriate ownership.
MyMac:~ michelle$ sudo mv /Users/hadmin /var/.hadmin MyMac:~ michelle$ sudo chown -R hadmin /var/.hadmin
- Remove the Public and Sites folders from the hidden administrator’s home folder.
Even though we have moved the hidden administrator’s home folder, it may still show up when various network sharing services are enabled. This is easily remedied by removing the Public and Sites folders from this home folder.
Again, because you’re modifying another user’s home folder, the fastest method is to use the command line. In the following example, Michelle will remove the shared folders in the hidden administrator’s home folder.
MyMac:~ michelle$ sudo rm -R /var/.hadmin/Public /var/.hadmin/Sites
- Modify the loginwindow settings so it does not show the hidden administrator account or any account with user IDs below 500. This will also prevent
the Accounts preference and the fast user switching menu from showing accounts with user IDs below 500.
The quickest method to set these custom settings is to use the defaults command. In the following example, Michelle will modify the loginwindow preferences to hide accounts with user IDs below 500, and then hide the hadmin account.
MyMac:~ michelle$ sudo defaults write /Library/Preferences/com.apple.loginwindow Hide500Users -bool TRUE MyMac:~ michelle$ sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array hadmin
- Test your work by logging out of your current account and then logging in as the hidden administrator.
- If everything is working properly, delete your initial administrator account because it’s not hidden.
Aside from having an interesting location for the home folder, your hidden administrator account is identical in function to any other administrative account.
)
)
)
)
Purging the Model 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.
- Whether you’re using two separate Macs or two bootable volumes, shut down the model system.
- Now start using the creation system. You will need administrative access on the creation system.
- 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.
- 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, 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/Users/Shared/* sudo rm -rf /Volumes/PretendcoHD/var/db/volinfo.database sudo rm -rf /Volumes/PretendcoHD/var/vm/swap* sudo rm -rf /Volumes/PretendcoHD/var/vm/sleepimage
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 client 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 default, 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.
-
/Library/Managed Preferences—This folder contains the cache files used by the directory service MCX managed client system. These items should be cleared if you have defined computer-specific management settings from a directory server.
Cloning the Model to Create a System Image
Now it’s time to create a disk image of the model system volume. As you learned in Chapter 2, “Deploying Individual Items and Containers,” it’s fairly easy to create a disk image using the contents of a folder or volume. You can create disk images in the graphical interface using the Disk Image application and at the command line using the hdiutil command.
)
Here are a few tips to keep in mind when creating a cloned system disk image:
- Make sure to specify just the model system image volume, not the physical drive, as the source for the cloned system image.
- The cloned system image format must be read-only (optionally compressed) and not encrypted.
- Always make sure to have roughly twice the amount of free space available on the creation volume as the amount of used space on the model system volume.
- Using separate physical drives for the model system volume and the destination for the cloned system image will greatly reduce the disk image creation process.
- If you are unable to create the cloned system image because the system is reporting “Resource Busy” errors, unmount but do not eject the model system volume, and then create the cloned system image. Both Disk Utility and the hidutil command will still be able to create a cloned system image from the unmounted model system volume.
Preparing the Cloned System Image for Deployment
There is one last step to prepare your cloned system image for deployment. The cloned system image must be scanned in preparation for the Apple Software Restore (ASR) process. As you will learn in greater detail in the “Deploying System Images” section later in this chapter, the ASR process is used to restore the system image contents to a storage volume for deployment. The image scanning process can be performed by the Disk Utility application or the asr command.
The image scan process calculates additional data checksums for the cloned system image and stores this information in the disk image file. This checksum data is later used to verify the system restoration process. The image scan process will also reorder the cloned system disk image file if it is not properly ordered for the network ASR process. If the disk image file needs to be reordered, the system will have to rewrite the file to the same volume. This reordering process is why you need roughly twice the free space on the creation system to prepare the cloned system image for deployment.
To scan your cloned system image from the Disk Utility application:
- Open the Disk Utility application and choose Images > “Scan Image for Restore.”
- In the Open dialog that appears, select your cloned system image.
- Authenticate as an administrative user to initiate the scan process.
Depending on the size of your system image and the speed of your hardware, it can take anywhere from a few minutes to a few hours to complete the image scan process. During this time Disk Utility will show a progress bar dialog. When the process is complete, this dialog will let you know whether the image scan process was successful.
)
Scanning your cloned system image from the asr command is nearly as easy. The syntax is sudo asr imagescan -source followed by the path to the cloned system image. In the following example, Michelle scans the cloned system image she previously created, ClonedSystem.dmg on the external Storage volume. The asr command also displays image scan progress and success messages.
MyMac:~ michelle$ sudo asr imagescan -source /Volumes/Storage/ClonedSystem.dmg Password: Block checksum: ....10....20....30....40....50....60....70....80....90....100 asr: successfully scanned image "/Volumes/Storage/ClonedSystem.dmg"
Updating a Cloned System Image
One of the primary disadvantages of a cloned system image is that updates and changes are not easily made. Once a deployable system image is created, the image file itself can never be changed. Essentially, you have to replace your outdated cloned system image with a new cloned system image.
This process of having to build new cloned system images with every change is especially frustrating when you are testing and trying to work the kinks out of a new system deployment. Even the smallest change requires that you completely rebuild the entire system image.
There are three methods that you can use to update an existing cloned system image and still use your previous work as a starting point:
- Retain the original model system volume and apply your updates to the model system. Once the model system is updated, create a new cloned system image as outlined previously in this section.
- Restore the cloned system to a bootable volume as outlined in the “Deploying System Images” section later in this chapter. Treat this restored volume as the new model system and apply your updates. Once your updates are complete, create a new cloned system image.
- Convert the cloned system image to a read/write disk image as outlined in Chapter 2, “Deploying Individual Items and Containers.” Mount the new read/write disk image that contains your cloned system and apply the changes to the mounted volume. Once your updates are complete, convert the system disk image back to a read-only format and then rescan the image for deployment.