Common Issues and Solutions

There are a number of issues you may encounter as you are testing your method of deploying Mac OS X. Consider these issues and resolutions as you plan.

Requiring Permissions

Some applications require specific permissions on the folders they reside in and the folders they access. As you test your deployment method, part of the testing will include documenting how applications work in a "normal" configuration. Pay particular attention to permissions.

Some applications running in Mac OS X will behave erratically if they are run from a read-only folder. This is common for applications that save preferences to their own folders, rather than to a standard Library folder. If this is the case, copy the application to a folder in the user's home folder or create a folder in /Applications that is read/write for all users.

Note

Particularly on multiuser computers, you should exercise extreme caution when giving users read/write access to folders outside of their home folders. Giving them that access can expose the system to the potential for malicious activity and is considered a security risk.

Some Classic applications won't run if the Classic System Folder can't be written to. If you plan on setting the permissions on the System Folder to read-only, test your application before deployment to determine how it will behave with this configuration. If the application doesn't work properly, run Classic from a disk image and mount the disk image with a shadow file using ShadowClassic, from Bombich Software (www.bombich.comwww.bombich.com), or with the following commands:

 cd /System/Library/CoreServices/Classic\ Startup.app/Contents/MacOS sudo mv Classic\ Startup Real\ Classic\ Startup sudo ditto ~/ShadowClassic.app/Contents/Resources/shadow ./Classic\ Startup 

Deploying Site-Licensed Software

Many professional applications in Mac OS X use serial numbers to control licensing of the software. In some of those applications, the serial number is user specific, rather than computerwide. If you have configured an application to be deployed using a user-specific serial number, you might find that, although the application was installed/copied to the client computers, users are unable to run the application.

In some cases, you will be working with professional applications that use a serial number tied to the Built-in Ethernet Media Access Control (MAC) address. Again, even though the application may get copied during deployment, it might never run on any computer other than the computer on which it was initially installed. Regardless of where the software is to be used, a work-around may violate software agreements. A better method is to contact the vendor for a site license of the software, and inquire as to the proper method of mass deployment.

Using Firmware Passwords

If a user has set a firmware password for the computer, you won't be able to use the keyboard sequences to start up the computer from a different boot device without supplying the password. This inhibits the ability to use many of the methods described previously, such as changing the NetBoot image from which users are booting.

If you can log in to the computer as an administrator, you can change the startup disk without knowing the firmware password. You can also change or remove the password using the Open Firmware Password utility. If you don't have a copy of the utility handy, you can also use the nvram command to delete the firmware password:

 sudo nvram -d security-mode sudo nvram -d security-password 

