Volume Number: 15 (1999)
Issue Number: 6
Column Tag: ExplainIt

NetBooting and You

by Kenneth Stattenfield

Or, how I learned to stop worrying and love the server

Imagine you manage a room of computers in your local junior high school that gets used by different classes of students during each day, sometimes just for word processing or web surfing, and other times for student programming work. After school, games get played on the machines and teachers type up tests and notes. You, as manager, have several problems, and many of them involve somehow making sure that every computer in the lab has the correct software installed, that the folks in front of each computer have access to this software, and that the students can't read the teacher's or other student's documents.

Mac OS X Server, with its NetBoot feature, hopes to make your life a bit easier. It allows you to install software on one computer, once, and have it available on any computer in the room. It allows you to require students and faculty to log in to computers before using them, and gives different users and groups of users access to different applications. Some users might only be allowed to run the applications their teacher has approved; others might be allowed to run anything installed. Since it provides a robust, centralized file server where everyone stores documents, users can sit down in front of any computer and get to their information. And, since it doesn't allow users of the computers to make any permanent changes to the software on any particular computer, there's no risk that a budding prankster in third period will manage to corrupt the installed software so that you have to rush to fix it by fourth period, because a simple restart will restore the computer to the setup you originally created.

NetBoot should also appeal to other users. Businesses seeking to reduce support costs, cyber café's that want to set up a group of computers which can not be corrupted, or developers seeking a quick way to rapidly test applications in a clean environment. This article will give you a background for Mac OS X Server, describe how NetBooting works from a user and a technical perspective. It will also point out some things that you should be aware of as a developer if you want to be NetBoot friendly and point out some developer opportunities that involve NetBoot.

NetBoot is a feature of Mac OS X Server, and is actually a synergy of several of the server features of Mac OS X together with some support in the Open Firmware of recent Macintosh computers and some new additions to Mac OS 8.x system software.

Mac OS X Server also provides web services via an Apache web server, file transfer services via ftp, and a WebObjects 4.0 environment including a 50-transaction-per-minute license and Software Development Kit. Also included is a prerelease of the QuickTime Streaming Server for sending many video and audio streams of data to multiple computers. A full description of Mac OS X Server can be found at <http://www.apple.com/macosx/server/>.

When a user sits down in front of a NetBoot computer, the first thing they will notice is that it looks and boots pretty much like every Macintosh. Starting up several computers from a NetBoot server is about as fast as starting up from the local hard disk. Users are asked to login with a username and password, and then find themselves in one of three environments - the standard Finder environment, a "restricted" Finder environment where many commands (such as deleting files) are disabled, or a simplified "Panels" environment. In the "Panels" environment, an administrator has defined exactly what applications are available to a user, and the user sees a series of icon buttons, which they can use to start each allowed application.

When a user logs in, the Macintosh Manager software copies down any saved Preferences and certain other files from the NetBoot server onto the computer, sets up the appearance and desktop for the user, selects the correct printer for this user, and performs other initialization to personalize the computer. When the user logs out by choosing "Quit and Log Out" from the bottom of the File menu in the Finder, or by shutting the machine down, any changed preferences are copied back up to the server, and the computer is returned to a common state.

Once in the Finder, the user will see two 'disks' on their desktop with interesting icons - the "Network HD" and the "Applications HD". The "Network HD" is the boot drive and contains a Mac OS 8.5 System Folder and whatever else the administrator has chosen to put there. The Applications HD is read only, and contains the applications which ship with Mac OS 8.5 (Internet Explorer, Outlook Express, etc) and whatever the administrator has put there as well.

Users will notice that if they copy files onto the startup drive, or download files from the internet onto the internal drive, that none of the changes they have made to the startup drive are present after they have restarted the computer. This is especially apparent with extensions, control panels, etc, since they must restart the computer in order to use these items.

Administrators have a significant amount of control over the setup of the computers. Individual users can not install extensions or control panels, nor can they disable the ones that are already installed. Privileges can be set on a per-user or per-group basis, and each user can belong to one or more groups. Users can have print quotas, and might be restricted to certain printers. The also may have file space quotas on the server. A particular user or group might only be allowed to run certain applications. On computers which have CD or floppy drives, their use can be restricted so that only approved CDs are used, or to disallow floppy use entirely. Administrators can also remove, with an extension, the local hard disks from the user desktops.

