Volume Number: 23 (2007)
Issue Number: 07
Column Tag: Networking

Using NetBooting on the Mac OS X Server for delivery of mass client deployment Article Sub-Title

by Criss Myers

In this modern era of high technical and support costs, it is very important to be able to reduce the support required at the client side. The larger the network grows the less support time is available for each machine. Thus, the network team needs to be able to optimize their time as much as possible. Every system administrator wishes to lower the amount of downtime on the network. This reduces stress and pressure on the administration team and keeps their users happy. Clients require more and more from their computer and its associated network, and demand instant technical support. The client needs to be able to turn their computer on and for it to be in the same state every time with limited or no downtime. The network system administrator needs to be able to make improvements and upgrades, but if they go wrong, he needs to be able to revert to a previous working state as soon as possible. The most effective way to achieve this is through mass client deployment; this means each machine is setup identically and all updates are thoroughly tested offline before being deployed to the clients. This is nothing new to the computer market and similar systems are carried out on Windows, Unix, Linux, Sun and Novell networks. In this article, we will look at the often-overlooked Mac mass deployment system tool called NetBooting.

1. Network Install

Using Network Install, machines are imaged over the network via a network image distributed from a server. Then each time an updated system is ready, it can be deployed in the same manner to the machines again. This imaging can be achieved by using Apple's NetInstall, or Bombich's NetRestore, or Casper by JAMF.

These are great methods; it means that after each reinstall, the machines are setup identically and in a known stable working state. Any updates are tested offline before passing them on to the client, and the software and system can then be managed and controlled centrally by the administrator.

Over time however, the client machines can drift from this installed state, either by changing preferences, removing files, system crashes, etc. This may require a full client reinstall. This causes downtime; the initial install created downtime and each reinstall carries with it more downtime, plus the time used to report the problem to the administrator in the first place. This method carries with it many possible problems, but is suitable for mass deployment over a network.

2. DeepFreeze

DeepFreeze, by Faronics, is third party software that is installed onto the client system. Once setup, it 'freezes' the system at its current state. Any changes made during the current and future sessions will be lost after a reboot. The only way to change the system is to enter an "admin" password and reboot the client into a thawed state. This software prevents any unwanted changes to the system and returns the machine to the same state with every reboot. However, it allows the current user freedom to use the machine in any way they wish. This method is not centrally controlled and each client needs to be thawed individually before any updates can be applied. It is a very useful piece of software for small networks.

3. Apple's NetBoot system

The OS X Server has a system tool called Netboot; this is the same tool used for Netbooting and NetInstall, but we will focus on Netbooting. The server stores client system images, which contain a complete OS X system together with any applications required. The server can supply as many different images as required. These images are then available for booting client machines. The client machine, be it a PPC Mac with OpenFirmware or an EFI-based Intel box, has Netbooting capabilities via BOOTP/DHCP over the Ethernet port. Firstly, the client boots up and broadcasts a search for a Netboot server via BOOTP/DHCP; the first available NetBoot server then acknowledges this request. The client then seeks out a DHCP server (which may or may not also be the BOOTP server) to receive its network details. Once it has its network settings it then contacts the Netboot server again and either requests the default image or a specific image set via the Startup Disk. The Boot ROM is then copied to the client via TFTP (Trivial File Transfer Protocol). This protocol sends very small packets of data from the server to the client. The Boot ROM is either copied from an NFS or HTTP share on the server. This share stores the Netboot images. The typical place for this is in Library/NetBoot/NetBootSPx; each drive can have a Netboot share point if required to balance the load.

