One of the things our server needs to do is store calendar information for my partner and I. My calendars are all stored in iCal, and she just makes things up as she goes along. The better solution therefore seemed to be to store all calendar data on the server, thus making it available whenever we need it, from any machine. In order to do this, I used DAViCal, which seems to be up-to-date and still maintained, unlike some of the other possible options out there. It has a web interface for user administration, etc. but all calendar administration is done through your CalDav-enabled clients (e.g. iCal).

As with most of the other software packages discussed as part of this Ubuntu Home Server series of articles, DAViCal can be installed using apt-get.

sudo apt-get install davical

It was available in the default repositories for me. As before, all required dependencies will be installed, which include PHP and Postgre SQL in this case. I basically just followed the installation instructions on the excellent DAViCal site. Everything worked generally as described, although the section on creating virtual hosts did trip me up. I eventually found this article on v2kblog, which pointed to the solution. It turns out that the NameVirtualHost or Listen directives may be present in the apache ports.conf file by default. 98% of the Virtual Hosts tutorials online tell you to add these to the relevant file(s) in sites-available, so you end up with duplicate directives between the two files. This results in a warning from Apache when you reload or restart:

* Restarting web server apache2
[Tue Jul 05 22:32:22 2011] [warn] NameVirtualHost *:80 has no VirtualHosts

Comment out one set of the duplicates, and you’ll be fine. Strangely, the default config file wasn’t created for me, so I had to download the example from davical.org, save it to /etc/davical/config.php and amend as appropriate. Finally, when running the Postgre SQL query to view the initial admin password, I had to tell it specifically to use the davical database user:

psql -U davical -c 'select username, password from usr;

Once this is done, you can access the administration area and set up users and groups as desired. Again, the relevant official documentation is very good. Finally, once everything’s set up you can connect from the relevant client with a URL like http://calendar.local/user/home. This is pretty intuitive, but if you’re struggling then you know where to find decent help and explanations for a number of clients.

Getting the server up and running is one thing; if you want to import existing ics files then you’ve still got some more work to do. There are, again, instructions on the DAViCal website which I followed. I would add to ensure your admin user has sufficient access rights to do everything, as I seem to recall reading that by default the admin user cannot access the data of other users. Also don’t forget to create a user account before you try to import calendars in to it! Once they’ve all been imported, they’ll be available through http://calendar.local/caldav.php/<user>/<icsname>, so importing a file called parties.ics to the myuser user would give me an access address of http://calendar.local/caldav.php/myuser/parties. You can then use this address to subscribe to the calendar in your favourite calendar client software. Interestingly, if you’re using iCal then you add an “Account” in the Preferences screen, and use just the URL for the DAViCal user as the “Account URL” (e.g. http://calendar.local/caldav.php/myuser). This will then automatically pull in all the calendars present for that user; bear in mind that you’ll need to enter your authentication details too.

Gentle warning: This all worked perfectly for me, until I took my MacBook away from my desk, and therefore away from the connection to the calendars on the server. I could still view all the details, but iCal will not let you add events and then sync them back to the server next time you connect. That’s a bit of a deal-breaker for me, so I’m trying to find a way to work around it at present! Anything I find will be reported back here.