One of the problems we’ve encountered with systemd is the handling of interaction with the user on the console. In particular, we have always had the kerberos component run the kdcregister tool after the final reboot of the install process. This kdcregister tool asks the user to authenticate with their admin principle and then uses that to add the hostclient for the machine into the keytab. Although possible when booting with systemd the problem comes from having lots of components 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.
Similarly we want to keep using the same SSH host keys even after a reinstall. Consequently we needed to run our local script to restore the SSH host keys from our wallet repository. This has to happen before the first time the ssh daemon is started or it will generate new keys which are not overwritten by our scripts. Previously this was quite simple as the ssh daemon was managed directly by the LCFG component but it is now managed by systemd. Again, the simplest solution is to move this step to the end of the initial install phase.
One thing that has become clear with the move to systemd on EL7 is that we have lots of this type of Informatics-specific configuration which has to be done during the install process. If we move all that to the LCFG installer then we necessarily have to add lots of local scripts and packages to the installer ISO image (referred to as the installroot). This is not really manageable and requires other sites to carry lots of software which they don’t need. It’s also not very flexible, if we decide to add new scripts to the install process we end up having to rebuild the ISOs and update the PXE installer.
An alternative solution is to use the software 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 and, although there is a default profile, each site typically has their own. This is much more dynamic and flexible, we can add any local packages we like to our local installbase profiles and change them whenever necessary.
To actually use the software recently installed on the machine at this stage requires a chroot call as the new root partition is mounted as
/root. Rather than hardcode all this into the existing
install component I added a new
baseinstall component. This is designed to work just like the main
install component but uses software from the installbase. It does various things to sanitise the calling environment (e.g. setting the
PATH variable and tweaking the tty settings). Commands are called in a full shell so that it’s possible to use all the features you might need. 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’s assumed to be an LCFG component which should be passed to
Another advantage of this approach is that the 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
/root. With the baseinstall component the standard
configure method can be called without modifications.
By default the baseinstall component is included only on EL7 but it has no methods. This should work on SL6 but so far it has only really been tested on EL7.