Once the client has the Boot ROM, it will then boot up and access the rest of the OS from the server and load it into memory. It uses the local drive as a cache and virtual memory/swap space. When any information is needed, it is accessed over the network and loaded into the memory of the client. As far as the client is aware, the machine boots and runs as if everything was loaded from the local drive. The network image is mounted on the desktop, the local drive is also mounted, and it appears as a separate internal drive. Since the information is stored on the server and only the information being accessed is downloaded to the client at any one time, there is no limit on the size of the NetBoot image. This has an obvious advantage over NetInstall; if your install image is 45GB, which it can be with a program like Final Cut, it is going to take a long time to install over the network onto a single client, let alone a whole lab. Whereas with NetBoot there is no difference between accessing a 5GB and a 45GB image.

Both Unix and Linux systems also use this technology. Apple implemented this in their second version of OS X Server called OS X Server 1.2. Initially it only supported OS 9 but, with the release of OS X 10.0 Client, OS X support was added.

Since Netbooting depends heavily on network infrastructure and memory in the client machine, this is not a cheap setup. The faster the processor and the more memory the client machine has, the smoother the performance. This is especially true if you are running the Pro Apps such as Final Cut. The more clients you Netboot the more bandwidth you will require. Since Netboot uses TFTP, it does not create large packet transfers but rather a large amount of traffic. A switch is a must, and a managed switch with port bonding is advantageous. A small network can run on 100BaseT but for larger networks a 1000BaseT or higher may be required. As the files are being distributed from a server, the server specifications are important also. On the server side, the faster the server, the better. For larger networks, bonding two or more gigabyte Ethernet cards together will help performance. The Netboot images should be stored on a separate drive from the system, and for optimal performance, an Xserve connected via Fibre Channel can be used. The Netboot server should also only be running those services required for Netbooting such as NFS or HTTP, NetBoot, BOOTP and DHCP/DNS, if another server is not providing these services. For even more performance, multiple Netboot servers can be used, but only one DHCP server is required. The clients will then connect to the first available Netboot server. An OS X Server can provide OS 9 and OS X images and can provide both PPC and Intel images. OS X 10.5 ("Leopard") will offer a single image that can boot both PPC and Intel machines, but until then, a separate image is required for each hardware type.

The advantages of NetBooting over other methods, such as DeepFreeze, are that the system is centrally controlled, set up, and received via a server. Any changes and updates are performed from the server; the client machine never needs installing or reinstalling to take advantage of any updates. The advantage over an install system is the reduced downtime. No time is wasted installing the system onto the client machine or reinstalling to perform updates. This also reduces network traffic. The only downtime is the time taken to boot the client machine, which, with a fast network and optimized system takes nearly the same time as booting from its local drive. The client is thus unaware of the fact that they are running from a network-controlled image.

Netbooting is excellent for a School or University setup where laboratories are required to be running during the day and where there is a limit to the available time for maintenance. This can mean that the network is free for client use and is not tied up running installs. It also means that staff is free to test software and updates without impacting the day-to-day running of the laboratories. Netbooting also offers secure setups; because the system is run from the server, there is no information stored on the client, and information that is cached is lost after a reboot. This is ideal for the military or for banks, where vital, secure and private information is not retrievable from a client machine. One bank that I know of, with over 1400 NetBooted Macs, uses this system.

This guide is based on my own experience using NetBoot and my own personal preferences. I have NetBooted OS 9 and OS X clients. For imaging, a separate external drive is sufficient. The image drive needs to be preserved in a stable state so that it does not get corrupted and cannot be used for anything other than creating the NetBoot base image. Any updates and additions will be installed onto this drive and therefore any corruption will be passed onto the clients. A separate (second) cloned drive can be used for testing purposes, and updates — software can be installed and tested on the clone drive prior to install on the main imaging drive.

1. OS X Server — Setup an OS X Server as required for your network and enable NetBooting via Server Admin, this automatically turns on NFS. Fig. 1 shows the settings required. Enable an Ethernet port and select a Volume for images. "Client Data" is only required for headless boot up (booting clients with no internal hard drive, not recommended for performance issues).

Fig. 1 Server Admin, NetBoot, Settings, General

Use a separate internal drive for the Netboot images, to do this create a share point on this drive and make sure it has an NFS Export setting to the World with read-only access. This will be the drive you select via Server Admin.

