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
file ip.cfg
).
To change the behaviour of the DHCP exchange, the installroot files
dhclient.conf
and dhclient-lcfg-script
need
to be changed (the former requests information from the DHCP server -
as shown above - and the latter packages that information for use by
the /etc/rc_install
script).
To change the information requested from the DHCP server, amend the
request list in dhclient.conf
(see example above,
and 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 dhcpd
component).
In DICE, the DHCP servers can be identified by the presence of
"#define DHCPD_INTERFACES
..." in the profile (and the
presence of a /etc/dhcpd.conf
file).
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
lcfg/core/packages/lcfg/lcfg_fc5_installroot.rpms
. Once
the RPM is installed, the component script will appear in
/usr/lib/lcfg/components
.
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.packages
resource in the
various release-version installbase.h files.
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 core/packages/lcfg
.
How To Use Install-Time Contexts
Contexts 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:
-
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)
See the
DICE Wiki pages
for more info.
Possible uses (via profile settings) include:
- to set lookups to use local files only
(this sets the
nsswitch
module "passwd", which
is used to update the /etc/nsswitch.conf
file):
nsswitch.mods_passwd[install] files
- 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.managepasswd
resource to "no" - the default
is "yes" - stops the component from managing the
/etc/passwd
and /etc/shadow
files):
!auth.managepasswd[install] mSET(yes)
!auth.managepasswd mSET(no)
Note that contexts are dealt with as part of the parsing of the
profile by 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 Process
The 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/server
on one of the LCFG servers,
or
http://
LCFG-server.inf.ed.ac.uk/cgi/status.cgi/inf.ed.ac.uk/
host.html,
where LCFG-server is currently "lcfg
",
"lcfg1
" or "lcfg3
").
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 Mean
There 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_install
script,
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
(
/bin/sh
).
- 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 /sbin/reboot
.
How To Write And Invoke Patches
Installroot 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 /group/project, 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).