|
|
|
| Task: | Software management |
| Group: | ajs |
| Stage: | 1 |
For Stage1, this review will only consider the issues relating to RedHat Linux software management. A wider review to encompass other platforms will be performed for Stage2.
As with the Linux task, the following describes the technology and processes at KB as this is currently the only managed Linux technology in the division.
With RedHat Linux, software is packaged in container files called RPMs; these contain the files for the package, along with pre/post install/uninstall scripts and information about the package. These RPMs are installed on each machine; a typical KB Linux machine has more than 1000 RPMs installed. No software is mounted from file servers.
The RPMs themselves are built from SRPMs (Source RPMs). These contain the original source, any patches and a specfile which describes how to build the RPM from the sources.
After an RPM has been built, it is submitted to the master RPM repository. This repository is then replicated, nightly or on demand, using rsync to a number of RPM repository mirrors.
The SRPMs are stored in a master SRPM repository; there is no need to replicate this directory.
Each machine runs a local tool called updaterpms to maintain the set of RPMs installed. This is driven by a configuration file per machine (or group of machines). Both the RPMs and configuration files are accessed over NFS.
This reliance on NFS is a major obstacle to updating machines (particularly laptops) remotely.
Bugs in local software are currently tracked in the KB tkgnats system, or reported directly to the software's author. This makes it more difficult for other sites using our code to report and track bugs.
There has already been recent agreement ( Paul's document Dice Software Guidelines) to store local software in a central CVS repository, with RPMs and other package formats) being created directly from the CVS'd source.
This CVS repository is now in service in dcs.ed.ac.uk, but should be able to move to inf.ed.ac.uk very soon.
The current tool, rpmsubmit, is a crude setuid binary which copies the submitted RPM over NFS to the master repository. This has obvious implications for the security of the whole DICE system, as well as blocking remote RPM submission.
Other tasks have already raised the issue of user contributed software. This has never been satisfactorily resolved at KB; currently if users want to submit RPMs, they have to do so via the CSOs who run rpmcheck (which does some simple security checks) over the RPM. It would be highly desirable for this procedure to be automated as far as possible.
It may be prudent to accept only signed RPMs for submission; this would be one way to authenticate the individual submitting an RPM. Certainly RPMs which are expected to be exported should be signed; an issue for the LCFG Software Guidelines document ?
Further thought is required, but a replacement rpmsubmit should be probably considered the most important deliverable of this task.
It has already been decided to use the existing KB Linux software distribution technology for Stage 1, for a number of reasons :-
For Stage 1, given the decision to use the existing KB technology for software distribution, there appears to be no obvious argument for not using the existing KB technology for software repositories and mirror replication.
A new master RPM repository under inf.ed.ac.uk will need creating, with, presumably, at least one RPM mirror per physical site. This is the responsibility of the Install/Config/Softdist Servers task.
A separate bug tracking system for local software makes sense for the following reasons :-
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh |
|
