[2685] in Release_7.7_team
RE: So what SHOULD we do about CNboot?
daemon@ATHENA.MIT.EDU (Tom Coppeto)
Tue Apr 10 20:34:34 2001
Reply-To: <tom@MIT.EDU>
From: "Tom Coppeto" <tom@MIT.EDU>
To: "Bill Cattey" <wdc@mit.edu>, <release-team@mit.edu>
Cc: <pbh@mit.edu>, <longpd@mit.edu>, <mark@mit.edu>
Date: Tue, 10 Apr 2001 20:35:11 -0400
Message-ID: <HAEGLCGNHJINDBBIGLDGEEJODBAA.tom@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-reply-to: <0uosK3Vz00018NMnMs@mit.edu>
We have one solution to this problem. Sun provides a version of inetboot
that depends on dhcp and this works without any mods to the miniroot. This
was featureful for me since we deployed 420r machines before any of the
cnboot work had been done and allowed the native distribution on the
solaris8 cd to just work.
DHCP by itself is a small problem in scale since there is no way to
distuinguish what installation is desired and we do restrict the giving out
of addresses through registration (I cheated to get the 420's up and running
on a short schedule).
Mark modified inetboot to alter the vendor field so that we can punch a hole
in the campus DHCP to allow the installation of suns -- the same way we are
dealing with the windows pxe clients. [This is where Mark and I are today]
We also need to modify the dhcpagent on the miniroot to pull this scheme
off. It isn't pretty but it is effective and was easy to implement with
solaris8 source.
This gets us the network configuration required for installation but it does
not address the "island of control" problem of specifying which install
server and image to boot from. The Sun DHCP scheme allows the install
paramaters to vary only with the platform, not specified by the user.
Currently, there can be only one installation game in town using DHCP.
The next step is to add another change to inetboot (and adding something to
the boot script to re-fetch these paramaters after booting the mini) that
accepts a token that can be used to deliver the appropriate installation
paramaters via some method like tftp or dns. In this case DHCP is only used
for network configuration and we use some non-DHCP mechanism for
installation paramaters. Now, anyone with a need for repeatable solaris
installations can use this method, using any specified boot image or install
server, from anywhere where any DHCP server will give out an address to
them.
Unless sun can be of more help here, we will have this work done in any case
since supporting multiple solaris versions and restricting installs to the
MIT dhcp are a pain otherwise. We've already had people set up their own
DHCP servers to get their machines installed and this is something we'd like
to avoid as well -- which means we need such a solution that interoperates
better.
The bottom line is that while we don't get out of the modification business
altogether and will continue to require source for inetboot, this is much
more in line with the way sun intends it to be done and fighting them less
saves us time and gets our stuff out faster. Sun just doesn't understand
DHCP on a campus scale might be used for any number of things and crosses
many departments.
- Tom
-----Original Message-----
From: Bill Cattey [mailto:wdc@MIT.EDU]
Sent: Tuesday, April 10, 2001 6:13 PM
To: release-team@MIT.EDU
Cc: pbh@MIT.EDU; tom@MIT.EDU; longpd@MIT.EDU
Subject: So what SHOULD we do about CNboot?
As you know, the way we install Suns relies on an annual port of a thing
called CNBoot. CNBoot enables us to sit down at a Sun, type in an IP
address, the install server address, and the name of the thing the
installer should install.
Every year we end up having to port it to the new version of Solaris.
We got into the CNBoot business because we did not like the existing
alternatives for being able to associate an IP address and a program to
install with a Sun box.
Some enterprises just register the ethernet MAC address and associate
that with the IP address and install image.
Sun install servers can assume they are the only install server in the
world and respond to ALL requests. This has been problematic when we
want an client system with the Athena install to coexist on a subnet
with a vanilla Sun install server.
Since the first version of CNBoot was received by us in 1993, the Athena
development team has tried to get Sun to either adopt it as a standard
part of the Sun install system, or to work with us on production of some
new standard install system.
The Athena development team has, up to now, considered solutions that
require registering MAC addresses, or imposing a single install server
as non-starters.
With enterprise-wide install being much on the minds of both Athena and
Pismere folks, I think it's appropriate to ask what should we do about
CNBoot? Should we:
1. Quit trying to get Sun to adopt our old CNBoot as standard?
2. Quit trying to get Sun to work with us on something new?
3. Relax the "no registering of MAC addresses" requirement?
4. Relax the "no single install authority" requirement?
5. Resign ourselves to an annual port of CNBoot?
6. Some other option?
Up to now we and Sun have been unable to rendez-vous on this topic.
In the near future an engineer from Sun may come to discuss install with
us. What course of action offers the greatest long term benefit at the
lowest long term cost?
Should we assemble a small group of people to brainstorm this problem
and suggest a couple courses of action? What I have tried thus far by
myself has not had as much success as I would like.
-wdc
