DICE Deployment: Install/Configuration/Softdist servers

.........................

home

units

doc

.........................

Task: Install/Configuration/Softdist servers

Group: ajs,iainr

Stage: 1

Introduction

This task includes the base installation, configuration, software-distribution servers.

The configuration server is where the master copies of machine configurations reside. It runs mkxprof to create XML profiles and runs an http server to publish XML profiles.

Linux software is packaged in RPMs and distributed from a master RPM repository to a number of RPM mirrors (see Software task for more details). Experience at KB has shown that one RPM mirror can adequately service more than 200 clients.

Linux PCs are installed by booting a cut down Linux over NFS from an install server, using DHCP and (optionally) PXE. A number of install servers will be required; for efficiency, install servers should be on the same subnet as the client being installed.

One agreed design principle is that individual sites should have sufficient resilience against significant (eg a week) EdLAN failure.

Configuration Server(s)

There are two obvious possible models :-

One master server for the whole Division; all machine configuration data and profile generation on one machine. Multiple slave servers with replicated copies of the profiles.
- Pros: all configuration data in one place; simplifies validation?
- Cons: profile generation expensive with considerable delays between editing configuration and that configuration being distributed
Multiple masters, one per site/cluster; only system wide header files stored/edited centrally and distributed to masters(via rsync?). All other configuration data held and profiles generated on site/cluster server.
- Pros: more scaleable solution, configuration still possible if site/cluster physically annexed.
- Cons: makes validation more awkward?

Model 2, with multiple masters, is the proposed model as the performance benefits appear to outweigh the possible obstacles to validation.

Profile generation is sufficiently expensive that servers should be almost solely dedicated to that task. Some experimentation on the best suitable hardware configuration would be useful.

Dependencies

All components need to be converted to new LCFG guidelines, such that components defaults are distributed by RPM.
The configuration editor (rfe) is required to edit files.
The profile generation software needs to be able to look in multiple directories for files; eg one for local cluster files, one for component default files and one for replicated system wide header files.

RPM master and mirror repositories

One RPM/SRPM master server will be required
At least one RPM mirror will be required per physical site, probably 2 at KB, 1 at each of FH, SB and BP.

Rpmcfg files, the files that indicate which RPMs should be installed on each machine, are currently carried as part of the replicated RPM hierarchy. There are plans to move this configuration info into the LCFG profiles, but until the technology to do this exists, it is proposed that the rpmcfg files remain in the RPM hierarchy.

The master RPM/SRPM server doesn't need a fast CPU or large amounts of RAM, but will need sufficient disk space to allow for a replicated copy of all the files.

The mirror servers will require fast network connections and ideally large amounts of RAM. Ideally connected to all client wires, but particularly to wires where large numbers of machines are installed in parallel (eg teaching labs).

The mirror servers could also act as install servers (see below)

Dependencies

A server to act as RPM/SRPM master server.
Servers (probably 5 of) to act as RPM mirrors.
The configuration editor (rfe) is required to edit rpmcfg files

Install servers

There are a minimum of two services required for bootstrapping the install process - an NFS service to serve the read-only install-root and a DHCP service by which a new machine discovers its address and the location of the install-root.

DHCP isn't routable, so there must be a DHCP server directly connected to any wire that will have Linux boxes; the network task has in effect already suggested this in order to grant even static IP addresses.

NFS is routable, so the server providing the install-root need not be on the same wire as the machine being installed.

As mentioned in the previous section, the RPM mirror servers could NFS serve the install-root for the relevant site.

Issues

Who provides the DHCP service ?
What are the requirements for PXE network booting ?

Interim

Machine configurations are being edited on the existing KB YP master (using rfe) with profiles being generated on dice3.inf.ed.ac.uk. Once all components are converted to the new guidelines and there is a useable configuration editor, DICE machine configuration editing and generation can be moved to a new server. Although it is intended that there should be multiple configuration servers for DICE production, we can probably live with just one server in the first instance (until May?).

The master RPM/SRPM server is the DCS master server (fechlin.dcs.ed.ac.uk). Although there is no obvious urgency to provide a new master server, it might be a good idea to create new rpm and rpmcfg hierarchies?

There is one DICE RPM mirror server on wire-m :- medlar.inf.ed.ac.uk. This is also carrying the install-root and running DHCP (configured manually). This is probably sufficient until there are more DICE enabled wires.

Documentation

Documentation to be produced by this task

Actions

Actions for meeting on 19/02/2002

Create a configuration server.
Think about whether really need separate rpm/rpmcfg hierarchy for DICE.

: Deploy

Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh

Task:	Install/Configuration/Softdist servers
Group:	ajs,iainr
Stage:	1