Testing Images


Images need to be thoroughly tested before deployment. This commonly involves both hardware and software testing. It can be catastrophic to roll out images, only to find that something minor with one machine can quickly escalate into a major issue with all machines. This can be true of application testing, font testing, directory service testing (critically important), and security testing.

Note

This book primarily focuses on creation of the image and testing related to hardware and software. For information on directory services, security, and file systems, please consult Mac OS X System Administration Reference, Volume 1.


Testing Images with Hardware

Because disk images will be deployed on various systems in your organization, you should develop a means of testing representative systems that includes both the basic CPU and any critical peripherals. The goal is to find out how many different images need to be maintained to fully support all the equipment you need to deploy on.

When you test Mac OS X, try the version or versions you plan to use on all of the computer types on which you will be deploying that operating system. Make sure you have tested enough representative systems to be satisfied that these computers meet the requirements of the operating system. If an image doesn't work on a particular system, compare the build version of Mac OS X to the model of computer and boot ROM version of the system, and refer to the Apple Knowledge Base to ensure that the operating-system version is designed to work on that particular system.

Tip

Given the hardware differences between desktop and portable computers, you should maintain different disk images for each.


Newer hardware typically requires a new build of Mac OS X. In most cases, this newer build will also work on older hardware. If an operating-system upgrade is needed, create a new disk image with the upgraded software, verify that it works on the affected system, and then test the updated disk image on the other computers. As the following figure shows, several methods should be used to deploy images, each depending on the type of image or package being deployed and the type of hardware that will receive the image.

One common and best-practice technique to use when maintaining disk images is to establish a set of base images and then configure customized packages or scripts to run after the images are installed or restored. This technique cuts down on the need to maintain more than a couple of images and on having to constantly update your images. It is less time-consuming to update packages and scripts. For example, you may use the stock Mac OS X installation packages, and then layer your own applications and customizations on top of them. In order to modify parts of the base Mac OS X image, you may wish to take advantage of payload-free packages that just contain postflight scripts to make modifications to the installed system, as discussed in Lesson 3, "Packaging."

If you need to support critical peripheral hardware, such as printers, displays, or scanners, update the driver software on the disk image. In this series of tests, the issues you are looking for are incompatibilities related to the custom driver and the existing drivers on that image. Again, if incompatibilities can't be resolved, maintain multiple disk images and decide how to communicate the compatibility issues to your users, or use custom packages to deliver custom drivers and remove other drivers.

If you need to support laptop computers, be sure to test your image on a laptop. Keep in mind that a laptop computer often has no network connection or may have only a wireless connection. Be sure to verify that your software works in no-network situations. Also be aware that not all laptops support backlit keyboards. If the image is built on a laptop that does not require that specific driver, it may not enable backlit keyboards when deployed to laptops that do support that feature.

Lastly, the type of processor present may also affect the image (depending on software release). It is a good idea to test a PowerPC-based image on an Intel-based image and vice versa. As operating systems and code continues to evolve, this may become a moot issue; however, it should be tested thoroughly to insure maximum compatibility. Generally, one image per chip set is advised. For example, if you maintain four images for your PowerPC-based Macs, you might wish to build and maintain four images for your Intel-based Macs.

Testing Images with Software

Once you have completed the hardware testing, you should test the software that was deployed on the disk image. If you are using NetBoot or Network Install images, verify that the applications run and that documents work as expected while the computer is started up from an image. If you are using ASR images, verify that the applications work as expected after being restored and that the documents are where you intended them to be.

