CNBoot Project

by Bill Cattey

Last Modified: $Date: 2002/05/28 23:20:03 $

Update: May 2002

Sun has taken steps to implement part 1 of the CNBoot enhancement request by documenting the long form boot PROM command. Find the relevant information on page 19 of the OpenBoot 4.x Command Reference Manual.

Over time, more and more customers have come forward interested in this functionality.

Meeting have been held with various Sun managers and engineers.

In the 1994/1995 academic year, MIT made its first large-scale deployment of Sun workstations as part of the Athena Computing Environment. The Sun Workstation of 1983 was the commercial product that most closely resembled the Athena workstation computing model, but for various reasons it was not until 1994 that purchasing from Sun was possible.

The final obstacle to deploying Suns at MIT was in getting a modification to the Sun network install process that could be made to conform to infrastructure constraints: No pre-registering of MAC addresses for systems to be deployed, No per-subnet support servers, and independent coexistance on the same LAN with a departmentally purchased Sun install server. This modification originally coded by Georg Nikodym of the Sun OpCom Migration support group in May of 1994 was called CNBoot.

For every subsequent annual Sun upgrade, MIT had to come up with a rewrite of CNBoot. Initially this consisted of finding where Georg was working and getting permission for him to do the port. Most recently, MIT used Solaris 8 reference sources as the basis of a port. Note that "reference sources" are supplied for a customer to read and understand. They are not really intended to be compiled into working binaries. With minimal help from Sun, we had to understand the restructured 64 bit rewrite of the relevant modules, port our changes, and get everythying to compile ourselves this year.

MIT very much wants to get out of the business of porting CNBoot every year. In December of 1998 we filed RFE 4199849 explaining the issue, outlining a specific solution that would completely meet our requirements, and asking to engage in dialog to come to a mutual solution. Unfortunately, every time we checked back on the RFE, we were told that the RFE had been implemented. Our reply each time has been, "We don't understand how our enhancement could possibly be implemented if nobody talked to us to explain the implementation, or to test whether or not it met our requirements. Please reopen the RFE and get someone to talk to us about it."

This document describes the solution we advocated in the RFE, another possible solution, and the status of the process of getting MIT out of the business of an annual port of CNBoot.

The stumbling block to using the Sun network install at MIT has been the assumption that, whenver the installing client system needed to know its IP address, it could broadcast a RARP request to get it.

RARP is a problem for MIT because we have a couple hundred subnets, and on many of these subnets, we don't have enough of a presence to install a RARP server. (Sometimes we end up fighting the janitorial staff for enough space to deploy a 10Base-T hub without fear that it will be destroyed when the wet floor mop hits it.) We also have a service model that requires never pre-registering the MAC address of the desktop machine deployed.

One way to frame the issue is, Athena Sun installs must avoid use of RARP. Another way is to state the underlying requirements:

