[OpenAFS] That infamous, magnificent bastard, error 19270408.

[Christopher D. Clausen]

Bill Stivers <stiversb@ucsc.edu> wrote:
>> It's always amazing to me the people that have this problem, when
>> it should be pretty simple to debug.
>
> Maybe the FAQ entry should be rewritten?  Once this is over and done
> with and I've fixed my clients, or worked around them, I'll throw
> some text at the FAQ maintainer.  I figure it's only fair.  There
> seem to be many possible quirks that lead to this problem, and I keep
> running into small nuances of differing quirks, but nothing that
> really, in a step by step fashion, for a less-experienced AFS
> administrator, gives black-and-white clear answers.  I come from a
> different side of the fence, and have used NIS+ and NFS in the past.
> For me AFS has been something that Just Works.  This is kind of a
> baptism of fire for me; I apologize for my ignorance.


I had kvno issues when I setup our cell originally.  Its one of those 
things you only fix once and then you know what not to do the next time.

>> When you say that they checked them ... what exactly did they check?
>> Did they compare the kvnos to make sure that they match?
>
> The key files themselves were compared;  I took your, and Christopher
> Clausen's advice, and ran "bos listkeys" against each of our AFS
> servers from a working client, and the results were identical:
>
> unix1% bos listkeys ichabod
> key 1 has cksum 2004690267
> key 3 has cksum 4138398621
> Keys last changed on Fri Sep  1 13:52:20 2006.
> All done.
> unix1% bos listkeys maneki
> key 1 has cksum 2004690267
> key 3 has cksum 4138398621
> Keys last changed on Fri Sep  1 13:52:20 2006.
> All done.
> unix1% bos listkeys elan
> key 1 has cksum 2004690267
> key 3 has cksum 4138398621
> Keys last changed on Fri Sep  1 13:52:14 2006.
> All done.
>
> All of the checksums match correctly.  On one of the broken clients,
> I ran a klist as you suggested, with the  -ef option as Christopher
> Clausen suggested, with the following results:
>
> be-sun33% klist -ef
> Ticket cache: FILE:/tmp/krb5cc_38497_kVaiSO
> Default principal: stiversb@CATS.UCSC.EDU
>
> Valid starting     Expires            Service principal
> 09/10/06 16:01:04  09/11/06 13:16:04 
> krbtgt/CATS.UCSC.EDU@CATS.UCSC.EDU renew until 09/11/06
>         16:01:09, Flags: RI Etype (skey, tkt): DES cbc mode with
> CRC-32, DES cbc mode with CRC-32
> 09/10/06 16:01:12  09/11/06 13:16:04  afs/cats.ucsc.edu@CATS.UCSC.EDU
>         renew until 09/11/06 16:01:09, Flags: RT
>         Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode
> with CRC-32


DES is the proper encryption type for an afs service principal.  (I have 
seen people attempt to use DE3 or RC4-HMAC enc_types in afs keys.  That 
doesn't work at all, yet.)

I'm guessing your non-K5 clients are using a afs@CATS.UCSC.EDU principal 
and not the afs/cats.ucsc.edu@CATS.UCSC.EDU principal that the K5 
clients would see by default.

Does aklog work if you run aklog -524 instead of aklog (or aklog -5)?

You want to use your Kerberos admin interface (kadmin) to examine the 
knvos on:
afs@CATS.UCSC.EDU
afs/cats.ucsc.edu@CATS.UCSC.EDU

Ideally, it would be helpful to check the kvnos on the keytabs used by 
asetkey (or a similar utility) to add the Kerberos keys to the KeyFile.

<<CDC