Forum

Hiawatha version: 6.17
Operating System: Ubuntu 9.04 Server

I would like Hiawatha has WebDAV feature one day!

I'm looking at supporting SVN at the moment. This might require a subset of webdav. But, no promisses. I'm just looking at it.

Hugo Leisink,

Thanks for your concern.

Samiux

Hugo,

Just a bit of context about the request from the point of view of the administrator of a small SME network. Windows users (sales) can access the internal network using an OpenVPN road warrior setup. Through the VPN, they can connect to the company file server.

After considering using CIFS and offline mode, it turned out that Webdav (i.e. HTTP) is a much more efficient protocol that CIFS in particular when used with a proper client like "webdrive" for Windows. This program uses the laptops hard drive as a cache and use file close to transmit semantics to minimize traffic. This is very useful for our company which has only access to a slow ADSL uplink with no possibility to upgrade to something better. The cache can also go offline so as long as the files are not directly shared between users, this works very well.

On the server side, Apache has a mod_dav module which works well but has an important problem. It does access the files using the user id which makes unusable with file system quotas. When relying on user discipline as a way to limit the volume of data also proved to be a dead end, file system quotas proved to a reliable solution. Thanks to quotas the volume of data to be backed up remains within what the company can afford.

In the end, the company ended up using the preexisting Apache server. A PHP webdav script along with some suphp magic were glued together to serve the user files. This is very hackish and the PHP processes often fail with a segmentation fault. Instead of suphp, maybe PHP and mod_fcgi would be more reliable. However as users do not seam to be affected by it the hackish solution stuck.

Hiawatha is much lighter that Apache. The source is easy to understand. The focus on security means that the userid change would probably be done in a sane way. Also a light server means that a silent server can be used which is really important when employees share the same room with the servers. Another perk of working in a small company...

The only missing piece except for webdav is authentication through the central authentication server (kerberos). Checking "httpauth.c" shows that replacing the file backend by a couple of calls to SASL with so little effort that it can be considered a site specific customization. If you are curious about how to do it, have a look at Mod Authn SASL [sourceforge.net] for an example in the context of Apache.

Thank you for taking the time to work on Hiawatha.

I have no idea what inpact inplementing SASL has on Hiawatha. But I don't want Hiawatha to become as bloated as Apache. I'll take a lookt at it. What you can do in the meantime is export the users and their passwords from the SASL backend to a .htpasswd like textfile which Hiawatha can use.

About webdav: webdav is big. It's on my mind to implement it for Hiawatha, but that will take quite some time. Since I became a dad 3 months ago, my spare time became a rare thing. My plan is to include SVN support in Hiawatha for the next release, which might require a subset of webdav. But I still have to dig into that one.

Hugo,

In case you wonder about how to do the privilege separation with as little overhead as possible, there is a
collection of patches [privsep.org] for Apache. The trick is to communicate with a root process that distribute open file descriptors using UNIX pipes.

Hugo,

I have been experimenting with the privsep patch set for Apache. Up to now, it works nicely. Files are accessed using the permissions of the account authenticated by Apache. It uses PAM which is a bit heavy. For the sake of experimentation, I replaced the calls to PAM to calls to SASL. In the end, the code is simpler: one call to initialize the library, one call to check the password and one call to free the resources. So you really do not need to worry about SASL, I just suggested it because I thought it would make your life easier. If it is not the case then never-mind, I can maintain my own patch if needed.

Then regarding Webdav, the protocol has been extended and improved during the years. Most of it is not very useful because the existing clients do not support it. I think that the most difficult part is the handling of attributes. The apache implementation uses a binary database. Once the database is there the "locks" are not a design problem any more. The people that made the Apache privilege separation patch set also thought of using extended attributes [privsep.org] instead of a database. Anyhow, I assume that you will use the subversion library to access the datastore ("fsfs" or "bdb"). This means pulling in the Berkeley Database through a shared library.

Finally, as far as the dad story goes, let me just say "proficiat".

Oh and by the way, running a few "ldd" on my system show that the subversion libraries link to SASL.

Webdav would be a great thing as it would allow to use XMarks (bookmarks sync) with Hiawatha, this is what prevents me from switching to Hiawatha for the moment.