The risks of viruses are lessened in a NetBoot environment, because end users do not have persistent write access to the boot disk nor to the applications disk. Even if a user manages to infect a particular computer with a conventional virus (like MBDF , upon restarting that computer will throw away every change made by the user (including the complete set of infected applications) and go back to the uninfected setup originally created by the administrator. However, document-based viruses, like Microsoft Word macro viruses, or applications which the users place in their space on the fileserver, will still exist so NetBoot does not entirely eliminate the problems with computer viruses.

Administrators install software by using a utility called the "NetBoot Desktop Administrator" application. When run by an administrator on a NetBoot client, this application places that particular computer into a 'persistent mode', and all future changes made on that computer are preserved across reboots. The administrator can install software, remove software, rearrange or delete files, etc. When happy with the new setup, the administrator runs this application again and commits the changes made so that all users will see them the next time their computers reboot.

A NetBooted computer implements these features in several ways. Only recent Macintosh models iMacs and later) are capable of NetBooting, because the lowest level of support necessary to NetBoot is only implemented in the Open Firmware for these machines at this time. In these machines, at startup the code in Open Firmware will look at where they are suppose to startup from, notice that it is a NetBoot server, and will begin the process by sending out a special Ethernet BootP packet asking if a NetBoot server is available. If there is a server in the same subnet, it will reply to the client with an IP address the client can use as well as information about what disks will appear on the client once it boots. After getting an IP address, a client will download a copy of the Mac OS ROM file from the server and then mount the Network HD and Applications HD disks from the server.

From the point of view of the Mac OS, the boot and applications disks are using a normal, block oriented disk driver named "LANDisk", which uses an Appleshare File Protocol over IP (AFP/IP) connection to the NetBoot server to get and put data onto the 'disk'. However, this AFP/IP session is distinct from any 'normal' Appleshare session that may be opened on the computer.

At the lowest level, the system is using a special version of the Ethernet hardware driver which can allows the driver for the network disks and Open Transport to share a single IP number. Incoming packets are distinguished based on the protocol and port number. Packets destined for the AFP session for the .LANDisk driver are not visible from Open Transport. The AFP session that is used by the .LANDisk driver is not accessible from within the Mac OS proper.

On the server, the "Application HD" and "Network HD" are stored as uncompressed, read only DiskCopy disk images. A client opens a read-only connection to each of these over the AFP/IP session, and the block driver translates read requests for a given block into a read from a given offset in the appropriate file. The non-persistence of the startup disk is accomplished almost entirely by the client. When a client starts up, if a particular volume is suppose to be non-persistent, then the server gives the client two files for that volume - one is the DiskCopy image, which is opened read only, and the second is an empty, writeable file. The client will write any changes to the disk into this second file. It will read a block from the first file unless the block being read has already been written to, in which case it reads from the second file. This second file essentially becomes a shadow and contains only the changes from the first file. The contents of this second file are discarded whenever the client reboots, so the changes made disappear.

The system also patches a number of traps to force users to log in and log out, and to prevent users from tampering with the system folder in an attempt to circumvent the security of the system.

Hopefully, we at Apple did enough work to maintain compatibility that most Macintosh software should work correctly in the NetBoot environment. However, no system update or change is ever free of changes that can affect the existing base of applications, and this one is no different. In testing the NetBoot environment, we found that most applications worked correctly, although some had minor problems. Applications which attempted to write back to their own data forks failed when placed on the read-only Applications drive, but also would have problems running from a locked fileserver prior to the release of the NetBoot server. We found a few applications which attempted to write back to their own files only on first launch as part of a user personalization or serial number entry process, in which case they would fail.

One of the implications of a NetBoot environment is that the 'local' hard drive is not the primary data storage for a user, since users may move around from computer to computer but want their data always accessible. While the current setup with user files stored on a fileserver volume works ok, it is not necessarily the most appropriate solution. For example, in a NetBoot computer lab it is probably better to set everyone up with email accounts on a IMAP server and have them read their mail with an IMAP client instead of setting everyone up with POP3 accounts. The IMAP architecture has users keep their email on a central server instead of downloading it into a number of private but still server based POP3 databases. You may find that this mentality causes you to rethink how the applications you produce are designed and used.

There are still some things that you, as a developer, need to be aware of. If you store preferences outside the Preferences folder, then these likely will not be saved and restored for each user as they log in and out. If your preference files are excessively large, then users may complain that your software is causing excessive log in and out times.

If your applications use the local hard drive to cache data, then make sure that the user can control where this cache is created - otherwise, NetBoot users will find that their applications perform poorly as they rebuild this cache each time they use your application.

