Perhaps the most interesting part of Apple’s just-released Mac OS X Server is NetBoot, which enables newer Macintosh clients to boot the Mac OS over an Ethernet network from a server machine. Demonstrated at January’s Macworld Expo, NetBoot simplifies the lives of system administrators by effectively turning a disk image file on the server machine into the startup disk for any reasonable number of Mac OS clients on an Ethernet network.
Inside the Image Machine — With the release of Mac OS X Server, we know a bit more about how NetBoot actually works. The server holds two standard Mac OS disk image files – one with the system software, and one with applications available to NetBoot clients. When someone boots a Macintosh with the "New World" ROM-in-RAM architecture – currently only iMacs and blue and white Power Macintosh G3s – pressing the N key during startup forces the machine’s Open Firmware to look on the local Ethernet network for a NetBoot server, using the industry-standard BootP protocol. The server responds by returning an IP address from a pre-assigned range (each IP address is matched to the requesting computer’s hardware Ethernet address so the server can assign the same IP address to the same workstation each time). A separate part of BootP handles a request to boot from the server; that half of the protocol uses Trivial File Transfer Protocol (TFTP) to download the "Mac OS ROM" image file to the client machine, where booting can proceed somewhat normally. FTP is uses TCP/IP, a complex protocol for a computer that’s not yet booted. TFTP is a simpler version that runs on UDP (User Datagram Protocol), a lower-level communication method than TCP.
Once the ROM file is on the client systems, they can initialize a IP stack from within the ROM image and log into the server, using AFP server information returned by BootP plus a username and password provided by you. Mac OS X Server responds with three disk images that look like two separate volumes – the applications disk (as mentioned); a read-only system startup disk containing a lightly modified Mac OS 8.5.1; and a shadow disk image of the same size. A major obstacle faced by NetBoot is that boatloads of Mac OS applications assume they can write to the startup disk. On a NetBooted machine, they can – but the changes are redirected to this shadow disk image. The real startup disk image is shared among all clients and doesn’t change, but programs on each client machine can write to the disk with the changes being stored privately in a separate shadow file for each client.
For example, suppose you’re using a NetBooted machine and you install a font you downloaded from the Internet. That involves writing to the Fonts folder inside the System Folder. The Finder allows it, and your font appears to be in the folder and is available to applications after that point. But behind the scenes, Mac OS X Server is showing your Mac client a "merged" disk with your changes layered on top of the real, unchanged, startup disk. It works because no client can change the startup disk. If the original disk image changed behind the shadow file’s back, so to speak, the differences would be applied to data that wasn’t where it should be, creating a huge mess.
When each NetBoot client restarts or shuts down, the shadow startup disk image file is discarded, so folks using lab machines can temporarily modify the startup disk any way they choose, because the changes only affect that particular Mac OS session. The Macintosh Manager, a software program illogically not named after Don Crabb, is the descendant of At Ease for Workgroups and provides client-level customizations like desktop patterns and Finder preferences for clients. The Macintosh Manager kicks in at the authentication level – once the server knows who is trying to boot, it knows what preferences you have set, so your customized desktop follows you from machine to machine. Each user has a folder on the AFP server for private files and preferences; the Mac OS that boots from the network maps the built-in location for the Preferences folder to this folder on the server instead of the standard location in the System Folder. As long as applications ask the Mac OS where the Preferences folder is instead of assuming its location, everything magically works, and each user’s preferences are available from any client machine starting up from the same NetBoot server.
Easily Configured Piracy — The startup and application disk images can be changed only by the Administrator (an alias for "root," to Unix partisans), presumably only when no other clients are logged in. That’s how NetBoot delivers on its promise of centralized management – updates to either disk image automatically appear on all NetBoot clients during the next startup. Install an application once and all clients can access it. Similarly, changes to system configuration apply to all clients at once – alter the startup disk image to include the StuffIt Engine, and all clients have access to it. You can even prevent users from mucking up the internal hard disk on client machines by installing an included extension that unmounts the internal hard drive during startup, leaving it unavailable to the user.
NetBoot can raise licensing issues, though – if you boot 20 Mac OS clients with a commercial extension like Default Folder 3.0, you need twenty licenses for it. You may need to use a license management program like Sassafras Software’s KeyServer to help manage licenses; KeyServer modifies applications to check in with a central server before launching, and only allows as many concurrent clients as you have licenses. Thus, a lab of thirty iMacs could all see Photoshop 5.0 on the Applications disk image, but if you’ve used KeyServer to permit only five clients, a sixth Photoshop user must wait until someone else quits Photoshop. The Mac OS X Server package includes a demo version of KeyServer.
No Miracle Cure — NetBoot is not without significant limits. First, think about how often your Macintosh hits the startup disk during the normal boot process. Now imagine that over a slow network connection. Apple says NetBoot is intended only for use on 100Base-T networks, where transfers can meet or beat normal SCSI speed. It uses the BootP protocol, and BootP is designed to run on a single network segment, so you can’t easily use NetBoot to start clients that are separated from the server by a router (some routers allow BootP extensions that bridge network segments, but that would likely impact performance). Mac OS X Server has robust networking, so adding more Ethernet cards can improve bandwidth for a range of BootP clients, but you need heaps of RAM to support lots of clients adequately. Apple recommends at least 128 MB of RAM for heavily loaded servers, and more than 200 MB if you want to run services like Apache or WebObjects in addition to NetBoot. Apple says that a Mac OS X Server machine running just the NetBoot service (not the Web or file servers) can accommodate about 50 clients; adding other services reduces that capacity.
Second, think about disk space requirements. If your startup disk image file occupies 50 MB, then you must have enough disk space for each concurrently booted client to have its own shadow copy of that file. A thirty-machine lab thus requires 1.5 GB of disk space (50 MB times 30 clients) for shadow files, in addition to space for the Mac OS X Server software, space for users’ private folders, an applications volume, and other files. One recommendation from Apple advises at least 5 GB of storage space on the server machine.
Lastly, NetBoot requires support in Open Firmware for the BootP protocol. Machines older than the iMac don’t have it. Open Firmware is burned into a ROM chip on older machines and can’t realistically be patched to add such major new functionality. So, only iMacs and blue and white Power Macintosh G3 computers can be NetBoot clients. The Macintosh Manager program will be available for older Mac OS clients as a replacement for At Ease for Workgroups, but they’ll still boot only from local hard drives, and you’ll still have to configure them the same ways you do now.
Nothing like NetBoot was previously available for the Macintosh, so there’s no "should I upgrade" decision. Instead, the questions for lab administrators are:
Do I have a lab of machines capable of networked booting?
Can my server handle the NetBoot clients on a single Ethernet segment per Ethernet port?
Do I want the easier configuration and trickier licensing entailed by sharing a single startup and applications volume?
In future technology purchases, I believe administrators will love NetBoot. Those with labs of older machines won’t find it useful, but every time an institution or company installs a group of several iMac machines with a Mac OS X Server for any reason, NetBoot solves a ton of configuration problems. There will almost certainly be some compatibility issues at first, as there were when Apple II machines first acquired network booting capability in 1987 with a far simpler operating system. But in the long run, NetBoot will be worth the bumps, especially in educational settings.
[Matt Deatherage is the publisher of MWJ, an acclaimed subscription-only newsletter featuring in-depth information for serious Macintosh users. A free three-week trial subscription is available at the MWJ Web site.]