At the Forge - Sharing Calendars

FTP is fine for some tasks, but it has a number of drawbacks. To begin with, you might not want to run an FTP server on your computer, given its history of security problems. You also might prefer to have everything run over HTTP for performance reasons or because you can encrypt the transmission over SSL. For a variety of reasons, then, you might want to consider another alternative: mod_dav.

DAV, or Distributed Authoring and Versioning, makes it possible to create and modify files on a server, rather than just retrieve and read them. That is, DAV turns HTTP into a read-write protocol. DAV has been around for a number of years already, and mod_dav modules for Apache 1.x and 2.x have existed for some time. I am still using Apache 1.x on my main server, but it should be equally easy to install and use mod_dav for Apache 2.x.

To begin with, you need to download mod_dav (see the on-line Resources). Because I had compiled Apache with DSO (shared object) capabilities, I didn't have to recompile it from scratch in order to incorporate mod_dav. I merely had to tell it where to find apxs, the automatically generated Perl program that gives Apache modules all of the information they need in order to compile without the Apache source code. After unpacking the mod_dav source code, I typed:

./configure --with-apxs=/usr/local/apache/bin/apxs

Once done, I compiled and installed mod_dav:

make
make install

I double-checked to make sure that my Apache configuration file, httpd.conf, was still intact after the modifications provided by make install. Following that, I configured Apache to include a new named virtual server, which I called davcal.lerner.co.il:

<VirtualHost 69.55.225.93>
ServerName davcal.lerner.co.il
ServerAdmin calendar@lerner.co.il

# Directory and file names not beginning with /
# are relative to ServerRoot
ServerRoot /usr/local/apache/v-sites/davcal.lerner.co.il

DocumentRoot www
ErrorLog logs/error-log
CustomLog logs/access-log combined
CustomLog logs/referer-log referer

DAVLockDB  DAVLock
  <Directory
  /usr/local/apache/v-sites/davcal.lerner.co.il/www/>
    DAV On
    <Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL
           COPY MOVE LOCK UNLOCK>
      AuthName "Calendar DAV access"
      AuthType basic
      AuthUserFile passwd
      Require user calendar
    </Limit>
  </Directory>
</VirtualHost>

Notice the DAV-specific directives in the above configuration section. I have set up where the DAV locking will reside with DAVLockDB, obviously outside of the HTTP-accessible DocumentRoot directory. I then turn DAV on for a particular directory and limit DAV access to the calendar user, with a password specified in an external file. That password file, which is also outside of the Web site's root directory, is created and updated with the standard htpasswd program, located by default in /usr/local/apache/bin.

Finally, notice that our <Limit> section specifies limits only for potentially dangerous requests. The standard HTTP GET request, by contrast, requires no user name or password. This is a good configuration if you want to let anyone subscribe to your calendar but give limited access for publishing and modifying the calendar file. If this calendar were going to be used in a business, you probably would want to limit access to it as well, perhaps by giving each user his or her own password.

We can publish this calendar by bringing up (once again) the Publish entire calendar dialog for a particular calendar. This time, we use an HTTP URL, without specifying a user name or password: http://davcal.lerner.co.il/calendar.ics.

This publishes the calendar to the site, as you can tell by looking at the appropriate directory on the server. You similarly can publish the calendar using WebDAV each time the calendar is updated, just as we saw before.

Finally, we can subscribe to this calendar using the same techniques that we have seen in previous months. Choose Subscribe to remote calendar from the File menu and enter the URL for this calendar file. Thanks to the magic of WebDAV, we even can use the same URL for writing and reading the file.

Although the open-source world might not have a fancy back-end calendar system like Microsoft Exchange, solutions exist that are more flexible and more than good enough for most groups.

I should note that Sunbird does appear to have some problems with publishing and subscribing; if nothing else, meetings that were listed as private on my Sunbird application continued to be marked in that way when the file was uploaded—and were then displayed as private when I subscribed to the calendar with a different program. Moreover, Sunbird continues to be slow when working with large calendars; however, that problem has been noted by the Sunbird developers and presumably will be fixed in the coming months.

There is also the promise of a new server for handling iCalendar files in Novell's Hula Project. Since Novell acquired both Ximian and SUSE, Hula is one of the most-hyped new projects to emerge from that combination. If Hula does indeed include iCalendar support, I will be curious to see how it improves on the FTP and WebDAV solutions I have outlined above. Until then, there are workable solutions that satisfy my own needs, as well as those of many other small organizations looking to collaborate with each other.

Resources for this article: /article/8323.