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

[Matt Peterson]

Hi, 

I have posted to this list a couple times, but for the most part I have been 
a silent observer.  

I have been interested in OpenAFS since it was first released, but I have not 
been able to really evaluate the implementation until lately.  Having spent 
countless hours installing and using OpenAFS I have made the general 
observation that AFS would be a superior filesystem to NFS and would an 
attractive replacement for Linux users if it were not for the following:

   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.  

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

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

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

The purpose of this email is not to point out the problems of OpenAFS, but 
rather to get some information about the plans developers have to improve the 
implementation -- specifically the Linux implementation.  I would also be 
interested in some statement about how willing OpenAFS is to the possiblity 
of a development branch of CVS that would allow more agressive development 
that what is currently taking place.

By agressive development, I mean how much interest would there be in the 
following:

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

   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.

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

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

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?

Regards,

-- 
Matt Peterson
Sr. Software Engineer
Caldera, Inc
matt@caldera.com