Tags:
create new tag
view all tags

Using the baseinstall system

As part of the development work for SL7 a new baseinstall system was added to the LCFG installer. This new system adds support for running scripts and calling LCFG component methods in a similar way to the existing support for "install methods". The crucial difference is that the baseinstall phase is run after the installation of the initial set of packages (but before the first reboot) and the methods are run after calling chroot to enter the newly created install root directory.

The use of baseinstall methods has a number of benefits over the standard install methods:

Running site-specific scripts

Informatics has various site-specific scripts which must be run as part of the install process prior to the first time the machine goes into active service. For example, typically the SSH host keys are retained even over reinstalls so that users are not unnecessarily prompted to accept new keys. Consequently it is necessary to run a local script to restore the SSH host keys from a wallet repository. This process has to occur before the first time the SSH daemon is started or that will generate new keys which are (intentionally) not overwritten by the script. Prior to SL7 this was quite simple as the SSH daemon was managed directly by the LCFG component but it is now managed by systemd.

It might have been possible to move all that to the existing LCFG installer but then it would be necessary to add lots of local scripts and packages to the installer ISO image (usually referred to as the installroot). This is not easy to manage and requires all sites to carry lots of software which they probably do not need. It is also rather inflexible, if a site needs to add new scripts to the install process then the install ISOs must be rebuilt and the PXE installer updated.

A better alternative solution is to use the software which has just been installed onto the machine in the first phase (referred to as the installbase). The list of packages for the installbase comes from an LCFG profile (e.g. lcfginstallbase-sl71-stable) and, although there is a default profile, each site typically has their own (e.g. diceinstallbase-sl71-stable). This is a much more dynamic and flexible approach, any site can add any local packages they need to their local installbase profiles and change them whenever necessary.

Avoids the need to run interactive scripts at boot time

One of the problems often encountered with systemd is the handling of interaction with the user on the console. For example, Informatics have always had the LCFG kerberos component run the kdcregister tool after the final reboot of the install process. This kdcregister tool requires the user to authenticate with their admin principle and then uses that to add the hostclient key for the machine into a keytab file. Although possible when booting with systemd the problem comes from having lots of services starting simultaneously and all writing to the console, it becomes very difficult to spot that an interactive prompt is waiting for user input! The solution was to move this registration step from after the final reboot to before the end of the initial install phase.

Avoids the need for scripts to handle an alternative root directory

Using the baseinstall system means that code does not need to be modified to deal with an alternative root. Previously many LCFG components have had to have an extra install method which deals with the new config files being stored in the /root directory. With the baseinstall system a standard LCFG component configure method can be called without modifications.

Using a baseinstall method

The baseinstall methods are used in a very similar way to the install methods, for example:

!baseinstall.installmethods     mADD(kdcr)
baseinstall.imethod_kdcr        %oneshot% /usr/bin/kdcregister_wrapper -f -a -r <%kerberos.realm%> -s kdc.inf.ed.ac.uk hostclient/$(hostname)

As with the install component, the %oneshot% indicates a script is to be called and otherwise it is assumed to be an LCFG component which should be passed to om.

The calling environment is sanitised (e.g. setting the PATH variable and tweaking the tty settings). Note that commands are called in a full shell so that it is possible to use all the features you might need.

-- Main.squinney - 2015-11-18

Topic revision: r2 - 2016-01-22 - squinney
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback