[OpenAFS-devel] A few questions about the current Linux implementation of the AFS client

[Derek Atkins]

Hi,

Matt Peterson <matt@caldera.com> writes:

>    1 - AFS Server installation is a real pain.  Granted, there is very good
>        documentation, but the process is lengthy, complex, unautomated and  
>        frought with pitfalls.  

There are some scripts that were just committed to CVS that should
help improve this.

>    2 - The AFS management tools (kas, vos, pts, fs, and friends) are foriegn
>        to and unwelcome to most Unix users.  

Unfortunately the standard Unix tools are not generic enough to be
able to handle AFS.  For example, how would you tell a user to set
"a" (admin) access on a directory using chmod?

Another thing to keep in mind is that the AFS acls are per-directory,
not per file.

>    3 - The AFS Client implementation on Linux is poorly designed and very
>        unstable to the point that reboots become common place.

I'm not sure what you mean by "poorly designed".  The client on Linux
is pretty much the exact same code as the client on every other
platform.  The only difference are the specific hooks into the Linux
kernel (vs.  Solaris, Irix, Tru64, AIX, BSD, etc).  OpenAFS works on
all the platforms with a common source tree.  This is considered a
feature.

>    4 - Marginal use and support PAM based authentication, and session and  
>        management, and password

In reality, people should be using krb5, not AFS's aklog.  Therefore
the only real PAM management that needs to happen is pretty much
pam_session to setup PAGs and obtain/destroy tokens.  One solution,
pam_openafs_session, will do this by calling out to aklog.  There are
other solutions as well, such afs pam_afs_krb5 (or is it pam_krb5_afs?
I forget) which basically does the same by calling the library
functions directly instead of the external application.

>    1 - CVS repository and access for developers willing to work on real
>        installation and setup functionality for the server components.  

Anonymous CVS access is there.  Send patches to openafs-bugs,
openafs-devel, openafs-gatekeepers as appropriate.  I'm sure that such
patches, so long as they don't destroy the portability to other OSes,
would be accepted (but I cannot speak for the gatekeepers).

>    2 - CVS repository and access for AFS enhanced replacements (or wrappers) 
>        for GNU binutils (ls, chown, chmod, df du, etc).   What about KDE 
>        KPropsDialog Plugin that offers AFS specific "right click" 
>        functionality in KDE Konqueror.

As I said before, I'm not sure that this is necessarily the right
thing to do.. The AFS ACL system is much finer grained that standard
Unix permissions, and stored on a per-directory vs. per-file basis.  I
reiterate my question about "how would you set admin access using
chmod"?

If you're going to have to change the UI for chmod, you might as well
use 'fs setacl'.  Perhaps a wrapper around 'fs setacl' would be
appropriate.

A KPropsDialog plugin for AFS specific functionality would be a REALLY
good thing.  Something for Gnome would be just as welcome.

Hint #1: special-case /afs so you don't go walking off into
never-never land.

>    3 - Major revamp of the Linux Client to replace the "black hole syscall" 	
>        design with a more workable design that uses kernel_thread() instead
>        of processes that are buried in syscalls.  AFS is started by mount and
>        stopped with umount like every other sane filesystem.  (There would be 
>        no need for a /etc/rc.d/init.d/afs startup script).  Dynamic 
>        configuration could be supplied via mount parameters. The proc would
>        be used to provide status and additional runtime configuration.  (i.e
>        cat /proc/fs/afs/CellSrvDB or cat /usr/vice/etc/CellSrvDB > 
>        /proc/fs/afs/CellSrvDB).

Unfortunately afsd does a lot more setup than just 'mount /afs' and
'umount /afs'.  It creates the cache directory hierachy, creates all
the cache files, and then passes all this information down into the
kernel.  There is no way to do all this just by "mount".  You need
some other piece to push the information into the kernel.

Another thing is that with afsdb rr lookups for dynamic cell location,
you need a user-space upcall method in order to perform DNS lookups.
You certainly don't want the kernel to have to know about DNS itself.

Third, the majority of the code still needs to be portable to other
OSes.  There are only so many linux-specific "hacks" that I believe
will be allowed into the mainline sources.  However, don't quote me,
I'm not a gatekeeper.

I do think you're missing the point here, however.  The "black-hole
syscall" design isn't really a major flaw with AFS.  It works, and it
works fine.  It is, in many ways, doing the exact same thing as
kernel_thread() except it's being done by a push method instead of a
pull method.  It's more portable.  And this is a Good Thing.

>    4 - PAM code could be modified to provide better authentiction, password
>        and session control.

This would certainly be a good thing.  However, keep in mind that
KAServer should, in the longer term, go away.  Be sure you're looking
at the krb5 integration, because that's the more interesting problem.

> Is there interest in maintaining this type of development on OpenAFS, or is 
> OpenAFS in "maintenance mode" only?  If there is interest, how does one go 
> about getting involved?

I think there is definite forward progress on OpenAFS development.
Some of the problems you've pointed out are "known" problems, but
nobody has had the time or initiative to work on them.  However I
would argue that changing how afs/afsd works for Linux is not a good
use of your time.  Changing the Linux-specific interfaces to better
hook into the Linux kernel would DEFINITELY be a good use (e.g. use
the kernel inode table instead of creating matching inodes in AFS).
Just my humble opinion, mind you.

In the end, I would certainly love to see AFS included in major linux
distributions.  Moving towards that is a good goal.

> Regards,

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available