[OpenAFS] Upgrade plan - any gotchas?

Christopher D. Clausen cclausen@acm.org
Mon, 12 Dec 2005 12:29:22 -0600

Steve Gaarder wrote:
> Here's my plan for upgrading both OS and OpenAFS on my primary AFS
> server. Please let me know if you see any potential problems,
> gotchas, etc.

What do you mean by "Primary"?  Do you only have one AFS DB server for 
your cell?  Most cells run at least 3 AFS DB servers (just look through 
the CellServDB file.)

> These items I have already done:
> 1.  Set up a second VLDB and file server.  Change all the CellServDB
> files to include both servers.  (Authentication is via Krb5; neither
> AFS server is a KDC)

When you say "second," what do you mean?

You probably want at least three VLDB, PTS, (and possibly BackupDB, if 
you use that) servers total.  (So that two are up at any given time.) 
Ubik (syncronization protocol that AFS uses) grants an extra vote to the 
server with the lowest IP address, and if the server you take down has 
the lowest, you might not reach quorum and bad things can happen.

> 2.  Move all non-replicated volumes to the second server.  Have
> replicas of the others on both servers.

I'd say to leave the non-primary servers up for a day or two to make 
sure everything is synced and working before you take down the primary.

> Here is what I plan to do:
> 3.  Shut down the primary server.  I can do this during regular hours
> because the secondary server will carry all the load.

This should be fine, assuming you don't loose quorum among the DB 

I upgraded my cell to OpenAFS 1.4.0 by taking down a single server at a 
time, having previously vos moved the data, doing the upgrade, patching 
the systems, rebooting (just to make sure that the services start on 
reboot) and enabling the AFS server processes.

> 4.  Install the new OS (RHEL 4) on a new partition.  Install OpenAFS
> 1.4.0 but don't start it.
> 5.  Copy /usr/afs/db, /usr/afs/etc/, and /usr/afs/local from the old
> system partition to the new one. Mount /vicepa same as on the old
> system.

You should NOT copy /usr/afs/db.  These DBs will auto replicate from the 
other server and there is no need to pre-populate that directory.  In 
fact, doing so may cause problems.  And you can have all kinds of issues 
if you copy the sysid file from another server (this might be better 
now, but in general copying unique identifiers is NOT a good idea.) 
Also be aware that different servers may have different NetRestrict or 
NetAllow files and you don't want to copy them.

There are details about most of these things on the wiki, which is 
unfortunately still down.


Note that this is based upon what I read in various on-line sources 
several years ago when I was planning our AFS cell.  Things may have 
changed since then and I assume that somone will correct anything that 
is totally wrong.

I'm sure there are several people willing to answer questions in real 
time on #openafs on the freenode IRC network, if you like that sort of 

Christopher D. Clausen