Dropping Google Calendar – Webdav to the rescue

There has been a lot of uproar recently about Google’s new (some say lack of) privacy policy.  I’m not really going into the details of that here because frankly, it doesn’t have much to do with my personal decision to move away from their services.  For the last few years I’ve been nervous about how large and monopolistic Google has become and I’ve had the idea in the back of my mind that I might not want to stick with them for much longer; the new privacy policy announcement was really just the little shove I needed to get started with the process.

At the shop (aside from email, of course) the biggest potential problem for us is calendaring.  We’ve been very happy with how nicely Google’s calendars work in our ability to share them with each other and view them on various devices like Android phones.  I knew that to replace that I would need equivalent functionality or we’d really be moving backwards in our scheduling workflow.

I tried a couple of products with limited success:

  • DaviCal – I couldn’t really even connect properly to this in the first place even after reading several howto’s
  • CalendarServer (also known as Darwin Calendar Server) – it would initially, but seemed to flake out a lot (suddenly not serving pages in the web based interface, etc.)

Then I realized that pretty much any client that supports third party calendars can handle CalDav/WebDav.  This seemed to be my golden ticket, as WebDav is pretty easy to set up and is widely used—meaning that show-stopping bugs aren’t likely to live long.

At this point it is actually not a simple thing to use WebDav or anything else besides the Google Calendar on Android phones, so there may be a future post on that. Since this is the case no matter which method we choose it’s not really a deciding factor here.

What is WebDav?  The simplest explanation is that it’s a protocol that allows read/write access to files over a network as an extension to the HTTP.  As far as I can tell by reading online (though I haven’t seen much on the topic without reading RFC’s), the only difference between CalDav and normal WebDav is that it minimizes the amount of data that must be transferred during a calendar sync.

The Apache webserver has a widely supported module called mod_dav that adds WebDav support and that’s what I chose to use.  There is a mod_caldav module but it doesn’t look like it’s kept up very well.  As of this writing it hasn’t been modified since March of 2010, nearly two years ago.

On our CentOS server, things were pretty simple once I got through it.  I found a few hotwo’s, none of them complete.  Here’s what I did:

  1. Our virtual hosts are set up by adding VHOST_hostname.conf files to /etc/httpd/conf.d/ so I added VHOST_webdav.conf like so (the mod_dav module was already enabled for us, but you can enable it in /etc/httpd/conf/httpd.conf if not):
    <IfModule mod_dav.c>
        DavLockDB webvar/DavLock
        Alias /webdav "/var/www/webdav"
        <Directory /var/www/webdav>
            Dav On
            Options +Indexes
            IndexOptions FancyIndexing
            AddDefaultCharset UTF-8
            AuthType Basic
            AuthName "Alltech WebDAV Server"
            AuthUserFile /etc/httpd/webdav.users.pwd
            Require valid-user
            Order allow,deny
            Allow from all
        </Directory>
     </IfModule>
  2. Now you notice that line that says “DavLockDB webvar/DavLock”?  That means that mod_dav will create it’s lock file in {ServerRoot}/webvar with the basename DavLock for the files.  In our case {ServerRoot} is /etc/httpd, so we need to create that directory and give apache write permission for it:
    mkdir /etc/httpd/webvar
    chown apache:apache /etc/httpd/webvar
  3. We’ll also need to create the folder that our Directory container referenced (which is where our files will live):
    mkdir /var/www/webdav
    chown apache:apache /var/www/webdav
  4. Of course we’ll need to create a standard htpasswd file for the users and passwords.  According to our config, we want to create it thusly:
    htpasswd -c /etc/httpd/webdav.users.pwd myusername
    It will prompt you for a password for the user “myusername”.  To add more users, just leave off the “-c” parameter and substitute the new user name.
  5. Now restart apache:
    service httpd restart
  6. You can test it by using the “cadaver” command-line webdav client:
    cadaver http://servername/webdav
    If you don’t get errors and you can do a directory listing with ‘ls’, you win.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: