[OpenAFS] Re: Any budding documentation writers

[Simon Wilkinson]

On 3 Mar 2010, at 18:46, Russ Allbery wrote:
> In practice, at least 95% of our users are going to be using Kerberos.
> Making the common case go more smoothly is a good idea, and that  
> includes
> at least documenting things like how you make aklog use a different  
> ticket
> cache and possibly some Kerberos-specific glue if anything like the
> allow_weak_crypto case comes up down the road.  I think it's also  
> fairly
> important to support the historic klog interface, at least in the near
> term and for the common case, to avoid confusing users who are used  
> to it,
> so one of the first things I'd do in that world is write klog.krb5 for
> rxgk and then ask for it to be included in the distribution.

aklog will work in exactly the same way as aklog always has. We don't  
need any explicit Kerberos knowledge there, because we're just another  
GSSAPI application at that point. If something breaks us, then it will  
also break every other GSSAPI application under the sun - hacks like  
allow_weak_crypto won't be necessary, because we're doing things  
properly.

aklog doesn't currently have a mechanism to allow ticket cache  
selection (beyond the usual environment variables stunt), so that  
shouldn't be an issue either. The only Kerberos specific configuration  
for aklog currently is which realm to use to get tickets for a  
particular cell. The way that rxgk does cell principal naming means  
that this can become part of your Kerberos configuration (where it  
belongs), rather than part of the aklog command line.

klog.krb5 is another question. It's actually a relatively new tool (it  
landed in master in 2006, and I pulled it up to 1.4.x in late 2007 -  
it's only been available since 1.4.7), and I'm really not sure how  
widespread the usage is. If we want to move people off kaserver, then  
I guess it has its value, but I'm keen on pushing 'aklog' as being the  
primary way you authentication to afs, not least because it gives you  
single signon.

> I'm all in favor of the core code being mechanism-agnostic, but I  
> don't
> think we should extend that line to all of the userspace tools when we
> know what mechanisms many of our users will be using and can make  
> their
> lives easier and the transition less abrupt.

I'm really keen on being able to build tools which can switch between  
GSSAPI mechanisms at the whim of the dynamic linker. That's what we  
managed with the OpenSSH client, and I can't see any reason not to do  
it here. It makes it _much_ easier for folks who want to live in a  
multiple mechanism world.

S.