[OpenAFS] AFS clients for OSX/Darwin
Mon, 24 Apr 2006 14:47:44 -0400
On Friday, April 21, 2006 01:02:57 PM -0700 Ben Poliakoff <firstname.lastname@example.org>
> 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
(*) 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) <email@example.com>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA