[OpenAFS] AFS clients for OSX/Darwin

[Jeffrey Hutzelman]

On Friday, April 21, 2006 01:02:57 PM -0700 Ben Poliakoff <benp@reed.edu> 
wrote:

> Is anyone willing to discuss the relative merits and failings of Arla
> and OpenAFS on OSX (and the future of AFS for OSX)?  I know this list
> is specific to OpenAFS, but I don't see an obvious forum or list for
> discussing non-vendor specific AFS client issues (given that the
> info-afs list seems to be dormant).  I'd be very happy to take a
> redirect if anyone knows of a better forum for these topics.

Well, info-afs would have been the place, once upon a time.  But as you 
noticed, it's basically defunct.  IBM discontinued the list without much 
advance notice to anyone, and attempts to move it elsewhere were not very 
successful.  So, this is probably as good a place as any.


> My casual investigations over the past couple of years seem to indicate
> that Arla for OSX presents some distinct advantages over OpenAFS.  The
> two most notable ones are:
>
>     - it seems to handle IP address changes (and transitions from
>       wired to wireless ethernet) more gracefully than OpenAFS
>
>     - it has some (albeit primitive) Finder support for ACL display/
>       editing whereas OpenAFS does not
>
> Is anyone aware of whether or not there are plans for the OpenAFS port
> for OSX/Darwin to address these issues?
>
> The first issue is big for mobile clients (laptops). I've never been
> able to configure the OpenAFS client for OSX to be as "resiliant" to
> changes in network connectivity (-dynroot and -fakestat, while useful,
> don't address the issue).  With Arla or the Windows client one can
> unplug a wired ethernet connection, and continue operations via an
> available wireless connection.  When I try that with the OpenAFS client
> for OSX I get timeouts and spinning beachballs in the Finder.

I suspect what you're seeing may be due in part to problems the fileserver 
has in dealing with clients that change addresses under certain 
circumstances.  I'm not making any promises, but you _may_ find this gets 
better if you upgrade fileservers to 1.4.1 or newer.

Also, Derrick is right; for a mobile machine you really want -dynroot and 
-fakestat-all, especially on MacOS.


> Neither OpenAFS or Arla seem to have any sort of dynamic trigger for
> "authentication upon access" (i.e. launching an authentication dialog
> when accessing files under /afs).

Right.  That would be difficult, because (as someone mentioned) it's hard 
to tell when you want authenticated vs unauthenticated access.  Certainly 
having a dialog box pop up every time some process failed to access a file 
in AFS would be quite disruptive, both to the user whose attention is being 
demanded(*) and to processes that are trying to accomplish things in the 
background and now need to wait for a user who isn't there or is busy with 
something else.




(*) A well-designed system should never demand that the user pay attention 
to what the computer wants to do instead of to what the user wants to do. 
Computers do what users tell them, not the other way around.


> My Mac heavy institution is investigating the use of AFS as the primary
> network file service for end users (replacing netatalk and samba).  With
> the proper amount of love/funding Arla *or* OpenAFS for OSX could be
> very pleasant for the end user!  The Windows OpenAFS client is really
> excellent with regard to the aformentioned issues, it would be great for
> the OSX client to get some feature parity.

Windows support has received a lot of attention over the past couple of 
years, in part because people have been paying for it, and in part because 
we have an interested developer who contributes a large fraction of his 
time to it.  MacOS support has received less attention because there has 
been less interest in paying people to work on it, and less time has been 
volunteered (either due to lack of interest or lack of time).  I won't 
presume to speak for the Arla project, but I imagine the situation there is 
the same -- both projects are made up primarily of volunteers who are 
either not paid at all to work on AFS or can only provide the limited 
amount of time their employers can spare.

If your organization is interested in better support for MacOS, the best 
way to achieve that is to contribute some of your own resources, either by 
using some of your own developer time or paying others to work on it.  And 
no, I'm not asking for anyone to pay _me_ to do this work, but if 
interested parties contact me offline I will be happy to try to put you in 
touch with qualified developers who might be available.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA