White dot for spacing only
The Dice Project


Task: Linux platform support
Group: ajs,iainr
Stage: 1

1 Introduction

This task includes :-

2 Time scales

This task has (at least) four phases :-
  1. A minimal setup by early January so that the base DICE linux platform, complete with Kerberos/LDAP, is available for other tasks to work on top of in early 2002. This will be Redhat 7.1 based.
  2. A more complete setup, based on Redhat 7.1, completely independent of dcs.ed.ac.uk infrastructure. This needs to be complete by end March.
  3. An upgrade to Redhat 7.2, improved kernel building, documentation. It intended that the move to using the new LCFG paths will be coscheduled with the 7.2 upgrade. This needs to be complete by June.
  4. All components to be converted to using the new LCFG ngeneric component. This is not absolutely essential for DICE deployment, but most components, effort willing, should be converted by October.
Because the first phase of this task is required before many of the other tasks can start work on even prototypes, the majority of the effort available is being employed completing this phase. This should be completed by the beginning of January, at which point progress so far will be documented before more careful evaluation of the design of the phase 1 deliverable.

3 Review of current practice

The only managed Linux technology is that from KB. A decision was taken early on in the DICE project to base the new DICE Linux on the KB technology, appropriately updated, at least for Stage1.

The DICE Linux task maps pretty well on to the existing KB task of Linux Platform Manager.

3.1 Components

The LCFG components (previously called objects) are the code scripts which configure or manage a particular aspect of a machine. For example, the amd component will configure and start a machine's auto-mounter. They are very similar to the startup scripts used by the System V init mechanism.

Of the existing LCFG components, some are clearly specific to Linux; for example, the kernel, hardware and xfree components. Others are clearly service specific and are fairly portable between platforms, eg dns, apache and postgres. In between, there are several objects which, while being in many ways service specific, do some things in particularly Linux ways, eg the auth component.

Identifying which components are the responsibility of the Linux task is an issue; pragmatically, it is likely that the Linux task will continue to hold responsibility for many of the "in-between" components until we have the technology for greater modularity in LCFG components, ie for Stage1.

The coordination of upgrading all of the components for each new Linux release has traditionally been performed by the Linux Platform manager.

3.2 Machine installation technology

Linux machines are installed by bootstrapping the Linux kernel from a floppy or CDROM; there has been some useful work done on PXE booting (booting the kernel over the network), but this has yet to be fully integrated. The kernel then runs a cut down version of Redhat, called the "installroot" over NFS or from CDROM. This "installroot" calls LCFG components to configure the new machine; it is itself built using the standard software installation technology.

3.3 Kernel Building

The Linux kernel is highly modularised, with device drivers either being compiled into the kernel or loaded from module files. There are quite a few compile-time kernel parameters, but in practice we've not found (at KB) much reason to tinker with them.

At KB, we have managed with four distinct kernels (per kernel release) :-

public kernel
majority of device drivers loaded at install time - used for all desktops and laptops.
server kernel
as above, but with SCSI compiled into kernel so can boot from SCSI drives. Also some network parameters tweaked.
smp kernel
the server kernel, but compiled for multi-processor machines.
install kernel
all required device drivers compiled into kernel - used at install time.

Until recently, the master copies of the kernel configurations and RPM specfiles were contained in the relevant SRPM, with manual synchronisation of the specfiles between kernels. Since this summer, the RPM specfile has been built from one RCS'd parameterised master specfile with the kernel config files also in RCS. Would be nice to parameterise the kernel config file.

3.4 Documentation

There has been no on-line documentation on which Linux hardware is recommended/supported/tested. This knowledge has largely been held in the heads of certain individuals.

4 New technology

5 Work to be carried out

5.1 Phase 1

5.2 Phase 2

5.3 Phase 3

5.4 Phase 4

6 Miscellaneous Issues

6.1 Multiple release support

Historically, at KB we've upgraded the vast majority of machines to the latest release every year. However, this process has often taken several months to complete. It is likely that the sheer scale of the division (both in numbers of machines and spread of requirements) will result in the need to support several releases simultaneously.

7 Actions

Actions for meeting on 19/02/2002



 : Deploy 

Mini Informatics Logo - Link to Main Informatics Page
Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh
Spacing Line