[5214] in Release_7.7_team
using wanboot for Sun installs
daemon@ATHENA.MIT.EDU (Robert A Basch)
Thu Jul 21 00:36:25 2005
Message-Id: <200507210436.j6L4a4Ai028648@anhedonia.mit.edu>
To: release-team@MIT.EDU
Date: Thu, 21 Jul 2005 00:36:04 -0400
From: Robert A Basch <rbasch@MIT.EDU>
X-Spam-Score: 1.041
X-Spam-Level: * (1.041)
X-Spam-Flag: NO
After doing more investigation, I believe we can deploy a new install
method for Solaris 10, using Sun's wanboot instead of cnboot, thus
eliminating the need to hack the Solaris kernel and boot sources. At
a recent release team meeting following my initial investigation, we
identified two problems with wanboot:
1) While wanboot supports manual configuration of network settings,
doing so is less user-friendly than the cnboot-based method -- the
installer would have to specify the boot server URI of the form
http://18.x.y.z/cgi-bin/wanboot-cgi, as well as the host IP and router
addresses and netmask.
2) wanboot downloads a miniroot image into a ramdisk. The miniroot
I generated for testing was about 170 MB, which took several minutes
to download. Apparently the miniroot cannot be compressed.
Since 2) is only a significant issue for a custom install (once the
miniroot downloads and boots, the install is started automatically,
and the prompt for a custom install will time out after a minute),
I focused on how 1) could be dealt with, and found that DHCP could
provide the necessary configuration information. While our PROMs
do not have sufficient DHCP capability to be useful on MITnet,
wanboot does; specifically, it can be given a DHCP client identifier
to use, which will distinguish it from other booting clients. The
only disadvantage is that wanboot will not use any manually specified
IP address when using DHCP, so it would need to be assigned a
temporary address; however, the "real" IP address could still be
passed via the command line, so that the install miniroot could
read and use it.
I have talked to Mark Silis about this, and he said it should be
fine to add the appropriate configuration to the MITnet DHCP servers
to make this work. The DHCP server would assign a (temporary) address
to a client with the appropriate prefix (e.g. "athena-sun") in the
identifier, and also pass back the boot server URI for wanboot.
(I also spoke to Garry and Jonathon, and they both seem open to this,
though would prefer that the MITnet DHCP servers simply forward these
requests to an Ops server; however, Mark prefers not to have other
DHCP servers giving out IP addresses).
For the installer, this can be done via a boot command line such as:
boot net:18.179.0.20,wanboot,<my-IP-address> -o host-ip=<my-IP-address>,client-id=athena-sun,dhcp
The first part of the command is the familiar <server-IP,boot-file,my-IP>
syntax we now use, with cnboot as the boot file. The "-o ..." part gives
options to wanboot: the host-ip setting is used only to pass the machine's
real IP address to the miniroot, as the dhcp option will cause wanboot to
use an address assigned by the DHCP server. The "client-id" setting is
used by the DHCP server to distinguish our client from others; the server
will return the URI for wanboot to use, in addition to the assigned IP
address. (A variation on this command might be to append the IP address
to the client-id, instead of supplying the host-id parameter; we may
need to do this if the DHCP server requires the client ID to be unique,
as I suspect, though I have not been able to verify that with Mark as
of this writing).
Once it has been properly configured, wanboot connects to the boot URI,
which invokes a CGI program on the web server, delivering a tiny (less
than 1 MB) wanboot filesystem containing configuration, followed by
the actual miniroot. Note that the URI supplied in the DHCP configuration
is generic, merely pointing at the boot server's wanboot cgi program,
as in 1) above; wanboot can be configured to support different
clients, based on IP address or client ID, so we would not need to
change the DHCP server configuration to, say, test a non-production
install. (We can add configuration to the DHCP servers to support a
test install server, as well as the production server).
As for the download time, this can be reduced significantly by having
the client mount a separate /usr partition via NFS. I was able to
generate a root of about 70 MB which worked this way, i.e. reducing
the download time by over 50%. Unfortunately, though, I also found
that there are apparent performance problems with wanboot on a Solaris
9 server; downloads of even this smaller root from a Solaris 9 server
took well over 5 minutes, where the same download took about a minute
and a half from a Solaris 10 server. A "wget" of the miniroot from
the Solaris 9 server was reasonably fast, so I suspect the wanboot
server software is the culprit. This could be a problem, since Ops
presumably will not be running Solaris 10 servers for a while.
(And currently tkl, the Sun install boot server, is still running
Solaris 8, and would have to be upgraded to at least Solaris 9 to
support wanboot). I will investigate this performance problem
further, but I don't think it is a showstopper, since, again, the
installer would only have to wait for the download to complete if
doing a custom install.
Comments?
