Radicale v2 v3.2-devel v3.1-maintain master v3 v2 v1

Linux / *BSD ¶

First of all, make sure that python 3.3 or later (python ≥ 3.6 is recommended) and pip are installed. On most distributions it should be enough to install the package python3-pip.

Then open a console and type:

# Run the following command as root or
# add the --user argument to only install for the current user
$ python3 -m pip install --upgrade radicale==2.1.*
$ python3 -m radicale --config "" --storage-filesystem-folder=~/.var/lib/radicale/collections

Victory! Open http://localhost:5232/ in your browser! You can login with any username and password.

Windows ¶

The first step is to install Python. Go to python.org and download the latest version of Python 3. Then run the installer. On the first window of the installer, check the "Add Python to PATH" box and click on "Install now". Wait a couple of minutes, it's done!

Launch a command prompt and type:

C:\Users\User> python -m pip install --upgrade radicale==2.1.*
C:\Users\User> python -m radicale --config "" --storage-filesystem-folder=~/radicale/collections

If you are using PowerShell replace --config "" with --config '""'.

Victory! Open http://localhost:5232/ in your browser! You can login with any username and password.

MacOS ¶

To be written.

Configuration ¶

Radicale tries to load configuration files from /etc/radicale/config, ~/.config/radicale/config and the RADICALE_CONFIG environment variable. A custom path can be specified with the --config /path/to/config command line argument.

You should create a new configuration file at the desired location. (If the use of a configuration file is inconvenient, all options can be passed via command line arguments.)

All configuration options are described in detail on the Configuration page.

Authentication ¶

In its default configuration Radicale doesn't check user names or passwords. If the server is reachable over a network, you should change this.

First a users file with all user names and passwords must be created. It can be stored in the same directory as the configuration file.

# Create a new htpasswd file with the user "user1"
$ htpasswd -B -c /path/to/users user1
New password:
Re-type new password:
# Add another user
$ htpasswd -B /path/to/users user2
New password:
Re-type new password:

$ python3 -m pip install --upgrade radicale[bcrypt]==2.1.*

[auth]
type = htpasswd
htpasswd_filename = /path/to/users
# encryption method used in the htpasswd file
htpasswd_encryption = bcrypt

user1:password1
user2:password2

[auth]
type = htpasswd
htpasswd_filename = /path/to/users
# encryption method used in the htpasswd file
htpasswd_encryption = plain

Addresses ¶

The default configuration binds the server to localhost. It can't be reached from other computers. This can be changed with the following configuration options:

[server]
hosts = 0.0.0.0:5232

More addresses can be added (separated by commas).

Storage ¶

Data is stored in the folder /var/lib/radicale/collections. The path can be changed with the following configuration:

[storage]
filesystem_folder = /path/to/storage

Security: The storage folder should not be readable by unauthorized users. Otherwise, they can read the calendar data and lock the storage. You can find OS dependent instructions in the Running as a service section.

Limits ¶

Radicale enforces limits on the maximum number of parallel connections, the maximum file size (important for contacts with big photos) and the rate of incorrect authentication attempts. Connections are terminated after a timeout. The default values should be fine for most scenarios.

[server]
max_connections = 20
# 100 Megabyte
max_content_length = 100000000
# 30 seconds
timeout = 30

[auth]
# Average delay after failed login attempts in seconds
delay = 1

Running as a service ¶

The method to run Radicale as a service depends on your host operating system. Follow one of the chapters below depending on your operating system and requirements.

[Unit]
Description=A simple CalDAV (calendar) and CardDAV (contact) server

[Service]
ExecStart=/usr/bin/env python3 -m radicale
Restart=on-failure

[Install]
WantedBy=default.target

# Enable the service
$ systemctl --user enable radicale
# Start the service
$ systemctl --user start radicale
# Check the status of the service
$ systemctl --user status radicale
# View all log messages
$ journalctl --user --unit radicale.service

[Unit]
Description=A simple CalDAV (calendar) and CardDAV (contact) server
After=network.target
Requires=network.target

[Service]
ExecStart=/usr/bin/env python3 -m radicale
Restart=on-failure
User=radicale
# Deny other users access to the calendar data
UMask=0027
# Optional security settings
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
NoNewPrivileges=true
ReadWritePaths=/var/lib/radicale/collections

[Install]
WantedBy=multi-user.target

# Enable the service
$ systemctl enable radicale
# Start the service
$ systemctl start radicale
# Check the status of the service
$ systemctl status radicale
# View all log messages
$ journalctl --unit radicale.service

MacOS with launchd ¶

To be written.

Classic daemonization ¶

Set the configuration option daemon in the section server to True. You may want to set the option pid to the path of a PID file.

After daemonization the server will not log anything. You have to configure Logging.

If you start Radicale now, it will initialize and fork into the background. The main process exits, after the PID file is written.

Security: You can set the umask with umask 0027 before you start the daemon, to protect your calendar data and log files from other users. Don't forget to set permissions of files that are already created!

Windows with "NSSM - the Non-Sucking Service Manager" ¶

First install NSSM and start nssm install in a command prompt. Apply the following configuration:

• Service name: Radicale
• Application
  • Path: C:\Path\To\Python\python.exe
  • Arguments: -m radicale --config C:\Path\To\Config
• I/O redirection
  • Error: C:\Path\To\Radicale.log

Security: Be aware that the service runs in the local system account, you might want to change this. Managing user accounts is beyond the scope of this manual. Also make sure that the storage folder and log file is not readable by unauthorized users.

The log file might grow very big over time, you can configure file rotation in NSSM to prevent this.

The service is configured to start automatically when the computer starts. To start the service manually open Services in Computer Management and start the Radicale service.

Manage user accounts with the reverse proxy ¶

