I suppose these days running your own Internet services would be considered to fall under the banner of a “personal cloud”. I run my own email, for example, something which many nowadays outsource to the likes of Google. The reason I do this is the control it gives me over exactly how the services I use function. I also find it interesting. Many people associate email with one of these hosted “cloud” services and may not even realise that the vast majority of what you use on the Internet you can do yourself.
I have just added a new service to my arsenal – that of a CalDAV server (using the Darwin Calendar Server – this is the open source (Apache Licensed) version of the software available in Snow Leopard Server). The only other major option I could see is DAViCal (which uses php – yuck!)
Setting this up isn’t too difficult once you get past the almost complete lack of documentation. Fortunately the use of XML (Apple’s plist format) for the configuration files allows you to make some pretty good guesses as to what various settings do. The server seems to work around the concept of “principals”. This is a term which refers roughly to objects which can own calendars, e.g. users, groups, resources, locations etc. Principles are identified by a GUID (ick) and a set of DAV properties. The structure beyond that is automatically generated by the server.
Basic Installation
Using Debian, this is easy, just do:
aptitude install calendarserver
Note: This pulls down memcached, so don’t be surprised to see that running.
Other platforms may have this package in their package management systems, if not you may have to install it from source (not too hard given it’s Python-based).
The server makes use of user-level Extended Attributes on the filesystem to store information. If these aren’t switched on for your filesystem you’ll need to enable them. This can be done by adding the “user_xattr” flag to your /etc/fstab, e.g.:
/dev/hda3 /home ext3 defaults,user_xattr 1 2
Server Setup
The server operates on port 8008 by default without SSL. I like all my services to be encrypted (the default SSL port is 8443), but this is easy to set up in the configuration. You can also set which IP addresses the server listens on. Unfortunately the version included with Debian doesn’t support IPv6 yet – I will have to fix that sometime.
If you look at the server with a web browser (e.g. https://myserver.com:8443) you get an interface which allows you to interrogate the various principals and settings. You can also enable admin via this interface.
<!--
Permissions
-->
EnableAnonymousReadRoot
EnableAnonymousReadNav
EnablePrincipalListings
The first two settings here determine whether non-authenticated users can view basic root-level information about your CalDAV server, and whether they can view detailed information deeper into the hierarchy. I see no reason to enable these.
The third setting determines whether detailed information is listed for principals (to authenticated users). This is quite useful for diagnostic purposes so I turn this on.
Authentication can be via Basic Auth (good to use with SSL), Digest Auth (useful for non-SSL) or Kerberos. The latter option is overkill for my needs.
There are also settings for your public/private key pair, log files, process management etc. These are all quite straightforward and self-explanatory (if you’ve configured Apache you’ll be fine with these).
A nifty feature I might have to look into further is integration with an XMPP server for notifications. Various Server-to-Server protocols are also available (for distributed meeting planning). I haven’t explored these options yet.
One setting towards the end is important:
EnableWebAdmin
With this turned on you can query and set various properties via the web interface. Only principals which have been placed into one of the “special principals” containers can do this, e.g.:
AdminPrincipals
<!-- /principals/__uids__/some-GUID/ -->
I don’t see much need to use the web admin interface so I turned it off for the moment.
The other “special principle” groups allow global read access (“ReadPrinciples”) to all other principals (e.g. you can see everyone’s calendars etc.) and “sudo” principals (which can impersonate other principals) – the “sudo” ones are set via a third configuration file, sudoers.plist).
Quotas are supported Data Store settings, the defaults are fairly sensible for a small installation though you’ll probably want to tweak down the default 100MB per user if you have a larger site.
User Setup
The main thing to worry about when configuring the server is to set up your source of principals (e.g. where the user/group etc. information comes from, this is known as a Directory Service). Various sources are supported, the simplest of which is an XML file. OpenDirectory, LDAP etc. work too.
LDAP is something I may explore later to tie my services together, for now I went with the XML option for simplicity.
These principals are specified in the “accounts.xml” file. You define a realm, under which multiple accounts of type user, group, location or resource can live. In a larger site the maintainability of a single XML file is likely to become a problem at which point use of LDAP or OpenDirectory would become a pressing concern.
One big downside to this approach is the need to specify user passwords in cleartext in the configuration file. This is something I try and avoid doing and will be a big motivation to moving to LDAP as a directory backend.
I’d recommend for a small installation specifying non-GUIDy GUIDs for your users. E.g.:
someusername
g_someusername
someusernamepassword
Some User
mailto:someuser@some.domain
This means that instead of getting URLs appearing like:
/principals/__uids__/AE668DD7-D2B8-4D4D-A574-2AA533DF26A4/
You get:
/principals/__uids__/g_someusername/
Which is easier to debug.
More info on users and groups: http://dcswiki.org/dwiki/doku.php?id=users
Using the server
Both iCal (Mac OSX) and the iPhone (iOS 4.1+) can use a CalDAV server. There’s some good info on setting this up here:
http://manuals.kerio.com/kmsug/en/sect-caldav.html
And for BusyCal:
http://www.busymac.com/help/sync/caldav-other.html
Conclusion
Setting this up is really quick and easy if you already have a Debian server available. Being able to sync my calendars wirelessly between my Mac and iPhone (as well as enabling other people to subscribe to view it) is a powerful capability. The next step is to set up a CardDAV server as well to do the same thing for contacts.
