On Mon, 10 Nov 2014, Andrew Deason wrote: > On Mon, 10 Nov 2014 22:23:51 -0500 (EST) > Benjamin Kaduk <[email protected]> wrote: > > > On Mon, 10 Nov 2014, Andrew Deason wrote: > > > > > On Mon, 10 Nov 2014 14:24:49 +0100 > > > Volkmar Glauche <[email protected]> wrote: > > > > > > > I've never used kaserver/kerberos4, but maybe I followed installation > > > > guidelines that still had kaserver in mind and proposed kvno=0. Would > > > > bumping the kvno affect existing tokens/Keyfiles that are still > > > > relying on kvno=0? If so, I'll have to postpone keytab installation > > > > until I find a maintenance time slot. > > > > > > For specifically rxkad.keytab (i.e. non-DES) processing, we mostly > > > ignore the kvno for incoming connections, so this shouldn't break > > > anything and you should be okay (checking the kvno only changes the > > > error we return if we can't find a working key). > > > > Well, it behaves the same as any kerberized (clustered) service during > > key rollover: > > This is true if the key actually changes. I interpreted Volkmar's text > to mean that Volkmar would (hypothetically) just change the kvno in the > keytab only. Since we don't verify the kvno provided by clients against > the kvno in our rxkad.keytab (in this specific situation), I believe > that should work with no downtime.
Ah, I had read it a different way. Yes, I agree that using (e.g.) ktutil to make a keytab that contains the same key with both kvno 0 and 1 should solve this issue without an outage. Probably just replacing rxkad.keytab with a version of kvno 1 (and no kvno 0 copy) would also work, but I'd have to think about it a bit more to be sure. Sorry for increasing the confusiong... -Ben _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
