[1104] in SIPB-AFS-requests
Minutes of tonights meeting
daemon@ATHENA.MIT.EDU (Matt Braun)
Tue Aug 10 00:31:38 1993
To: sipb-afsreq@athena.mit.edu
Cc: marc@athena.mit.edu, warlord@athena.mit.edu, yandros@athena.mit.edu,
jweiss@athena.mit.edu, autumn@athena.mit.edu, gamadrid@athena.mit.edu,
ckclark@athena.mit.edu, gsstark"unconscious"@athena.mit.edu,
rjbarbal@athena.mit.edu, tlyu@athena.mit.edu, marthag@athena.mit.edu,
srz@athena.mit.edu, mkgray@athena.mit.edu, mhbraun@athena.mit.edu
Date: Tue, 10 Aug 93 00:31:05 EDT
From: Matt Braun <mhbraun@athena.mit.edu>
In attendance: marc, warlord, yandros, jweiss, autumn, gamadrid, ckclark,
gsstark (unconscious), rjbarbal, tlyu, marthag, srz, mkgray, mhbraun
1) Binaries: Currently we are running AFS 3.2A-Richard there is no newer
version that would work in our configuration (ie allow the cell to be named
differently from where it is being authenticated). We are running the 3.1
backup software since there is no 3.2A-Richard software available now. There
might be something wrong with the tapeconfig that marc set up. He will check
on it.
Tape sets need to be re-arranged ----- warlord will deal
2) We talked about the likelihood of trading Rosebud in from a maxine with
equivalent disk. I will ask Kim whether she is interested.
3) We need a set of instructions for installing the rs6k and adding disks.
marc volunteers
4) We agreed that rosebud should now have a servers /etc/passwd (no non-root
users).
yandros volunteers to correct this & /etc/security
5) We discussed adding a 3rd primary. After lots of arguing where we all
agreed, it was decided that it would be a nice idea but getting the hardware
would not be likely.
6) Reliability: The main reason the sipb cell is not as reliable as the athena
cell is hardware. We do not have the disk space to move everything off one
server and if one of our servers go down there is a greater than 50% chance
that we will lose quorrum. Availablility of personnel was also sighted as
another reason for lower reliability. It was decided that the reliability
level of the Athena cell was something to strive for.
7) Outages: When outages happen people should leave things alone until they are
sure of what they are doing.
Policy statement:
"Letting the cell remain in a read only state until more than than
one Admin can agree on a course of action is the preferred action"
8) Current state: the pts db's are *not* consistent right now. We *need*
Richard to be able to rebuild them
9) We need to backup atleast the vldb & ptdb. They should be copied into a
backed up volume nightly so they get dumped to tape weekly.
warlord will deal
10) Giving out bits: Admins in training should be given an overview of AFS and
what to do and what are considered 'safe operations.' They should also be
informed that when something goes wrong to find a more senior admin. People
can be added to the appropriate acls if and when a current admin is willing to
go out on a limb and vouch for them. Ideally, the senior admin will act as a
guide for the member who wants to become an AFS admin. The admin that vouches
for the new admin will be responsible for making sure that the new admin's
actions are correct and appropriate. The senior admin should also be
available to answer the new admin's questions. If other AFS admins object to
the addition, it is their perogative to remove the bits and/or open discussion
about the issue. It is strongly suggested that admin who is about to add
somebody to system:administrators and SUsers should at least talk it over with
other admins for the sake of reducing flaming, but this is not required.
This is supposedly what used to happen, but it has not been happening recently.
11) Security issues:
The following need to be changed:
rcmd.rosebud --------- changed
afs.sipb srvtab ------ needs to be changed, marc & jweiss will deal
12) All changes and problems with the cell should be documented and archived
in the sipb-afs meeting!!!
13) discussion about the postmortem for the outage.
yandros has the outline and will type it in RSN!
Matt
PS for the people that do not know, sipb-afsreq is archived (world-readably)
in charon:/usr/spool/discuss/sipb-afs