Fig. 2 shows these settings in Workgroup Manager, Sharing, Protocols, NFS Export Settings.

For performance, you can bond multiple Ethernet ports, and use an Xserve RAID to store your images. Setup DHCP and DNS, either on the same server or a different server as appropriate.

2. Setup a client admin Mac with OS X and Server Tools. It can be a PPC or Intel Mac. This Mac will be used for creating the Netboot images and does not have to be the same hardware as the image you are creating. The faster the machine the quicker the image will be created.

Fig. 2 Workgroup Manager Settings

3. Get an external Firewire hard disk — Firewire 800, of course, will provide faster imaging. Buy multiple copies of the same drive so you can create clones for backup and testing purposes. One thing you don't want to do is to lose the data on this drive, especially once you have made considerable changes and updates over time.

4. Connect the Firewire drive to either a PPC or Intel Mac. It can be the same Mac as your admin Mac, but it needs to be the same platform as that for which you are creating an image. Use a PPC Mac to create a PPC setup and an Intel Mac to create an Intel setup. It doesn't matter which model it is, i.e. you can create an iMac NetBoot setup using a laptop. Create a separate setup for both PPC and Intel on separate drives.

5. Boot this Mac from an install DVD/CD and install OS X onto the external Firewire drive not the internal Mac drive.

6. Reboot the Mac to the external Firewire drive and finish the install and setup.

7. Install any OS updates and configure the system, accounts, network, directory access, etc. and remove anything not required such as Airport Admin or unwanted language setups. Try to reduce any unwanted items.

8. Install any software updates that you wish to deliver via this Netboot image. The volume of data on this drive doesn't matter; NetBooting does not require a small volume. NetBooting 5gb is the same as NetBooting 45gb as only the information being accessed is downloaded at any one time. Programs like Final Cut will create a large volume.

9. Test all the software and configure as required.

10. Shutdown the system and connect the external drive to your client admin machine and boot the admin Mac. You now have an OS X system to image. However, if you create an image from this external drive you will get a NetBoot image with zero free space. If your drive is 80GB and it is using 45GB for data, the resulting NetBoot image will be 45GB. Programs such as Photoshop require scratch disk space; the default location for this is on the system drive. In this case, it will be the 45GB NetBoot image. We therefore need to create some free space. To do this we create a blank "dmg" via Disk Utility. Create as big a "dmg" as you require onto the external drive.

11. Launch System Image Utility from the Admin Tools in /Applications/Server/. This tool will create your Netboot image.

12. Select "New Boot" and under "General" give it a name, a unique index number, and a description, use NFS and Local path. I personally advise NFS rather than HTTP for performance related reasons.

Fig. 3 System Image Utility

13. Under "Contents" select your Firewire hard disk from the "Image Source" and choose your language.

14. From the "Model Filter" you can filter this new image to boot only specific models; the list will display the available models for the specific architecture. You can use this filter to prevent unwanted Macs from booting from the network.

15. Click "Create", name the image and save it to your local drive.

16. Once the image is created, you will have a folder called xxx.nbi — nbi for Net Boot Image. Connect to your server, mount the NetBootSPx share point, and upload this folder.

17. Once uploaded, open Server Admin / NetBoot, select the newly added image and activate. Select one as a default image.

Fig. 4 Enabled images showing Index, Architecture, and Protocol

18. This image will now be available to any Mac of the same hardware on the network, via System Preferences / Startup Disk. You can use Apple Remote Desktop (ARD) to set the Startup disk for ARD controlled machines. This way you can change the Startup disk for a client machine without the user needing to know. So, if you create a new NetBoot image with updated software, you can change the clients Startup disk to this new image and they next time they reboot the client they will boot from the new image.

