[OpenAFS] Re: Any budding documentation writers
Wed, 3 Mar 2010 19:01:37 +0000
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
> at least documenting things like how you make aklog use a different
> 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
> 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
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
> I'm all in favor of the core code being mechanism-agnostic, but I
> 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
> 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.