Installation of SystemImager

SystemImager Install

Background

The Physics Department has Computer Labs in Weniger 412 and 497. These machines have Linux installed on them. To make administration easier, the support staff looked for a solution, similar to Symantec Ghost for Windows, to use with Linux machines. After some searching, the SystemImager Package was decided upon.

It is possible to clone machines in any operating system environment by using a Linux Rescue disk and the command dd.
# dd if=/dev/sda of=/dev/sdb (Assumes you want the first drive copied to the second drive. If drives are IDE, use hda and hdb instead)
But for this to work, the drives must be the same size, although copying from smaller drive to a larger should work, but the extra space is wasted.

This approach was used initially for the original lab setup, but is time consuming, and requires opening up each machine and placing hard drives in different machines.

I was looking for something that would do this over the network, and also would allow for incremental updates.

This document describes the installation and configuration of SystemImager in the labs. There is also a section on problems that occurred during installation. Note that this document was created from memory, some time after the actual installation.

Installation:

The files were downloaded from sourceforge. Version 3.7.3 was used. This is actually an unstable version, but due to problems encountered with the boot process with an older version, this actually seemed to work better. See the Problems section at the end of this document for explanation.

The following packages were installed on the server via the standard rpm method:

client
common
flamethrower (not used, see Problems)
server
x86_64boot-standard
x86_64initrd-template

The same packages were installed on a sample client. This client had been installed with all software that was requested for a lab machine. Basically, this machine was ready to be cloned to all other machines.

Configuration:

fstab

I basically just followed their guide for doing the setup, although this manual was for version 3.4.1, most of the steps are the same.

There really wasn't much special configuration needed to do to do a basic setup. The main step on the client is to do
# si_prepareclient --server physics-server.physics.oregonstate.edu

This starts an rsync process on the client so that the server can download all of the files from the client.

Then start the si_getimage program on the server to pull the image to the server.
# si_getimage --golden-client wngr497-pc04.physics.oregonstate.edu --image 11_10_2006
replacing wngr497-pc04.physics.oregonstate.edu with the name or IP of the client, and 11_10_2006 with whatever name you want to call the image. Follow the instructions in the script.
This will start downloading all of the files on the client to /var/lib/systemimager/images on the server. Note that there wasn't much space for these images in that partition, so I made the images directory a symlink to /space/systemimager_images, which is a 235 GB partition, plenty of room for a few ~15 GB images.
Note that it is a good idea to keep images a couple of versions back in case something is wrong with an image.

Also, you can change any files directly to the image by changing those files. The root directory is the image name under the images folder.

Now, the difficult part was getting this image on the other machines with a bootable CD. The 3.7.3 version made this easier, I was unable to get this to work with 3.6.3 (see Problems below).
The basic thing to do is to issue the command:
# si_mkautoinstallcd --out-file boot.iso (Or whatever you want to call the ISO CD image)
Then burn the CD using your favorite CD writing program such as k3b.

The install CD will not now where to get your image from, unless your DHCP server is your image server. If that is the case, follow the instructions in the manual from systemimager.org for telling your client machine where to go. If you have the case that we did where the DHCP server is not controlled by us, and so we could not add the necessary instructions to the DHCP command, you will need to alter the CD, or use an additional floppy disk to give it the proper information. I could nto figure out how to edit the CD to do this, so I had to use a floppy disk. In the future on a machine without floppy drives, this would be impossible, and another solution would have to be found. One idea would be to do the initial installs in a private environment where the DHCP server can be controlled, then place the machines in the public area. This was the major problem I had. The floppy disk method would not work with the older version, see below for details.

The floppy disk must have a file named local.cfg with at least the following lines:
IMAGESERVER=physics-server.physics.oregonstate.edu (replace with your image server)
IMAGENAME=11_10_2006 (again, replace with your image name)

Once the CD is made, simply boot the client machine with the boot CD you made. If you have to use an additional floppy, place the floppy in the drive while the machine is booting, after the message that is in color is gone. After some time (for me, it took 40-70 minutes per machine on a 100MB network. Doing 3 at a time took about an hour), the machine will show a message saying:
"I have been done for xx minutes now! Reboot me already!!!

Once rebooted, the machine should be identical to the golden-client, except whatever info is given to it by the DHCP server.

Do all the machines you wish to do.

Updating a machine:

One of the nicest features of the systemimager program is that you can do incremental changes to your clients without having to start the above process over. Follow the above steps for getting the image on to the server. Now, all you need to do is to "push" the update to the clients. This is done with the following command:
# si_pushupdate --image 11_10_2006 --concurrent-processes 3 --updateclient-options "--no-bootloader --reboot" --client wngr497-pc --range 01-03 --domain \ physics.oregonstate.edu --server physics-server.physics.oregonstate.edu --ssh-user root

An explanation of each option:
si_pushupdate (the program that does the updating)
--image (pretty self-explanatory)
--concurrent-processes (the server can push out to as many clients as you want. I usually limit this to 10 or less, but it definitely does speed things up)
--updateclient-options (everything following this in quotes will be passed directly to the clients command of si_updateclient, see here for a list)
--client (you can either do one at a time, or do several by using a basename and the range and domain options)
--range (use with client and domain to do multiple machines)
--domain (this will make the machines wngr497-pc01.physics.oregonstate.edu - wngr497-pc03.physics.oregonstate.edu update)
--server (image server)
--ssh-user (do the updates over ssh with the following user, user must have full access to files on client)

For --ssh-user to work without having to enter passwords, I have enabled ssh-keys so that no passwords are needed. See here for details.

There is a file on the clients that lets you exclude certain files from being updated. This file is image/etc/systemimager/updateclient.local.exclude. Here is what I added to the end of this file for our machines:
-------------------
# Added by Justin Elser 10/2/2006
# files that should not be included in image

# kconf_updaterc is needed or else kde takes forever
/local/kconf_updaterc
# otherwise NIC comes up as eth1 which breaks maple
/etc/udev/rules.d/30-net_persistent_names.rules
# default printer is already set
/etc/cups/printers.conf
/etc/cups/printcap
# don't need to change var/tmp
/var/tmp
-------------------

This machine must be on the client to be effective, meaning that if you put it in the image, it won't take affect until after you update the image, not before.

Problems encountered:

The first and major problem encountered was trying to make the bootable CD work. Since I didn't have access to the DHCP server, I had to either modify the CD or create a boot floppy. For some reason, whenever I tried to use a floppy with 3.6.3, the kernel would complain about the floppy drive not working, when I knew the drive was working fine. It turns out that 3.7.3 has this system called UYOK, or Use Your Own Kernel. The kernel that was being used did not work with the floppy drive in the Dell Optiplex GX620, complaining that it was a SCSI drive or something. When I switched to a version with UYOK, the floppy worked just fine.

I did spend quite some time trying to get the proper information on the CD instead of the floppy, but had no luck with this. I forgot most of the stuff I tried, but know that it involved uncompressing the kernel image on the CD, modifying it, and recompressing the kernel. Never got it to work.

I also attempted to use Flamethrower to do multicast installs, thinking that this would save on time. However, I could never get the clients to connect to the server properly. In the end, it would have taken less time if I had never tried this. There is however, an option in new versions to use bittorrent to do the file transfer. This would probably be faster, but I was worried that our campus watches for bittorrent traffic.

Navigation

Support