The first step before we are able to clone a setup is to provide an initial setup on one of the cluster machines. The idea is to use this machine as the clone master. Partitioning, installation of the different OSes with the selected software as well as configuring of the booting procedure and the security setup is done only once on this master machine. After that it can be copied to the whole cluster.
For the initial installation we partitioned our 9 GB harddisks into a small 20 MB partition holding the boot-manager, two Windows NT partitions for educational use (one in US English and one localized in German) and a third Windows NT partition without security for research work, 2 GB each. Further, we added a partition for the ETH specific System Oberon which is 100 MB in size. For parallel computation with scientific codes we install Linux into a 1 GB partition for the root file system and a smaller 128 MB swap partition. A 1 GB partition is left as spare partition for future operating systems to be installed later (such as e.g. Solaris, NetBSD or Rhapsody) or for more swap space in scientific codes.
The booting procedure is accomplished by a commercial boot utility named System Commander. A startup screen permits the users to select a partition with the desired OS image from a list of options and allows password protection for certain partitions as well as for removable devices such as the floppy or the ZIP drive. For unattended operation of the cluster a selectable default OS is booted after a few seconds (timeout).
As we used standard installation tools for the different OSes we had to figure out in which order such a multi-boot installation can be setup. Especially the installer and bootloader of Windows NT has some restrictions. There may be different procedures but this one we know to work.
First we booted the master machine with the WindowsNT installer and deleted all existing partitions. After that three partitions have to be setup. A small one (16 MByte) for the Boot Commander and a 200 MByte large partition for a small Linux installation (CloneSys). After that the partition in which Windows NT has to be placed can be setup. The installer will then format the boot partition as well as the Windows NT partition and start the installation. After that the system has to be rebooted which won't run because of an error in the installer. At this stage System Commander comes to help. Its setup program installs its own master boot record which then starts the boot loader. At the first booting procedure System Commander recognizes the Windows NT installation and attaches it to the list of bootable OSes. With this, Windows NT can be started and the setup can be continued.
After this initial procedure we installed our small Linux system on the 200 MB partition which allowes to setup the rest of the machine.
As we had different Windows NT installations which we wanted to be installed on a C drive we additionally did a ``normal'' Windows NT installation on a first partition of a clean disk. This image we then cloned to our multi-boot master machine. After the first boot, the drive letters have to be remapped using the NT Disk Administration Tool. First the boot partition (DOS) has to be mapped to X: as it comes up as the C-drive. After that Windows NT can be mapped back to C: again. This allows to clone the same Windows NT master to more than one partition and adjusting the drive letters back to C for all the installations.
We detected a restriction of the Windows NT boot loader which forced us to install bootable Windows NT systems in partition that start before about 4 GByte on the disk.
Each OS setup used in the cluster is installed once on a master machine. The master is booted with a small service OS and the disk partitions are copied block-wise onto a server that serves as a repository for all current partition images. To replicate the partition to one or more other machines we reverse the route of the transfer from the image-server to the client machines and write the image block-wise back to the several local disks.
Since the original OS image and its copies on the disk are bit-wise identical we call this way of replicating partitions, entire disks or images with OS installations cloning. In most cases a freshly cloned OS can not be brought to life with a simple boot but requires some configuration. After a considerable effort we could keep the individual configurations of the operating systems at a minimum and make freshly cloned images bootable. We use a DHCP server on the same Ethernet segment to assign IP addresses and machine names based on the unique Ethernet MAC address built into the primary network interface of each PC.
The most important goal of security settings is to avoid any inconvenience by another operating system that is unrelated to the users work and that might not even be known to that user. A second purpose of the security setup is to protect the integrity of the system installation from corruption and to prevent the different users from clobbering each others personal data stored on the servers. In a multi-boot setup multiple levels of security are needed and the different security mechanisms of the different operating systems need to be coordinated.
The first level of this security setup handles the booting procedure. The System Commander utility offers menu controlled selection of the operating system of choice and protects research systems and administration setup with a fairly sophisticated password protection scheme, that allows user groups to be defined.
The second level of system security deals with the visibility (or better invisibility) of partitions with other operating systems including the boot partition with its powerful administrative tools. It should remain impossible to modify data on partitions belonging to other operating systems at least for a normal, mortal user. In order to dissuade educational users from exploring and cracking system security, a shareware tool, called DeviceLock hides unused partitions and systematically denies access to them at the Windows NT driver level. The same task is accomplished in UNIX systems by retaining mount as a privileged operation and configuring the default mounting tables accordingly.
Since the NTFS 4.0 file system does not yet support basic OS concepts like mount points multi-boot setups have to worry about drive letters. We enlist the device name remapping mechanism of Windows NT and remap the partitions in a way that the partition of the active OS image is always the C: drive. This allows to use the same application links (and shortcuts stored in the user profiles) across all Windows NT installations on the campus. With this trick it is even possible to switch between two different Windows NT systems transparently for an English or German version.
For our education environment a Windows NT Domain Server authenticates users and controls access to the local and remote files in the cluster -- for the research environment a Linux server handles all user authentication according to the Sun NIS protocol.
The lightweight Oberon system that is used for the system software courses copies itself onto a RAM disk upon startup and restricts the access to the disks to read-only at the driver level.