[OpenAFS] Re: Any budding documentation writers

Russ Allbery rra@stanford.edu
Wed, 03 Mar 2010 11:13:50 -0800

Simon Wilkinson <sxw@inf.ed.ac.uk> writes:

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

I'm apparently less optimistic than you are about what additional
workarounds may be required in the future with particular GSSAPI
implementations for problems that we can't forsee at this point.  But we
can cross that bridge when we come to it.

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

Er, many OpenAFS users do not have simple control over their Kerberos
configuration without duplicating it and setting environment variables.
And for debugging purposes, it's obnoxious to have to make a separate copy
of krb5.conf and mess around with the environment variable whose name I
always put the wrong number of underscores in, rather than just using a
command-line flag.

I would rather not drop this functionality.

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

It's been the default klog in Debian since May of 2008, and anecdotal
reports that I've received indicate that use of klog is way more
widespread than one might think it 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.

Yes, but that's only the case for AFS users who otherwise use Kerberos.
This is not the case for a surprising number of AFS users.  They don't use
Kerberos for anything other than AFS and don't even know it exists.  They
just want to authenticate to AFS, and they're used to having a single
command to do that.

Now, of course, there are other ways of solving that problem, such as a
simple shell script wrapper around kinit and aklog, but note that any such
wrapper is going to be making the same assumptions as klog.krb5 does
without being quite as convenient and straightforward.

Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>