If you can't log in as an administrator and don't have the existing firmware password for that computer, you will have to change the amount of RAM in the computer by shutting down the computer, adding or removing memory cards, and then reset the PRAM by holding down the selected keys (Command-Option-P-R at startup) while the computer chimes three times as it boots. For more information, refer to the AppleCare Knowledge Base article "Setting up firmware password protection in Mac OS X 10.1 or later" (http://docs.info.apple.com/article.html?artnum=106482).

Binding to Active Directory

If you are binding your computers to Active Directory for authentication, you'll want to personalize the computer name for each individual Mac OS X computer. (This is taken care of automatically using Windows computers bound to Active Directory.) A work-around for this issue is to unbind your image master computer, still keeping the search paths configured. Once a computer has been imaged from the master image, use dsconfigad as a one-time startup item. Since computers listed in Active Directory must have unique names, have a startup script pull the Built-in Ethernet (MAC) address and use that as the computer name prior to running dsconfigad. For example, the following script pulls the MAC address and uses it for the computer name:

 #!/bin/sh MACaddr=`ifconfig en0 | awk '/ether/ { gsub(":", ""); print $2 }'` dsconfigad -f -a $MACaddr -domain yourdomain -u username -p password 

Handling Static Network Values

There are a number of computer-specific, sometimes called static, values, such as the IP address, computer name, SSH key, and ByHost files. On an ASR image, these values will be the same as those on the computer from which the image was made. When you deploy that image, the values get copied to the target computer. You have a couple of options for resolving this issue. One is to use the System Image Utility to configure computer names to be used on client computers, or to modify host-specific settings such as the directory service that will be accessed and the model of computer the image will be used on. Another option is to use a payload-free package with post-actions or simple shell scripts to change these values on each newly deployed computer. Furthermore, since printers tend to be location specific, consider how to change those settings once an image is deployed. Any files that are based on the MAC address can be changed via the same startup script that binds the computer to the AD domain, simply by locating the ByHost files and changing the names of the files.

Using Non-Package Installers and LogGen

Although Installer in Mac OS X provides a record of what files were installed and where, other installation applications, such as VISE, do not. One solution is to use logGen, a command-line utility that detects file-system changes. It can be run before and after an installation with VISE, and will generate a list of those files that were added, deleted, or modified. Then you can create a custom installation package of the contents using PackageMaker. Or, using the find command, you can create a file just before the installation to act as the baseline for a creation date. After the installation, identify the folders that were created after you created the baseline file.

Note

Another solution is to use the PackageMaker command line utility to take a snapshot of the drive after the installation. Then a package can be created with the differences between before installing the software and after installing it. That package can then be deployed to other computers.

Working with Root-Only Installers

Some applications require that you install to / (root of the volume). If, however, the computer you are installing to is in Target Disk Mode, you cannot install that application because the volume is in /Volumes. There are two possible solutionsone easier but less reliable, and one harder but more reliable. The easy solution is to modify the package requirements to no longer require the target volume to be the currently booted volume. There are a number of places within a package where this check could be made, such as InstallationCheck, VolumeCheck, packagename.info, Info.plist, or packagename.dist. The drawback to this solution is that pre- and post-action scripts may not be robust enough to work on a non-root volume. This not only may cause application-installation problems, but it also could potentially harm your system. The other solution, although much more labor intensive, is much safer. Using logGen or a similar utility, identify the files that are installed and create a custom package that will put the files in the correct locations.

Using Resource Forks

Although not used nearly as much as they once were, resource forks are still quite common in Mac OS X. If an application or folder is missing a custom icon, typically the resource fork is missing, and there will likely be other problems with your installation. Using extra care to use only resource-fork-preserving command-line tools, such as those supplied with Mac OS X v10.4 and higher, will reduce the possibility of resource-fork problems. Many of the command-line tools included in earlier versions of Mac OS X ignored resource forks.

Another issue to watch for when using .dmg files is that those created in Mac OS X v10.1 and v10.2 often include a resource fork. The result is that when you download them via HTTP, they become unusable. The solution is to provide the affected disk-image file over AFP, which preserves the integrity of a forked file. Alternatively, compress the .dmg file as a .zip file. This will allow it to be downloaded using protocols that don't support forked files.

Hiding Visible Folders and Files

After performing a NetInstall or restoring Mac OS X from a disk image, you may see certain files and folders (such as etc, tmp, and var) at the root level of the Mac OS X volume that are not supposed to be visible. In Mac OS X v10.3 and earlier, these items are made hidden (invisible) by listing them in a file named ".hidden" at the root level of the Mac OS X volume. Mac OS X v10.4 and later do not use this method, but rather hide files by setting certain attributes in the files themselves.

However, in Mac OS X v10.4 and v10.4.1, these attributes are not preserved when you create a disk image. To prevent these files from becoming visible on a NetInstalled or restored system, use the following steps to make them invisible on the source disk image:

1.	Create a disk image in read/write format, or convert your existing image to read/write format.
2.	Mount the image.
3.	Insert your Mac OS X v10.4 Installation DVD into your computer.
4.	Open a Terminal window and enter the following two commands: [View full width] $ cd /Volumes/Mac\ OS\ X\ Install\ DVD/System/Installation/Packages/OSInstall.mpkg /Contents/Resources/ $ sudo ./SetHidden /Volumes/mountedImage hidden_MacOS9
5.	Unmount the disk image.
6.	Convert it back to compressed format.
7.	Scan the image for restore.

You can also create the older, .hidden file at the root level of the volume and place root-level directory, file, and symbolic link names into that file, as well, or use the developer tool, SetFile, located in /Developer/Tools, to hide folders anywhere on the file system. With SetFile, you use the -a flag for attributes and the V flag to make the folder invisible.

For instance, after navigating to the /Developer/Tools directory, you can run this command to make the /Developer folder invisible:

 $ ./SetFile -a V /Developer