Developper_Guidelines

Developing SystemImager

Design Goals

The design goal for SystemImager was to create a tool that was both easy and fast to use, allowing system administrators to perform incremental upgrades that minimized system disruptions and provided software independent of any packaging system. The specific requirements follow:

• Images should be pulled from a working system.
• Unattended installs are a must.
• The unattended install system has to be able to repartition the destination drive(s).
• System administrators who don't completely understand the tool should be able to use it.
• The install should be easy and quick so that it can be useful immediately without a lot of site-specific customization.
• Images should be stored as normal files to allow for incremental upgrades, as opposed to "dd" style block level images of physical disks.
• The SystemImager software should be independent of any and all packaging systems (such as RPM) in order to easily accommodate different distributions.
• SystemImager should be able to store multiple images for different types of systems and for revision control.
• A mechanism should be available to let unattended install clients know which image to install.
• SystemImager should have a command line interface that can easily be wrapped with a GUI.

Development of SystemImager Architecture

Minimal system requirements were a top priority for SystemImager, which began as a series of utilities written as shell scripts. However, shell scripts were inadequate as SystemImager matured and its utilities became more complex. Perl, part of most Linux installs and possessing minimal system requirements, then replaced shell scripts. Using Perl, developers have been able to generate cleaner, more advanced code.

SystemImager architecture was designed to be open to modification at every level. The protocol for transferring files during installs and updates is currently rsync(1), but the modular code easily allows drop-in replacements as is appropriate. All unicast file transfer mechanisms, including rsync(1) are implemented in a "pull" fashion, which is generally considered to be superior to a "push," because it is much easier to monitor the state of the receiving system prior to and during the file transfers.