Before testing the application on the images, you might want to create a baseline by determining how the applications work normally. This will help you answer some basic questions:

  • Where are the preferences for the application stored?

    After running the application, look in the Preferences folder or an application-specific folder in ~/Library and /Library or in ~/Library/Application Support /Library/Application Support, and sort by date to see what preferences were added when the application was run.

  • Are there preferences for each of the application's users?

    Before running the application, take note of the items in ~/Library. After running the application, see if any new items have been created in ~/Library.

  • Are the preferences stored in the top-level Preferences folder, or are they ByHost preferences?

  • How does the application work when run by a user with administrator privileges versus a normal user?

    This is a simple test to determine what kind of access the application needs when it is running.

  • Will the application work differently when run by a network user?

    Some applications are very sensitive to users who have network home directories.

  • Where are the components of the application stored?

  • Use the package receipt and BOM to identify the location of installed files. Also, open the package to see where items are placed. For applications that don't use Apple packages to install, you can use third-party utilities such as logGen (LSA Mac OS X Software site: www.lsa.umich.edu/lsait/admin/mac/software/index.asp) to find all the areas to which an application is installed.

Your ability to run an application might depend on whether its preferences can be saved to a home folder, a read-only System directory, or a special preferences location. Your ability to deploy an application might depend on whether its components are stored in a single location or across the file system. Once you have a baseline for the application, identify issues when deploying or running it from a disk image.

You should also test any client/server applications to make sure that the network connectivity and performance is what you expect. If you plan to use network home folders, authentication through an Open Directory master (or other directory service), or preference management, test the image in each of the intended scenarios in the following way:

1.

Start up the computer from a NetBoot image.

2.

Authenticate from a directory running on an Open Directory master.

3.

Have your environment predefined by preference management in Workgroup Manager.

4.

Verify that your users can accomplish this regardless of which computer they log in from (hardware/software-based testing).

5.

Finally, verify that host-specific preferences don't keep users from accomplishing their tasks.

These include screen-saver, energy, and Software Update preferences. This may require further configuration beyond restoring from disk images or starting up from disk images, such as postinstallation or login scripts.

Using a Click Matrix

As you plan what you want to test, start a comprehensive checklist, or click matrix, that will include all of the configurations and tasks that need to be completed and validated before the images and packages are ready for use. Each task should simulate the workflow that your users will go through. The tasks should include application, installation, network connection, and hardware tests. If you think it might make a difference in how the computers are used, test it! Each task should be tested carefully and documented, recording which files changed, where temporary files are stored, and if permissions and/or ownership changes. Be sure to document and save your click matrix for the next time you need to rebuild your image or package.

Testing Packages

Installer is an excellent tool for testing packages. Use it to verify that the interface scripting displays properly, that the files and folders install in the correct places, and that the scripting completes the tasks you configured the script to accomplish. In addition, you can test your scripts separately before adding them to the package.

Installer provides a lot of information to work with when you test your packages. The Installer log (Window > Installer Log or /var/log/install.log) will display any error messages or activity that occurred during the installation of the package. Use this information to track down errors in the creation or scripting of the package.

Each time Installer installs a package, it creates a receipt in /Library/Receipts. Receipt files look like packages (.pkg) but include a record of the installation instead of the actual package contents. Included in this receipt is a bill of materials (.bom) file. Each .bom file contains a list of the files installed by the package, the proper permissions for each file, the UID and GID for the owner and group, the file sizes, and the checksum. Use lsbom to output the contents of a .bom file. For example,

 lsbom -p fM\? /Library/Receipts/Java.pkg/Contents/Archive.bom 


will list specified contents of the bill of materials for Java.pkg. The -p argument specifies which parameters to outputin this example, the filenames (f), the permissions (M), and the name of the owner and group of each file (?). In the example just shown, you must escape the question mark with a backslash since it is a special shell character. Use the .bom files to verify not only that the package installed properly, but also that it registers that it installed properly.

Note

Third-party software can automate the testing of packages and workflows, thus reducing the time spent searching for potential errors. Software such as Eggplant from Redstone Software offers this type of testing automation (among other features).





Apple Training Series(c) Mac OS X v10. 4 System Administration Reference
Apple Training Series: Mac OS X v10.4 System Administration Reference, Volume 2
ISBN: 0321423151
EAN: 2147483647
Year: 2006
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net