For example, modifications to the behaviour of the install process (for COs, mainly outwith Informatics):
request subnet-mask, broadcast-address, routers, domain-name, domain-name-servers, host-name, time-servers, user-class, ntp-servers;is controlled by the local copy of
dhclient.conf- which is part of the installroot image (and is therefore configurable - on a site-wide basis - prior to installation).
It is also possible to supply (some of) this information via
removeable media (floppy or memory stick, containing the configuration
To change the behaviour of the DHCP exchange, the installroot files
to be changed (the former requests information from the DHCP server -
as shown above - and the latter packages that information for use by
To change the information requested from the DHCP server, amend the
request list in
dhclient.conf (see example above,
dhclient.conf(5) for more detail). It is assumed that
the corresponding options will be available via
dhcpd.conf on the DHCP server (this file is
controlled via LCFG, and configured by the
In DICE, the DHCP servers can be identified by the presence of
#define DHCPD_INTERFACES ..." in the profile (and the
presence of a
If an additional component is required at install time (and assuming
that the component has already been submitted via the component and
server defaults file RPMs) the component RPM name should be included
in this list - which is currently maintained via Subversion as
the RPM is installed, the component script will appear in
The configuration of the service for which the component is responsible should be handled by the Configure() method within the component script.
lcfg_fc5_installbase.rpms" (minimal RPM set for LCFG Fedora Core 5 install) or "
lcfg_fc6_64_installbase.rpms" (minimal RPM set for LCFG Fedora Core 6 x86_64 install). These are then included in the
profile.packagesresource in the various release-version
files.host.html, where LCFG-server is currently "
To add a new package (an RPM in the DICE world) to the package list, add the package name to the relevant file in the Subversion repository under
How To Use Install-Time ContextsContexts can be used to constrain the scope and applicability of resources (for instance, to set local - rather than network - resources when using a standalone laptop). It is also possible to use contexts at install time, and some are automatically set - there are, for example, two contexts used at install time:
See the DICE Wiki pages for more info.
install: this is set for the majority of the installroot process
installbase: this "is set from the start of the installbase process (ie the first boot off the hard disk) until some, undefined, time during the updaterpms run of the first boot" (and can, for example, be used to install packages that are not part of the installbase)
Possible uses (via profile settings) include:
Note that contexts are dealt with as part of the parsing of the profile by
- to set lookups to use local files only (this sets the
nsswitchmodule "passwd", which is used to update the
- to install additional (or remove/upgrade/downgrade) software after the initial installation:!profile.packages mADD(+package[install!=true])
- to manage passwords locally after installation (setting the
auth.managepasswdresource to "no" - the default is "yes" - stops the component from managing the
/etc/shadowfiles):!auth.managepasswd[install] mSET(yes) !auth.managepasswd mSET(no)
mkxprof(when the XML version is generated) or
rdxprof(when the DBM file is generated). There are no constraints on the value of a context string, and it is up to the component or other application/utility to do something useful with it.
An Overview Of The Install ProcessThe install process is covered in detail in other documents, but from the CSO perspective, it involves:
- Adding new host to DNS and DHCP server (use "
rfe dns/inf" to add details to both DNS and DHCP).
- Creating a basic profile to specify any machine-specific install options:
- use "
rfe -n -t lcfg/template
lcfg/host" to create a new profile for host host based on host template
- use "
rfe -n lcfg/host" to create a new profile for host host with a default set of headers to edit.
- Check profile has compiled correctly (examine log file
/var/lcfg/log/serveron one of the LCFG servers, or
lcfg1" or "
Choose method of installation (CD or network via PXE), and boot accordingly (using a BIOS utility to select the boot method, if required). Choose installation mode (default, or single-step debug).
What The Different Installroot Boot Options MeanThere are various options available at install time and, once the install kernel is running and the profile has been downloaded, a list of these options is presented:(I)nstall, (D)ebug, (S)hell, (P)atchup, (R)eboot:These behaviours are controlled by the
rc_installscript, which executes local commands or calls relevant components as appropriate:
- The "(I)nstall" option invokes the install component with the install method, and reboots (by calling the local DoReboot function - see below) if this is successful.
- The "(D)ebug" option is similar to the "(I)nstall" option, but allows single-stepping through each of the install actions and methods.
- The "(S)hell" option simply drops to a Bourne shell (
- The "(P)atchup" option is covered below, see "How To Write And Invoke Patches".
- The "(R)eboot" option calls the DoReboot function defined within
rc_install- which sends TERM and KILL signals to all processes, unmounts filesystems, and calls
How To Write And Invoke PatchesInstallroot patches are small scripts that can be downloaded from the web for execution locally, and "are usually used to repair problems which hinder a Linux machine from booting". The execution of such a script is initiated manually at install time by choosing "p" from the install options and giving the patch name. Once selected, the install component is invoked with the "patchup" method, which downloads the patch from a given URL into /tmp, and then runs it - returning to the "
(I)nstall, (D)ebug, (S)hell, (P)atchup, (R)eboot" prompt when complete.
Patch scripts should be installed in a patches sub-directory of the relevant unit under
, for example:/group/project/linux-team/html/patches/grub(At the time of writing, there are no other patch locations.)
To write a patch, simply create an executable script in the default location above. For a little more detail, and an example, see the patch page (which also contains a list of the available patches).