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

[Andrew Deason]

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.

If you are changing the key (extracting a new keytab from the KDC
usually does this), then yes, you certainly do risk downtime unless you
take very specific steps to avoid it, so you'd want to do this during a
maintenance window. This discussion has probably already gotten
confusing enough, though, so you may just want to do this during a
maintenance window now, anyway, to be safe.

-- 
Andrew Deason
adeason@sinenomine.net