[2072] in Release_7.7_team
Minutes for 2000-02-02 meeting
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Feb 2 20:45:30 2000
Date: Wed, 2 Feb 2000 20:45:12 -0500
Message-Id: <200002030145.UAA01279@egyptian-gods.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
I have some notes about things we talked about, which I'll include
first:
* For the Solaris proposal, we might want to leave the
partition layout the way it is for small disks. (Say,
anything under 2GB.) That way we can assume that anything
partitioned under the new layout has plenty of space.
* See source-developers [285] et seq for my notes on teTeX.
One problem is that teTeX comes with a big gzipped tarfile
to install in the target area, which doesn't interact all
that well with CVS.
* Thomas's update model is a little too simplified, because it
only gives workstations access to the most recent version of
the package lists.
- We sometimes like to run scripts during an update.
(This interferes with backing out patch releases,
but I don't know if we can avoid it.)
- When we want to remove a package, we want that to
happen just once (when the patch release is taken).
So a workstation has to keep track of what releases it has
taken and also needs to look for control files for
intermediate patch releases.
The last point requires another iteration of design review. I'll send
out a new proposal in email.
1. Release web page
Bill had suggested changing some email addresses on the release web
page to mailto: URLs. The team decided not to do so because of
spambots.
2. Private workstations
We discussed the feedback received at the Tuesday meeting (most people
seemed to want shared OS maintenance, and many of their problems would
be helped by having things local). As usual, we are somewhat
constrained by the partitioning of existing machines. After some
discussion, we came up with a proposal for Solaris and the Athena 8.4
release:
* For new installs, install with just / and /usr/vice/cache
partitions (and swap, of course). That way we don't have to
worry about / or /usr being smaller than we'd like as long
as the disk is big enough.
* On all systems, move to an IRIX-like model where we use the
native pkg suite to install the base OS packages, but still
use track for the srvd.
* On systems with one big / partition, install all of the OS
packages locally.
* On systems with split-up partitions, make a symlink farm
into /os for non-base OS packages. Try to avoid symlinking
directories if possible.
* Suggest that private workstation owners reinstall to take
advantage of the new release layout.
miki will evaluate this proposal and get back to us next week on
whether it seems feasible.
3. xss autolock
fuzzballs has recommended that we use the xss auto-lock feature
(something like auto-blank at ten minutes and auto-lock at fifteen) to
enhance security on cluster workstations. We'd probably run xss in
the default xsession unless te user sets skip_xss.
Nobody particularly volunteered to do the work. Greg might get around
to it some day.
4. TeX
keithw suggested we should be using teTeX. The main problem is that
it's really big. At the meeting we suggested that we could hire
keithw to deal with tex stuff. This has been on Greg's back burner
for a while.
5. Linux
We want to deploy on Monday. There were a lot of details to work out.
a) Organization of /afs/dev.mit.edu/system stuff
We settled on a path prefix of /afs/dev.mit.edu/system/rhlinux and the
following subdirs:
redhat-6.1 Copies of Red Hat CDs
redhat-6.1-updates Additional RPMs from Red Hat
athena-8.3 Athena RPMs
control Lists of RPMs for patch releases
installer Install scripts which live in AFS
(The version numbers for the update RPMs and the Athena RPMs are
mainly for volume management sanity; it is not actually necessary to
separate out those RPMs for different releases.)
b) Update
Thomas suggested a model where each Athena release has a list of RPMs.
Greg noted that we sometimes want RPMs deleted on Athena machines (not
present in a new version of the OS, contains a security hole,
conflicts with locker software), so Thomas amended the model to also
include a list of RPMs to delete.
An update, then, does an "rpm -u" (update or install) of all packages
on the new package list, and deletes packages on the deletion list.
For public machines, it deletes any package not in the new list.
c) Cluster information
The proposed model is to define two new cluster variables to use
instead of syslib. They would look like:
sysprefix /afs/athena.mit.edu/system/rhlinux
syscontrol control/8.3-current
were 8.3-current would be a symlink to 8.3.24 or something. The
update would cd to the sysprefix value (so paths in RPM lists can have
paths relative to there, allowing the packs to be identical between
the athena and dev cells) and read the control file, which would say
where to find the package list and deletion list.
d) Tasks
tb: Finish install
Rebuild RPMs (w/ ghudson)
Pull up some fixes to 8.3_linux
Make some pending bugfixes
Install media
Write instructions
Tell afsreq to copy packs when ready
aurora: Cluster poster
ghudson: Write update scripts
Tell hesreq to create new clusters
e) Install
The install process starts with a floppy (based on etherboot) which
asks for the IP address, server address, gateway, and filename. (The
server will be tkl.) It tftps to the server and gets a kernel to
boot with a ramdisk.
The ramdisk asks for the IP address again (we can fix this
eventually), loads AFS, and runs a script named "phase2" out of AFS.
The phase2 script installs RPMs from a list (which should at some
point point to the list from the update) and configures the system.
Places where things will live:
* Install media - bootkit locker
* ramdisk - on tkl
* phase2 script - /afs/athena.mit.edu/system/rhlinux/installer
* Sources for all this stuff - als locker
