-
Notifications
You must be signed in to change notification settings - Fork 26
Developper_Guidelines
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.
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.
SystemImager releases use an "A.B.C.D" numbering scheme similar to that used by the Linux kernel.
VERSION.MAJOR.MINOR[.EXTRAVERSION]