[OpenAFS] Some questions about the future of OpenAFS

[Tim Gaastra]

I've been reading the list with interest over the past few weeks
(particularly the Home Directory discussion ne near-flamewar and the
talk about IBM withdrawing AFS as a product) and its got me to thinking
about a few questions since OpenAFS appears headed towards becoming the
reference implementation of AFS...

I apologize if this is retread territory...

1) Is there a time table for converting AFS to be a Kerberos V5 service?
(I.E., no need for krb524d, no need to use asetkey to grab the Key from
a keytab into the Keyfile but instead just using a keytab like other V5
services, etc.)

2) If such a v5 conversion occurs, could AFS tokens be done away with
completely and authorization take place purely with Kerberos
tickets/principals? (No need for aklog, etc).. I personally would like
the ptserver to just be about assigning principals to groups and
defining what principals have what privileges rather than it being
another user database (I do agree with the sentiment that a minimal
number of user databases is a good thing).

3) What are the moral and technical objections to tying some of the
databases (the ptserver, mostly, obviously this isn't the best idea for
the VLDB) to a kerberized version of LDAP (by which I mean an LDAP that
authenticates access via Kerberos)... "Why would anyone want to do
this?" Well, the biggest reasons I can come up with is centralization of
administration, the use of common tools to be able to build and maintain
the database, and general openness of access. I already use LDAP for my
nss services, it would be nice if I could build off that in the future.
For instance, if quarterly, if I worked in a university (as I once did),
I have to change the 200-300 odd people who belong to the "operating
systems project" group to give them access to the AFS volume(s) where
they are to store their OS class projects, it would be nice to be to use
Perl or the like to build the LDIF file which ties their Kerberos
principals to that group, dump it into the LDAP based ptserver database
(after properly authenicating to it as a valid AFS administrator, of
course), etc. Yes, I know it could be done scriptwise already, but I
like "neat" solutions (note the quotes there).

I definitely like some of the ideas of AFS, and I DO understand that it
needs to be handled differently from other "network available
filesystems" (since the same is true of all such NAFs... Coda is
different from NFS is different from SMB/CIFS etc) but I'm just
interested in the direction that people see it going in the future now.