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

[Volkmar Glauche]

Dear Benjamin, dear Andrew, dear list,

thank you very much for discussing the details of this keytab problem. =20
The kvno in the kdc is indeed zero. I don't remember how this =20
happened. Since we have been working without rxkad-k5 since now, my =20
solution is to rectify the kvno issue by rekeying during the next =20
scheduled maintenance window.

Best regards,

Volkmar

Zitat von Benjamin Kaduk <kaduk@MIT.EDU>:

> 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 installati=
on
>> > > > guidelines that still had kaserver in mind and proposed kvno=3D0.  =
Would
>> > > > bumping the kvno affect existing tokens/Keyfiles that are still
>> > > > relying on kvno=3D0? If so, I'll have to postpone keytab installati=
on
>> > > > 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
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>



--=20
Freiburg Brain Imaging
http://fbi.uniklinik-freiburg.de/
Tel. +761 270-54783
Fax. +761 270-54819