One of the main challenges in running a school computer laboratory is managing the software running on the different PCs allocated for use by students. System administrators face various scenarios, all stemming from the nature of a learning environment in which users all have superuser access to their machines. For example:

In addition, there are several variations of the scenarios depicted above. Compounding the problem are scheduling pressures, as school computer laboratories frequently must accommodate a variety of classes, each one having its own unique requirements. Even administrators who manage a laboratory dedicated to one class per week still have to reinstall their systems for subsequent classes.

System management tools designed for the enterprise generally are inappropriate for a school computer laboratory environment. They were meant to manage a more-or-less consistent profile of computer systems across a company, one that changes less frequently and one with stricter usage policies than a learning environment. The cost of a commercial system management suite also can be prohibitive for a school.

Scripted installation tools, such as Red Hat's Kickstart program, can automate the installation of the operating system, but external and customized applications must be packaged separately by administrators. While this is a straightforward process for some applications, it can be quite complex for larger applications, especially those requiring interactive user input for configuration.

One solution that addresses these issues is to maintain an archive of system images required for every class that is run in the laboratory. A system image can be restored to a personal computer as needed, typically in under half an hour. Far more efficient than a scratch OS installation, the system image does not need to be configured or loaded with additional required applications: configuration files and programs are stored as part of the image itself.

Thus, if an operating system is crippled because of a deleted system file, the administrator can simply restore the computer with the image pertaining to a certain class. Software with conflicting library requirements or even different operating system flavors can be installed in different system images and restored as needed. Classes with pre-established software requirements no longer need to go through the whole installation process to set up their systems.

Additionally, system images can be built on one master machine and re-used on machines with the same or similar configurations. This is a significant time saver for system administrators, as they can now build the image once and deploy it to several machines simultaneously.

Several commercial system image utilities are on the market, Ghost and DriveImage being the most popular ones, and on the whole they don't cost too much. However, school system administrators on severe budget constraints can do away with the purchases altogether and achieve greater flexibility by using basic utilities that ship with almost all Linux distributions.

Typically, an operating system, along with its configuration files and all the installed applications, resides in an entire partition of a computer's hard disk. When the computer boots up, the bootloader points to this partition as the source of all the required programs for normal operation. So at the heart of it all, you need a utility to back up an entire hard-disk partition to a file and, conversely, to restore it from a file to a partition.

The dd utility suits this purpose. dd's documentation modestly claims that it copies and converts files. In reality, it is a powerful utility because Linux and other UNIXes treat everything as files. For example, if you wanted to write an image of the second partition of your first hard drive (/dev/hda2) to a file, you would issue the command

        dd if=/dev/hda2 of=myimage.img

A 2GB-sized partition would result correspondingly in a 2GB file, so you would need to make sure the directory you are copying the image to has sufficient capacity. Also, make sure the partition you are cloning is not mounted or being used for any other activity.

Restoring an image to a partition is as easy a process.

   
        dd if=myimage.img of=/dev/hda2

Because the image backup and restore utility can't run by itself, you need to run it off an operating system. The same operating system must have access to all the partitions you are modifying, as well as the area where the image files are located. Other required components are the bootloader and a file partition utility.

The way this would work in practice, then, is:

To illustrate these concepts in a practical example, let's consider a simple implementation on a single PC. The PC is part of a laboratory being used regularly for classes on Linux application development in DB2. The classes last for a week, after which the laboratory administrators must install a pristine set of both the operating system and the database.

The PC in this example has two IDE hard disks, the primary being 6.5GB in size and the secondary being 20GB. The primary is used for the operating systems and applications and the secondary one holds data.

This is the overview of what we are going to do.

The inordinate number of reboots is atypical for a Linux installation. It is necessary during the setup phase, however, as we are dealing with multiple OS images.

Phase I: Install the Master Operating System

For this example, Red Hat Linux 7.2 is the master operating system. Installation of the master OS follows the ordinary installation procedures. The only point that requires some special attention occurs during the Partition Setup of the installation.

