[3218] in SIPB-AFS-requests
db server upgrade to 3.4a successful
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Wed Dec 30 02:18:44 1998
To: sipb-afsreq@MIT.EDU
Cc: zacheiss@MIT.EDU
Date: Wed, 30 Dec 1998 02:18:36 EST
From: Garry Zacheiss <zacheiss@MIT.EDU>
The update of the sipb cell db server processes to AFS 3.4a this
evening was successful. For reference, the ptserver and vlserver
binaries are the only ones that were upgraded in this outage. The
binaries and source used for the new binaries come from
/mit/ops/src/afs34a-patches5/@sys/
and should be moving into the sipb cell soon. Further updates as events
warrant.
On each server, directories /usr/afs/bin and /usr/afs/bin.old
exist. /usr/afs/bin is identical to bin.old except for the two binaries
already mentioned. It's important to note that until Sunday morning's
restart, processes will be running out of bin.old, so the directory
shouldn't be removed until that time. As a sidebar, rb was extremely
short on space on its /var partition, and after some consultation with
jweiss, kcr removed a 27 MB timed debugging log from 1997.
A backup of the prdb and vldb from reynelda prior to the outage
was kept, and is stored in
reynelda:/usr/afs/db.33
In the event that we would need to back out of this upgrade, the
db files would need to be restored from this backup.
One slight complication occured during the upgrade. Immediately
following the upgrade, it was not possible to authenticate to either the
prdb or the vldb using pts or vos (file permissions worked fine). We
determined that this was because AFS 3.4a no longer uses an
/usr/afs/etc/Realms file for determining the kerberos realm to
authenticate from. Instead, it uses /usr/afs/etc/krb.conf, which wasn't
present on any of the servers. Creating this file with the contents
"ATHENA.MIT.EDU" made authentication to the db processes possible
again. Thanks to marc for noticing the krb.conf file on seiko, and the
absence of one on the sipb cell servers.
The fileserver processes on these machines have not yet been
upgraded. This is something that would probably best be done in the
window provided by a Sunday AM restart, and could easily be done at the
same time rb is upgraded to a Sun. However, not all the machines need
to have the file servers upgraded at the same time. Interoperability of
3.3a and 3.4a fileservers is well tested, and doesn't result in any
problems.
Garry
