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.
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
