ReAssure Project Home Page

ReAssure Experimental PCs

ReAssure Experimental Hardware

Dual Athlons on Sun hardware
4 GB RAM
up to 6 Gbit network interfaces (1 control + 5 experimental)

Reimaging of Experimental PCs
The ReAssure system reimages experimental PCs using PXE. Reimaging is only done when there is a change in the host OS software. Experimental PCs poll the PXE Boot server at boot time, and are told to boot either from their local file system, or using files on the server. If they boot from the server, then a script runs that wipes the disk, repartitions it, and reinstalls all the software in the correct partitions.

Details
The relevant scripts are in the "web_server/reimaging" directory of the ReAssure software download. These are installed in the /diskless directory on the server. The directory structure is:

/diskless
	/pxelinux.0 (the pxe boot linux kernel)
 	/pxelinux.cfg
		/default
		/remote.boot
	/bzImage  ( a ~2MB file)
	/reimage
		/bin etc... ( a full system image)

	/tmp
	/var
	/vmlinuz (symlink -> bzImage)

In the "pxelinux.cfg" directory, the "default" file contains:

default Local
prompt 1
timeout 2

label Local
  localboot 0

which tells the experimental PC to boot using the local file system. The file "remote.boot" contains:

default Remote
prompt 1
timeout 3

label Remote
  kernel /bzImage
  append ip=dhcp root=/dev/nfs nfsroot=172.30.0.5:/diskless/reimage

which tells the experimental PC to boot using the image in the "reimage" directory. This contains a reimaging script ("setup/reassure_setup.sh"). The reassure_setup.sh script is launched from the net-booted OS's /etc/init.d/local startup script. The script repartitions the experimental PC, creates new file systems, mounts the partitions under /mnt/gentoo/, and expands the tar balls, which appear to be locally available from the point of view of the script. The tar balls are the wad.tar and template.tar files that it expects to be in the tar/ subdirectory.

wad.tar is the entire expPC system.
template.tar overwrites /etc/conf.d/net and /etc/conf.d/hostname from wad.tar, to be modified later via a 'sed' command. template.tar itself can most likely be done away with entirely by using a slightly more clever 'sed' command. It's on the to-do list.

The new OS is setup using a chroot environment (standard practice for Gentoo Linux), and then sets up new SSH keys, NX keys, known hosts, etc... This is done by the script "chroot.sh", which performs these actions:

vmware_answers.txt is read by vmware_config.pl, to automate the vmware configuration. Note that doing this doesn't correctly remove /etc/vmware/not_configured, so that is scripted in
A symlink is created so that vmware-server will run when the system boots on its own.
Grub is installed on the MBR, to handle booting from the local disk.
SSH known_hosts are cleaned up to make NX happier
SSH keys are generated, though that step is not strictly necessary and may be removed in the future.
NX is setup to use the nomachine keys. Note that the nxsetup fails every time, because it is actually trying to SSH into the OS you have chrooted from, which may not be configured for NX. It has been our experience that NX is still set up correctly in spite of its error message, and exceptions to that may be due to other factors (heavy NFS load, etc.)
known_hosts (which NX just populated with the id.pub of the OS you have chrooted from) is set back to contain the expPC root's id.pub, so NX will more likely be happy when the expPC boots on its own
user processes are set to a hard limit.

The experimental PC reboots at the end.

The DHCP server DHCP needs to be configured to support the PXE boot process. Relevant settings in /etc/dhcp/dhcpd.conf are:

allow bootp;
allow booting;

group {
        next-server 172.30.0.5 ;
        filename "pxelinux.0";

# define IP addresses based on MAC addresses
        host exp01 {
                hardware ethernet 00:09:3D:12:20:ED;
                fixed-address 172.30.0.11;
        }

        host exp02 {
(...)