Lesson 4. Delivering Images and Packages
Time |
This lesson takes about 2 hours to complete. |
Goals |
Install Mac OS X and Mac OS X Server on multiple remote or local workstations using ASR images |
|
Create and deliver custom installation packages for Mac OS X and Mac OS X Server |
|
Configure Mac OS X Server to store and deliver NetBoot and Network Install images through NetBoot services |
|
Configure multiple install packages for use with a Network Install image |
Learning how to plan your deployment, create and manage images, make custom packages, and check for software revisions is critical to a successful mass deployment operation. But if the method of image delivery does not work well within your environment (network setup, security, physical location of Macs), time may be wasted, networks may get clogged with traffic, and your entire deployment project may suffer as a result.
In this lesson, you will learn how to install Mac OS X v10.4 on multiple computers by delivering your master image both locally and over a network. You will set up your image for NetBoot startup and perform updates with packages and scripts. The methods you learn in this lesson will allow you to automate the process of image delivery so that you can present a low-maintenance, consistent interface to your users.
Delivering Locally
One of the simplest, most portable, and most flexible methods of local image delivery is through the use of a FireWire drive (Intel-based Macs can also boot over USB with the new formatting structure) as a startup disk. Just configure a portable FireWire (or USB, where applicable) drive with Mac OS X installed, as well as a copy of the disk image you wish to distribute and a utility to distribute the image, such as Apple Software Restore (ASR) or Disk Utility.
You may choose to place a script to initiate the delivery process in a conveniently accessible location on the FireWire drive. To deliver the image, simply start the computer with the FireWire drive and double-click the script. You can even create a script in the /Library/StartupItems folder that will allow users to start up the computer from the FireWire drive, walk away, and return when the delivery is complete. As the following figure shows, using a FireWire drive to deploy an image to a single computer is an easy and network-friendly method of one-to-one deployment.
Warning
If you create a script that is capable of delivering an image with little or no user interaction, use it with extreme caution. Starting up the wrong computer with the delivery FireWire drive may result in a loss of data.
Intel-based Macs must boot from drives with a GUID Partition Table (GPT), and PowerPC-based Macs must boot from drives with an Apple Partition Map. As a result, you may not currently use the same disk drive to boot both Intel and PowerPC-based Macs.
Using ASR
ASR, which is described in Lesson 2, “Creating and Using Disk Images,” is a native Mac OS X application that efficiently copies disk images onto volumes. With an ASR-ready disk image, you can use the command-line tool asr to distribute your image. As shown in the following figure, ASR can be used to push many disk images to many computers or one disk image to several computers.
After starting the computer from the FireWire drive, enter the following syntax at the command line or from a UNIX script:
sudo asr -source sourceimage -target targetvolume [options]
where sourceimage is the path to your master image and targetvolume is the path to the local startup volume for the computer. The optional [options] parameter can be any number of options available to asr as described in the asr manual page. In this example,
sudo asr -source /Users/Shared/master.dmg -target /Volumes/Macintosh HD/ -erase
the -erase option is used, indicating that asr should erase the target volume and perform a fast block copy. By default, without the -erase option, asr will perform a restore in place, which is slower. Type man asr on the command line for details on this option, on block-copy restores versus file-copy restores, and on other features.
Using Disk Utility
Some administrators prefer to use Disk Utility because it has a graphical user interface with drag-and-drop support, and because, unlike ASR, it offers less chance of deleting and imaging a drive unintentionally. As the following figure shows, Disk Utility is a simple, GUI-based version of ASR, so it does not offer a few advanced options that come with ASR.
To deliver an image using Disk Utility, follow these steps:
1. Start the computer from the FireWire drive. Alternatively, if you have the images stored on a portable computer, you can boot the target computer in target disk mode and connect it to the portable computer as a FireWire drive.
2. Open Disk Utility.
3. Click the computer’s hard-drive icon on the left.
4. Click the Restore tab, as shown in the following figure.
5. Click and drag the master image into the Source field.
6. Click and drag the target-volume icon into the Destination field.
7. Select Erase Destination for a fast block copy, or leave it unselected for a restore in place.
8. Click Restore.
Tip
You might find it helpful to set Disk Utility to launch at login.
Using a Bootable DVD
Using a CD or DVD to deliver your image has a few advantages over using a FireWire drive. Though not as flexible or easy to set up, optical media discs are inexpensive and can be easily mass produced. Because they are read-only, they also reduce the possibility of corruption or accidental modification.
Due to limited storage size, it is not likely that your master image will fit on a CD, and with a complex modern operating system like Mac OS X v10.4, it is extremely difficult to create a CD capable of starting your computer. DVDs have greater storage capacity, and so they are much more practical. As shown in the following figure, putting the disk image on a bootable DVD allows for a more inexpensive mass deployment solution than that of FireWire drives, but without the ability to update the images without creating new DVDs.
To create a bootable DVD, configure a model and create an install image in System Image Utility (as you would to create NetBoot or Network Install images). Instead of saving the image to your NetBoot storage folder, save the image to a folder in your home folder. Then use the Finder or Disk Utility to burn a DVD of that image. Although Disk Utility can be used to create bootable DVDs, System Image Utility allows you to easily configure a stripped-down version of Mac OS X as the startup volume on the DVD.
Delivering over the Network
Mac OS X v10.4 offers several options for network image delivery, eliminating the need to physically move from computer to computer to deliver images. You can store your master image and update packages on a server on the network. Then you can connect directly, remotely distribute your image to multiple computers simultaneously, or script the process so that your computers will automatically pull images and packages from your server.
Using NetBoot
Client computers that start up from a NetBoot image get fresh system environments every time they start up, eliminating the overhead involved in maintaining local delivery of images, as seen below.
The NetBoot service in Mac OS X Server v10.4 supports Mac OS X computers that have Macintosh firmware version 4.1.7 or later. To start up a computer into Mac OS X v10.3 or earlier using NetBoot or to use Network Install, the Mac OS X computer must have a minimum of 128 MB of RAM and 100Base-T Ethernet or faster network connections. To start up a computer into Mac OS X v10.4 using NetBoot, the client computer must have at least 256 MB of RAM.
For NetBoot deployments of 10 to 50 clients, a 100Base-T switched network is required. Gigabit Ethernet is required for booting more than 50 clients (although Apple has no official test results for configurations beyond 50 clients). Apple does not support the use of AirPort wireless technology with NetBoot clients. NetBooting computers requires a solid network infrastructure.
Note
Mac OS X Server v10.4.4 supports Intel-based Mac OS X computers, but the server itself currently must still be a PowerPC-based computer.
More Info
Version v10.4.4, or later, of the System Admin Tools provides Universal applications for administering Mac OS X Server v10.4 from both Intel and PowerPC-based Macintosh computers. It also includes an updated System Image Utility application for creating NetBoot and NetInstall images of Intel-based Macs. For more information, refer to the AppleCare Knowledge Base article “About Server Admin Tools v10.4.4” (docs.info.apple.com/article.html?artnum=302923).
When a client computer starts up from a NetBoot image, the following process takes place:
1. The client places a request for an IP address.
When a NetBoot client is turned on or restarted, it requests an IP address from a DHCP server. Although the server providing the address can be the same server providing the NetBoot service, the two services don’t have to be provided by the same computer.
2. After receiving an IP address, the NetBoot client sends out a request for startup software over the local subnet.
The NetBoot server then delivers the boot ROM file (booter) to the client using Trivial File Transfer Protocol (TFTP) via its default port, 69.
3. Once the client has the ROM file, it initiates a mount and loads the NetBoot network disk image.
The images can be served using HTTP (or HTTPS, provided the necessary certificates exist in the appropriate locations) or NFS. Mac OS 9 computers used Apple Filing Protocol (AFP) for mounting during NetBoot.
4. After the NetBoot client starts up from the NetBoot image, the client then requests an IP address from a DHCP server on the local subnet.
Depending on the type of DHCP server used, the NetBoot client might receive an IP address different from the one received in step 1.
Note
Previous versions of NetBoot server that used AFP to deliver network disk images could potentially run into AFP license restrictions. If you purchased the ten-client version of Mac OS X Server, your AFP license restricted you to supporting no more than ten AFP clients, limiting the number of Mac OS 9 NetBoot clients to less than ten. This would not affect your Mac OS X NetBoot clients, as they use NFS or HTTP and are unrestricted even with the ten-client version of Mac OS X Server.
In order to configure NetBoot on your server, do the following:
1. Place your master boot image created with System Image Utility or NetRestore Helper (as described in Lesson 2) in the /Library/NetBoot/NetBootSP nfolder.
2. Launch Server Admin and connect to your Mac OS X Server.
3. Click the NetBoot service and then the Settings button to display the Settings pane.
4. Select which Ethernet port(s) provide the NetBoot services.
5. Select which volume(s) provide the image and client data.
6. Click the Images button to display the Images pane, and choose the protocol to serve the image.
7. Select the default image(s). You can select on default one PowerPC-based image and one Intel-based image.
8. Click Save to apply changes.
9. Start NetBoot services.
10. To start any supported computers on the local subnet with this image, select the image in the Startup Disk pane in System Preferences or hold down the N key while the computer is starting up.
Using Network Install
You can distribute and install software, including the Mac OS X operating system, with Network Install images. On Mac OS X Server, use the System Image Utility to create a Network Install image. Create the image by cloning a system that’s already installed and set up, or by using a Mac OS X Install Disc.
Network Install allows for the installation of packages and metapackages, similar to that of a DVD install, and can be automated to erase the volume set to receive the image or packages. (Note that if you choose to auto-install, you won’t have to interact with each computer.) You can also set various ByHost files (specific to an individual computer) to match the receiving computer’s MAC address.
For example, when using a Mac OS X Install Disc (you can also use a Mac OS X Server Install Disc when doing a Network Install of Mac OS X Server), you have the option of removing certain packages within the install disc itself. You can also add other packages, such as updates and security updates, and scripts to a Network Install image or image downloaded using Apple Software Update.
Note
You cannot mix and match updates for PowerPC-based Macs and Intel-based Macs and add them to a Network Install image. Doing so may cause the installed operating system not to function. It is best to keep Intel-based Network Install (and for that matter NetBoot) images and PowerPC-based images totally separate.
Exploring Other NetBoot/NetInstall Options
NetBoot and NetInstall can be customized in a number of different ways to satisfy the needs of your environment. Network topology, firewall rules, quantities of computers, and other items may require you to make some adjustments to the NetBoot or NetInstall settings.
Serving Your Image over HTTP
NetBoot and NetInstall images are optimally served via NFS because of its speed and low overhead. However, your environment may not allow NFS servers for security reasons. In those cases, you can serve your image via HTTP instead of NFS. To set this option, simply select the radio button when you’re setting up your image in the System Image Utility. However, many Web servers are unable to serve files larger than 2 GB.
NetBooting from a Different Subnet
You may need to perform a NetBoot or NetInstall from a network other than the one that your server is on. If this will be a regular occurrence, you may want to have your network administrator forward your broadcast traffic from your network to the NetBoot server. This is commonly changed using DHCP or IP helper addresses.
You also have the option of specifying a particular NetBoot server and image through a number of mechanisms:
• Apple Remote Desktop (ARD) allows you to specify the server IP address and image name from which the client should boot.
• The bless command can use options of the following format:
bless —netboot —server bsdp://xxx.xxx.xxx.xxx
• Using the nvram command, you can specify both the server and the image file:
sudo nvram boot-file enet:xxx.xxx.xxx.xxx,NetBootNetBootSPnnameOfNBIfolder.nbimach.macosx
sudo nvram boot-args rp=nfs: xxx.xxx.xxx.xxx:/private/tftpboot/NetBoot/NetBootSPn:nameOfN
BIfolder.nbi/ImageName.dmg
sudo nvram boot-device enet:xxx.xxx.xxx.xxx,NetBootNetBootSPnnameOfNBIfolder.nbiooter
Substitute your server’s IP address and actual NBI path in the commands above. Once you set the new boot device, reboot the computer to initiate the connection.
You can simplify this using a free application named, appropriately enough, NetBoot Across Subnets, from Mike Bombich (www.bombich.com/software/nbas.html).
Making Advanced Customizations
A number of advanced customizations can be made with NetBoot and NetInstall. The primary locations for making image customizations are the following:
• The bootpd configuration
• NBImageInfo.plist
• Inside the disk image
The bootpd process (started by launchd) handles the reception of the NetBoot BSDP requests and generates the responses to each client. Most of the bootpd configuration is stored in the local NetInfo database. If needed, you can make alterations to this data using nicl. To see your current settings, type
nicl . -read /config/dhcp
This shows the logging level, any MAC address filtering, and the interfaces for which NetBoot is enabled. You should generally use only the approved NetBoot interfaces to make changes to your NetBoot configuration, including the Server Admin utility and the serveradmin command. More documentation for the serveradmin command is available in the Mac OS X Server Command-Line Administration guide. After you’ve made any changes to your NetBoot configuration, you’ll likely have to restart your NetBoot server for the changes to take effect:
sudo serveradmin stop netboot
sudo serveradmin start netboot
Further enhancements to the NetBoot server are also made in the local NetInfo database under the /config/NetBootServer entry. The following are some of the configuration options you may wish to use:
• afp_users_max—If you will be using NetBoot with more than 50 machines simultaneously from one server, you may need to raise this number.
• age_time_seconds—Particularly in environments where you’re using NetInstall to install machines in assembly-line fashion, you may wish to lower this number. This number indicates how long your server remembers a NetBoot connection.
• machine_name_format—Normally, computers that are NetBooted receive a hostname that is of the format “Net-Boot%03d.” You can modify this field to change the format. Note that it should use printf format and contain one number to indicate the machine number.
• shadow_size_meg—This setting controls the size of your diskless client’s shadow file. The default, 48 MB, may need to be increased if you have to save more information from a computer while it’s NetBooted.
The NBImageInfo.plist file contains all of the details about your NetBoot or NetInstall image. All of the options in this file can be set from the System Image Utility when you create your image, but there may be times when you’d like to make quick changes to some of the options without re-creating your image. Just use a text editor to modify the file and restart your NetBoot service as outlined above. Some of the options you may wish to change include the following:
• Name—The name that appears in the Startup Disk preference pane.
• IsEnabled—A Boolean value indicating whether this image is available.
• IsDefault—A Boolean value indicating whether this image is the default image used when a computer is booted with the N key pressed.
It’s possible to have more than one default image. Although you can’t set more than one default image (per architecture) in the Server Admin tool, you may wish to have multiple default images available if you’re using different computer model filtering in your images.
• Index—This integer, between 1 and 65535, is used to identify common images coming from multiple NetBoot servers.
If you have only one server, you can use any number. If you have multiple servers in a load-balancing arrangement, identical numbers under 4096 will be treated by a NetBoot client as different images, and each image will show up in the Startup Disk preference pane. Index numbers of 4096 and above will be treated as identical images, and only one entry will be shown in the Startup Disk preference pane.
Selecting this image on the client will boot the client from whichever server responds first. Subsequent reboots by the client will favor the initial NetBoot server that responded.
• SupportsDiskless—A Boolean value that determines if a NetBoot image can be used on a computer with no disk, or on a computer where you would prefer nothing to be written to the local disk.
Normally, temporary files and caches are written to /private/var/netboot on a NetBooted system. A diskless NetBoot will instead store this information in a shadow file on the NetBoot server.
• EnabledSystemIdentifiers—An array of each specific computer model that is allowed to use this image.
You can obtain the identifier for any computer by typing sysctl hw.model on the command line of that computer.
• Architectures—An array of processor types that this image supports. Possible values include ppc and i386.
More details about all of these options can be found in the bootpd manual page:
man bootpd
Creating Utility NetBoot Images
NetBoot doesn’t necessarily need to boot into a fully operational Mac OS X system. Through some simple modifications of the /etc/rc files in your disk image, you can make your NetBoot image perform simple utility functions. Some examples of this might include the following:
• Rescue image—An image that contains various rescue utilities such as those pertaining to disk recovery, virus detection, memory testing, or other rescue/diagnostic applications. In fact, Xserve Remote Diagnostics is one such image that has no real user interface but instead might just execute a script to modify the target system and reboot. This is similar to the use of a payload-free package, discussed in the previous lesson.
Using NetRestore
NetRestore, by Mike Bombich (www.bombich.com), extends the features of ASR with a graphical user interface and scripting tools. You can use NetRestore to restore a master disk image to a target volume whether the disk image is hosted locally, on a network via AFP, or on the Internet via HTTP. NetRestore can also be used in conjunction with NetBoot to fully automate the deployment of a lab.
NetRestore does the following:
• Restores a disk image to a hard drive via block-level or file-level copying
• Clones local hard drives and restores disk images located locally or across a network
• Runs pre- and post-restore customizing tools to set computer-specific information
• Includes a helper application for creating master images and Network Install-Restore image sets
• Offers extensive user-community support
• Features easy configurability and support for browsing images and drag and drop for on-the-fly restores
• Supports post-action customization scripts:
• Set Open Firmware password
• Set ARD custom field data
• Fix ByHost preference items
• Set network configuration (static IP and so on)
• Has full automation
• Works while started up from
• An external FireWire drive
• A bootable CD/DVD
• A network drive (NetBoot)
Using ASR over a Network
ASR provides features that allow restoration of a volume from an image located on a remote server. Through ASR via HTTP or ASR multicast, you can remotely store your master ASR-ready disk image on a file server, rather than copy it to several media devices or spend the time and resources necessary to set up NetBoot services. This solution greatly reduces the amount of disk space necessary for local restoration and allows you to have one centrally located master image that can be maintained with relative ease.
Using ASR over the network is easier than setting up NetBoot, but it still requires a method of starting up your computer from a device other than the startup disk you wish to restore. This device could be a CD, a DVD, a FireWire drive, or a second hard drive or partition. Alternatively, use it in conjunction with NetBoot to provide a complete, network-based image-restoration process. One of the new features of NetRestore is the ability to create a bootable network image that will use ASR multicast to restore the target computer.
With ASR multicast, you can share an ASR image over the network without setting up any other service. This feature allows several clients to connect to the server and simultaneously perform fast block copies of the image to their local volumes.
Use the following command in Mac OS X or Mac OS X Server to set up the multicast:
asr -source sourceimage -server configurationfile
where sourceimage is the path to an image file. The -server option tells asr to multicast the source image over the network. The configurationfile parameter is the path to a configuration .plist file that contains the following information:
• Multicast Address—This is the multicast address for the data stream.
• Data Rate—This is the desired data rate in bytes per second. On average, the stream will go slightly slower than this speed but will never exceed it.
To create the .plist configuration file, you can use Property List Editor or run these commands from Terminal:
• defaults write /tmp/myconfig "Data Rate" -int 6000000
• defaults write /tmp/myconfig "Multicast Address" multicastaddr
This will create the file /tmp/myconfig.plist. multicastaddr will be specific to your network and should be provided by your network administrator.
Finding the correct data rate may take some experimenting. The best data rate depends a great deal on the network hardware you are using. If you’re using a network dedicated to loading machines, you’ll want to use a fast data rate. If, however, you’re using a slow network that is shared by many users, you may want to keep the data rate down to avoid clogging it.
You can also include the following optional keys in the configuration file:
• DNS Service Discovery—Whether the server should be advertised via DNS Service Discovery. It defaults to true.
• Client Data Rate—The rate at which the slowest client can write data to its target.
• Multicast TTL—Time to live on the multicast packets.
• Port—The port used in the initial client-server handshake.
See the asr man pages for more information on server options.
When the server is running, perform a software restore on any client connected to the network with the following command:
asr -source asr://serveraddress -target targetvolume -erase
where serveraddress is the address of the server running the asr multicast, and targetvolume is the volume you will be restoring. The -erase option is required for multicast restores.
One way to take advantage of this feature is to configure a NetBoot image to be diskless, start up the client computer from that image, and run ASR over multicast. This method offers an exclusively network-based delivery solution that requires no media and can be performed efficiently on multiple computers simultaneously.
To set up ASR over HTTP or HTTPS, simply prepare your ASR-ready disk image and upload it to a folder that is shared by a Web server. As shown in the following figure, ASR Multicast allows a one-to-many setup that is often easier to maintain.
Be sure to do an imagescan before you upload your image:
asr -imagescan master.dmg
Once your image is uploaded, verify that it is available via HTTP by accessing the URL with a Web browser. For example, if your image is located on a Mac OS X v10.4 Web folder at /Library/WebServer/Documents/image/master.dmg, then type
http://serveraddress/image/master.dmg
in your Web browser where serveraddress is the address of the Web server where the ASR image is stored. This should result in a download of the image.
Now, restore any volume on any computer connected to the network with the following command:
asr -source http://serveraddress/image/master.dmg -target targetvolume [options]
where serveraddress is the address of the Web server, and targetvolume is the volume you will be restoring.
Apple is continuously revising its hardware offerings by releasing new computers and new versions of existing computers, which is great for the end user but presents a challenge to those who maintain disk images used to boot those systems. It is very common for a brand-new computer to be unable to boot from your existing image due to the lack of drivers for a new piece of hardware included in the computer. A good way to check this is to compare the build number of the OS on your image to that of the OS that shipped with the computer. You can use the sw_vers command to see the version information for the booted OS. For example, your image may be built off 8G32, while a new computer might ship with 8H12. A higher letter or number indicates that this is a newer build of the operating system, and you may need to rebuild your image from the newer OS to support the new hardware.
Performing Remote Administration
Apple Remote Desktop is an easy-to-use, powerful, open-standards-based desktop management application for all your networked Macintosh computers. You can remotely control and configure systems, install software, offer live online help to users, and assemble detailed software and hardware reports for an entire Mac network.
The administration utility Remote Desktop lets you distribute software and related files to client computers. You can also distribute and automatically install packages and metapackages. ARD Admin lets you install software and software updates on one or more client computers without user interaction or interruption, whether or not a user is logged in. After installation, Remote Desktop erases the Installer files. If the computers need to be restarted, as they do following an operating-system update, restart them from Remote Desktop.
For example, on your production computer, use Apple Software Update to download an iCal update to the model computer. If the update works as expected and introduces no compatibility issues, copy the install package to a computer running Remote Desktop to distribute to computers that need upgrading. Note that this approach conserves Internet bandwidth because only one copy of the package needs to be downloaded. Use this same method to distribute custom packages you created with PackageMaker.
Another example is to use Remote Desktop to set the startup volume of remote client systems to point to a Network Install image, and then remotely restart the clients to initiate installation. Before initiating installations that require computers to be restarted, send a text message to clients using Remote Desktop, notifying them of a pending installation and that you will log them off or lock their screen at a specific time to install an operating-system update.
You can use Remote Desktop to set NetBoot images as the startup volumes of client systems and then restart the systems remotely. With just a few clicks you can reconfigure all the computers in a lab or cluster without having to manually restart and configure each computer individually.
Remote Desktop can distribute and run UNIX shell scripts on client computers. For example, a script can mount an AFP server volume, from which it downloads a disk image to client computers. The script might also download an install package and then perform a command-line install. Remote UNIX commands also provide you with a powerful diagnostic and auditing tool, since you can issue any UNIX command on any number of machines and see the results in one collated list.
Using Remote Desktop, you can distribute and install self-contained (drag-and-drop) applications by copying them to one or more client computers. To check whether an installation has been completed successfully, use Remote Desktop to observe the client computer remotely. Remote Desktop will be the focus of a lesson later in this book.
Using the Installer Command
Similar to the graphical Installer utility, the command-line installer tool can also be used to install Mac OS X. The installer tool installs one package or metapackage per invocation. In the case of the metapackage, all packages in the metapackage will be installed unless disqualified by a package’s check tool.
The command-line installer tool provides two main benefits over the traditional method of double-clicking a package to install it in the GUI:
• You can install packages remotely via SSH. Copy the .pkg file to the remote machine, ssh into it, and run the installer tool remotely.
• You can create scripts to automate package distribution and installation. These scripts could make use of other features of scripting languages to create complex tests and methods for package installation. You can use this method with both FireWire and DVD distribution techniques. Simply create a script that runs installer, and make it easily accessible or place it in the startup items.
To run the installer program, use the following command:
installer [options] -pkg pathToPackage -target pathToDestinationVolume
where pathToPackage is the path to the package to install, and pathToDestinationVolume is the target volume. For example:
installer -verbose -pkg /Users/Shared/master.pkg -target /Volumes/MacHD/
In this scenario, installer will install the package located at /Users/Shared/master.pkg to the hard drive mounted at /Volumes/MacHD/. With the -verbose option, installer displays output in a human-readable format rather than the default output, which is formatted for scripting. Type man installer on the command line for details on this option and several others.
One good way to determine whether a package can be installed on a computer is by using the installer command with the -pkginfo parameter. For example,
installer -pkginfo -pkg myPackage.pkg -target /
In this case, installer will list the package or packages contained within the package myPackage.pkg that can be installed on the current startup volume (/). If for some reason the package can’t be installed, it won’t be listed. Add this command to a conditional statement in a custom script to verify that a package can be installed before attempting to perform the installation.
Using Radmind
Radmind (detailed more in the appendix, “Using Radmind”) can also be used for deploying systems. Generally speaking, radmind isn’t well suited for deploying a system with an empty drive, but it is an effective tool for taking a computer that came preloaded with an operating system and bringing it in line with your image configuration. You can use radmind in combination with one of the other methods mentioned above, which is a great solution for maintaining the integrity of the operating system after it has been loaded.
Lesson Review
1. What are some methods that can be used to deliver images locally?
2. What are some methods for delivering images and packages over a network?
3. What method does asr use to deploy a single image to many computers?
4. What protocols of image delivery are available with NetBoot?
5. What must be done to the image before using Disk Utility to image a volume?
Answers
1. FireWire drives, optical media.
2. ASR multicast, NetBoot services, NetRestore.
5. Scan the image for restore.
References
Administration Guides
“System Imaging and Software Update Administration”:http://images.apple.com/server/pdfs/
System_Image_and_SW_Update_v10.4B.pdf
“Command-Line Administration”: http://images.apple.com/server/pdfs/Command_Line_v10.4.pdf
Knowledge Base Articles
You can check for new and updated articles in the AppleCare Knowledge Base, at www.apple.com/support.
System Imaging Services Overview:http://docs.info.apple.com/article.html?path=ServerAdmin/10.4/en/c0os.html
URLs
Visit the following sites for more information:
Radmind: http://rsug.itd.umich.edu/software/radmind
Mac OS X Management Software and Tips: www.bombich.com