[OpenAFS-devel] More on aklog

[Derrick J Brashear]

On Tue, 12 Oct 2004, Ken Hornstein wrote:

> I think that's a bit of a red herring.  If you had a V4 infrastructure,
> you'd never create a principal named "firstname.lastname".  If you were
> V5-only, then you would expect that that the name would be simply
> work in PTS, because you'd be depending on it working (and you'd be
> REALLY screwed if you switched to V5 tickets from krb524d).  We have
> a user who's surname is root as well, so I understand the possibilities,
> but it's my feeling that if you didn't know enough about Kerberos to
> understand this problem, you'd likely wouldn't know what an instance
> _is_, and you wouldn't be creating principals with instances in them.

Well, I suppose we can add a "shoot me in the foot" configure switch or 
something, but it's important for people to understand in that case that 
crossrealm users will have names allocated by that other realm's 
administration. It may or may not be the same administrators, with the 
same username policy.

>>> So far it's only seemed to cause
>>> people problems,
>>
>> Because the people who haven't had any problems are busily reporting the
>> problems they don't have, I suppose...
>
> Not sure I follow that.

If people have problems, they whine. If people have no problems, you never 
hear from them. Why "customer satisfaction surveys" don't reflect reality.

> Sure, it's all ancedotal.  If someone wants to pipe up and say, "boy,
> this code really saved my bacon", (and it's _not_ you :-) ) I'll shut
> up.  It's hard to do a survey for this sort of thing.

Yes, exactly.

> - There's an inconsistancy in how the AFS server and krb524d handle V5
>  principal names.  You could argue that krb524d is wrong; I'd even be
>  inclined to agree with you.  But the fact that they _don't agree_ is
>  a problem.  I think one of them should change so that people don't
>  get bitten by this in the future.

Ok, I think you hit on the crux of the issue here. I suppose this is a 
problem with not shipping all portions of this system ourselves?

>> Hey, I have a rotten idea, send a patch with aklog and some configure
>> gunk, and slip in the reversion of this "change" with it.
>
> Would you accept a patch to at least log the problem when servers
> encounter it?  That sure would have helped us in tracking down the
> problem quicker, at least.  I promise I won't commit it until after I
> put aklog in the openafs tree :-)

that sounds reasonable