Wouldn't a better key-update-transition plan be:
* create a new key
* stash it in the KeyFile in the next kvno slot
* wait until the servers pick it up
* update the afs key on the kdc to match the new value (make sure it
matches the kvno that you used before)
* profit.
From what I understand -- and please correct me if I'm wrong -- all
of the various key versions in the key file should be valid(?) for
transacting with AFS -- so in order to go service-outage-less, you
need to make sure the new key available to all of the servers before
you go and make that the current AFS service key on the KDC?
Once your "longest" key expiration time is reached for your cell, you
could safely remove the old key version from the KeyFile...
-rob
On Mar 16, 2007, at 2:43 PM, Russ Allbery wrote:
A V Le Blanc <[EMAIL PROTECTED]> writes:
On a test cell, I've been able to change the encryption key as
follows:
I change the afs password using kadmin and export it to the
KeyFile. I
then have to kill the bos process and all server processes on all
servers, since my old admin tokens don't work any more, nor do new
ones
when I reauthenticate. After restarting bos, the other processes
start
cleanly, and authentication works again.
Once the KeyFile is distributed to all of your systems, the AFS server
processes should pick up the change automatically (I think there's
some
short checking interval). There were some bugs in this in earlier
versions of 1.4 on Solaris, but I'm fairly sure they were ironed out.
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