The way we set up the partitions for our system is as follows: allocate a 100MB partition, /dev/hda1, as our /boot directory, and allocate a 384MB partition, /dev/hda2, as our swap file. The swap file can be used by the master operating system or the secondary operating system; there is no need to create separate swap files for each. Swap file size depends on the physical memory of your system. Allocate at least a 2.5GB partition, /dev/hda3, as the root (/) directory for the master OS. Allocate the remainder of the disk space for the secondary OS, which is another instance of Red Hat Linux 7.2. There is no need to define the free space as a Linux partition here; this can be done in the next step.

The default bootloader for Red Hat 7.2 is GRUB, and it should be installed on the master boot record (MBR) of /dev/hda, our primary hard disk. Use its default configuration.

The rest of the installation procedure should proceed normally. We can configure network settings, user accounts and X the same as with any ordinary Linux installation. The system should reboot at the end of the installation. You might want to go through this process to make sure the installation completed successfully and to configure additional settings on the system.

Phase 2: Install the Secondary Operating System

After we've installed the master operating system, we can install the secondary one. Again, the installation process should be typical of a regular Red Hat 7.2 setup, except in two areas: the partition setup and the bootloader setup.

Create a Linux partition from the remaining free disk space left over from our operation in Phase 1. Install the root (/) directory of the secondary operating system on this partition. We should not change in any way the other partitions created in the previous step. In this case, the root (/) partition of the secondary operating system is /dev/hda5.

We also should be careful in the bootloader setup. In the case of the secondary operating system, we do not install a bootloader. Instead, we use the master OS's bootloader to load the secondary OS.

Installation of the secondary operating system should proceed as normal, with the configuration of the network, required user accounts and other settings. At the end of the installation the system will reboot.

Phase 3: Modify the Bootloader of the Master Operating System

During the bootup phase, GRUB shows only the master operating system. This is normal, as we did not specify the secondary operating system to the bootloader. Proceed with the boot and log in to the master operating system.

Logging in as root and opening a terminal, we need to modify the configuration file for GRUB, which is /etc/grub.conf. The original GRUB configuration file reads:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/hda3
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Master (2.4.7-10)
        root (hd0,0)
        kernel /vmlinuz-2.4.7-10 ro root=/dev/hda3
        initrd /initrd-2.4.7-10.img

Now, add the lines to identify the secondary operating system.

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/hda3
#          initrd /initrd-version.img
#boot=/dev/hda
default=1
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Master (2.4.7-10)
        root (hd0,0)
        kernel /vmlinuz-2.4.7-10 ro root=/dev/hda3
        initrd /initrd-2.4.7-10.img
title Red Hat 7.2 Guest (2.4.7-10)
        root (hd0,4)
        kernel /boot/vmlinuz-2.4.7-10 ro root=/dev/hda5
        initrd /boot/initrd-2.4.7-10.img

The title of the secondary OS is arbitrary. In this case, we call it Red Hat Guest (2.4.7.10).

The root parameter should read (hd0, 4). This means the primary hard disk, called hd0 in GRUB terminology, and the fifth partition, because GRUB begins counting from 0, not 1.

The kernel parameter should read /boot/vmlinuz-2.4.7-10 ro root=/dev/hda5. This line identifies the location of the kernel that the secondary OS will be booting, that it is to be mounted as read-only and that the root partition is /dev/hda5. If you plan on using a different flavor of Linux, you will have to determine the names of these files. This is not a difficult step, because Linux distributions usually store them in the /boot directory anyway, and under similar names.

The initrd parameter specifies the location of the root image of the operating system. This is similar to the kernel parameter discussed above. Again, if you plan on using a different Linux distribution, you will have to determine for yourself what this file is named.

If we want our bootloader to default to the secondary operating system, we have to modify the default parameter to 1, which means the second option in our list.

After all this is done, save the file. There is no need to run a program to re-read this file; GRUB reads it automatically at boot time.

An additional note: if you know the layout of the Linux distribution you are going to use as the secondary one, you can perform this step immediately after Phase 1.

After we reboot the system, GRUB should show the master operating system and secondary operating system as selectable options. We should choose the secondary operating system and log into it.

At this point, we perform all the necessary set-up procedures for the image. Following the thread of our example, install DB2 for Linux and the prerequisite programs. After we are satisfied with the settings, we can reboot and proceed to phase 5, creating the image.

Reboot the machine and select the master operating system, and log in as root. Because we have to save the image of the file in our much larger data disk, we need to mount it. From a terminal window, enter:

mount /dev/hdb1 /mnt/data

