School Laboratory Management Blues

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:

• Essential system programs might be inadvertently or
  maliciously deleted, thus bringing down an application or the
  operating system itself; or
• Installation of new applications might necessitate
  a change in some system libraries, thereby creating conflict with
  existing applications; or
• Classes that require scratch installations of an
  operating system may disrupt subsequent classes dealing with
  databases or web servers.

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.A Proposed SolutionOne 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.General Implementation StrategyTypically, 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:

1. Boot from the master operating system.
2. Use dd to restore a saved image to a preset
   partition.
3. Reboot the system and use the bootloader to select
   the partition from which the machine should boot.

A Sample Implementation: OverviewTo 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.

1. Install the master operating system, creating a
   partition for the master OS itself and a partition for swap space
   but leaving enough space for the secondary OS. This will be a
   standard installation of a Linux distribution.
2. Reboot the machine and install the secondary OS,
   creating a partition in the remaining space on the primary disk.
   Two differences are: i) we can reuse the swap space that we created
   in step 1; and ii) we do not install the bootloader for this
   secondary OS because we will use the bootloader from step 1.
3. Reboot the machine and switch back to the master
   OS. Modify the bootloader configuration file to recognize the
   secondary OS.
4. Reboot the machine and switch to the secondary OS.
   Install all the applications that will be used for laboratory work
   on the secondary OS and configure them as necessary.
5. Finally, reboot the machine and switch back to the
   master OS. Create an image of the secondary OS.

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 SystemFor 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 SystemAfter 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
SystemDuring 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.Phase 4: Final Configuration of the Secondary
Operating SystemAfter 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.Phase 5: Create the Image of the Secondary
Operating SystemReboot 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.Restoring an ImageHow 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:

1. Boot the machine to the master operating
   system.
2. Log in as root, open a terminal and mount the data
   disk with mount /dev/hdb1 /mnt/data.
3. Restore the image with dd
   if=/mnt/data/myimage.img of=/dev/hda5

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.During Normal OperationNow 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.Variations, Enhancements and CaveatsThe 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.ResourcesIf 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
RootbootKickstart documentation can be found at:www.redhat.com/en.tldp.org/HOWTO/KickStart-HOWTO.html256.com/gray/docs/rh_boot/linux.web.cern.ch/linux/aims/aims-doc.htmlFor more information on Linux in use in schools, check out
k12linux.org.