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

[Bill Stivers]

Thanks Ken and Christopher:

>
> So, I am confused a bit here.  When you say "working with internal
> k5/k4 bits" ... what does that mean?  You're using klog?  Or the 524
> translator?  It sounds like systems that use the "internal" bits
> work fine, but ones that use pure k5 don't.
>

That would be correct;  it's the pure k5 clients that are not working  
correctly.  The solaris 8 clients that are working are running a  
login sequence that gets a k5 ticket from pam, pre-emptively destroys  
any old k4 tickets lying around, uses krb524init to generate a k4  
tgt, and then runs a different aklog, potentially as old as the  
transarc one, which dutifully creates a proper token.

The only clients I'm having this issue on are ones that were  
configured to use exclusively k5, without any form of ticket  
translation and without getting additional k4 tickets.


>
> 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.


>
> 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


Kerberos 4 ticket cache: /tmp/tkt38497
klist: You have no tickets cached

The output of kvno of the afs-related k5 principal is:

be-sun33% kvno afs/cats.ucsc.edu@CATS.UCSC.EDU
afs/cats.ucsc.edu@CATS.UCSC.EDU: kvno = 1

I'd assume, potentially incorrectly, that the kvno of 1 should  
correspond to a key of type 1 from the bos output, and, ergo, stuff  
should Just Work.

Do you see anything obviously, flagrantly amiss in this output?

Thanks once again!

---
Bill Stivers
IC Unix Lab and Systems Administrator
University of California at Santa Cruz
stiversb@ucsc.edu
v) 831-459-2472
f) 831-459-2914