Posted by simonw on Fri 4 Nov 2005 at 12:11
Setting up WebDAV (Web based Distributed Authoring and Versioning) was covered briefly previously in an article on SVN. But this didn't stop a plea from a member of DCGLUG for an idiots guide.
WebDAV is a way of making parts of your webserver writable to certain clients. There are obvious reasons why you might want to do this, such as making it easy to update a website, and less obvious reasons, such as sharing Calendar data, or sychronising your bookmarks in Firefox, or to supply a small amount of password protected web space for people to share documents.
Whilst it is called "Authoring and Versioning" it seems the versioning is still arriving in the Apache2 mod-dav. The "Authoring" in this context replaces FTP, and effectively adds some basic file system type behaviour, such as locking. The main reasons to use it are; firewall evasion (port 80 is nearly always open), avoiding the complexities of FTP, or because it makes sense over other solutions for some purpose. As such it is an enabling technology, WebDAV doesn't of itself do much that is new or exciting, but it will. One strong point is the easy integration with Apache 2, which means you can use other Apache directives to set up neat solutions, such as editing scripts on a website.
The example will create a WebDAV enabled directory, on the "www.example.com" website, referenced by "http://www.example.com/webdav/". The example was worked through on Debian Sid, but works "as is" under Debian Sarge.
First make sure Apache 2 is installed and the optional DAV related modules enabled;
apt-get install apache2 a2enmod dav_fs a2enmod dav
If a2enmod or a2ensite are new to you, read Chris's introduction.
Then you need to rustle up a virtual host if you don't already have one, I created a vanilla virtual host by copying "/etc/apache2/sites-available/default" and editting it down till it reads as follows;
cat /etc/apache2/sites-available/example.com
<VirtualHost *>
ServerAdmin webmaster@example.com
ServerName example.com
ServerAlias www.example.com
DocumentRoot /home/srw/example.com
<Directory /home/srw/example.com>
Options Indexes MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
</VirtualHost>
Then remember to create the directory, and give ownership to the Apache user. Note editting sites outside of WebDAV may alter file ownership and thus break access via WebDAV.
mkdir /home/srw/example.com chown www-data /home/srw/example.com a2ensite example.com apache2ctl configtest /etc/init.d/apache2 reload
And a quick check using a browser or wget showed my empty directory index at "http://www.example.com/".
Now we need to set up an authentication scheme, because we don't want just anyone editting our website. I will use "Digest Authentication", which may muddle some old clients but ensure passwords aren't sent in plain text across the network, the alternative "Basic Authentication" is explained in detail in the Apache documentation.
Enable the module, and create a password file.
a2enmod auth_digest htdigest -c /home/srw/digest-password webdav-example myuser
After the "htdigest" you'; be prompted to enter myuser's password.
Now we add the "WebDAV" section to the virtual host.
cat /etc/apache2/sites-available/example.com
<VirtualHost *>
ServerAdmin webmaster@example.com
ServerName example.com
ServerAlias www.example.com
DocumentRoot /home/srw/example.com
<Directory /home/srw/example.com>
Options Indexes MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
# Note Alias goes to our DocumentRoot.
Alias /webdav /home/srw/example.com
# But we apply different settings
<Location /webdav>
DAV On
AuthType Digest
AuthName "webdav-example"
AuthDigestFile /home/srw/digest-password
Require valid-user
</Location>
</VirtualHost>
apache2ctl configtest
(NB: apache2ctl is quite capable of accepting very broken authentication settings, such as if you have "AuthUserFile" instead of "AuthDigestFile". It is also quite capable of ignoring errors in other extensions to the core of Apache, like mod-perl, but that is for another article).
/etc/init.d/apache2 reload
Now in principal we can edit "example.com" using WebDAV, but do we have a client? Debian has "cadaver" which is a simple(?) command line WebDAV client, which is very handy for testing things.
apt-get install cadaver cadaver http://www.example.com/webdav/
Once in you can use a selection of fairly normal shell commands, and even "tab completion" of file names, whilst "edit filename" will invoke your editor of choice.
We could have made a simpler configuration, by using a "<Directory>" instead of a "<Location>" directive, without the Alias, and created a simple filestore for one or more users.
I'm still uncovering the mysteries of cadaver and WebDAV, and have yet to deploy it in anger, although I use it to sync my bookmarks, and we are experimenting at work.
Other patterns of configuration can be applied, as you can use "<Limit>" to only allow certain WebDAV operations against a directory, this means you don't always need two ways to refer to the same directory. Although this is needed if in one view the files are handled differently, such as scripts which are usually executed, then you have to override that handler in the WebDAV view.
I also found that the Indexes (such as index.html) may have a default lock against them. Try something like this if it happens to you;
cadaver http://www.example.com/webdav/ Authentication required for webdav-example on server `www.example.com': Username: myuser Password: dav:/webdav/> edit index.html Locking `index.html': failed: 423 Locked dav:/webdav/> discover index.html Discovering locks on `index.html': Lock token <opaquelocktoken:28cfc4e4-9c04-0410-bed0-c546ac2f7a25>: Depth 0 on `http://www.example.com/webdav/index.html' Scope: exclusive Type: write Timeout: infinite Owner: (none) dav:/webdav/> unlock index.html Unlocking `index.html':Enter locktoken: opaquelocktoken:28cfc4e4-9c04-0410-bed0-c546ac2f7a25 succeeded. dav:/webdav/> edit html
The desirable client, at least for those who find FTP challenging, is a filesystem client. But as you'll see from my question earlier, getting some of these clients to work nicely can be more challenging than perhaps is immediately desirable. Although there are fairly simple workarounds for most of these issues. More on the Debian WebDAV clients when I get more time to play.
This article can be found online at the Debian Administration website at the following bookmarkable URL:
This article is copyright 2005 simonw - please ask for permission to republish or translate.