[2304] in Release_7.7_team
Minutes of our 2000-06-14 meeting
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Jun 14 15:31:40 2000
Date: Wed, 14 Jun 2000 15:30:57 -0400 (EDT)
Message-Id: <200006141930.PAA23937@small-gods.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
Attending: ajfox rbasch tb aurora ghudson miki jweiss wdc zacheiss
1. Local netscape
It doesn't work yet, but it should soon.
dash generally invokes netscape using htmlview, which currently
doesn't take advantage of the local netscape. Making htmlview use the
local netscape is a little tricky and can't be done with a simple sed
substitution. Options are:
* Ignore the problem; htmlview will still work even if it's
slower.
* Get the infoagents locker to adjust htmlview for our
purposes. This might wind up being rather kludgy.
* Maintain our own version of htmlview in /usr/athena/bin.
We're going to go with the third option. htmlview is not a terribly
complicated script, and our version can assume that
/usr/athena/bin/netscape is present and will dtrt.
2. Linux update policy
Our current RPM update policy is:
* You can locally add an RPM.
* You can locally remove an RPM.
* You can locally upgrade an RPM, and it will stay at the
upgraded version until we have an even newer version to
install.
* You can't locally downgrade an RPM and have it stay
downgraded.
We could change the current policy in one of two ways to allow locally
downgrading an RPM:
* We could not touch an RPM unless it has changed in the
release. This wouldn't actually make a locally downgraded
RPM stay downgraded in all cases, but it would decrease the
"but this release had nothing to do with the RPM in
question" factor.
* We could not touch an RPM under any circumstances unless the
old release state matches the installed state. This would
allow locally downgraded RPMs to stay downgraded, although
it would also make locally upgraded RPMs stay stuck at the
current state unless we happened to upgrade through that RPM
version.
The problem with these changes is that it makes the update somewhat
less robust in the case where /var/athena/release-rpms gets out of
sync with what's installed on the system (because a post-install
script fails, or because of a bug).
After some discussion, we decided that the right answer is to
implement an exception file where an administrator can list RPMs which
shouldn't be touched. We might not do this right away.
3. Linux kernel problem
We don't currently support initrd; when we upgrade a kernel, we just
install the RPM and point lilo.conf at it. This sucks for SCSI-only
systems.
In the long term, we would like our install and our update to support
the construction of ramdisk images. In the short term, we can
document a manual kernel update procedure, or we can ignore the
problem and claim not to support SCSI-only systems.
4. Issues remaining for early
Greg will put out a patch release, hopefully tonight, to propagate
some recent changes.
We need mkserv knfs for Solaris.
We need OS verification for Solaris and Linux. miki has finished the
work for Solaris and it is under review by Greg. Thomas is finishing
the work for Linux.
We need to populate the special safe cluster for Suns which don't have
adequate partitions.
We need to propagate system packs to the athena cell.
We should fix printing on Linux. [Post-meeting data: It works on at
least Solaris, and probably IRIX, but it definitely seems to fail on
Linux.]
We are going to target the evening of Monday the 26th, which gives us
a week or so to deal with these issues. We should send mail to the
early contacts next Monday, one week before the release.
5. xss running by default
We would like to make xss run by default. There are three problems:
* People who run xss in their dotfiles will get an error
message which is difficult to decipher.
* The current implementation of xss-button will not work for
an already running xss.
* People who use the SIPB xscreensaver could get dueling
screensavers.
The first problem is unfortunate but not fatal, and probably doesn't
bite too many users. And it's difficult to do anything about. We
will live with that.
We have to fix the second and third problems before we can make the
change. Greg will hopefully fix xss-button this week. For the third
problem, we will attempt to convince the SIPB locker maintainers to
make xscreensaver a script on all platforms (at least at the 8.4
version), so people will have to run xscreensaver.real or something to
actually run it.
6. IRIX status
We have no word from SGI on when we will have a patch available.
Transarc is not going to give us a patch. But the good news is, SGI
can give us a patch independent of Transarc with nothing worse than a
slight performance impact.
In the meantime, we have disabled the processor workaround which
causes the problem. The problematic instruction is cvtl, which
converts a long to a floating point number, and we have no idea what
the impact will be (although the nature of the instruction suggests
that it may be more likely to affect programs which do floating-point
math). We believe that the impact could include things like Matlab
generating bad results, which could be poor.
7. Linux PWOG
Heather will call a meeting around July 18/19 to discuss the scope of
the Linux PWOG and how she will get the required information.
8. Release notes
People should send mail to Heather when the release changes in ways
which require release notes change.
9. ssh key on Linux
The ssh RPM creates an ssh host key. If the machine is public, this
key could be captured and used at a later date to decrypt ssh traffic
(if the machine has since become private). However, on layered
machines it is convenient for the key to be generated.
We decided that we will remove the host key in the public workstation
cleanup at boot and reactivate time.
10. AFS problem
We have started seeing an AFS problem, which appears to be somewhat
independent of platform and AFS version, where a particular file gets
screwy. In bugs [17884], Camilla reported that on an 8.3 or 8.4 SGI a
file would sometimes stat correctly but you'd get a permission denied
error trying to read it; miki and Bob have also seen problems during
the install where the directory pointed to by /os had the wrong stat
information (the owner bits were set to 0) and could not be searched.
This problem could basically kill a machine during an update. We
don't have a workaround, since AFS 3.5.patches seems to be affected as
well as AFS 3.6.
Usually, Transarc wants fs trace and kdump information in cases like
this. It's very difficult to get fs trace information retroactively
(since we can't reproduce the problem), but we can at least get kdump
output. Greg will send instructions to release-team explaining what
to do the next time we see this problem.
11. krb5 ftpd security hole
There is a newly-discovered security issue in the krb5 ftpd, which was
introduced in krb5 1.1.1 (and thus by Athena 8.4). Greg will fix it
in the patch release tonight. People should upgrade (if the patch
release is out) or disable their ftpd.
