Components - machines
There is one master machine and multiple subordinates.
There is no need for the master machine to also be a G4,
but without a doubt it avoids a lot of possible confusing by
having it be one and the same as the subordinates.
The task of the master is to be a switch. A master switch.
The administrator can configure the booting of the subordinate machines
on a one by one basis to boot into MacOS, to boot any other preinstalled
OS, or to install Debian Linux using a novel installation process
which nonetheless performs a standard Debian install.
Perspective of a subordinate machine
Let me describe "the method" from the point of view of a G4
that is to become a subordinate machine, starting from the when the
power comes on. At power up, the first thing to be executed
is the Open Firmware. Open Firmware
will proceed to issue a unicast DHCP request
(as opposed to multicast/broadcast) to the master server.
If it does not receive a response, it will give up after a preset
timeout period and boot
MacOS if it can find it on the hard drive.
If the DHCP process is successful, then it will have received an
executable bootfile which it will execute, passing full control over to it.
Assuming Linux is to be installed, then the bootfile will
request a second bootfile which is yaboot. Upon execution
yaboot will tftp request its config file - yaboot.conf, which
will in turn request the linux kernel, and a ramdisk image.
This ramdisk image contains the bare minimum needed to install Debian Linux
using debootstrap ! Thus the Debian that gets installed
is live - if you want it to be - straight from an official
Debian mirror. If you use Sid, you will be guaranteed to be
one of the first to find the latest fu^H^Herrors that break
the process. Don't worry, they usually get fixed fairly
quickly - try again every 6 hours :)
The master view
First, using a web form, the desired subordinate nodes
are set to boot and install Linux instead of booting MacOS by the operator.
(for example)
Next, the operator must reboot the machines, whereupon
the master server will start to receive DHCP requests from
a known and permitted operating system. The only permitted
OS in this case is Open Firmware. This ensures that when MacOS
boots and sends DHPC requests our DHCP server will - ignore it.
Upon successful DHCP configuration of the subordinate, a tftp
request for the bootfile (specified in OF and in DHCP) will be received
by the server. This connection will be intercepted by tcpd, which
will attach the connection to a tftp daemon which has its
TFTPROOT set to a directory unique to the connecting machine, as
determined by the IP address of the connecting machine. This is known
as the twist.
Within this host specific TFTPROOT directory is the host specific
bootme file and host specific yaboot.conf file. The tftp requests for which
are all twisted into the appropriate host specific directory.
Outline of key principles
- subordinates are netbooted
- a private network address space is used for running Linux - which
is not under the control of any existing DHCP server.
- a modified DHCP server is placed on the network to control the netbooting
- tftp requests are twisted using tcpd on a per host IP identified basis
- debootstrap is used to install a base Debian Linux from a small ramdisk image
- symbolic links are used in the host specific TFTPROOTs to a general
TFTPROOT
- a web form(cgi) is used to set the links in the twisted TFTPROOTs, which
maintain state information for each subordinate machine
- debut.tgz is provided for creating new ramdisk images from sources
- the ramdisk image loads an installation script from the master
machine using HTTP.
- the installation script can use 'dpkg --set-selections' to
specify packages which should be installed during the base-config
process of the Debian installation (occurs after first reboot)
- a debian package (fart-0.xx.deb) is provided to create or recreate a master
server in its entirety.
- arp handling must be fixed on the master server