19. On the server, open the xxx.nbi folder and mount the System.dmg. It will mount onto the desktop. You can now perform some basic alterations (to prevent corruptions do not mount this while a client is NetBooting from it). You can now delete the "dmg" you created to give yourself free space. You can also install or copy files to the System.dmg at this stage also. This is useful if you want to make minor changes to the image without having to re-image.

Under the NetBoot section of Server Admin select overview, from this window you can see whether the Netboot Service is running, how many images and what type they are and if they are running or stopped.

Fig. 5 Server Admin, NetBoot Overview

Server Admin also allows you to filter the NetBoot process to certain MAC addresses; this is also useful to prevent unauthorized Macs from booting from the network.

Fig. 6 Filtering by MAC address to allow only certain clients Netboot-ability

NFS is required for NetBooting, sometimes the NFS process will stop, there is no way to start the service via Server Admin, the quickest way is to open Workgroup Manager and un-share the NetBoot folder and then re-share it. Since this share requires NFS for its NFS Export, it automatically starts the NFS service. [Ed. Note: you can also hand-crank NFS in a shell by calling the nfs daemon directly: "sudo /sbin/nfsd -t -u -n 6". Hit the man page for more information.]

NetBoot can require BOOTP to be running, and I find this does not always launch at boot up. To start BOOTP manually, open Terminal and type, sudo ./usr/libexec/bootpd and this will launch the service, then run Disk Utility to repair the permissions on the Startup disk; this normally fixes the problem for the next boot up.

NetBoot also requires a working DNS system, so make sure your DNS is working properly.

Boot up process, error indicators

1. On boot up of a client machine, you will get a flashing globe icon; this is the client broadcasting for a Netboot server. This icon is a square icon with a globe on a PPC Open Firmware system, and a grey globe icon on an Intel EFI machine. This icon should not flash for very long. This icon will stop flashing once a NetBoot server has been found. The client then displays a small spinning grey globe icon while it gathers its DHCP settings. If the client does not find a server it will timeout and will boot from the local drive. Check that bootpd is running on the server.

2. The client then displays a spinning grey wheel icon while it downloads the Boot ROM. If the client displays a "no entry" sign this means that the client cannot boot from the chosen NetBoot image.

3. Once the Boot ROM is loaded into the client's memory, it downloads and initializes the rest of the Operating System. If the NetBoot image is corrupted the client will kernel panic at this stage. If the client shuts down after the Boot ROM is loaded then this indicates that the client's hard drive cannot be written to.

4. If the NetBoot server needs to be rebooted at any time, the clients will go offline and they will get the spinning wheel; once the NetBoot server is back online, the clients will automatically reconnect and go back online without loss of service or reboot.

5. If the clients get repeated spinning wheels or run slowly this maybe due to poor network performance and optimization. You may need to increase the bandwidth available or add extra NetBoot servers as well as adding additional memory to the clients.

Netboot is a valuable tool for any administrator. The ability to keep control of images in a central location can save incredible amounts of time, and keep users comfortable with a consistent experience across machines.

If you have the technical resources and wish to reduce your technical support costs and downtime then NetBooting is for you. It does require high technical costs but it also reduces the technical support costs as well. Since the client is never imaged, any changes are instant once the client is rebooted. Reverting back to a previous working version is as simple as rebooting the client. All testing and development is carried out offline and changes are passed to the client via a start-up disk change. All of this makes NetBooting a very appetizing system. As a support officer, you can easily diagnose a problem, and you can be guaranteed that if software works fine on one client it will be replicated on all other clients using the same Netboot image. Thus, (m)any problems will be due either to hardware failures or user's settings, not system OS problems. Reboot the client or login as a known working user and you can troubleshoot very easily. As a support technician, this makes so much sense and makes your life so much easier, making NetBoot a vital system of deployment for any network, large or small.

Criss Myers is a Senior Mac IT Technician for the Faculty of Science and Technology, at the University of Central Lancashire, Preston, United Kingdom. He has been a Systems Server Administrator from the very first version of OS X Server. He Works with Macs as well as Linux, Unix and Windows.