SystemImager began as a series of utilities written as shell scripts. Minimal system requirements were considered a top priority. As SystemImager matured, and the utilities became internally more complex, it became clear that shell scripts were falling short of the need. Perl was chosen to pick up the yoke and has allowed for cleaner, more advanced code. It was determined that Perl is installed as part of most "base" Linux installs and therefore was a reasonable choice from a minimal requirements perspective.
The architecture was designed to be open to future modification at every level. The protocol used for transferring files during installs and updates is currently rsync(1). But the modular code will easily allow for drop-in replacements as is appropriate. All unicast file transfer mechanisms are implemented in a "pull" fashion, which is generally considered to be superior to a "push". Using a "pull" mechanism, it is much easier to monitor the state of the receiving system prior to and during the file transfers. In the future, multicast may be an option and may need to be implemented as a push.
There are other methods available for doing automatic installs, such as RedHat's KickStart which installs systems based on a list of pre-defined packages. But package based installs are very limiting in that they generally don't have an automated way for dealing with non-packaged files. If you re-compile your kernel, add a piece of non-packaged software, or modify certain configuration files, you are usually required to do some sort of scripting or programming to deal with these "special cases".
In order keep imaging simple, SystemImager uses images that are based on a working installed system. We call this system a "golden client". Just get one of your machines working exactly the way you want and pull it's image to the imageserver with the "getimage" command. You can re-compile your kernel, install custom software, and do any configuration file tweaking you like. SystemImager will get it all.
Now that you have your golden client configured, we need to run the "prepareclient" command. prepareclient will collect the partition information from your disks and put it in the /etc/systemimager/partitionschemes directory. A file will be created in this directory for each of your disks and will contain that disk's partition information. prepareclient will also create an rsync(1) configuration file (/tmp/rsyncd.conf) and start rsync in server mode (rsync --daemon). This allows the image server to pull the image from the client, but will not cause the rsync daemon to be restarted after the golden client is rebooted. This helps avoid security concerns of sharing a golden client's root filesystem via rsync.
On the imageserver we now run the getimage command. Here's an example:
"getimage -golden-client 192.168.1.1 -image my_webserver_image_v1"
getimage contacts the golden client and requests it's /etc/systemimager/mounted_filesystems file. This file contains the list of mounted filesystems and the devices on which they are mounted. It pulls out the mount points for the filesystems that are unsupported and creates an exclusion list. Currently supported filesystems are ext2, ext3, and reiserfs. Unsupported filesystems are everything else including things like proc, devpts, iso9660, etc. getimage then pulls the golden client's entire system image, excluding the filesystems in the exclusion list. The files are pulled by connecting to the rsync daemon running on the golden client. All the files from the client will be copied over, recreating the file and directory hierarchy in the image directory.
getimage can also be used to update an existing image. By simply specifying an existing image name, you are asking getimage to update that image to match the files on your golden client. In this case, only the parts of files that are different will be copied over. Files that exist in the old image but not on the golden client will be deleted, and files that exist in both places but have changed will be updated. This is one way to keep an image updated when new security patches or other system updates come out. However, the recommended method is to never overwrite a known working image, so that you have a form a revision control. This is not true revision control, where individual file revisions are tracked on a line by line basis. It is revision control on an image by image basis. This form of revision control also ties in to the updateclient command which will be discussed later. By default, all images are stored in the parent directory of "/var/lib/systemimager/images/" in a directory that bears the image name. For example: "/var/lib/systemimager/images/my_webserver_image_v1/".
After getimage has pulled the files to the image directory on the imageserver it creates a customized autoinstall script. The autoinstall script in our example would be named "my_webserver_image_v1.master". All autoinstall scripts are placed in the "/var/lib/systemimager/scripts" directory. The disk partitioning information left behind by the prepareclient command is used to add the necessary commands to re-partition the disk(s) on the autoinstall clients. File system information is taken from the /etc/fstab file in the image (Ie.: "/var/spool/systemimager/images/my_webserver_image_v1/etc/fstab") and is used to determine the appropriate file system creation commands and to determine mount points for the autoinstall process. Based on command line options passed to getimage or questions it has asked, certain networking information is added to the autoinstall script. This information is added in variable form as the autoinstall client will determine the values for things such as it's hostname and IP address during the autoinstall process.
After running getimage, you will run the addclients command. addclients will ask you for the series of hostnames that you will be installing by combining a base host name and a number range. For example, if your base host name is "www", and your number range is from "1" to "3", then the resultant host names would be "www1, www2, www3". It will then prompt you to choose the image that will be installed to these hosts and will create soft links for each hostname that point to the master autoinstall script for that image. For example: "www3.sh -> web_server_image_v1.master". If the image is updated and you choose to allow getimage to also update the master autoinstall script, then each of the associated soft links therefore point to the updated autoinstall script. If individual host configuration is necessary, the soft link for that host can be removed and replaced with a copy of the master autoinstall script that can then be customized for that host. This customization is a manual process and is up to the system administrator.
addclients will then prompt you for the IP address infornnmation for these hosts and will re-write the imageserver's /etc/hosts file accordingly, then copy this file to /var/lib/systemimager/scripts/hosts. The latter file is used during the autoinstall process for clients using DHCP to determine their host names.
The unattended install portion is flexible and can work with most any hardware available. It is also easily modified to work with new or special hardware. A miniature Linux distribution (Brian's Own Embedded Linux) is used for autoinstalls. It consists of a customized kernel and an initial ram disk which contains only the specific commands and utilities necessary to perform autoinstalls. The same kernel and initial ram disk (initrd.gz) can be used to boot from floppy disks, CDROMs, the network, or any running Linux system's local hard drive. The commands "mkautoinstalldiskette" and "mkautoinstallcd" make use of the syslinux(2) utility to create floppies and CDROMs that will boot the SystemImager kernel and initial ram disk. pxelinux(2), which is a sister tool to syslinux, allows the same kernel and initial ram disk to boot PXE capable machines from the network. A configuration file is needed by syslinux and by pxelinux, but the two tools are able to use the same configuration file and SystemImager handles this for you.
The autoinstall kernel is compiled to contain all the necessary drivers for the majority of systems. Custom kernels can be compiled to meet special disk and network driver requirements. To use a custom kernel, simply copy it to /usr/share/systemimager/i386-boot/kernel. All of the autoinstall media is created from /usr/share/systemimager/i386-boot/kernel and /usr/share/systemimager/i386-boot/initrd.gz on the image server.
Once the kernel has booted, it mounts the initial ram disk as it's root filesystem. It then executes an initialization script on the ram disk that has been written to do SystemImager specific things. This script will use either a configuration file (/local.cfg), DNS, or a combination of DHCP and the /var/lib/systemimager/scripts/hosts file pulled from the image server to determine the autoinstall client's IP address and hostname information. If DHCP is used, the client parses the hosts file retrieved from the image server to find it's IP address and can therefore determine it's hostname. Finally it retrieves an autoinstall script from the image server based on it's hostname and executes it. The autoinstall script is image specific. This is how a client determines which image it will receive. Here is a summary: IP address -> hostname -> image specific autoinstall script named with hostname.
The most common way to assign IP addresses to autoinstall clients is DHCP. To easify the configuration of the DHCP configuration file (/etc/dhcpd.conf), SystemImager includes a utility called mkdhcpserver. This utility asks you for all the information it needs to create a DHCP configuration file that is appropriate for your installation of SystemImager. It is also possible to use DHCP to assign static IP addresses to your clients on an ongoing basis after installation. If you choose to do so, simply run the mkdhcpstatic command after all of your clients have had a chance to boot and be assigned an IP address. It will modify your /etc/dhcpd.conf file on the imageserver to include static entries for each of your hosts.
Alternately, hostname, imageserver, and networking information can be put in a configuration file on a floppy diskette. Or if you are using a running system's hard drive as the boot media, you can run "updateclient -autoinstall -server <imageserver> -config eth0" which will create a local.cfg file at the root of the client's hard drive containing the existing live network settings.
When the autoinstall client boots, it will look for this file and use the provided values instead of getting them from DHCP and the /var/lib/systemimager/scripts/hosts file on the image server. A local.cfg file on a floppy will work with any of the autoinstall media. The configuration file can even be put on the autoinstall floppy itself! If you use a local.cfg file on a hard drive and on a floppy, the settings on the floppy will override the settings on the hard drive.
The format of this configuration file is simply VARIABLE=value for all the appropriate settings. The name of this file must be local.cfg and it must exist on the root of the floppy or hard drive. The floppy can be formatted with either ext2 or fat. An example local.cfg file can be found with the documentation files which are usually installed in /usr/share/doc.
Sometimes you will want to update an image on your image server. There are a couple of ways to do this. The first way is to directly edit the files in the image directory. The best way to do this is to chroot into the image directory. Once you have done the chroot, you can work with the image as if it were a running machine. You can even install packages with apt-get or RPM, for example. The second way is to run the getimage command again, specifying a golden client that has been modified in the desired way. Again, only the parts of the files that have changed will be pulled across. Files that have been deleted on the golden client will also be deleted in the image. You are also given the option to update the master autoinstall script for the image or to leave it alone. The advantages of this method are that you can verify that your new configuration works on the golden client, and that the master autoinstall script is updated.
Once a system has been autoinstalled, the updateclient command can be used to update a client system to match a new or updated image on the image server. Let's say that you've installed your company's 300 web servers and a security patch comes out the next day. You simply update the image on the image server and run updateclient on each of your web servers. Only the modified files are pulled over, so it takes very little time, and your entire site is patched! It is recommended that you create an entirely new image with a new version number so that you have some form of revision control. This way, if you find out that the patch you applied hosed up your entire web farm, you simply do an updateclient back to the last known working image!
By incorporating some modifications sent in by A.L. Lambert of epicRealm, using the "updateclient" command with the -autoinstall option will copy the autoinstall kernel and initial ram disk to the local hard drive of an autoinstall client that is currently running, but needs to be re-deployed. It will then modify the /etc/lilo.conf file to include an appropriate entry for the new kernel and initial ram disk and will make this new kernel the default. The next time the client system is booted, it will load the SystemImager kernel and initial ram disk, which will begin the autoinstall process! This means that you can remotely re-deploy any running Linux machine without having to have someone feed the machine a floppy or CD and without having to reconfigure the BIOS to boot off the network (which can be quite squirrelly with some BIOSes).