[OpenAFS] Changes for Mosaic's AFS cell...

[Christopher D. Clausen]

Rodney M Dyer <rmdyer@uncc.edu> wrote:
> Does it matter whether the cell servers are upgraded
> first?  Obviously not, since our existing test server already works. 
> I've never upgraded a cell server myself, and the person who last
> upgraded our cell servers has "left the building".

Other than having servers that support whatever features you need, no, 
it shouldn't matter.  I had a problem with "foreign users" from other 
Kerberos realms not working b/c my servers were too old.  If you are not 
intending to use any new functionality you should be fine upgrading 
either the clients or the servers in any order.

I would recomend doing server upgrades as close as possible though to 
minimize problems that may occur.

> Our current
> back-end systems guy just wanted some indication about the sequence
> of events in which things should take place.  Because of issues with
> the UBIK quorum, if no accounts, or volumes are being added, removed,
> or replicated during an upgrade, is the sequence of cell server
> upgrades important?  I mean our cell is fairly small so can we just
> upgrade each one without worry right?

I've updated to various dev builds and rc versions in random order, one 
AFS server at a time, on the three AFS DB servers for the acm.uiuc.edu 
cell without issues (at least not issues related to upgrade order.) 
Just vos move all volumes off, shut it down, do whatever system upgrades 
at the same time, and restart with the newer version.

I will say that 1.4.1-rc10 appears to be running just fine on sun4x_510 
after crashes with previous versions forced upgrades.

I'd say to minimize the amount of time that the server is down and of 
course do it during off-peak times.

> 2.  We need to shut down an older cell server and bring up a new one
> in another building.
>
> For issue 2, we have set the vlserver prefs on each client so that the
> clients won't select the cell server we want to move to another
> building (or it will be last in the pref list).  Can we just shut
> down the old cell server and bring up another (in another building)
> without much worry about UBIK issues?  This is somewhat similar to
> issue 1.

I have done this as well without any issues.

I assume you have two other AFS DB servers to maintain quorum?

Is the IP address of the new server going to match the old server?

> 3.  We'd like to turn off the old KAS from Transarc and rely totally
> on Kerb 5 (finally).  We are already using Kerb 5 everywhere and none
> of our AFS clients use KAS anymore, but we've never actually disabled
> it.

I setup Kerberos 5 only from the start, so I can't comment on this other 
than we don't have any Transarc stuff and everything appears to be 
working.

> 4.  We'd like to try real K5 AFS service tickets without using the 5
> to 4 daemon.
>
> For issue 4, I am under the impression (from my conversation at the
> last BPW) that we can disable our 5 to 4 daemon that AKLOG uses and
> AKLOG will just take the K5 encrypted part and just stuff it into the
> AFS cred manager.  The only thing we need to do is update our key
> files on the file servers right?  Can AKLOG do what it needs to do
> without having access to a 5 to 4 daemon?

If you have an aklog that uses pure krb5, yes, it should just work 
without a krb524d running.

AFAIK, you shouldn't need to update your AFS key files, but its possible 
that mine are new enough to not need to refreshed to a new enc_type.

<<CDC
-- 
Christopher D. Clausen
ACM@UIUC SysAdmin