Set the configuration option type in the auth section to http_x_remote_user. Radicale uses the user name provided in the X-Remote-User HTTP header and disables HTTP authentication.

Example nginx configuration:

location /radicale/ {
    proxy_pass           http://localhost:5232/;
    proxy_set_header     X-Script-Name /radicale;
    proxy_set_header     X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header     X-Remote-User $remote_user;
    auth_basic           "Radicale - Password Required";
    auth_basic_user_file /etc/nginx/htpasswd;
}

Example Apache configuration:

RewriteEngine On
RewriteRule ^/radicale$ /radicale/ [R,L]

<Location "/radicale/">
    AuthType      Basic
    AuthName      "Radicale - Password Required"
    AuthUserFile  "/etc/radicale/htpasswd"
    Require       valid-user

    ProxyPass        http://localhost:5232/ retry=0
    ProxyPassReverse http://localhost:5232/
    RequestHeader    set X-Script-Name /radicale/
    RequestHeader    set X-Remote-User expr=%{REMOTE_USER}
</Location>

Security: Untrusted clients should not be able to access the Radicale server directly. Otherwise, they can authenticate as any user.

Secure connection between Radicale and the reverse proxy ¶

SSL certificates can be used to encrypt and authenticate the connection between Radicale and the reverse proxy. First you have to generate a certificate for Radicale and a certificate for the reverse proxy. The following commands generate self-signed certificates. You will be asked to enter additional information about the certificate, the values don't matter and you can keep the defaults.

$ openssl req -x509 -newkey rsa:4096 -keyout server_key.pem -out server_cert.pem -nodes -days 9999
$ openssl req -x509 -newkey rsa:4096 -keyout client_key.pem -out client_cert.pem -nodes -days 9999

Use the following configuration for Radicale:

[server]
ssl = True
certificate = /path/to/server_cert.pem
key = /path/to/server_key.pem
certificate_authority = /path/to/client_cert.pem

Example nginx configuration:

location /radicale/ {
    proxy_pass https://localhost:5232/;
    ...
    # Place the files somewhere nginx is allowed to access (e.g. /etc/nginx/...).
    proxy_ssl_certificate         /path/to/client_cert.pem;
    proxy_ssl_certificate_key     /path/to/client_key.pem;
    proxy_ssl_trusted_certificate /path/to/server_cert.pem;
}

Manage user accounts with the WSGI server ¶

Set the configuration option type in the auth section to remote_user. Radicale uses the user name provided by the WSGI server and disables authentication over HTTP.

DAVx⁵ ¶