(Here we assume that /dev/hdb1 has been partitioned and formatted properly as a Linux filesystem.) Then we create the image of the secondary operating system. Again, from a terminal window type:

dd if=/dev/hda5 of=/mnt/data/myimage.img

Depending on the speed of the hard disk and the size of the partition being cloned, this process can take anywhere from 15 to 30 minutes.

How do we restore the image of the secondary operating system to the partition? Let's say we're done with our experimentation on the OS and its installed applications, and we want it restored to a pristine state. Here is what we would do:

Restoration should take about as long to complete as it took to create the image. After this step, reboot the machine and choose the secondary operating system from GRUB. Make sure you are restoring the image to the same partition you originally created it from or, alternatively, to a partition the same size as the original. Remember, it is possible to transfer this image to a similarly configured machine.

Now that we have a fully configured system, with a master operating system to manage the secondary operating system and its images, how does this make life easier for laboratory system administrators?

Following the scenario above, imagine it's a Friday afternoon and the DB2 for Linux class has just wrapped up. Instructor and students have gone home, and two hapless laboratory administrators are left behind to prepare 30 PCs for class the following week. If they were to reinstall the operating system and applications on each system, it would probably take them at least four hours--assuming a touch time of fifteen minutes per PC--even if they did several PCs simultaneously. On top of that, they might configure some parameters incorrectly through typographical errors during manual setup.

However, using the scheme described above, the lab can be set up in two hours by a single administrator. He would boot each machine to its master operating system, execute a script to recreate the secondary operating system and automatically shut down the PC and leave for the day. Recreating the secondary operating system on each PC would take approximately half an hour at most, with no manual intervention after the process has been initiated.

The scheme would be of greater value if, as is usually the case in many training centers, the school offers several different types of classes, each one requiring its own unique configuration. Preparing the computers manually requires that the system administrator be conversant with the installation for each type of software the school uses. Alternatively, the school would need several administrators with specialized skills in each of the software they teach. Using the method of system images, a system administrator can recreate an image without a working knowledge of the application itself.

The scheme described above has a master operating system installed on the same hard disk as is the secondary operating systems. Because students have root access to the secondary operating system, there's still room for mischief, for example, a student could delete the master partition.

To work around this, we could create a single-diskette Linux system that contains the bare utilities in lieu of the master operating system. Instead of selecting a master or secondary OS from a bootloader, the administrator simply boots from the floppy and initiates reconstruction of the system image from a storage area. One such mini-distribution that could be used for this purpose is Tom's Rootboot (see Resources).

A temptation that might arise from this approach is to use dd to recreate the entire hard disk instead of restoring only a partition on the hard disk. While this is possible now with the boot floppy, it's not necessarily a good idea because reconstituting the entire hard disk is a much longer process.

Leaving the system image on each local hard drive is efficient, because it's always available for retrieval. On the downside, it takes up space on the hard drive and is susceptible to deletion. It then would be advisable to keep backups of the system images on a network filesystem, accessible from either the master OS or the boot floppy by using NFS, CIFS or FTP.

Paranoid system administrators who fear that more savvy students will modify images maintained on local hard disks would do well to create checksums for these images. The checksums can be mounted on read-only network filesystems. The master operating system or admin floppy can read these checksums to verify the integrity of the images.

Another method would be to compress the image, create a installation utility and burn it to a bootable CD. This is feasible if the entire image fits in the limited space alloted by a 700MB CD-R. Alternatively, it could be done using a bootable DVD, but this is impractical at the moment.

Now, to the auxiliary components: PCs in a school laboratory typically need to have their network configured. This can be done easily by setting up the DHCP client on the images and having a DHCP server on the live network. Also, as students may need to log in using their personal accounts, the images can be set up for LDAP or NIS authentication.

If you would like to use a prepackaged set of tools that automates parts of these processes, take a look at SystemImager. SystemImager has created scripts and interfaces to further ease the deployment of preconfigured images to multiple machines.

Tom's Rootboot

Kickstart documentation can be found at:

www.redhat.com/

en.tldp.org/HOWTO/KickStart-HOWTO.html

256.com/gray/docs/rh_boot/

linux.web.cern.ch/linux/aims/aims-doc.html

For more information on Linux in use in schools, check out k12linux.org.