[2249] in Release_7.7_team
Minutes of our 2000-05-10 meeting
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed May 10 15:13:16 2000
Date: Wed, 10 May 2000 15:13:08 -0400 (EDT)
Message-Id: <200005101913.PAA07654@small-gods.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
Attending: zacheiss, othomas, rbasch, aurora, ajfox, tb, ghudson, wdc,
miki, jweiss
1. LLAMA licensing scheme
The LLAMA team came up with a "trust but verify" plan for third-party
software licensing which worked something like this:
* To use third-party software, you have to have an ID in a
file on your machine.
* The SLW client will transmit this ID to the server, and the
server will log it along with the IP address.
* Cluster machines will all use the universal cluster ID.
Departmental machines will use an ID they get from
registering their machine and paying Athena fees. (Students
wouldn't have to pay fees. There might be a universal Id
for dorm machines; it probably has to be different from the
cluster universal ID.)
* The logging gives us enough information to detect gross
violations of the registered IDs, or to detect people using
the universal keys from non-cluster or non-dorm machines.
We discussed how to deal with the universal IDs. We are not
especially happy with adding questions to the install process. We
came up with the following acceptable plan:
* Cluster machines will all be placed in a cluster which sets
some variable which means "I am a cluster machine."
* At boot time, machines with this cluster variable set will
copy in the universal cluster ID from AFS if no key is
present. Machines without this cluster variable set will
delete the existing ID if it is a universal ID. If there is
a registered ID present, it won't be touched.
We also discussed some administrative concerns, but did not attempt to
resolve them. The issue will be kicked back to the LLAMA team. It
may become unnecessary to implement IDs at all; logging IP addresses
might be good enough. But that's not a release-team issue.
2. SGI AFS problem
IRIX 6.5.3 is not supported by Transarc or SGI, has a critical NFS
problem, and hangs randomly on 300MHz O2s.
IRIX 6.5.4 is supported by Transarc, is not supported by SGI (they
won't fix the critical NFS bug), but does have a fix for the O2
hanging problem.
IRIX 6.5.7 is not supported by Transarc, but is supported by SGI. AFS
fails to work under IRIX 6.5.7 on old Indy machines unless you disable
a processor bug workaround in the kernel.
We are still figuring out whether it's feasible to upgrade the 90 or
so old Indy machines to newer processors.
Our current thinking is to keep going with IRIX 6.5.7 if we can solve
the current problem; the Transarc support issue for 6.5.7 is more
likely to fix itself than the SGI support issue for 6.5.4. For the
beta, we might disable the processor bug workaround and see if that
actually induces visible failures.
3. Scheduling and status
Based on when we went to alpha, we should go to beta in about a week.
This is gating on:
* IRIX: AFS issue, although we may just disable the processor
bug workaround for beta
* Solaris: Update system rework, or at least fixing the
specific issue of sendmail.cf getting stomped on.
* Linux: ability to upgrade kernel RPMs
* System release notes
miki is doing the Solaris update system rework and expects to be done
by Monday. Greg is working on the last two issues. If we slip by
more than a week or so, we will have to compress beta testing and/or
early testing to have a public release by the end of July.