NetBooting opens new opportunities for developers and value-added resellers. Early on, many of the users of NetBoot setups will be schools or computer lab set-ups. Over time this should increase and may encompass business users, especially in environments where centralized control and workflow management is important. So, a pre-press environment may decide to use a NetBoot server for many of the users in order to insure that every user has exactly the same set of fonts and applications, with the correct versions, running at all times. For example, if schools use the NetBoot architecture, that they may also want to buy good web filtering software (perhaps server based, combined with a good web proxy, since bandwidth is still rather limited in schools).

NetBoot also shifts the focus for where data is stored from local files onto fileservers and onto other kinds of servers. A calendar application which stores all of its data in files in the system folder is not as useful in a NetBoot environment as one which can store data in a file on the fileserver.

It is possible a single user will be logged onto more than one computer at a time. The current NetBoot environment doesn't handle this situation very gracefully, but does allow it to happen. If a user logs onto two computers, and does something that changes a particular file in the Preferences folder on both computers, there is not concept of merging these changes - the files with the later modification file dates will be kept and the earlier ones will be discarded.

For the terminally curious, you can tell if your system is NetBooted with Gestalt().

Boolean IsSystemNetBooted ()
{ long value;
		if ( (Gestalt(gestaltSplitOSAttr, & value ) == noErr) &&
				( value & ( 1 <<
					gestaltSplitOSBootDriveIsNetworkVolume) ) )
		return true;

		return false;
}

There is presently no easy way to tell if the system is booted persistently or non-persistently. Eventually, there will be a gestalt selector with this information.

You may also want to make changes in the documentation for your products, to indicate whether you have tested them in a NetBoot environment and to detail any oddities during the install or configuration.

Licensing of products for use in the NetBoot environment requires some thought, since the 'same' application is installed once into the master image but then gets used on a number of computers. You might consider selling a license for a single NetBoot server, allowing all clients of the server to use the software, or you may want to recommend a product like KeyServer (from Sassafras Software, <http://www.sassafras.com/>) that can monitor and restrict use to only those number of copies which have been purchased. Licensing is especially important in a regimented environment like a school computer lab, where most users will probably be expected to use the same software simultaneously.

Similarly, applications which require serial numbers and insure that only one copy of the application is running with a given serial number have a serious problem if they write the serial number back into the application's data files, since each computer booted from a NetBoot server will use exactly the same set of applications. To this end, Apple has recommended for some time that applications do not write back to themselves. With the advent of NetBooted computers, it's useful to also add that applications with serial numbers should write their serial numbers to their Preference files. This way, a user who has purchased an application will enter it's serial number when they use the application the first time, and the serial number will move around with them as they log in and out from each computer.

On the client side, Apple expects to eliminate the necessity of copying preference and other files back and forth as users log in and out. In order to do this, we will change FindFolder() so that it returns a vRefNum and dirID which point to a folder on a server when you call FindFolder ( kOnSystemDisk, kPreferencesFolderType, ... ). Your code must use both the vRefNum and dirID returned by FindFolder in all cases. Do not assume that the vRefNum for special folders, including those in the system folder, is -1.

Future versions of the Mac OS may include more security, both to prevent one user from accessing the files and folders of another user, as well as protecting some parts of the system (like the System Folder) from being accessed by users who do not have the authority to make changes to the computer.

Many users have also requested that NetBoot client computers use DHCP instead of BootP to acquire their IP address, and this is something which Apple is looking into doing in a future version. Additional authentication, and opening up the authentication that is provided, is also being considered.

On the server side, any move to DHCP would have to be mirrored with DHCP support and the user interface changes to configure DHCP. It is also desired to produce a solution that can run with IP only, eliminating the need to use AppleTalk in a NetBoot setup. Also, future versions of Mac OS X server should support gigabit Ethernet and more networking connectivity.

NetBooting is a new capability for Macintosh computers. At the moment, it will appeal most to administrators and to lab-type computer settings, but over time, as more Macintosh computers are capable of being booted from the Network and as fast, ubiquitous networks begin to appear, the ability for users to get to their data in a seamless way no matter where they happen to be will become very important. Your applications probably already work in a NetBoot environment, but with a little work you may be able to give your users a fabulous experience.

Keith Stattenfield toils within the castle walls of Apple Computer in Cupertino, California, fixing bugs and misfeatures in each Mac OS 8.x release. His exploits can be observed in real time at <http://www.stattenfield.org/keithcam/>