[OpenAFS] Re: OpenAFS 1.6.5/1.6.10 - server segfaults during migration to rxkad-k5

[Benjamin Kaduk]

On Mon, 10 Nov 2014, Andrew Deason wrote:

> On Mon, 10 Nov 2014 22:23:51 -0500 (EST)
> Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
> > On Mon, 10 Nov 2014, Andrew Deason wrote:
> >
> > > On Mon, 10 Nov 2014 14:24:49 +0100
> > > Volkmar Glauche <volkmar.glauche@uniklinik-freiburg.de> 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