Enter the URL of the Radicale server (e.g. http://localhost:5232) and your user name. DAVx⁵ will show all existing calendars and address books and you can create new.

GNOME Calendar, Contacts and Evolution ¶

GNOME Calendar and Contacts do not support adding WebDAV calendars and address books directly, but you can add them in Evolution.

In Evolution add a new calendar and address book respectively with WebDAV. Enter the URL of the Radicale server (e.g. http://localhost:5232) and your user name. Clicking on the search button will list the existing calendars and address books.

Thunderbird ¶

InfCloud, CalDavZAP and CardDavMATE ¶

You can integrate InfCloud into Radicale's web interface with RadicaleInfCloud. No additional configuration is required.

Set the URL of the Radicale server in config.js. If InfCloud is not hosted on the same server and port as Radicale, the browser will deny access to the Radicale server, because of the same-origin policy. You have to add additional HTTP header in the headers section of Radicale's configuration. The documentation of InfCloud has more details on this.

Manual creation of calendars and address books ¶

This is not the recommended way of creating and managing your calendars and address books. Use Radicale's web interface or a client with support for it (e.g. DAVx⁵).

{"tag": "VCALENDAR"}

{"tag": "VADDRESSBOOK"}

$ curl -u user -X MKCOL 'http://localhost:5232/user/calendar' --data \
'<?xml version="1.0" encoding="UTF-8" ?>
<create xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:I="http://apple.com/ns/ical/">
  <set>
    <prop>
      <resourcetype>
        <collection />
        <C:calendar />
      </resourcetype>
      <C:supported-calendar-component-set>
        <C:comp name="VEVENT" />
        <C:comp name="VJOURNAL" />
        <C:comp name="VTODO" />
      </C:supported-calendar-component-set>
      <displayname>Calendar</displayname>
      <C:calendar-description>Example calendar</C:calendar-description>
      <I:calendar-color>#ff0000ff</I:calendar-color>
    </prop>
  </set>
</create>'

$ curl -u user -X MKCOL 'http://localhost:5232/user/addressbook' --data \
'<?xml version="1.0" encoding="UTF-8" ?>
<create xmlns="DAV:" xmlns:CR="urn:ietf:params:xml:ns:carddav">
  <set>
    <prop>
      <resourcetype>
        <collection />
        <CR:addressbook />
      </resourcetype>
      <displayname>Address book</displayname>
      <CR:addressbook-description>Example address book</CR:addressbook-description>
    </prop>
  </set>
</create>'

$ curl -u user -X DELETE 'http://localhost:5232/user/calendar'

server ¶

Most configuration options in this category are only relevant in standalone mode. All options beside max_content_length and realm are ignored, when Radicale runs via WSGI.

encoding ¶

auth ¶

user1:password1
user2:password2

rights ¶

storage ¶

web ¶

logging ¶

headers ¶

In this section additional HTTP headers that are sent to clients can be specified.

An example to relax the same-origin policy:

Access-Control-Allow-Origin = *

Layout ¶

The file system contains the following files and folders:

• .Radicale.lock: The lock file for locking the storage.
• collection-root: This folder contains all collections and items.

A collection is represented by a folder. This folder may contain the file .Radicale.props with all WebDAV properties of the collection encoded as JSON.

An item is represented by a file containing the iCalendar data.

All files and folders, whose names start with a dot but not .Radicale. (internal files) are ignored.

If you introduce syntax errors in any of the files, all requests that access the faulty data will fail. The logging output should contain the names of the culprits.

Future releases of Radicale 2.x.x will store caches and sync-tokens in the .Radicale.cache folder inside of collections. This folder may be created or modified, while the storage is locked for shared access. In theory, it should be safe to delete the folder. Caches will be recreated automatically and clients will be told that their sync-token isn't valid anymore.

You may encounter files or folders that start with .Radicale.tmp-. Radicale uses them for atomic creation and deletion of files and folders. They should be deleted after requests are finished but it's possible that they are left behind when Radicale or the computer crashes. It's safe to delete them.

Locking ¶

When the data is accessed by hand or by an externally invoked script, the storage must be locked. The storage can be locked for exclusive or shared access. It prevents Radicale from reading or writing the file system. The storage is locked with exclusive access while the hook runs.

# Exclusive
$ flock --exclusive /path/to/storage/.Radicale.lock COMMAND
# Shared
$ flock --shared /path/to/storage/.Radicale.lock COMMAND

Logging to a file ¶

An example configuration to write the log output to the file /var/log/radicale/log:

[loggers]
keys = root

[handlers]
keys = file

[formatters]
keys = full

[logger_root]
# Change this to DEBUG or INFO for higher verbosity.
level = WARNING
handlers = file

[handler_file]
class = FileHandler
# Specify the output file here.
args = ('/var/log/radicale/log',)
formatter = full

[formatter_full]
format = %(asctime)s - [%(thread)x] %(levelname)s: %(message)s

You can specify multiple logger, handler and formatter if you want to have multiple simultaneous log outputs.

The parent folder of the log files must exist and must be writable by Radicale.

Security: The log files should not be readable by unauthorized users. Set permissions accordingly.

[handler_file]
class = handlers.TimedRotatingFileHandler
# Specify the output file and parameter for rotation here.
# See https://docs.python.org/3/library/logging.handlers.html#logging.handlers.TimedRotatingFileHandler
# Example: rollover at midnight and keep 7 files (means one week)
args = ('/var/log/radicale/log', 'midnight', 1, 7)
formatter = full

[handler_file]
class = handlers.RotatingFileHandler
# Specify the output file and parameter for rotation here.
# See https://docs.python.org/3/library/logging.handlers.html#logging.handlers.RotatingFileHandler
# Example: rollover at 100000 kB and keep 10 files (means 1 MB)
args = ('/var/log/radicale/log', 'a', 100000, 10)
formatter = full

General Architecture ¶

Here is a simple overview of the global architecture for reaching a calendar or an address book through network:

Radicale is only the server part of this architecture.

Please note that:

• CalDAV and CardDAV are superset protocols of WebDAV,
• WebDAV is a superset protocol of HTTP.

Radicale being a CalDAV/CardDAV server, it also can be seen as a special WebDAV and HTTP server.

Radicale is not the client part of this architecture. It means that Radicale never draws calendars, address books, events and contacts on the screen. It only stores them and give the possibility to share them online with other people.

If you want to see or edit your events and your contacts, you have to use another software called a client, that can be a "normal" applications with icons and buttons, a terminal or another web application.

Code Architecture ¶

The radicale package offers 9 modules.

__main__ : The main module provides a simple function called run. Its main work is to read the configuration from the configuration file and from the options given in the command line; then it creates a server, according to the configuration.

__init__ : This is the core part of the module, with the code for the CalDAV/CardDAV server. The server inherits from a WSGIServer server class, which relies on the default HTTP server class given by Python. The code managing the different HTTP requests according to the CalDAV/CardDAV normalization is written here.

config : This part gives a dict-like access to the server configuration, read from the configuration file. The configuration can be altered when launching the executable with some command line options.

xmlutils : The functions defined in this module are mainly called by the CalDAV/CardDAV server class to read the XML part of the request, read or alter the calendars, and create the XML part of the response. The main part of this code relies on ElementTree.

log : The start function provided by this module starts a logging mechanism based on the default Python logging module. Logging options can be stored in a logging configuration file.

auth : This module provides a default authentication manager equivalent to Apache's htpasswd. Login + password couples are stored in a file and used to authenticate users. Passwords can be encrypted using various methods. Other authentication methods can inherit from the base class in this file and be provided as plugins.

rights : This module is a set of Access Control Lists, a set of methods used by Radicale to manage rights to access the calendars. When the CalDAV/CardDAV server is launched, an Access Control List is chosen in the set, according to the configuration. The HTTP requests are then filtered to restrict the access depending on who is authenticated. Other configurations can be written using regex-based rules. Other rights managers can also inherit from the base class in this file and be provided as plugins.

storage : In this module are written the classes representing collections and items in Radicale, and the class storing these collections and items in your filesystem. Other storage classes can inherit from the base class in this file and be provided as plugins.

web : This module contains the web interface.

Getting started ¶

To get started we walk through the creation of a simple authentication plugin, that accepts login attempts if the username and password are equal.

The easiest way to develop and install python modules is Distutils. For a minimal setup create the file setup.py with the following content in an empty folder:

#!/usr/bin/env python3

from distutils.core import setup

setup(name="radicale_silly_auth", packages=["radicale_silly_auth"])

In the same folder create the sub-folder radicale_silly_auth. The folder must have the same name as specified in packages above.

Create the file __init__.py in the radicale_silly_auth folder with the following content:

from radicale.auth import BaseAuth


class Auth(BaseAuth):
    def is_authenticated(self, user, password):
        # Example custom configuration option
        foo = ""
        if self.configuration.has_option("auth", "foo"):
            foo = self.configuration.get("auth", "foo")
        self.logger.info("Configuration option %r is %r", "foo", foo)

        # Check authentication
        self.logger.info("Login attempt by %r with password %r",
                         user, password)
        return user == password

Install the python module by running the following command in the same folder as setup.py:

python3 -m pip install --upgrade .

To make use this great creation in Radicale, set the configuration option type in the auth section to radicale_silly_auth:

[auth]
type = radicale_silly_auth
foo = bar

You can uninstall the module with:

python3 -m pip uninstall radicale_silly_auth

Authentication plugins ¶

This plugin type is used to check login credentials. The module must contain a class Auth that extends radicale.auth.BaseAuth. Take a look at the file radicale/auth.py in Radicale's source code for more information.

Rights management plugins ¶

This plugin type is used to check if a user has access to a path. The module must contain a class Rights that extends radicale.rights.BaseRights. Take a look at the file radicale/rights.py in Radicale's source code for more information.

Web plugins ¶

This plugin type is used to provide the web interface for Radicale. The module must contain a class Web that extends radicale.web.BaseWeb. Take a look at the file radicale/web.py in Radicale's source code for more information.

Storage plugins ¶

This plugin is used to store collections and items. The module must contain a class Collection that extends radicale.storage.BaseCollection. Take a look at the file radicale/storage.py in Radicale's source code for more information.

Why a Migration? ¶

Radicale 2.x.x is different from 1.x.x, here's everything you need to know about this! Please read this page carefully if you want to update Radicale.

You'll also find extra information in issue #372.

Python 3 Only ¶

Radicale 2.x.x works with Python >= 3.3, and doesn't work anymore with Python 2.

(No, Python 3.3 is not new, it's been released more than 4 years ago. Debian stable provides Python 3.4.)

Dependencies ¶

Radicale now depends on VObject, a "full-featured Python package for parsing and creating iCalendar and vCard files". That's the price to pay to correctly read crazy iCalendar files and support date-based filters, even on recurring events.

Storage ¶

Calendars and address books are stored in a different way between 1.x.x and 2.x.x versions. Launching 2.x.x without migrating your collections first will not work, Radicale won't be able to read your previous data.

There's now only one way to store data in Radicale: collections are stored as folders and events / contacts are stored in files. This new storage is close to the multifilesystem, but it's now thread-safe, with atomic writes and file locks. Other storage types can be used by creating plugins.

To migrate data to Radicale 2.x.x the command line argument --export-storage was added to Radicale 1.1.x. Start Radicale 1.x.x as you would normally do, but add the argument --export-storage path/to/empty/folder. Radicale will export the storage into the specified folder. This folder can be directly used with the default storage backend of Radicale 2.x.x.

If you import big calendars or address books into Radicale 2.x.x the first request might take a long time, because it has to initialize its internal caches. Clients can time out, subsequent requests will be much faster.

You can check the imported storage for errors by starting Radicale >= 2.1.5 with the --verify-storage argument.

You can install version 1.1.x with:

$ python3 -m pip install --upgrade radicale==1.1.*

Authentication ¶

Radicale 2.x.x only provides htpasswd authentication out-of-the-box. Other authentication methods can be added by creating or using plugins.

Rights ¶

In Radicale 2.x.x, rights are managed using regex-based rules based on the login of the authenticated user and the URL of the resource. Default configurations are built in for common cases, you'll find more about this on the Authentication & Rights page.

Other rights managers can be added by creating plugins.

Versioning ¶

Support for versioning with git was removed from Radicale 2.x.x. Instead, the configuration option hook in the storage section was added, the Collection Versioning page explains its usage for version control.

Oriented to Calendar and Contact User Agents ¶

Calendar and contact servers work with calendar and contact clients, using a defined protocol. CalDAV and CardDAV are good protocols, covering lots of features and use cases, but it is quite hard to implement fully.

Some calendar servers have been created to follow the CalDAV and CardDAV RFCs as much as possible: Davical, Baïkal and Darwin Calendar Server, for example, are much more respectful of CalDAV and CardDAV and can be used with a large number of clients. They are very good choices if you want to develop and test new CalDAV clients, or if you have a possibly heterogeneous list of user agents.

Even if it tries it best to follow the RFCs, Radicale does not and will not blindly implements the CalDAV and CardDAV standards. It is mainly designed to support the CalDAV and CardDAV implementations of different clients.

Simple ¶

Radicale is designed to be simple to install, simple to configure, simple to use.

The installation is very easy, particularly with Linux: one dependency, no superuser rights needed, no configuration required, no database. Installing and launching the main script out-of-the-box, as a normal user, are often the only steps to have a simple remote calendar and contact access.

Contrary to other servers that are often complicated, require high privileges or need a strong configuration, the Radicale Server can (sometimes, if not often) be launched in a couple of minutes, if you follow the tutorial.

Lazy ¶

The CalDAV RFC defines what must be done, what can be done and what cannot be done. Many violations of the protocol are totally defined and behaviours are given in such cases.

Radicale often assumes that the clients are perfect and that protocol violations do not exist. That is why most of the errors in client requests have undetermined consequences for the lazy server that can reply good answers, bad answers, or even no answer.

2.1.12 - Wild Radish ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.x.x.

• Include documentation in source archive

2.1.11 - Wild Radish ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.x.x.

• Fix moving items between collections

2.1.10 - Wild Radish ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.x.x.

• Update required versions for dependencies
• Get RADICALE_CONFIG from WSGI environ
• Improve HTTP status codes
• Fix race condition in storage lock creation
• Raise default limits for content length and timeout
• Log output from hook

2.1.9 - Wild Radish ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.x.x.

• Specify versions for dependencies
• Move WSGI initialization into module
• Check if REPORT method is actually supported
• Include rights file in source distribution
• Specify md5 and bcrypt as extras
• Improve logging messages
• Windows: Fix crash when item path is a directory

2.1.8 - Wild Radish ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.x.x.

• Flush files before fsync'ing

2.1.7 - Wild Radish ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.x.x.

• Don't print warning when cache format changes
• Add documentation for BaseAuth
• Add is_authenticated2(login, user, password) to BaseAuth
• Fix names of custom properties in PROPFIND requests with D:propname or D:allprop
• Return all properties in PROPFIND requests with D:propname or D:allprop
• Allow D:displayname property on all collections
• Answer with D:unauthenticated for D:current-user-principal property when not logged in
• Remove non-existing ICAL:calendar-color and C:calendar-timezone properties from PROPFIND requests with D:propname or D:allprop
• Add D:owner property to calendar and address book objects
• Remove D:getetag and D:getlastmodified properties from regular collections

2.1.6 - Wild Radish ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.x.x.

• Fix content-type of VLIST
• Specify correct COMPONENT in content-type of VCALENDAR
• Cache COMPONENT of calendar objects (improves speed with some clients)
• Stricter parsing of filters
• Improve support for CardDAV filter
• Fix some smaller bugs in CalDAV filter
• Add X-WR-CALNAME and X-WR-CALDESC to calendars downloaded via HTTP/WebDAV
• Use X-WR-CALNAME and X-WR-CALDESC from calendars published via WebDAV

2.1.5 - Wild Radish ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.x.x.

• Add --verify-storage command-line argument
• Allow comments in the htpasswd file
• Don't strip whitespaces from user names and passwords in the htpasswd file
• Remove cookies from logging output
• Allow uploads of whole collections with many components
• Show warning message if server.timeout is used with Python < 3.5.2

2.1.4 - Wild Radish ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.x.x.

• Fix incorrect time range matching and calculation for some edge-cases with rescheduled recurrences
• Fix owner property

2.1.3 - Wild Radish ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.x.x.

• Enable timeout for SSL handshakes and move them out of the main thread
• Create cache entries during upload of items
• Stop built-in server on Windows when Ctrl+C is pressed
• Prevent slow down when multiple requests hit a collection during cache warm-up

2.1.2 - Wild Radish ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.x.x.

• Remove workarounds for bugs in VObject < 0.9.5
• Error checking of collection tags and associated components
• Improve error checking of uploaded collections and components
• Don't delete empty collection properties implicitly
• Improve logging of VObject serialization

2.1.1 - Wild Radish Again ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.x.x.

• Add missing UIDs instead of failing
• Improve error checking of calendar and address book objects
• Fix upload of whole address books

2.1.0 - Wild Radish ¶

This release is compatible with version 2.0.0. Follow our migration guide if you want to switch from 1.x.x to 2.1.0.

• Built-in web interface for creating and managing address books and calendars
  • can be extended with web plugins
• Much faster storage backend
• Significant reduction in memory usage
• Improved logging
  • Include paths (of invalid items / requests) in log messages
  • Include configuration values causing problems in log messages
  • Log warning message for invalid requests by clients
  • Log error message for invalid files in the storage backend
  • No stack traces unless debugging is enabled
• Time range filter also regards overwritten recurrences
• Items that couldn't be filtered because of bugs in VObject are always returned (and a warning message is logged)
• Basic error checking of configuration files
• File system locking isn't disabled implicitly anymore, instead a new configuration option gets introduced
• The permissions of the lock file are not changed anymore
• Support for sync-token
• Support for client-side SSL certificates
• Rights plugins can decide if access to an item is granted explicitly
  • Respond with 403 instead of 404 for principal collections of non-existing users when owner_only plugin is used (information leakage)
• Authentication plugins can provide the login and password from the environment
  • new remote_user plugin, that gets the login from the REMOTE_USER environment variable (for WSGI server)
  • new http_x_remote_user plugin, that gets the login from the X-Remote-User HTTP header (for reverse proxies)

2.0.0 - Little Big Radish ¶

This feature is not compatible with the 1.x.x versions. Follow our migration guide if you want to switch from 1.x.x to 2.0.0.

• Support Python 3.3+ only, Python 2 is not supported anymore
• Keep only one simple filesystem-based storage system
• Remove built-in Git support
• Remove built-in authentication modules
• Keep the WSGI interface, use Python HTTP server by default
• Use a real iCal parser, rely on the "vobject" external module
• Add a solid calendar discovery
• Respect the difference between "files" and "folders", don't rely on slashes
• Remove the calendar creation with GET requests
• Be stateless
• Use a file locker
• Add threading
• Get atomic writes
• Support new filters
• Support read-only permissions
• Allow External plugins for authentication, rights management, storage and version control

This release concludes endless months of hard work from the community. You, all users and contributors, deserve a big thank you.

This project has been an increadible experience for me, your dear Guillaume, creator and maintainer of Radicale. After more than 8 years of fun, I think that it's time to open this software to its contributors. Radicale can grow and become more than the toy it used to be. I've always seen Radicale as a small and simple piece of code, and I don't want to prevent people from adding features just because I can't or don't want to maintain them. The community is now large enough to handle this.

If you're interested in Radicale, you can read #372 and build its future.

1.1.2 - Third Law of Nature ¶

• Security fix: Add a random timer to avoid timing oracles and simple bruteforce attacks when using the htpasswd authentication method.
• Various minor fixes.

1.1 - Law of Nature ¶

One feature in this release is not backward compatible:

• Use the first matching section for rights (inspired from daald)

Now, the first section matching the path and current user in your custom rights file is used. In the previous versions, the most permissive rights of all the matching sections were applied. This new behaviour gives a simple way to make specific rules at the top of the file independant from the generic ones.

Many improvements in this release are related to security, you should upgrade Radicale as soon as possible:

• Improve the regex used for well-known URIs (by Unrud)
• Prevent regex injection in rights management (by Unrud)
• Prevent crafted HTTP request from calling arbitrary functions (by Unrud)
• Improve URI sanitation and conversion to filesystem path (by Unrud)
• Decouple the daemon from its parent environment (by Unrud)

Some bugs have been fixed and little enhancements have been added:

• Assign new items to corret key (by Unrud)
• Avoid race condition in PID file creation (by Unrud)
• Improve the docker version (by cdpb)
• Encode message and commiter for git commits
• Test with Python 3.5

1.0 - Sunflower ¶

• Enhanced performances (by Mathieu Dupuy)
• Add MD5-APR1 and BCRYPT for htpasswd-based authentication (by Jan-Philip Gehrcke)
• Use PAM service (by Stephen Paul Weber)
• Don't discard PROPPATCH on empty collections (Markus Unterwaditzer)
• Write the path of the collection in the git message (Matthew Monaco)
• Tests launched on Travis

As explained in a previous mail, this version is called 1.0 because:

• there are no big changes since 0.10 but some small changes are really useful,
• simple tests are now automatically launched on Travis, and more can be added in the future (https://travis-ci.org/Kozea/Radicale).

This version will be maintained with only simple bug fixes on a separate git branch called 1.0.x.

Now that this milestone is reached, it's time to think about the future. When Radicale has been created, it was just a proof-of-concept. The main goal was to write a small, stupid and simple CalDAV server working with Lightning, using no external libraries. That's how we created a piece of code that's (quite) easy to understand, to use and to hack.

The first lines have been added to the SVN (!) repository as I was drinking beers at the very end of 2008. It's now packaged for a growing number of Linux distributions.

And that was fun going from here to there thanks to you. So… Thank you, you're amazing. I'm so glad I've spent endless hours fixing stupid bugs, arguing about databases and meeting invitations, reading incredibly interesting RFCs and debugging with the fabulous clients from Apple. I mean: that really, really was really, really cool :).

During these years, a lot of things have changed and many users now rely on Radicale in production. For example, I use it to manage medical calendars, with thousands requests per day. Many people are happy to install Radicale on their small home servers, but are also frustrated by performance and unsupported specifications when they're trying to use it seriously.

So, now is THE FUTURE! I think that Radicale 2.0 should:

• rely on a few external libraries for simple critical points (dealing with HTTP and iCal for example),
• be thread-safe,
• be small,
• be documented in a different way (for example by splitting the client part from the server part, and by adding use cases),
• let most of the "auth" modules outside in external modules,
• have more and more tests,
• have reliable and faster filesystem and database storage mechanisms,
• get a new design :).

I'd also secretly love to drop the Python 2.x support.

These ideas are not all mine (except from the really, really, really important "design" point :p), they have been proposed by many developers and users. I've just tried to gather them and keep points that seem important to me.

Other points have been discussed with many users and contibutors, including:

• support of other clients, including Windows and BlackBerry phones,
• server-side meeting invitations,
• different storage system as default (or even unique?).

I'm not a huge fan of these features, either because I can't do anything about them, or because I think that they're Really Bad Ideas®™. But I'm ready to talk about them, because, well, I may not be always right!

Need to talk about this? You know how to contact us!

0.10 - Lovely Endless Grass ¶

• Support well-known URLs (by Mathieu Dupuy)
• Fix collection discovery (by Markus Unterwaditzer)
• Reload logger config on SIGHUP (by Élie Bouttier)
• Remove props files when deleting a collection (by Vincent Untz)
• Support salted SHA1 passwords (by Marc Kleine-Budde)
• Don't spam the logs about non-SSL IMAP connections to localhost (by Giel van Schijndel)

This version should bring some interesting discovery and auto-configuration features, mostly with Apple clients.

Lots of love and kudos for the people who have spent hours to test features and report issues, that was long but really useful (and some of you have been really patient :p).

Issues are welcome, I'm sure that you'll find horrible, terrible, crazy bugs faster than me. I'll release a version 0.10.1 if needed.

What's next? It's time to fix and improve the storage methods. A real API for the storage modules is a good beginning, many pull requests are already ready to be discussed and merged, and we will probably get some good news about performance this time. Who said "databases, please"?

0.8 - Rainbow ¶

• New authentication and rights management modules (by Matthias Jordan)
• Experimental database storage
• Command-line option for custom configuration file (by Mark Adams)
• Root URL not at the root of a domain (by Clint Adams, Fabrice Bellet, Vincent Untz)
• Improved support for iCal, CalDAVSync, CardDAVSync, CalDavZAP and CardDavMATE
• Empty PROPFIND requests handled (by Christoph Polcin)
• Colon allowed in passwords
• Configurable realm message

This version brings some of the biggest changes since Radicale's creation, including an experimental support of database storage, clean authentication modules, and rights management finally designed for real users.

So, dear user, be careful: this version changes important things in the configuration file, so check twice that everything is OK when you update to 0.8, or you can have big problems.

More and more clients are supported, as a lot of bug fixes and features have been added for this purpose. And before you ask: yes, 2 web-based clients, CalDavZAP and CardDavMATE, are now supported!

Even if there has been a lot of time to test these new features, I am pretty sure that some really annoying bugs have been left in this version. We will probably release minor versions with bugfixes during the next weeks, and it will not take one more year to reach 0.8.1.

The documentation has been updated, but some parts are missing and some may be out of date. You can report bugs or even write documentation directly on GitHub if you find something strange (and you probably will).

If anything is not clear, or if the way rights work is a bit complicated to understand, or if you are so happy because everything works so well, you can share your thoughts!

It has been a real pleasure to work on this version, with brilliant ideas and interesting bug reports from the community. I'd really like to thank all the people reporting bugs, chatting on IRC, sending mails and proposing pull requests: you are awesome.

0.7.1 - Waterfalls ¶

• Many address books fixes
• New IMAP ACL (by Daniel Aleksandersen)
• PAM ACL fixed (by Daniel Aleksandersen)
• Courier ACL fixed (by Benjamin Frank)
• Always set display name to collections (by Oskari Timperi)
• Various DELETE responses fixed

It's been a long time since the last version… As usual, many people have contributed to this new version, that's a pleasure to get these pull requests.

Most of the commits are bugfixes, especially about ACL backends and address books. Many clients (including aCal and SyncEvolution) will be much happier with this new version than with the previous one.

By the way, one main new feature has been added: a new IMAP ACL backend, by Daniel. And about authentication, exciting features are coming soon, stay tuned!

Next time, as many mails have come from angry and desperate coders, tests will be finally added to help them to add features and fix bugs. And after that, who knows, it may be time to release Radicale 1.0…

0.7 - Eternal Sunshine ¶

• Repeating events
• Collection deletion
• Courier and PAM authentication methods
• CardDAV support
• Custom LDAP filters supported

A lot of people have reported bugs, proposed new features, added useful code and tested many clients. Thank you Lynn, Ron, Bill, Patrick, Hidde, Gerhard, Martin, Brendan, Vladimir, and everybody I've forgotten.

0.6.4 - Tulips ¶

• Fix the installation with Python 3.1

The bug was in fact caused by a bug in Python 3.1, everything should be OK now.

Calypso ¶

After a lot of changes in Radicale, Keith Packard has decided to launch a fork called Calypso, with nice features such as a Git storage mechanism and a CardDAV support.

There are lots of differences between the two projects, but the final goal for Radicale is to provide these new features as soon as possible. Thanks to the work of Keith and other people on GitHub, a basic CardDAV support has been added in the carddav branch and already works with Evolution. Korganizer also works with existing address books, and CardDAV-Sync will be tested soon. If you want to test other clients, please let us know!

0.6.3 - Red Roses ¶

• MOVE requests fixed
• Faster REPORT answers
• Executable script moved into the package

What's New Since 0.6.2? ¶

The MOVE requests were suffering a little bug that is fixed now. These requests are only sent by Apple clients, Mac users will be happy.

The REPORT request were really, really slow (several minutes for large calendars). This was caused by an awful algorithm parsing the entire calendar for each event in the calendar. The calendar is now only parsed three times, and the events are found in a Python list, turning minutes into seconds! Much better, but far from perfection…

Finally, the executable script parsing the command line options and starting the HTTP servers has been moved from the radicale.py file into the radicale package. Two executable are now present in the archive: the good old radicale.py, and bin/radicale. The second one is only used by setup.py, where the hack used to rename radicale.py into radicale has therefore been removed. As a consequence, you can now launch Radicale with the simple python -m radicale command, without relying on an executable.

Time for a Stable Release! ¶

The next release may be a stable release, symbolically called 1.0. Guess what's missing? Tests, of course!

A non-regression testing suite, based on the clients' requests, will soon be added to Radicale. We're now thinking about a smart solution to store the tests, to represent the expected answers and to launch the requests. We've got crazy ideas, so be prepared: you'll definitely want to write tests during the next weeks!

Repeating events, PAM and Courier authentication methods have already been added in master. You'll find them in the 1.0 release!

What's Next? ¶

Being stable is one thing, being cool is another one. If you want some cool new features, you may be interested in:

• WebDAV and CardDAV support
• Filters and rights management
• Multiple storage backends, such as databases and git
• Freebusy periods
• Email alarms

Issues have been reported in the bug tracker, you can follow there the latest news about these features. Your beloved text editor is waiting for you!

0.6.2 - Seeds ¶

• iPhone and iPad support fixed
• Backslashes replaced by slashes in PROPFIND answers on Windows
• PyPI archive set as default download URL

0.6.1 - Growing Up ¶

• Example files included in the tarball
• htpasswd support fixed
• Redirection loop bug fixed
• Testing message on GET requests

The changelog is really small, so there should be no real new problems since 0.6. The example files for logging, FastCGI and WSGI are now included in the tarball, for the pleasure of our dear packagers!

A new branch has been created for various future bug fixes. You can expect to get more 0.6.x versions, making this branch a kind of "stable" branch with no big changes.

GitHub, Mailing List, New Website ¶

A lot of small changes occurred during the last weeks.

If you're interested in code and new features, please note that we moved the project from Gitorious to GitHub. Being hosted by Gitorious was a nice experience, but the service was not that good and we were missing some useful features such as git hooks. Moreover, GitHub is really popular, we're sure that we'll meet a lot of kind users and coders there.

We've also created a mailing-list on Librelist to keep a public trace of the mails we're receiving. It a bit empty now, but we're sure that you'll soon write us some kind words. For example, you can tell us what you think of our new website!

Future Features ¶

In the next weeks, new exciting features are coming in the master branch! Some of them are almost ready:

• Henry-Nicolas has added the support for the PAM and Courier-Authdaemon authentication mechanisms.
• An anonymous called Keith Packard has prepared some small changes, such as one file per event, cache and git versioning. Yes. Really.

As you can find in the Radicale Roadmap, tests, rights and filters are expected for 0.7.

0.6 - Sapling ¶

• WSGI support
• IPv6 support
• Smart, verbose and configurable logs
• Apple iCal 4 and iPhone support (by Łukasz Langa)
• CalDAV-Sync support (by Marten Gajda)
• aCal support
• KDE KOrganizer support
• LDAP auth backend (by Corentin Le Bail)
• Public and private calendars (by René Neumann)
• PID file
• MOVE requests management
• Journal entries support
• Drop Python 2.5 support

Well, it's been a little longer than expected, but for good reasons: a lot of features have been added, and a lot of clients are known to work with Radicale, thanks to kind contributors. That's definitely good news! But…

Testing all the clients is really painful, moreover for the ones from Apple (I have no Mac nor iPhone of my own). We should seriously think of automated tests, even if it's really hard to maintain, and maybe not that useful. If you're interested in tests, you can look at the wonderful regression suite of DAViCal.

The new features, for example the WSGI support, are also poorly documented. If you have some Apache or lighttpd configuration working with Radicale, you can make the world a little bit better by writing a paragraph or two in the Radicale documentation. It's simple plain text, don't be afraid!

Because of all these changes, Radicale 0.6 may be a little bit buggy; a 0.6.1 will probably be released soon, fixing small problems with clients and features. Get ready to report bugs, I'm sure that you can find one (and fix it)!

LDAP Authentication ¶

Thanks to Corentin, the LDAP authentication is now included in Radicale. The support is experimental and may suffer unstable connexions and security problems. If you are interested in this feature (a lot of people seem to be), you can try it and give some feedback.

No SSL support is included yet, but this may be quite easy to add. By the way, serious authentication methods will rely on a "real" HTTP server, as soon as Radicale supports WSGI.

Journal Entries ¶

Mehmet asked for the journal entries (aka. notes or memos) support, that's done! This also was an occasion to clean some code in the iCal parser, and to add a much better management of multi-lines entries. People experiencing crazy X-RADICALE-NAME entries can now clean their files, Radicale won't pollute them again.

New Roadmap ¶

Except from htpasswd and LDAP, most of the authentication backends (database, SASL, PAM, user groups) are not really easy to include in Radicale. The easiest solution to solve this problem is to give Radicale a CGI support, to put it behind a solid server such as Apache. Of course, CGI is not enough: a WSGI support is quite better, with the FastCGI, AJP and SCGI backends offered by flup. Quite exciting, isn't it?

That's why it was important to add new versions on the roadmap. The 0.6 version is now waiting for the Apple iCal support, and of course for some tests to kill the last remaining bugs. The only 0.7 feature will be WSGI, allowing many new authentication methods and a real multithread support.

After that, 0.8 may add CalDAV rights and filters, while 1.0 will draw thousands of rainbows and pink unicorns (WebDAV sync, CardDAV, Freebusy). A lot of funky work is waiting for you, hackers!

Bugs ¶

Many bugs have also been fixed, most of them due to the owner-less calendars support. Radicale 0.6 may be out in a few weeks, you should spend some time testing the master branch and filling the bug tracker.

0.5 - Historical Artifacts ¶

• Calendar depth
• iPhone support
• MacOS and Windows support
• HEAD requests management
• htpasswd user from calendar path

iPhone support, but no iCal support for 0.5, despite our hard work, sorry! After 1 month with no more activity on the dedicated bug, it was time to forget it and hack on new awesome features. Thanks for your help, dear Apple users, I keep the hope that one day, Radicale will work with you!

So, what's next? As promised, some cool git branches will soon be merged, with LDAP support, logging, IPv6 and anonymous calendars. Sounds pretty cool, heh? Talking about new features, more and more people are asking for a CardDAV support in Radicale. A git branch and a feature request are open, feel free to hack and discuss.

0.4 - Hot Days Back ¶

• Personal calendars
• HEAD requests
• Last-Modified HTTP header
• no-ssl and foreground options
• Default configuration file

This release has mainly been released to help our dear packagers to include a default configuration file and to write init scripts. Big thanks to Necoro for his work on the new Gentoo ebuild!

0.3 - Dancing Flowers ¶

• Evolution support
• Version management

The website changed a little bit too, with some small HTML5 and CSS3 features such as articles, sections, transitions, opacity, box shadows and rounded corners. If you’re reading this website with Internet Explorer, you should consider using a standard-compliant browser!

Radicale is now included in Squeeze, the testing branch of Debian. A Radicale ebuild for Gentoo has been proposed too. If you want to package Radicale for another distribution, you’re welcome!

Next step is 0.5, with calendar collections, and Windows and MacOS support.

News from contributors ¶

Jonas Smedegaard packaged Radicale for Debian last week. Two packages, called radicale for the daemon and python-radicale for the module, have been added to Sid, the unstable branch of Debian. Thank you, Jonas!

Sven Guckes corrected some of the strange-English-sentences present on this website. Thank you, Sven!

News from software ¶

A simple VERSION has been added in the library: you can now play with radicale.VERSION and $radicale --version.

After playing with the version (should not be too long), you may notice that the next version is called 0.3, and not 0.5 as previously decided. The 0.3 main goal is to offer the support for Evolution as soon as possible, without waiting for the 0.5. After more than a month of test, we corrected all the bugs we found and everything seems to be fine; we can imagine that a brand new tarball will be released during the first days of June.

0.2 - Snowflakes ¶

• Sunbird pre-1.0 support
• SSL connection
• Htpasswd authentication
• Daemon mode
• User configuration
• Twisted dependency removed
• Python 3 support
• Real URLs for PUT and DELETE
• Concurrent modification reported to users
• Many bugs fixed by Roger Wenham

First of all, we would like to thank Roger Wenham for his bugfixes and his supercool words.

You may have noticed that Sunbird 1.0 has not been released, but according to the Mozilla developers, 1.0pre is something like a final version.

You may have noticed too that Radicale can be downloaded from PyPI. Of course, it is also available on the download page.

0.1 - Crazy Vegetables ¶

• First release
• Lightning/Sunbird 0.9 compatibility
• Easy installer

You can download this version on the download page.