Radicale on FreeBSD

by Tykling

05. dec 2017 11:25 UTC

I've been working to replace my OwnCloud installation with something else. I use the Calendar part of OwnCloud a lot, and this post is about replacing the CalDAV bits of OwnCloud with Radicale, a Python based CalDAV and CardDAV server.

I use nginx and supervisord so I will start out by showing the config for those before getting deeper into Radicale.

Nginx and Authentication

I run all my webstuff through a reverse proxy which takes care of terminating TLS and IPv6 and passes the request to the backend jail running the service in question. This means that the configuration of the backend webserver in the service jail can be kept very simple:

        location / {
             # regular proxy stuff
             proxy_http_version 1.1;
             proxy_set_header Host $http_host;
             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

             # radicale http_x_remote_user config
             proxy_set_header X-Remote-User $remote_user;
             auth_basic "Radicale - Password Required";
             auth_basic_user_file "/usr/local/etc/nginx/radicale-htpasswd";

I read in the Radicale reverse proxy documentation about the auth method called http_x_remote_user which sounds perfect since I can let nginx handle the authentication with regular HTTP Basic Auth. This was actually the reason I had to switch to the 2.x version of Radicale since 1.x doesn't support http_x_remote_user.


I am becoming a big fan of running stuff with Supervisord. Although software should be stable it is nice to have "something" keeping an eye on things, restarting as needed. But that is not all Supervisord does, it also handles logging very well. The following block (Ansible generated of course) is what I use to run Radicale and redirect console logs to syslog:

command=/usr/local/virtualenv/bin/python /usr/local/virtualenv/bin/radicale -C /usr/local/etc/radicale/config

To make Radicale not daemonize I had to add daemon = False to the [server] section of the config. Also note that I am calling the virtualenv Python directly and that the Radicale executable is also inside the virtualenv.

Radicale version

I started out (as one does) with Radicale from the FreeBSD Ports tree, which at the time of writing (December 2017) was at version 1.1.2. I was forced to switch to installing Radicale from pip instead to get the 2.x version. I will change that back to installing from FreeBSD Ports when the new Radicale arrives in Ports.

Radicale Config

All this boils down to the following config file:

daemon = False

type = http_x_remote_user

type = from_file
file = /usr/local/etc/radicale/rights

filesystem_folder = /usr/local/share/radicale/collections

config = /usr/local/etc/radicale/logging


Since Supervisord is configured to redirect both stdout and stderr to syslog I don't need Radicale to log to files or syslog by itself, it should just log to console and let Supervisord handle the rest. The following logging config accomplishes that:

keys = root

keys = console

keys = full

level = DEBUG
handlers = console

class = StreamHandler
# change this to DEBUG for more verbosity
level = INFO
args = (sys.stdout,)
formatter = full

format = %(asctime)s - %(levelname)s: %(message)s

Radicale used Pythons default logging framework and actually manages to distribute it in a fairly understandable and flexible way, well done. Documentation here.

Rights and Calendar Sharing

Radicale has a pretty flexible rights system. It can be configured in a couple of different ways, I went with from_file with the following rights file:

# Authenticated users can read and write their own collections.
user = .+
collection = %(login)s(/.*)?
permission = rw

# Everyone can read the root collection
user = .*
collection =
permission = r

This just means that each user can read and write their own collections. To configure sharing add a section like this:

user = tykling
collection = someone(/.*)?
permission = r

This would allow the user tykling to access all collections under the username someone. Read more about configuring rights in their rights documentation.

Radicale Storage

The Radicale directory structure is pretty simple and it saves it's data as .ics files. Here is the structure with an example calender with two events created:

$ sudo find /usr/local/share/radicale/collections

Creating Users and Calendars

For a while I didn't realise that Radicale has a webinterface to create users and collections in the filesystem. Since I authenticate users in nginx I first have to add the username and password in the htpasswd file there of course, but then I go to the Radicale web interface with a webbrowser and log on, and it shows me a simple view where I can choose to Create new addressbook or calendar. After creating a calendar I can copy the full URL including UUID for that collection and use that in when configuring Lightning or other clients.

Importing Existing Calendars

When searching for ways to import an existing calender (an ICS file exported from OwnCloud in my case) I found that the advice was just to drop the ICS file into the folder with the rest of the ICS files and it would kindof just work. But it didn't:

Dec  5 21:24:38 radicale1 supervisord: radicale_00 2017-12-05 21:24:38,470 - ERROR: An exception occurred during PROPFIND request on '/tykling/a5196bd5-f2fe-82dc-8e6a-81cefa92b4b6/': Failed to load item 'export.ics' in 'tykling/a5196bd5-f2fe-82dc-8e6a-81cefa92b4b6': Muliple VEVENT components with different UIDs in
 object: '2be379d9-3ef0-4749-a14e-bd11028b5675', '08fd2497-c73d-46f5-b25d-7888d1ed8f27'  

As you can see further up Radicale creates one (1) .ics file per event. The ICS format obviously supports multiple events in a single file, but support for this appears to have been removed from the Radicale 2.x series.

So I used this alternative method to import my ICS:

cat export.ics | curl -u 'tykling:password' -X PUT https://cal.tyk.nu/tykling/a5196bd5-f2fe-82dc-8e6a-81cefa92b4b6/ --data-binary @-

This took around 10 seconds for a ~100kb ICS file, and resulted in Radicale creating a whole bunch of ICS files. Perfect.


Thunderbird comes with Lightning built-in these days, and it works perfectly with Radicale. Just add a network calendar, paste in the URL to the collection, enter credentials, done. Thunderbird does not appear to support the calendar coloring thing where you can configure the color in Radicale and the CalDAV clients should show the calendar in that color. But I'll live :)

I run Copperhead OS on my phone so I only have access to the F-Droid app-store so I was happy to see that I still had some options wrt. CalDAV clients. I am currently using the "built-in" Etar calendar app to show/use the calendar, and Davdroid to synchhronise with the CalDAV server. This works very well, and it was even able to show a list of the calendars created under my user so I didn't have to enter the full URL. Fancy.

Search this blog

Tags for this blogpost