[OpenAFS] AFS vs DAV
John Rudd
jrudd@ucsc.edu
Fri, 16 Jan 2004 12:33:22 -0800
Noel Burton-Krahn wrote:
>
> Hi Dan,
>
> I'm not a university, but I use both DAV and AFS. DAV is useful which you
> don't want to install an AFS client, but it only allows file upload/download
> like FTP. You can't edit files directly with my DAV client (Windows
> Explorer) or server (Apache's mod_dav). DAV has no support cfor changing
> AFS permissions either. AFS requires client software, but it provides a
> real shared network drive.
>
Whether or not you can edit files with WebDAV sort of depends upon the
view of things and the DAV client.
WebDAV supports file locking (IIRC), so the WebDAV client can, for
example, lock the file, download it, modify it, upload a new copy, and
then unlock the file. It's not direct editing of the file within the
WebDAV protocol, but it is editing of the file through a WebDAV service.
There are also WebDAV based filesystems out there, including on Mac OS X
(through Finder's "Connect" feature), and with Windows, I think you use
the "web folders" feature (so I'm not sure what Xythos is trying to
accomplish with their client software -- it's only targeted at Windows,
yet Windows has support for that built in). Linux has a DavFS based
project, and I believe there was such a project at Stanford for Solaris
as well.
For WebDAV vs AFS:
If it can work, and I don't know how well WebDAV clients support for
this might be, you might be able to use some form of reverse web cache
or redirection system to have multiple web servers on the back end
serving your WebDAV file system. Some of these might be sharing the
same data for redundancy and load balancing, and some of them might be
only sharing parts of the data (so that you can make independent file
stores look like one service). This would compare to a couple of AFS's
more compelling features.
What WebDAV, as a file service in comparison to AFS, doesn't directly
have is:
1) on the client side, I don't know of anything that has been done to
make sessions have any sort of PAG like attributes (where different URLs
would get mounted in a way that doesn't give every client side user the
same set of authorizations (the authorizations of the person who
performed the mount). For single user systems, this isn't a big deal,
but it is a HUGE deal for multi- user systems.
2) I don't think, but I don't recall, if the apache kerberos
authentication module allows you to authenticate via tickets, it just
gives you success or failure on your supplied password. If something
like a khttps protocol could be crafted, that would be great ... but
until then, it seems like WebDAV pretty much requires you to use
password authentication. Though, I think someone here mentioned
something about using cookies as a means of some sort of single-sign-on,
but I don't recall exactly (our email server had a huge problem this
week, and I lost our entire WebDAV on AFS discussion ... and haven't had
time to fish it out of hte list archives).
I wouldn't want to replace AFS with WebDAV until these two are resolved
... plus, I would want to see vendor* support (including the above
features) for WebDAV as a file system service for a few more platforms
(Solaris, FreeBSD, and AIX ... plus having those features work into the
client side of Windows and Mac OS X). Until then, I only really think
of WebDAV file service as an alternative to distributing AFS clients to
single user workstations.
(* vendor support from Solaris and AIX ... for FreeBSD, actual support
from the FreeBSD project)
For example, with WebDAV over AFS, I can tell people what URL to use in
Finder Connect or Windows Web Folders that would let them access their
home directory. I don't have to distribute binaries, I don't have to
develop a "support AFS users on their own machines" arm of our helpdesk,
etc.
With direct AFS I have to give them AFS, Kerberos, and aklog binaries, I
have to come up with a support infrastructure for any problems that
might come up in their use or installation of those binaries, etc. This
approach has a lot more support overhead.