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,NetBoot\NetBootSPn\nameOfNBIfolder.nbi\mach.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,NetBoot\NetBootSPn\nameOfNBIfolder.nbi\booter 

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 computer name

  • 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.