• No pre-registering of MAC addresses (or any other hand-work) for each individual system to be deployed.
• No per-subnet support servers. Ideally hundreds of Athena Sun client systems should be able to be installed with a single central support server host.
• Ability to coexist on the same LAN with a departmentally purchased Sun install server. (i.e. A departmentally administered set of client hosts should be able to successfully install while on the same LAN as centrally installed and administered Athena client hosts.

A 3 part enhancement to the existing Sun install process that would neatly solve the problem was proposed in December 1998 in RFE 4199849:

1. Formal support of the presently undocumented long form "boot net:" command in the Open Boot PROM.

   boot net:<SERVER>,<BOOTFILE>,<CLIENT>,<GATEWAY>

2. Merging in functionality to the Sun inetboot program for which MIT has demonstrated proof of concept: Fetch the arguments from the long form "boot net:" and use them in preference to RARP if they are present.
3. Merging in functionality to the nfs_dlboot module for which MIT has demonstrated proof of concept: Use the arguments saved from the long form "boot net:" at install time if they are present instead of doing RARP.

Parts two and three represent on the order of 20 lines of C code change in the affected modules.

These modifications represent functionality that is invisible to anyone who is not using the long form "boot net:" command. Everything still works as before for those users. The only impact is a small development task to make sure the functionality is gracefully and robustly integrated into the standard Solaris sources, and a small ongoing committment to keep the features alive and well.

It is difficult to know when to "just add the 20 lines of code" and when to "protect the integrity of the existing code base". In the case of the CNBoot RFE, there seems at last to be a critical mass of large enterprises saying this functionality has great value. It clearly has small cost on the development side. The future support costs seem justified.

The Sun Open Boot PROM also supports the bootp protocol. Unfortunately, bootp as it is currently implemented by Sun allows differentiation of systems only through a central registration of MAC addresses. Some other way must be crafted to allow this differentiation.

A solution that most fits with what Athena operational staff are used to would involve a way for a person sitting at the client host being installed to type extra text that gets passed to the bootp server.

In the past our DECStation/Ultrix systems allowed a user-specified bootp "client identifier" at the PROM level. This identifier combined a partial IP address naming the subnet and 'athena' to show that it was ours. The bootp server assigned an address to the client that was specific to the subnet, and specified from where to TFTP an initial install program. That program prompted the person performing the install for a client IP address used in later boot stages.

RFC 951, the specification for the bootp protocol says that the last 64 bytes of the bootp packet is vendor specific data that can be sent. An example of the use of that data is:

e.g. could be hardware type/serial on request, or 'capability' / remote file system handle on reply. This info may be set aside for use by a third phase bootstrap or kernel.

So it is definitely within the scope of the bootp protocol for a vendor, such as Sun, to utilize some of this block for precisely the purpose of passing information from the client host to the bootp server. All that is required is to agree upon an identifier, and enhance the OpenBoot PROM to have a command to tag user-supplied data with that identifier in the 'vend' portion of the bootp packet. For example:

{ "SUN_USER_SPECIFIED_CAPABILITY", Up to 32 chars of data typed by the user, and accepted by the PROM }

It may be that the DHCP support in the current revisions of the OpenBoot PROM support something that could be used directly in this way, or could be co-opted into functioning in this way, but nobody at Sun has yet demonstrated such to us.

Sister schools to MIT were asked whether or not CNBoot functionality would be useful.

A representative from the University of Michigan said,

We would benefit hugely from this. The College of Engineering here at University of Michigan centrally installs about 300-400 Suns each year.

A representative from CMU said,

... RARP is no longer bridged across campus, so for that reason this would be a huge, huge win for us.

A representative from Stanford University said,

Yes, we badly want this feature. Lack of this feature has been the main thing preventing us from deploying a Jumpstart service to other administrators on campus. If you could do a boot net - install given nothing but the IP address of the install server and have that server pick up some generic install parameters, that would be great.

Apparently this page got indexed by a useful search engine. One day, out of the blue, I received email from representatives from Hydro Quebec saying, in part,

A colleage and I have just spent an incredibly frustrating weekend trying to put together a "no subnet boot server" unattended install solution without coming up with anything very elegant.

If you can provide me with your list of "other interested customers" for ammunition I'd be glad to contact our support group here in Toronto and add our voice to the list of people dissatisfied with the current net boot situation.

As a consequence of the Hydro Quebec folks discussing CNBoot in a Solaris Developer's forum, I received the following from the Sun Service Engineer responsible for the AOL account with Sun:

I would like to find out where you stand with your product, as well as see if I can help push the RFE through at Sun. I have made the same request you have, atleast from a functional standpoint.

The more large enterprises that hear about this functionality, the more who chime in saying that what MIT pioneered is a simple and valuable enhancement that should be taken over by Sun. Many express surprise that Sun has not taken action on this sooner. Some have expressed frustration at being told by their local Sun representative that nobody else has ever asked for such functionality. It seems that imperfect communication amongst customers and Sun has in the past, conspired to keep hidden the real value here. It's time to pay attention, and to remove the last tiny obstacles to getting this functionality into the hands of large customers hitherto dissatisfied with enterprise-wide boot and install from Sun.