Author: Paul Virijevich
SystemImager has many advantages over traditional imaging methods. It uses rsync to store the image remotely, and can do a backup or full install in just three to five minutes. Images are complete copies of a filesystem, and their files can be edited. Images on a server can be updated when a change is made to a client, and only the changes need be copied over to the image. You can also make changes to the image on the server and push it out to clients; once again, only the changes are copied. SystemImager also supports auto-installation; clients can receive an image based on their MAC addresses.
One potential disadvantage of SystemImager compared to commercial products is that no commercial support is available. This might not matter to you, but if your organization insists on it, you’re out of luck.
SystemImager installation is time-consuming but simple. Download and extract the code, then run make all in the newly created directory. This downloads a whole bunch of stuff. It seems like SystemImager needs its own version of just about everything out there. Expect to use about 650MB of disk space for everything that SystemImager will download, but you can delete this all as soon as you are done with building the application.
Once everything finishes, issue the following commands to set up your SystemImager server:
make install_server_allmake install_boel_binaries_tarballmake install_initrd
For machines you want to back up, instead of doing all this downloading and compiling, just create an archive of the systemimager-3.6.3 directory with tar (tar -cvf sysimager.tar systemimager-3.6.3) and copy it over to the clients. Extract the archive (tar -xvf sysimager.tar) and run make install_client_all from the source directory.
One of the great things about SystemImager is that it is distribution-neutral. You can run a Debian server to dish out images made from Fedora, openSUSE, SLES, RHEL, or just about any other distribution.
When it comes to hardware, things get a little bit trickier. With a little extra work, you can use the same image for IDE, SATA, and SCSI drives — but an image taken from an IDE machine won’t work unmodified on a SCSI system. However, you could write a script to go through the image directory and change any references of hda to sda. Better yet, you could specify such a change in a post-install script that would run after you load the image on a client. See /var/lib/systemimager/scripts/post-install/README for more information. For simplicity’s sake, however, if you have enough disk space on the server, you will probably just want to create separate images.
Creating an image
Now it’s time to start creating images. For an example, say you name your image server master and your client bob. On bob, run the command si_prepareclient --server master. SystemImager warns you that it is about to store some information about your client in /etc/systemimager and configure your system to run rsync. Answer yes at this prompt, and yes again when it asks to start rsync as a daemon. After a few moments, your client is ready to have its image retrieved by the server.
Now log on to master and tell it to retrieve the image with si_getimage --golden-client bob --image bob-image. You will see a security warning about rsync. If you are on a trusted LAN, it is safe to continue. The imaging process should take from three to five minutes but will depend on the size of the image, the speed of your hard disks, and network throughput.
After the image is retrieved, SystemImager will prompt with some questions about how you want to handle IP addressing for the client when its image is restored. You can choose DHCP, static, or replicant. If your SystemImager server is also a DHCP server, you can tell it what IP address to give to any client requesting this image. By default, SystemImager will assign this image a random IP address just like any other DHCP client. However, you can use the si_mkdhcpstatic command to make the IP address it gets the first time the image’s static IP every time it is installed. Static assigns the IP address the client has as it pulls the image from the server. Replicant never alters the IP address of the image, which is useful for backing up servers that need the same IP address when restored.
If you are running a DHCP server alongside SystemImager, you now have the option of choosing the IP address range for the clients with the si_addclients command. You can also specify what images clients should get based on their IP address. If you are not using DHCP, answer no and move on.
Your image is now in the server in the directory /var/lib/systemimager/images/bob. If you browse through the directory, you will notice that it has the exact same filesystem layout as the original.
Now that you have an image on the server, you can restore a client or roll out the image to new clients by using the command si_mkautoinstallcd --out-file image.iso on the server. This creates an ISO image you can burn to a CD.
If you are using SystemImager with DHCP, just pop the restore CD into a computer and watch SystemImager deploy the image based on the IP address of the client — no interaction needed. If you want to install an image and are not deploying based on IP addresses, you can specify parameters at the boot prompt. For example, using kernel IMAGESERVER=192.168.0.1 IMAGENAME=bob at the boot CD prompt will deploy the image bob from the server at 192.168.0.1 to the client machine. This is useful when you want to deploy the same image over and over again, regardless of whether you are running a DHCP server in conjunction with SystemImager.
You may be wondering if you can use SystemImager over the public Internet using SSH. Supposedly you can, but the documentation on setting this up is pretty much non-existent, as the docs aren’t very helpful. I did eventually stumble upon using ssh-user= as an option with si_getimage and si_updateclient. Doing so prompts for the password of the user you specify, but whether rsync is now tunneling through SSH is not apparent. I failed to find this feature anywhere in the documentation. It does show up if you do a si_getimage --help. Don’t let this worry you too much, as you’ll probably want to use SystemImager on a local network anyway.
If you don’t want to drag a CD around to every client, install the SystemImager client software on the client to be imaged. Then use si_updateclient --server master --image bob to install the image bob. There is one constraint. This method does not change the partitions on the existing client. It does not alter/etc/fstab, but it does update the bootloader configuration. If the new image has a different root partition (say sda2 instead of sda3), you will need to edit the new bootloader configuration and put back in sda3 as the root partition. Basically, you are getting the contents of the filesystems and their layout on your existing partitions. This may sound a little scary, but go ahead and try it. It actually works quite well.
Updating images and clients
The ability to update images or clients takes SystemImager beyond ordinary imaging software. Say you make changes on a client and want the image on the server to match the changes. All you have to do is run the si_prepareclient and si_getimage sequence again. SystemImager updates only the changes made on the client. The update will include altered files and new files on the host, and remove deleted files from the image.
The si_updateclient command lets you move in the opposite direction. If you have hundreds of machines with the same image, just update the master image and pull only the changes from the master image to the destinations. This could be useful for updating all servers after a security patch comes out. It is also simpler and cheaper than running a satellite update server as some “enterprise” Linux distributions suggest.
SystemImager does have some downsides. The binary packages for installing the software on RPM and Debian-based systems are out of date, so you must endure the long install process of the source code package. I also had to install some extra Perl modules, namely XML::Simple and AppConfig. This was not obvious until I tried to run a SystemImager command the first time. You would hope that this information would be in the documentation, yet that also seems out of date.
Don’t let these shortcomings get in your way. From a technology standpoint, SystemImager is hard to beat. You get the functionality of both an image and an update server in one package. Let’s also not forget the other thing it has going for it — speed. Once you get SystemImager up and running, you’ll wonder how you were ever able to live without it.
