This document describes setting up WebDAV on Apache 2 on a Red Hat 9 system. It assumes that apache is more or less unmodified - if you've made changes, adjust accordingly.
On Red Hat 9, httpd-2.0x includes the apache WebDAV modules. Ensure httpd-2.0 is installed:
# rpm -qa | grep
Just checking to make sure httpd-2.0 provides mod_dav:
# rpm -q
--provides httpd | grep dav
The default Red Hat apache configuration file (/etc/httpd/conf/httpd.conf) should contain directives supporting WebDav. If you run into problems, see http://httpd.apache.org/docs-2.0/mod/mod_dav.html and compare this to the contents of your httpd.conf.
In this document, we're going to use basic authentication over SSL - so ensure that openssl and mod_ssl are installed:
# rpm -qa | grep
If you haven't configured SSL on your server yet, create an SSL certificate for your host. Red Hat 9 has a make file that expedites this process.
Go to the directory containing the make file and create a certificate and key file (.pem) for your host. You can name it [anything].pem; naming it after the host seems handy:
# cd /etc/httpd/conf
# make www.myhost.org.pem
umask 77 ; \
PEM1=`/bin/mktemp /tmp/openssl.XXXXXX` ; \
PEM2=`/bin/mktemp /tmp/openssl.XXXXXX` ; \
/usr/bin/openssl req -newkey rsa:1024 -keyout $PEM1 -nodes -x509 -days 365 -out $PEM2 ; \
cat $PEM1 > www.myhost.org.pem ; \
echo "" >> www.myhost.org.pem ; \
cat $PEM2 >> www.myhost.org.pem ; \
rm -f $PEM1 $PEM2
Generating a 1024 bit RSA private key
writing new private key to '/tmp/openssl.c7ucXb'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:CT
Locality Name (eg, city) [Newbury]:HappyTown
Organization Name (eg, company) [My Company Ltd]:Happiness
Organizational Unit Name (eg, section) :Happy Department
Common Name (eg, your name or your server's hostname) :www.myhost.org
Email Address :email@example.com
Move the certificate to the certificate directory:
# mv /etc/httpd/conf/www.myhost.org.pem /etc/httpd/conf/ssl.crt/
Indicate the location of the certificate in apache's SSL configuration file, /etc/httpd/conf.d/ssl.conf. You don't need the default SSLCertificateFile and SSLCertificateKeyFile directives, so comment them out by putting a # at the beginning of those lines. Then add an SSLCertificateFile directive that points to your new certificate:
An SSLCertificateKeyFile directive isn't necessary since the key is contained along with the cert in .pem files.
Start (or restart) apache:
# service httpd start
If the service fails to start, check the log files in /var/log/httpd/ for clues.
Assuming apache starts, access it over SSL with a web browser:
Since you're using a self-signed certificate, you'll probably get a warning stating that it's certified by an unknown authority - that's OK.
You must create a directory on the server where apache will keep files stored by WebDAV (each user will have a subdirectory in this directory). The webdav directory must belong to the apache service account. For Red Hat 9, this account is probably "apache". If apache is running you can determine the account by checking the list of running processes:
# ps axu | grep httpd
root 1262 0.0 0.0 81048 884 ? S Jan06 0:42 /usr/sbin/httpd -
apache 26102 0.0 0.2 82524 2380 ? S Jan29 0:00 /usr/sbin/httpd -
apache 26103 0.0 0.2 82528 2392 ? S Jan29 0:00 /usr/sbin/httpd -
apache 26104 0.0 0.2 82528 2896 ? S Jan29 0:00 /usr/sbin/httpd -
apache 26105 0.0 0.2 82528 2400 ? S Jan29 0:00 /usr/sbin/httpd -
apache 26106 0.0 0.2 82528 2432 ? S Jan29 0:00 /usr/sbin/httpd -
apache 26107 0.0 0.2 82524 2372 ? S Jan29 0:00 /usr/sbin/httpd -
apache 26108 0.0 0.2 82524 2424 ? S Jan29 0:00 /usr/sbin/httpd -
apache 26109 0.0 0.2 82524 2404 ? S Jan29 0:00 /usr/sbin/httpd -
root 32025 0.0 0.0 1740 596 pts/0 S 03:26 0:00 grep httpd
Looks like it's "apache" (first column). You can also check the apache configuration file for the "User" and "Group" statements (filtering out comments):
# grep "User
" /etc/httpd/conf/httpd.conf | grep -v ^#
# grep "Group " /etc/httpd/conf/httpd.conf | grep -v ^#
We will use /var/www/webdav as the WebDAV directory:
# mkdir /var/www/webdav
This is outside of apache's document root, var/www/html. Later we will use an Alias directive in ssl.conf to tell apache where to find it.
Change ownership and make the webdav directory readable by the apache service account:
# chown root:apache /var/www/webdav
# chmod 750 /var/www/webdav
We'll come back to this directory and create subdirectories for individual users later.
There are several ways apache can authenticate users. In this document we'll use htpasswd to create a user authentication file named passwd.dav.
Create a place to put passwd.dav and set permissions so that only the apache service account can read it:
# mkdir /etc/httpd/passwd
# chown root:apache /etc/httpd/passwd
# chmod 750 /etc/httpd/passwd
Now use htpasswd to create the password file and add our first user:
# htpasswd -c /etc/httpd/passwd/passwd.dav flacco
Re-type new password:
Adding password for user flacco
NOTE - use the -c flag to htpasswd only the first time you use it - this creates the password file. If you use -c subsequently, you will overwrite the password file (and any existing passwords).
Set ownership and permissions so that only the apache service account can read it:
# chown root:apache /etc/httpd/passwd/passwd.dav
# chmod 640 /etc/httpd/passwd/passwd.dav
Create a directory for our user (flacco) to store his files via webdav:
# mkdir /var/www/webdav/flacco
Change ownership and permissions on this directory so that it's accessible only by the apache service account:
# chown apache:apache /var/www/webdav/flacco
# chmod 750 /var/www/webdav/flacco
NOTE - mod_dav assumes that it will have exclusive access to files accessed via WebDAV; allowing users to access/modify these files via other means is discouraged. Read more here: http://www.webdav.org/mod_dav/
In apache's SSL config file, /etc/httpd/conf.d/ssl.conf:
Somewhere between <VirtualHost _default_:443> and </VirtualHost>, add the following:
Alias /webdav/ "/var/www/webdav/" <Directory /var/www/webdav> DAV on AuthType Basic AuthName "WebDAV Storage" AuthUserFile /etc/httpd/passwd/passwd.dav </Directory>
The Alias directive tells apache where to look for requests for /webdav/
The DAV on directive turns on WebDAV in the directory (and its subdirectories).
The Auth* directives specify that access to anything in the webdav directory should use basic authentication using the password file we created earlier.
Under that, add directives for each WebDAV user's directory:
<Directory /var/www/webdav/flacco/> require user flacco </Directory>
Save and exit your editor, and restart apache:
# service httpd restart
If the startup fails, check the server logs for clues.
Create a test file in the user's WebDAV directory and change ownership/permissions to the apache service account:
# echo 'hello
world!' > /var/www/webdav/flacco/test.txt
# chown apache:apache /var/www/webdav/flacco/test.txt
# chmod 640 /var/www/webdav/flacco/test.txt
Try to access the test file with a browser, without using SSL:
You should get a 404 (object not found) error. If you don't, there's a problem (perhaps you put the webdav directory inside the apache document root, e.g. /var/www/html/webdav).
Now try to access the test file using SSL:
You might get a certificate warning - accept the certificate - and then a login dialog. Log in with the account information you created earlier using htpasswd. If all goes well, you should see this in your browser:
At this point, you're ready to test storing data to the server via WebDAV. For that you'll need a WebDAV client - like Mozilla Calendar. See this how-to for instructions on publishing Mozilla Calendar events to a WebDAV server (remember to use https:// instead of http://). If you encounter problems, go back to the server and check the server logs for clues.