System Configurator
From SystemImager
SystemConfigurator
SystemConfigurator is a configuration engine for Linux, designed to provide an single API for configuring network, bootloaders, and hardware setup. This is enough to get a machine back on the network after it has been installed by SystemImager.
Design Theory
SystemConfigurator is based on a design made by Sean Dague back in 2001 called footprinting. The basic concept is very similar to how autoconf works when building code, i.e. look for a feature, if that feature exists, use it.
SystemConfigurator is divided into major stages, each one largely represented by a controller module that governs that stage. The stages are as follows (listed in execution order):
| Stage | Controller | SC Flag | Comments |
|---|---|---|---|
| Hardware | Hardware.pm | -confighw | Modifies kernel modules config files |
| Network | Network.pm | -confignet | Sets up control files needed for networking to start |
| Initrd | Initrd.pm | -configrd | Runs appropriate mkinitrd executable to regenerate initrd. This is required if you move images between machines that don't have the same scsi controller. |
| Boot Loader Config | Boot.pm | -configboot | Sets up boot loader config files |
| Boot Loader Install | Boot.pm | -runboot | Installs a boot loader |
| Keyboard | Keyboard.pm | -configkeyboard | Fixes keyboard setup |
| Time Zone | Time.pm | -configtz | Can set timezone if specified. |
| User Exit | UserExit.pm | -configuserexit | Runs a specified set of userexits in order. Predates post-install scripts in SystemImager. |
Every module within a control group implements at least 1 footprint subroutine (boot loaders are special, and need 2). And the basic flow of any control group is as follows:
# Controller
foreach $module (@modulelist) {
if($module->footprint()) {
$module->setup();
}
}
What is a footprint? Let's take an easy instance, using lilo to install your boot loader. When should lilo be a valid option? If lilo.conf exists, that is a very good indication that the user wants to use lilo, so do it. See, simple. :-)
For most control groups this means it will run 0..N modules, configuring everything that it finds. While this may be more than it needs to do, and may be a bit sloppy, it does mean that SystemConfigurator as a whole ages pretty well. For instance, even though distros have changed their network script format over the last 2 years, SC still works fine with no changes in that area of code.
The exceptions to this rule are Initrd generation and Boot Loader install, as doing this more than once would be harmful (they would clobber each other anyway). In these cases the first one that matches, and is executed successfully, causes the loop to exit. The order that the modules is run has been tuned to produce the most correct scenarios.
