| Part | -Layer | -Protocol or Format | -
|---|---|---|
| Server | -Calendar/Contact Storage | -iCal/vCard | -
| Calendar/Contact Server | -CalDAV/CardDAV Server | -|
| Transfer | -Network | -CalDAV/CardDAV (HTTP + TLS) | -
| Client | -Calendar/Contact Client | -CalDAV/CardDAV Client | -
| GUI | -Terminal, GTK, Web interface, etc. | -
Free and Open-Source CalDAV and CardDAV Server
-The Radicale Project is a complete CalDAV (calendar) and CardDAV (contact) server solution.
-Calendars and address books are available for both local and remote access, possibly limited through authentication policies. They can be viewed and edited by calendar and contact clients on mobile phones or computers.
-Radicale aims to be a light solution, easy to use, easy to install, easy to configure. As a consequence, it requires few software dependencies and is pre-configured to work out-of-the-box.
-Radicale runs on most of the UNIX-like platforms (Linux, *BSD, MacOS X) and Windows. It is free and open-source software, written in Python, released under GPL version 3.
-Radicale supports the latest versions of many CalDAV and CardDAV clients.
-This document describes how to install and configure the server.
- -This document defines the main goals of the Radicale Project, what it covers and what it does not.
- -This document describes the global technical choices of the Radicale Project and the global architectures of its different parts.
- -Radicale is written in pure Python and does not depend on any library. It is known to work on Python 2.6, 2.7, 3.1, 3.2, 3.3, 3.4 and PyPy > 1.9. The dependencies are optional, as they are only needed for various authentication methods[1].
-Linux and MacOS users certainly have Python already installed. For Windows users, please install Python[2] thanks to the adequate installer.
-Radicale can be freely downloaded on the project website, download section. Just get the file and unzip it in a folder of your choice.
-At this time Radicale has been tested and works fine with the latest version of:
-More clients will be supported in the future. However, it may work with any calendar or contact client which implements CalDAV or CardDAV specifications too (luck is highly recommended).
-To start Radicale CalDAV server, you have to launch the file called radicale.py located in the root folder of the software package.
After starting Lightning, click on File and New Calendar. Upcoming window asks you about your calendar storage. Chose a calendar On the Network, otherwise Lightning will use its own file system storage instead of Radicale's one and your calendar won't be remotely accessible.
Next window asks you to provide information about remote calendar access. Protocol used by Radicale is CalDAV. A standard location for a basic use of a Radicale calendar is http://localhost:5232/user/calendar.ics/, where you can replace user and calendar.ics by some strings of your choice. Calendars are automatically created if needed. Please note that the trailing slash is important.
You can now customize your calendar by giving it a nickname and a color. This is only used by Lightning to identify calendars among others.
-If no warning sign appears next to the calendar name, you can now add events and tasks to your calendar. All events and tasks are stored in the server, they can be accessed and modified from multiple clients by multiple users at the same time.
-Lightning and Thunderbird cannot access CardDAV servers yet. Also, as of version 17.0.5 the SOGo Connector addon is not fully functionally and will create extra address book entries with every sync.
-Calendars ¶
-First of all, show the calendar page in Evolution by clicking on the calendar icon at the bottom of the side pane. Then add a new calendar by choosing in the menu File → New → Calendar.
A new window opens. The calendar type is CalDAV, and the location is something like http://localhost:5232/user/calendar.ics/, where you can replace user and calendar by some strings of your choice. Calendars are automatically created if needed. Please note that the trailing slash is important.
You can fill other attributes like the color and the name, these are only used for Evolution and are not uploaded.
-Click on OK, and your calendar should be ready for use.
Contacts ¶
-Switch to the contacts page and click File → New → Adress book. In the new window choose WebDAV as type and something like http://localhost:5232/user/addressbook.vcf/ as location. Remember to enter the correct username.
Calendars ¶
-Tested with 4.8.3, you need one running on Akonadi for Cal/CarDav support.
-The procedure below can also be done trough the sidebar "Calendar Manager". But to ensure it works for everyone this examples uses the menu-bar.
-Settings → Configure KOrganizer.General → Calendars.Add.DAV groupware resource (and click OK).Next).Configure the resource manually (and click on Finish).Add.CalDav.http://myserver:5232/Username/Calendar.ics/Fetch.OK.OK again.OK).--Note
-After you created a calender in a collection you can also use
-http://myserver:5232/Username/as an URL This will then list all available calendars.
Contacts ¶
-You can add a address book analogously to the above instructions, just choose CardDav and http://myserver:5232/Username/AddressBook.vcf/ in step 10 and 11. Also, if you already have a calendar set up you can add an address book to its "DAV groupware resource" under Configure-Kontact → Calendar → General → Calendars → Modify. This way you don't have to enter username and password twice.
CalendarSync can be combined with any Android calendar app and can even store the calendars in existing Android calendars which are synced by other sync adapters. Of course it can also create its own calendars.
-So, to sync using CalendarSync you will have to:
-Menu button,Create WebiCal,Then enter your URL, Username and Password. As URL please use http(s)://server:port/username/.
If you can use HTTPS depends on your setup. Please replace username with the name of your user account.
Press test connection button. If everything signaled as OK then press search calendars button, select the calendars which you want to sync, and press the configure calendar button at the top of the display. Your calendars are now configured.
-You can then start the first sync by going back to the main screen of the app an pressing the Process Webicals button. Of course you can also configure the app at its preferences to sync automatically.
ContactSync is designed to sync contacts from and to various sources. It can also overtake contacts and push them to the server, also if they are only available on the device (local only contacts).
-So to sync your contacts from the Radical server to your Android device:
-Menu button,Create WebContact,As URL please use http(s)://server:port/username/.
At the URL you will have to replace server:port and username so that it matches your specific setup. It also depends on your configuration if you can use HTTPS or if you have to use HTTP.
Press test connection button, if everything signaled as OK then press search address book button. Select the address books which you want to sync and press the configure address book button at the top of the display.
-You can then start the first sync by going back to the main screen of the app and pressing the Handle WebContacts button. Of course you can also configure the app at its preferences to sync automatically.
CalDAV-Sync is implemented as sync adapter to integrate seamlessly with any calendar app and widget. Therefore you have to access it via Accounts & Sync settings after installing it from the Market.
So, to add new calendars to your phone open Accounts & Sync settings and tap on Add account, selecting CalDAV as type. In the next view, you have to switch to Manual Mode. Enter the full CalDAV URL of your Radicale account (e.g. http://example.com:5232/Username/) and corresponding login data. If you want to create a new calendar you have to specify its full URL e.g. http://example.com:5232/Username/Calendar.ics/. Please note that the trailing slash is important.
Tap on Next and the app checks for all available calendars on your account, listing them in the next view. (Note: CalDAV-Sync will not only check under the url you entered but also under http://example.com:5232/UsernameYouEnteredForLogin/. This might cause strange errors.) You can now select calendars you want to sync and set a local nickname and color for each. Hitting Next again brings up the last page. Enter your email address and uncheck Sync from server to phone only if you want to use two-way-sync.
--Note
-CalDAV-Sync officially is in alpha state and two-way-sync is marked as an experimental feature. Though it works fine for me, using two-way-sync is on your own risk!
-
Tap on Finish and you're done. You're now able to use the new calendars in the same way you were using Google calendars before.
Set up works like CalDAV-Sync, just use .vcf instead of .ics if you enter the URL, e.g. http://example.com:5232/Username/AddressBook.vcf/.
DAVdroid is a free and open-source CalDAV/CardDAV client that is available in Play Store for a small fee or in FDroid for free.
-To make it working with Radicale, just add a new DAVdroid account and enter https://example.com/radicale/user/ as base URL (assuming that your Radicale runs at https://example.com/radicale/; don't forget to set base_prefix correctly).
aCal is a CalDAV client for Android. It comes with its own calendar application and does not integrate in the Android calendar. It is a "CalDAV only" calendar, i.e. it only works in combination with a CalDAV server. It can connect to several calendars on the server and will display them all in one calendar. It works nice with Radicale.
-To configure aCal, start aCal, go to the Settings screen, select Server, then Add server. Choose Manual Configuration and select Advanced (bottom of the screen). Then enter the host name of your server, check Active, enter your user name and password. The Simple Domain of your server is the domain part of your fully qualified host name (e.g. if your server is myserver.mydomain.org, choose mydomain.org).
As Simple Path you need to specify /<user> where user is the user you use to connect to Radicale. Server Name is the fully qualified name of your server machine (myserver.mydomain.org). The Server Path is /<user>/.
For Authentication Type you need to specify the method you chose for Radicale. Check Use SSL if your Radicale is configured to use SSL.
As the last thing you need to specify the port Radicale listens to. When your server is configured you can go back to the first Settings screen, and select Calendars and Addressbooks. You should find all the calendars that are available to your user on the Radicale server. You can then configure each of them (display colour, notifications, etc.).
Because settings are the same for InfCloud, CalDavZAP and CardDavMATE
-only InfCloud is used in description below.
Radicale configuration ¶
-Add/Modify the following section in Radicale main configuration file:
-# Additional HTTP headers
-[headers]
-Access-Control-Allow-Origin = *
-Access-Control-Allow-Methods = GET, POST, OPTIONS, PROPFIND, PROPPATCH, REPORT, PUT, MOVE, DELETE, LOCK, UNLOCK
-Access-Control-Allow-Headers = Authorization, Content-type, Depth, Destination, If-match, If-None-Match, Lock-Token, Overwrite, Prefer, Timeout, User-Agent, X-Client, X-Requested-With
-Access-Control-Expose-Headers = EtagInfCloud needs read access for everybody (including anonymous users) on Radicale's root directory. If using Radicales rights management add the following section to rights file:
# Allow caldavzap, carddavmate and infcloud to work
-[infcloud]
-user: .*
-collection: /
-permission: rAdditional you need to change [owner-write] section to use the same syntax for collection as shown in [public] section.
InfCloud configuration ¶
-Inside InfCloud configuration file config.js you need to set globalNetworkCheckSettings like following example:
// href:
-// put in here your protocol, host and port where Radicale is listening
-// additionalResources:
-// put in here a comma separated list of collections you want additionally look at.
-// Don't forget '' around each collections name
-var globalNetworkCheckSettings={
- href: 'https://host.example.com:5232/',
- hrefLabel: null,
- crossDomain: null,
- additionalResources: ['public'],
- forceReadOnly: null,
- withCredentials: false,
- showHeader: true,
- settingsAccount: true,
- syncInterval: 60000,
- timeOut: 30000,
- lockTimeOut: 10000,
- delegation: false,
- ignoreAlarms: false,
- backgroundCalendars: []
-}--Note
--
InfCloud,CardDavMATEandCalDavZAPcannot create calendars and/or address books. They need to be created before first login. Each user needs to have minimum of one calendar and/or one adressbook even if only using shared addresses and/or calendars. Client will not login, if the user collections don't exists.
You can easily create them by directly calling the URL's from your browser:
- http(s)://host.example.com:5232/user/calendar.ics/
- http(s)://host.example.com:5232/user/addresses.vcf/
Replace "http(s)" with the correct protocol, "host.example.com:5232" with you host:port where Radicale is running,
-"user" with the correct login name or the shared resource name i.e. 'public',
-"calendar.ics" and "addresses.vcf" with the collection names you want to use
-and do NOT forget the '/' at line end.
--Note
-If using self-signed certificates you need to do the following steps before using
-InfCloud, CardDavMATEorCalDavZAP.
-With your browser call one of the above URLs.
-Your browser warn you that you are trying to access anInsecuresite.
-Download and accept the certificate offered by the Radicale server.
-After installing and accepting it you should restart your browser.
Calendars ¶
-For iOS devices, the setup is fairly straightforward but there are a few settings that are critical for proper operation.
-SettingsMail, Contacts, CalendarsAdd Account… → Other → Add CalDAV Accounthttps, the port, and the user/calendar path, ex: https://myserver.domain.com:3000/bob/birthdays.ics/ (please note that the trailing slash is important)Description field. Otherwise it will put the whole servername in the field.Mail, Contacts, Calendars screen and scroll down to the Calendars section. You must change the Sync option to sync All events otherwise new events won't show up on your iOS devices!--Note
-Everything should be working now so test creating events and make sure they stay created. If you create events on your iOS device and they disappear after the fetch period, you probably forgot to change the sync setting in step 7. Likewise, if you create events on another device and they don't appear on your iPad of iPhone, then make sure your sync settings are correct
-
--Warning
-In iOS 5.x, please check twice that the
-Sync all entriesoption is activated, otherwise some events may not be shown in your calendar.
Contacts ¶
-In Contacts on iOS 6:
-SettingsMail, Contacts, CalendarsAdd Account… → Other → Add CardDAV AccountServer use the Radicale server URL with port, for example localhost:5232User name you like (if you didn't configure authentication)Password you like (again, if you didn't configure authentication)Description to something more readable (optional)NextCannot Connect Using SSL will pop up as we haven't configured SSL yet, Continue for nowMail, Contacts, Calendars screen you scroll to the Contacts section, select the Radicale server as Default Account when you want to save new contacts to the Radicale serverContacts, tap Groups, you should see the Radicale server--Note
-You'll need version 0.8.1 or up for this to work. Earlier versions will forget your new settings after a reboot.
-
--Note
-This description assumes you do not have any authentication or encryption configured. If you want to use iCal with authentication or encryption, you just have to fill in the corresponding fields in your calendar's configuration.
-
Calendars ¶
-In iCal 4.0 or iCal 5.0:
-Preferences dialog and select the Accounts tab+ button at the lower left to open the account creation wizardAccount type select CalDAVUser name you likePassword field can be left empty (we did not configure authentication)Server address use domain:port, for example localhost:5232 (this would be the case if you start an unconfigured Radicale on your local machine)Click Create. The wizard will now tell you, that no encryption is in place (Unsecured Connection). This is expected and will change if you configure Radicale to use SSL. Click Continue.
--Warning
-In iCal 5.x, please check twice that the
-Sync all entriesoption is activated, otherwise some events may not be shown in your calendar.
The wizard will close, leaving you in the Account tab again. The account is now set-up. You can close the Preferences window.
--Important
-To add a calendar to your shiny new account you have to go to the menu and select
-File → New Calendar → <your shiny new account>. A new calendar appears in the left panel waiting for you to enter a name.This is needed because the behaviour of the big
-+button in the main window is confusing as you can't focus an empty account and iCal will just add a calendar to another account.
Contacts ¶
-In Contacts 7 (previously known as AddressBook):
-Preferences dialog and select the Accounts tab.+ button at the lower left to open the account creation wizard.Account type select CardDAV.User name you like.Password field can be left empty (if we didn't configure authentication).Server address use domain:port, for example localhost:5232 (this would be the case if you start an unconfigured Radicale server on your local machine).Create. Contacts will complain about an Unsecured Connection if you don't have SSL enabled. Click Create again.Description of the newly added account to something more readable. (optional)General tab in the preferences and select the Radicale server as Default Account at the bottom of the screen. It probably shows up as `domain:port or the name you choose if you changed the description. Newly added contacts are added to the default account and by default this will be the local On My Mac account.--Note
-You'll need version 0.8.1 or up for this to work. Earlier versions can read CardDAV contacts but can't add new contacts.
-
You can find more information about syncEvolution and Radicale on the syncEvolution wiki page.
-https://my.server.fi:5232/myusername/calendarname.ics/Don't forget to add your CA to the phone if you're using a self-signed certificate on your Radicale. Make the CA downloadable to Internet Explorer. The correct certificate format is X509 (with .cer file extension).
---Note
-This section is written for Linux users, but can be easily adapted for Windows and MacOS users.
-
You can install Radicale thanks to the following command, with superuser rights:
-python setup.py install
-Then, launching the server can be easily done by typing as a normal user:
-radicale
---Note
-This section is following the latest stable version changes. Please look at the default configuration file included in your package if you have an older version of Radicale.
-
The server configuration can be modified in /etc/radicale/config or in ~/.config/radicale/config. You can use the --config parameter in the command line to choose a specific path. You can also set the RADICALE_CONFIG environment variable to a path of your choice. Here is the default configuration file, with the main parameters:
[server]
-
-# CalDAV server hostnames separated by a comma
-# IPv4 syntax: address:port
-# IPv6 syntax: [address]:port
-# For example: 0.0.0.0:9999, [::]:9999
-# IPv6 adresses are configured to only allow IPv6 connections
-#hosts = 0.0.0.0:5232
-
-# Daemon flag
-#daemon = False
-
-# File storing the PID in daemon mode
-#pid =
-
-# SSL flag, enable HTTPS protocol
-#ssl = False
-
-# SSL certificate path
-#certificate = /etc/apache2/ssl/server.crt
-
-# SSL private key
-#key = /etc/apache2/ssl/server.key
-
-# SSL Protocol used. See python's ssl module for available values
-#protocol = PROTOCOL_SSLv23
-
-# Ciphers available. See python's ssl module for available ciphers
-#ciphers =
-
-# Reverse DNS to resolve client address in logs
-#dns_lookup = True
-
-# Root URL of Radicale (starting and ending with a slash)
-#base_prefix = /
-
-# Possibility to allow URLs cleaned by a HTTP server, without the base_prefix
-#can_skip_base_prefix = False
-
-# Message displayed in the client when a password is needed
-#realm = Radicale - Password Required
-
-
-[encoding]
-
-# Encoding for responding requests
-#request = utf-8
-
-# Encoding for storing local collections
-#stock = utf-8
-
-
-[well-known]
-
-# Path where /.well-known/caldav/ is redirected
-#caldav = '/%(user)s/caldav/'
-
-# Path where /.well-known/carddav/ is redirected
-#carddav = '/%(user)s/carddav/'
-
-
-[auth]
-
-# Authentication method
-# Value: None | htpasswd | IMAP | LDAP | PAM | courier | http | remote_user | custom
-#type = None
-
-# Custom authentication handler
-#custom_handler =
-
-# Htpasswd filename
-#htpasswd_filename = /etc/radicale/users
-
-# Htpasswd encryption method
-# Value: plain | sha1 | ssha | crypt | bcrypt | md5
-#htpasswd_encryption = crypt
-
-# LDAP server URL, with protocol and port
-#ldap_url = ldap://localhost:389/
-
-# LDAP base path
-#ldap_base = ou=users,dc=example,dc=com
-
-# LDAP login attribute
-#ldap_attribute = uid
-
-# LDAP filter string
-# placed as X in a query of the form (&(...)X)
-# example: (objectCategory=Person)(objectClass=User)(memberOf=cn=calenderusers,ou=users,dc=example,dc=org)
-# leave empty if no additional filter is needed
-#ldap_filter =
-
-# LDAP dn for initial login, used if LDAP server does not allow anonymous searches
-# Leave empty if searches are anonymous
-#ldap_binddn =
-
-# LDAP password for initial login, used with ldap_binddn
-#ldap_password =
-
-# LDAP scope of the search
-#ldap_scope = OneLevel
-
-# IMAP Configuration
-#imap_hostname = localhost
-#imap_port = 143
-#imap_ssl = False
-
-# PAM group user should be member of
-#pam_group_membership =
-
-# Path to the Courier Authdaemon socket
-#courier_socket =
-
-# HTTP authentication request URL endpoint
-#http_url =
-# POST parameter to use for username
-#http_user_parameter =
-# POST parameter to use for password
-#http_password_parameter =
-
-
-[git]
-
-# Git default options
-#committer = Radicale <radicale@example.com>
-
-
-[rights]
-
-# Rights backend
-# Value: None | authenticated | owner_only | owner_write | from_file | custom
-#type = None
-
-# Custom rights handler
-#custom_handler =
-
-# File for rights management from_file
-#file = ~/.config/radicale/rights
-
-
-[storage]
-
-# Storage backend
-# -------
-# WARNING: ONLY "filesystem" IS DOCUMENTED AND TESTED,
-# OTHER BACKENDS ARE NOT READY FOR PRODUCTION.
-# -------
-# Value: filesystem | multifilesystem | database | custom
-#type = filesystem
-
-# Custom storage handler
-#custom_handler =
-
-# Folder for storing local collections, created if not present
-#filesystem_folder = ~/.config/radicale/collections
-
-# Database URL for SQLAlchemy
-# dialect+driver://user:password@host/dbname[?key=value..]
-# For example: sqlite:///var/db/radicale.db, postgresql://user:password@localhost/radicale
-# See http://docs.sqlalchemy.org/en/rel_0_8/core/engines.html#sqlalchemy.create_engine
-#database_url =
-
-
-[logging]
-
-# Logging configuration file
-# If no config is given, simple information is printed on the standard output
-# For more information about the syntax of the configuration file, see:
-# http://docs.python.org/library/logging.config.html
-#config = /etc/radicale/logging
-# Set the default logging level to debug
-#debug = False
-# Store all environment variables (including those set in the shell)
-#full_environment = False
-
-
-[headers]
-
-# Additional HTTP headers
-#Access-Control-Allow-Origin = *This configuration file is read each time the server is launched. If some values are not given, the default ones are used. If no configuration file is available, all the default values are used.
-Radicale uses the default logging facility for Python. The default configuration prints the information messages to the standard output. It is possible to print debug messages thanks to:
-radicale --debug
-Radicale can also be configured to send the messages to the console, logging files, syslog, etc. For more information about the syntax of the configuration file, see: http://docs.python.org/library/logging.config.html. Here is an example of logging configuration file:
-# Loggers, handlers and formatters keys
-
-[loggers]
-# Loggers names, main configuration slots
-keys = root
-
-[handlers]
-# Logging handlers, defining logging output methods
-keys = console,file
-
-[formatters]
-# Logging formatters
-keys = simple,full
-
-
-# Loggers
-
-[logger_root]
-# Root logger
-level = DEBUG
-handlers = console,file
-
-
-# Handlers
-
-[handler_console]
-# Console handler
-class = StreamHandler
-level = INFO
-args = (sys.stdout,)
-formatter = simple
-
-[handler_file]
-# File handler
-class = FileHandler
-args = ('/var/log/radicale',)
-formatter = full
-
-
-# Formatters
-
-[formatter_simple]
-# Simple output format
-format = %(message)s
-
-[formatter_full]
-# Full output format
-format = %(asctime)s - %(levelname)s: %(message)sAll the options of the server part can be changed with command line options. These options are available by typing:
radicale --help
-Radicale comes with a WSGI support, allowing the software to be used behind any HTTP server supporting WSGI such as Apache.
-Moreover, it is possible to use flup to wrap Radicale into a CGI, FastCGI, SCGI or AJP application, and therefore use it with Lighttpd, Nginx or even Tomcat.
-To use Radicale with Apache's mod_wsgi, you first have to install the Radicale module in your Python path and write your .wsgi file (in /var/www for example):
--Note
-The
-hosts,daemon,pid,ssl,certificate,key,protocolandcipherskeys of the[server]part of the configuration are ignored.
Next you have to create the Apache virtual host (adapt the configuration to your environment):
-<VirtualHost *:80>
- ServerName cal.yourdomain.org
-
- WSGIDaemonProcess radicale user=www-data group=www-data threads=1
- WSGIScriptAlias / /var/www/radicale.wsgi
-
- <Directory /var/www>
- WSGIProcessGroup radicale
- WSGIApplicationGroup %{GLOBAL}
- AllowOverride None
- Order allow,deny
- allow from all
- </Directory>
-</VirtualHost>--Warning
-You should use the root of the (sub)domain (
-WSGIScriptAlias /), else some CalDAV features may not work.
If you want to use authentication with Apache, you really should use one of the Apache authentication modules, instead of the ones from Radicale: they're just better.
-Deactivate any rights and module in Radicale and use your favourite Apache authentication backend. You can then restrict the access: allow the alice user to access /alice/* URLs, and everything should work as expected.
Here is one example of Apache configuration file:
-<VirtualHost *:80>
- ServerName radicale.local
-
- WSGIDaemonProcess radicale user=radicale group=radicale threads=1
- WSGIScriptAlias / /usr/share/radicale/radicale.wsgi
-
- <Directory /usr/share/radicale/>
- WSGIProcessGroup radicale
- WSGIApplicationGroup %{GLOBAL}
-
- AuthType Basic
- AuthName "Radicale Authentication"
- AuthBasicProvider file
- AuthUserFile /usr/share/radicale/radicale.passwd
-
- AllowOverride None
- Require valid-user
-
- RewriteEngine On
- RewriteCond %{REMOTE_USER}%{PATH_INFO} !^([^/]+/)\1
- RewriteRule .* - [Forbidden]
- </Directory>
-</VirtualHost>If you're still convinced that access control is better with Radicale, you have to add WSGIPassAuthorization On in your Apache configuration files, as explained in the mod_wsgi documentation.
--Note
-Read-only calendars or address books can also be served by a simple Apache HTTP server, as Radicale stores full-text icalendar and vcard files with the default configuration.
-
Authentication is possible through:
-Check the [auth] section of your configuration file to know the different options offered by these authentication modules.
Some authentication methods need additional modules, see Python Versions and OS Support for further information.
-You can also write and use a custom module handle authentication if you use a different technology.
-Please note that these modules have not been verified by security experts. If you need a really secure way to handle authentication, you should put Radicale behind a real HTTP server and use its authentication and rights management methods.
-You can set read and write rights for collections according to the authenticated user and the owner of the collection.
-The owner of a collection is determined by the URL of the collection. For example, http://my.server.com:5232/anna/calendar.ics/ is owned by the user called anna.
The authenticated user is the login used for authentication.
-5 different configurations are available, you can choose the one you want in your configuration file. You can also write and use a custom module handle rights management if you need a specific pattern.
-Everybody (including anonymous users) has read and write access to all collections.
-An authenticated users has read and write access to all collections, anonymous users have no access to these collections.
-Only owners have read and write access to their own collections. The other users, authenticated or anonymous, have no access to these collections.
-Authenticated users have read access to all collections, but only owners have write access to their own collections. Anonymous users have no access to collections.
-Rights are based on a regex-based file whose name is specified in the config (section "right", key "file").
-Authentication login is matched against the "user" key, and collection's path is matched against the "collection" key. You can use Python's ConfigParser interpolation values %(login)s and %(path)s. You can also get groups from the user regex in the collection with {0}, {1}, etc.
-For example, for the "user" key, ".+" means "authenticated user" and ".*" means "anybody" (including anonymous users).
-Section names are only used for naming the rule.
-Leading or ending slashes are trimmed from collection's path.
-Example:
-# The default path for this kind of files is ~/.config/radicale/rights
-# This can be changed in the configuration file
-#
-# This file gives independant examples to help users write their own
-# configuration files. Using these examples together in the same configuration
-# file is meaningless.
-#
-# The first rule matching both user and collection patterns will be returned.
-
-# This means all users starting with "admin" may read any collection
-[admin]
-user: ^admin.*$
-collection: .*
-permission: r
-
-# This means all users may read and write any collection starting with public.
-# We do so by just not testing against the user string.
-[public]
-user: .*
-collection: ^public(/.+)?$
-permission: rw
-
-# A little more complex: give read access to users from a domain for all
-# collections of all the users (ie. user@domain.tld can read domain/*).
-[domain-wide-access]
-user: ^.+@(.+)\..+$
-collection: ^{0}/.+$
-permission: r
-
-# Allow authenticated user to read all collections
-[allow-everyone-read]
-user: .+
-collection: .*
-permission: r
-
-# Give write access to owners
-[owner-write]
-user: .+
-collection: ^%(login)s/.*$
-permission: w--Note
-If the project doesn't comply with the requirements to use Git, Radicale will still work. Your collections will run fine but without the versionning system.
-
Git is now automatically supported on Radicale. It depends on dulwich.
-Radicale automatically detects the .git folder in the path you configured for the filesystem_folder variable in the [storage] section of your configuration file. Make sure a repository is created at this location or create one (using git init . for instance) else it won't work.
To summarize :
-Radicale will automatically commit any changes on your collections. It will use your git config to find parameters such as the committer and that's all.
-A dulwich project ported on Python 3 exists but it seems that it doesn't follow the current api (committer is mandatory and not retrieved from the git config by default). Until this problem isn't fixed, the Git support for Radicale on Python 3 will not be ensured.
-Python 2.6 suffered a bug causing huge timeout problems with TLS. The bug is fixed since Python 2.6.6.
-IMAP authentication over TLS requires Python 3.2.
-Python 2.7 and Python 3.x do not suffer this bug.
-With the htpasswd access, many encryption methods are available, and crypt is the default one in Radicale. Unfortunately, the crypt module is unavailable on Windows, you have to pick another method on this OS.
Additional md5 and bcrypt methods are available when the passlib module is installed.
The IMAP authentication module relies on the imaplib module, available with 2.x versions of Python. However, TLS is only available in Python 3.2. Older versions of Python or a non-modern server who does not support STARTTLS can only authenticate against localhost as passwords are transmitted in PLAIN. Legacy SSL mode on port 993 is not supported.
The LDAP authentication module relies on the python-ldap module, and thus only works with 2.x versions of Python.
-The PAM authentication module relies on the python-pam module.
-Bear in mind that on Linux systems, if you're authenticating against PAM files (i.e. /etc/shadow), the user running Radicale must have the right permissions. For instance, you might want to add the radicale user to the shadow group.
The HTTP authentication module relies on the requests module.
-The daemon mode relies on forks, and thus only works on Unix-like OSes (incuding Linux, OS X, BSD).
-The Radicale Project is a complete calendar and contact storing and manipulating solution. It can store multiple calendars and multiple address books.
-Calendar and contact manipulation is available from both local and distant accesses, possibly limited through authentication policies.
-The Radicale Project is mainly a calendar and contact server, giving local and distant access for reading, creating, modifying and deleting multiple calendars through simplified CalDAV and CardDAV protocols.
-Data can be encrypted by SSL, and their access can be restricted using different authentication methods.
-Radicale is a server, not a client. No interfaces will be created to work with the server, as it is a really (really really) much more difficult task[3].
-CalDAV and CardDAV are not perfect protocols. We think that their main problem is their complexity[4], that is why we decided not to implement the whole standard but just enough to understand some of its client-side implementations [5].
-CalDAV and CardDAV are the best open standards available and they are quite widely used by both clients and servers[6]. We decided to use it, and we will not use another one.
-The Radicale Project aims to be a light solution, easy to use, easy to install, easy to configure. As a consequence, it requires few software dependencies and is pre-configured to work out-of-the-box.
-The Radicale Project runs on most of the UNIX-like platforms (Linux, *BSD, MacOS X) and Windows. It is free and open-source software.
-The different parts of the Radicale Project are written in Python. This is a high-level language, fully object-oriented, available for the main operating systems and released with a lot of useful libraries.
-The main protocols and formats fully or partially implemented in the Radicale Project are described by RFCs:
---Note
-CalDAV and CardDAV implementations require iCal, vCard, ACL, WebDAV, HTTP and TLS. The Radicale Server does not and will not implement correctly these standards, as explained in the Development Choices part.
-
Important global development choices have been decided before writing code. They are very useful to understand why the Radicale Project is different from other CalDAV and CardDAV servers, and why features are included or not in the code.
-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[7], Cosmo[8] and Darwin Calendar Server[9], 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.
-The Radicale Server does not and will not support the CalDAV and CardDAV standards. It supports the CalDAV and CardDAV implementations of different clients (Lightning, Evolution, Android, iPhone, iCal, and more).
-The Radicale Server is designed to be simple to install, simple to configure, simple to use.
-The installation is very easy, particularly with Linux: no dependencies, no superuser rights needed, no configuration required. Launching the main script out-of-the-box, as a normal user, is often the only step 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 User Documentation.
-We, Radicale Project developers, are lazy. That is why we have chosen Python: no more ; or {}[10]. This is also why our server is 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.
-The Radicale Server 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.
-As already mentioned, the Radicale server doesn't fully support the CalDAV and CardDAV RFCs. For example, nested filters in queries currently don't work in all cases. Examples of not working queries can be found in issues #120 and #121.
-Here is a simple overview of the global architecture for reaching a calendar through network:
-| Part | -Layer | -Protocol or Format | -
|---|---|---|
| Server | -Calendar/Contact Storage | -iCal/vCard | -
| Calendar/Contact Server | -CalDAV/CardDAV Server | -|
| Transfer | -Network | -CalDAV/CardDAV (HTTP + TLS) | -
| Client | -Calendar/Contact Client | -CalDAV/CardDAV Client | -
| GUI | -Terminal, GTK, etc. | -
The Radicale Project is only the server part of this architecture.
-The package offers 8 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 server. The server inherits from a HTTP or HTTPS server class, which relies on the default HTTP server class given by Python. The code managing the different HTTP requests according to the CalDAV 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.
ical
-In this module are written the classes to represent collections and items in Radicale. The simple iCalendar and vCard readers and writers are included in this file. The readers and writers are small and stupid: they do not fully understand the iCalendar format and do not know at all what a date is.
xmlutils
-The functions defined in this module are mainly called by the CalDAV 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.
acl
-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 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 using a list of login/password-based access controls.
storage
-This folder is a set of storage modules able to read and write collections. Currently there are three storage modules: filesystem, storing each collection into one flat plain-text file, multifilesystem, storing each entries into separates plain-text files, and database, storing entries in a database. filesystem is stable and battle-tested, others are experimentals.
Want to say something? Join our IRC room: ##kozea on Freenode.
-Found a bug? Want a new feature? Report a new issue on the Radicale bug-tracker.
Interested in hacking? Feel free to clone the git repository on Github if you want to add new features, fix bugs or update documentation.
Radicale is available on PyPI. To install, just type as superuser:
-pip install radicale
-If you want the development version of Radicale, take a look at the git repository on GitHub, or clone it thanks to:
git clone git://github.com/Kozea/Radicale.git
-You can also download the Radicale package of the git repository.
-You can download the Radicale package for each release:
-Radicale has been packaged for:
-Radicale is also available on Cloudron and has a Dockerfile.
-If you are interested in creating packages for other Linux distributions, read the "Contribute" page.
-Radicale 1.1.2 is out!
-Radicale 1.1 is out!
-One feature in this release is not backward compatible:
-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:
-Some bugs have been fixed and little enhancements have been added:
-Radicale 1.0 is out!
-As explained in a previous mail, this version is called 1.0 because:
-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:
-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:
-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!
-Radicale 0.10 is out!
-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"?
-Radicale 0.8 is out!
-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.
-Radicale 0.7.1 is out!
-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…
-Radicale 0.7 is out, at least!
-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.
-New year, new release. Radicale 0.6.4 has a really short changelog:
-The bug was in fact caused by a bug in Python 3.1, everything should be OK now.
-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!
-Radicale version 0.6.3 has been released, with bugfixes that could be interesting for you!
-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.
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!
-Being stable is one thing, being cool is another one. If you want some cool new features, you may be interested in:
-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 is out with minor bugfixes.
-As previously imagined, a new 0.6.1 version has been released, mainly fixing obvious bugs.
-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.
-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!
In the next weeks, new exciting features are coming in the master branch! Some of them are almost ready:
-As you can find in the Radicale Roadmap, tests, rights and filters are expected for 0.7.
-Time for a new release with a lot of new exciting features!
-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)!
-According to the roadmap, a lot of features have been added since Radicale 0.5, much more than expected. It's now time to test Radicale with your favourite client and to report bugs before we release the next stable version!
-Last week, the iCal and iPhone support written by Łukasz has been fixed in order to restore the broken Lightning support. After two afternoons of tests with Rémi, we managed to access the same calendar with Lightning, iCal, iPhone and Evolution, and finally discovered that CalDAV could also be a perfect instant messaging protocol between a Mac, a PC and a phone.
-After that, we've had the nice surprise to see events displayed without a problem (but after some strange steps of configuration) by aCal on Salem's Android phone.
-It was Friday, fun fun fun fun.
-So, that's it: Radicale supports Lightning, Evolution, Kontact, aCal for Android, iPhone and iCal. Of course, before releasing a new tarball:
-Please report bugs if anything goes wrong during your tests, or just let us know by Jabber or by mail if everything is OK.
-Here it is! Radicale is now ready to be launched behind your favourite HTTP server (Apache, Lighttpd, Nginx or Tomcat for example). That's really good news, because:
-The WSGI support has only be tested as a stand-alone executable and behind Lighttpd, you should definitely try if it works with you favourite server too!
-No more features will be added before (quite) a long time, because a lot of documentation and test is waiting for us. If you want to write tutorials for some CalDAV clients support (iCal, Android, iPhone), HTTP servers support or logging management, feel free to fork the documentation git repository and ask for a merge. It's plain text, I'm sure you can do it!
-After a long, long work, the iCal support has finally been added to Radicale! Well, this support is only for iCal 4 and is highly experimental, but you can test it right now with the git master branch. Bug reports are welcome!
-Dear MacOS users, you can thank all the gentlemen who sended a lot of debugging iformation. Special thanks to Andrew from DAViCal, who helped us a lot with his tips and his tests, and Rémi Hainaud who lent his laptop for the final tests.
-The default server address is localhost:5232/user/, where calendars can be added. Multiple calendars and owner-less calendars are not tested yet, but they should work quite well. More documentation will be added during the next days. It will then be time to release the Radicale 0.6 version, and work on the WSGI support.
Two features have just reached the master branch, and the roadmap has been refreshed.
-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.
-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.
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!
-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.
-Radicale 0.5 was released only 8 days ago, but 3 new features have already been added to the master branch:
-Most of the code has been written by Necoro and Corentin, and that was not easy at all: Radicale is now multithreaded! For sure, you can find many bugs and report them on the bug tracker. And if you're fond of logging, you can even add a default configuration file and more debug messages in the source.
-Radicale 0.5 is out! Here is what's new:
-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.
-After a lot of help and testing work from Andrew, Björn, Anders, Dorian and Pete (and other ones we could have forgotten), a simple iPhone support has been added in the git repository. If you are interested, you can test this feature right now by downloading the latest git version (a tarball is even available too if you don't want or know how to use git).
-No documentation has been written yet, but using the right URL in the configuration should be enough to synchronize your calendars. If you have any problems, you can ask by joining our new Jabber room: radicale@room.jabber.kozea.fr.
-Radicale 0.5 will be released as soon as the iCal support is ready. If you have an Apple computer, Python skills and some time to spend, we'd be glad to help you debugging Radicale.
-During the last weeks, Radicale has not been idle, even if no news have been posted since August. Thanks to Pete, Pierre-Philipp and Andrew, we're trying to add a better support on MacOS, Windows and mobile devices like iPhone and Android-based phones.
-All the tests on Windows have been successful: launching Radicale and using Lightning as client works without any problems. On Android too, some testers have reported clients working with Radicale. These were the good news.
-The bad news come from Apple: both iPhone and MacOS default clients are not working yet, despite the latest enhancements given to the PROPFIND requests. The problems are quite hard to debug due to our lack of Apple hardware, but Pete is helping us in this difficult quest! Radicale 0.5 will be out as soon as these two clients are working.
-Some cool stuff is coming next, with calendar collections and groups, and a simple web-based CalDAV client in early development. Stay tuned!
-Radicale 0.4 is out! Here is what's new:
-no-ssl and foreground optionsThis 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!
-Some features have been added in the git repository during the last weeks, thanks to Jerome and Mariusz!
-Personal Calendars
-Calendars accessed through the htpasswd ACL module can now be personal. Thanks to the personal option, a user called bob can access calendars at /bob/* but not to the /alice/* ones.
HEAD Requests
-Radicale can now answer HEAD requests. HTTP headers can be retrieved thanks to this request, without getting contents given by the GET requests.
Last-Modified HTTP header
-The Last-Modified header gives the last time when the calendar has been modified. This is used by some clients to cache the calendars and not retrieving them if they have not been modified.
Radicale 0.3 is out! Here is what’s new:
-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.
-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!
-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.
-Radicale now supports another CalDAV client: Evolution, the default mail, addressbook and calendaring client for Gnome. This feature was quite easy to add, as it required less than 20 new lines of code in the requests handler.
-If you are interested, just clone the git repository.
-Radicale 0.2 is out! Here is what’s new:
-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.
-HTTPS connections and authentication have been added to Radicale this week. Command-line options and personal configuration files are also ready for test. According to the TODO file included in the package, the next version will finally be 0.2, when sunbird 1.0 is out. Go, Mozilla hackers, go!
-HTTPS connection
-HTTPS connections are now available using the standard TLS mechanisms. Give Radicale a private key and a certificate, and your data are now safe.
Authentication
-A simple authentication architecture is now available, allowing different methods thanks to different modules. The first two modules are fake (no authentication) and htpasswd (authentication with an htpasswd file created by the Apache tool). More methods such as LDAP are coming soon!
Dropping Twisted dependency was the first step leading to another big feature: Radicale now works with Python 3! The code was given a small cleanup, with some simplifications mainly about encoding. Before the 0.1.1 release, feel free to test the git repository, all Python versions from 2.5 should be OK.
-Good news! Radicale 0.1.1 will support Sunbird 1.0, but it has another great feature: it has no external dependency! Twisted is no longer required for the git version, removing about 50 lines of code.
-Lightning/Sunbird 1.0b2pre is out, adding minor changes in CalDAV support. A new commit makes Radicale work with versions 0.9, 1.0b1 et 1.0b2. Moreover, etags are now quoted according to the RFC 2616.
-Thunderbird 3 is out, and Lightning/Sunbird 1.0 should be released in a few days. The last commit in git should make Radicale work with versions 0.9 and 1.0b1pre. Radicale 0.1.1 will soon be released adding support for version 1.0.
-First Radicale release! Here is the changelog:
-You can download this version on the download page.
-Radicale code has been released on Gitorious! Take a look at the Radicale main page on Gitorious to view and download source code.
-The Radicale Project is launched. The code has been cleaned up and will be available soon…
-See Python Versions and OS Support for further information.
-I repeat: we are lazy.
-Try to read RFC 4791. Then try to understand it. Then try to implement it. Then try to read it again.
-Radicale is oriented to calendar user agents.
-CalDAV implementations, by Wikipedia.
-Davical, a standards-compliant calendar server.
-Cosmo, the web contents and calendars sharing server build to support the Chandler Project.
-Darwin Calendar Server, a standards-compliant calendar server mainly developed by Apple.
-Who says "Ruby is even less verbose!" should read the PEP 20.
-Free and Open-Source CalDAV and CardDAV Server
-Radicale is a small but powerful CalDAV (calendars, todo-lists) and CardDAV (contacts) server, that:
-Radicale is really easy to install and works out-of-the-box.
-$ python3 -m pip install --upgrade radicale
-$ python3 -m radicale --config "" --storage-filesystem-folder=~/.var/lib/radicale/collectionsWhen your server is launched, you can check that everything's OK by going to http://localhost:5232/ with your browser! You can login with any username and password.
-Want more? Why don't you check our wonderful documentation?
-Latest version of Radicale is 2.1.11, released on November 5, 2018 (changelog).
- -This documentation page is written for version 2.x.x. If you want to update Radicale from 1.x.x to 2.x.x, please follow our migration guide. You can find on GitHub the documentation page for the 1.1.x versions.
-You're new to Radicale and you want to know how to use it? Welcome aboard!
- -Now that you have Radicale running, let's see what we can configure to make it fit your needs.
- -Using is fun, but hacking is soooooooo coooooool. Radicale is a really small and simple piece of code, it may be the perfect project to start hacking!
- -You want to try Radicale but only have 5 minutes free in your calendar? Let's go right now! You won't have the best installation ever, but it will be enough to play a little bit with Radicale.
-When everything works, you can get a client and start creating calendars and address books. The server only binds to localhost (is not reachable over the network) and you can log in with any user name and password. If Radicale fits your needs, it may be time for some basic configuration.
-Follow one of the chapters below depending on your operating system.
-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
-$ python3 -m radicale --config "" --storage-filesystem-folder=~/.var/lib/radicale/collectionsVictory! Open http://localhost:5232/ in your browser! You can login with any username and password.
-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
-C:\Users\User> python -m radicale --config "" --storage-filesystem-folder=~/radicale/collectionsIf you are using PowerShell replace --config "" with --config '""'.
Victory! Open http://localhost:5232/ in your browser! You can login with any username and password.
-To be written.
-Installation instructions can be found on the Tutorial page.
-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.
-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.
The users file can be created and managed with htpasswd:
# 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:bcrypt is used to secure the passwords. Radicale requires additional dependencies for this encryption method:
- -Authentication can be enabled with the following configuration:
- -Create the users file by hand with lines containing the user name and password separated by :. Example:
user1:password1
-user2:password2
-Authentication can be enabled with the following configuration:
- -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:
- -More addresses can be added (separated by commas).
-Data is stored in the folder /var/lib/radicale/collections. The path can be changed with the following configuration:
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.
-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.
- -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.
-Create the file ~/.config/systemd/user/radicale.service:
[Unit]
-Description=A simple CalDAV (calendar) and CardDAV (contact) server
-
-[Service]
-ExecStart=/usr/bin/env python3 -m radicale
-Restart=on-failure
-
-[Install]
-WantedBy=default.targetRadicale will load the configuration file from ~/.config/radicale/config. You should set the configuration option filesystem_folder in the storage section to something like ~/.var/lib/radicale/collections.
To enable and manage the service run:
- -Create the radicale user and group for the Radicale service. (Run useradd --system --home-dir / --shell /sbin/nologin radicale as root.) The storage folder must be writable by radicale. (Run mkdir -p /var/lib/radicale/collections && chown -R radicale:radicale /var/lib/radicale/collections as root.)
Security: The storage should not be readable by others. (Run chmod -R o= /var/lib/radicale/collections as root.)
Create the file /etc/systemd/system/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.targetRadicale will load the configuration file from /etc/radicale/config.
To enable and manage the service run:
- -To be written.
-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!
First install NSSM and start nssm install in a command prompt. Apply the following configuration:
RadicaleC:\Path\To\Python\python.exe-m radicale --config C:\Path\To\ConfigC:\Path\To\Radicale.logSecurity: 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.
-When a reverse proxy is used, the path at which Radicale is available must be provided via the X-Script-Name header. The proxy must remove the location from the URL path that is forwarded to Radicale.
Example nginx configuration:
-location /radicale/ { # The trailing / is important!
- proxy_pass http://localhost:5232/; # The / is important!
- proxy_set_header X-Script-Name /radicale;
- proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
- proxy_pass_header Authorization;
-}
-Example Apache configuration:
-RewriteEngine On
-RewriteRule ^/radicale$ /radicale/ [R,L]
-
-<Location "/radicale/">
- ProxyPass http://localhost:5232/ retry=0
- ProxyPassReverse http://localhost:5232/
- RequestHeader set X-Script-Name /radicale/
-</Location>Be reminded that Radicale's default configuration enforces limits on the maximum number of parallel connections, the maximum file size and the rate of incorrect authentication attempts. Connections are terminated after a timeout.
-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.
-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 9999Use 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.pemExample 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;
-}
-Radicale is compatible with the WSGI specification.
-A configuration file can be set with the RADICALE_CONFIG environment variable, otherwise no configuration file is loaded and the default configuration is used.
Be reminded that Radicale's default configuration enforces limits on the maximum upload file size.
-Security: The None authentication type disables all rights checking. Don't use it with REMOTE_USER. Use remote_user instead.
Example uWSGI configuration:
-[uwsgi]
-http-socket = 127.0.0.1:5232
-processes = 8
-plugin = python3
-module = radicale
-env = RADICALE_CONFIG=/etc/radicale/configExample Gunicorn configuration:
- -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.
This page describes how to keep track of all changes to calendars and address books with git (or any other version control system).
-The repository must be initialized by running git init in the file system folder. Internal files of Radicale can be excluded by creating the file .gitignore with the following content:
.Radicale.cache
-.Radicale.lock
-.Radicale.tmp-*
-The configuration option hook in the storage section must be set to the following command:
The command gets executed after every change to the storage and commits the changes into the git repository.
-Radicale has been tested with:
-Many clients do not support the creation of new calendars and address books. You can use Radicale's web interface (e.g. http://localhost:5232) to create and manage collections.
-In some clients you can just enter the URL of the Radicale server (e.g. http://localhost:5232) and your user name. In others, you have to enter the URL of the collection directly (e.g. http://localhost:5232/user/calendar).
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 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.
Add a new address book on the network with CardDAV. You have to enter the full URL of the collection (e.g. http://localhost:5232/user/addressbook) and your user name.
Add a new calendar on the network with CalDAV. (Don't use iCalendar (ICS)!) You have to enter the full URL of the collection (e.g. http://localhost:5232/user/calendar). If you want to add calendars from different users on the same server, you can specify the user name in the URL (e.g. http://user@localhost...)
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.
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⁵).
-To create a new collection, you have to create the corresponding folder in the file system storage (e.g. collection-root/user/calendar). To tell Radicale and clients that the collection is a calendar, you have to create the file .Radicale.props with the following content in the folder:
The calendar is now available at the URL path /user/calendar. For address books the file must contain:
Calendar and address book collections must not have any child collections. Clients with automatic discovery of collections will only show calendars and addressbooks that are direct children of the path /USERNAME/.
Delete collections by deleting the corresponding folders.
-To create a new calendar run something like:
-$ 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>'To create a new address book run something like:
-$ 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>'The collection /USERNAME will be created automatically, when the user authenticates to Radicale for the first time. Clients with automatic discovery of collections will only show calendars and address books that are direct children of the path /USERNAME/.
Delete the collections by running something like:
- -Radicale can be configured with a configuration file or with command line arguments.
-An example configuration file looks like:
-[server]
-# Bind all addresses
-hosts = 0.0.0.0:5232
-
-[auth]
-type = htpasswd
-htpasswd_filename = /path/to/users
-htpasswd_encryption = bcrypt
-[storage]
-filesystem_folder = ~/.var/lib/radicale/collectionsRadicale tries to load configuration files from /etc/radicale/config, ~/.config/radicale/config and the RADICALE_CONFIG environment variable. This behaviour can be overwritten by specifying a path with the --config /path/to/config command line argument.
The same example configuration via command line arguments looks like:
-python3 -m radicale --config "" --server-hosts 0.0.0.0:5232 --auth-type htpasswd --htpasswd-filename /path/to/htpasswd --htpasswd-encryption bcryptThe --config "" argument is required to stop Radicale from trying to load configuration files. Run python3 -m radicale --help for more information.
In the following, all configuration categories and options are described.
-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.
A comma separated list of addresses that the server will bind to.
-Default: 127.0.0.1:5232
Daemonize the Radicale process. It does not reset the umask.
-Default: False
If daemon mode is enabled, Radicale will write its PID to this file.
-Default:
-The maximum number of parallel connections. Set to 0 to disable the limit.
Default: 20
The maximum size of the request body. (bytes)
-Default: 100000000
Socket timeout. (seconds)
-Default: 30
Enable transport layer encryption.
-Default: False
Path of the SSL certifcate.
-Default: /etc/ssl/radicale.cert.pem
Path to the private key for SSL. Only effective if ssl is enabled.
Default: /etc/ssl/radicale.key.pem
Path to the CA certificate for validating client certificates. This can be used to secure TCP traffic between Radicale and a reverse proxy. If you want to authenticate users with client-side certificates, you also have to write an authentication plugin that extracts the user name from the certifcate.
-Default:
-SSL protocol used. See python's ssl module for available values.
-Default: PROTOCOL_TLSv1_2
Available ciphers for SSL. See python's ssl module for available ciphers.
-Default:
-Reverse DNS to resolve client address in logs.
-Default: True
Message displayed in the client when a password is needed.
-Default: Radicale - Password Required
Encoding for responding requests.
-Default: utf-8
Encoding for storing local collections
-Default: utf-8
The method to verify usernames and passwords.
-Available backends:
-None : Just allows all usernames and passwords. It also disables rights checking.
htpasswd : Use an Apache htpasswd file to store usernames and passwords.
remote_user : Takes the user name from the REMOTE_USER environment variable and disables HTTP authentication. This can be used to provide the user name from a WSGI server.
http_x_remote_user : Takes the user name from the X-Remote-User HTTP header and disables HTTP authentication. This can be used to provide the user name from a reverse proxy.
Default: None
Path to the htpasswd file.
-Default:
-The encryption method that is used in the htpasswd file. Use the htpasswd or similar to generate this files.
-Available methods:
-plain : Passwords are stored in plaintext. This is obviously not secure! The htpasswd file for this can be created by hand and looks like:
user1:password1
-user2:password2
-bcrypt : This uses a modified version of the Blowfish stream cipher. It's very secure. The passlib python module is required for this. Additionally you may need one of the following python modules: bcrypt, py-bcrypt or bcryptor.
md5 : This uses an iterated md5 digest of the password with a salt. The passlib python module is required for this.
sha1 : Passwords are stored as SHA1 hashes. It's insecure!
ssha : Passwords are stored as salted SHA1 hashes. It's insecure!
crypt : This uses UNIX crypt(3). It's insecure!
Default: bcrypt
Average delay after failed login attempts in seconds.
-Default: 1
The backend that is used to check the access rights of collections.
-The recommended backend is owner_only. If access to calendars and address books outside of the home directory of users (that's /USERNAME/) is granted, clients won't detect these collections and will not show them to the user. Choosing any other method is only useful if you access calendars and address books directly via URL.
Available backends:
-None : Everyone can read and write everything.
authenticated : Authenticated users can read and write everything.
owner_only : Authenticated users can read and write their own collections under the path /USERNAME/.
owner_write : Authenticated users can read everything and write their own collections under the path /USERNAME/.
from_file : Load the rules from a file.
Default: owner_only
File for the rights backend from_file. See the Rights page.
The backend that is used to store data.
-Available backends:
-multifilesystem : Stores the data in the filesystem.
Default: multifilesystem
Folder for storing local collections, created if not present.
-Default: /var/lib/radicale/collections
Lock the storage. This must be disabled if locking is not supported by the underlying file system. Never start multiple instances of Radicale or edit the storage externally while Radicale is running if disabled.
-Default: True
Delete sync-token that are older than the specified time. (seconds)
-Default: 2592000
Sync all changes to disk during requests. (This can impair performance.) Disabling it increases the risk of data loss, when the system crashes or power fails!
-Default: True
Command that is run after changes to storage. Take a look at the Versioning page for an example.
-Default:
-The backend that provides the web interface of Radicale.
-Available backends:
-none : Just shows the message "Radicale works!".
internal : Allows creation and management of address books and calendars.
Default: internal
Set the default logging level to debug.
-Default: False
Log all environment variables (including those set in the shell).
-Default: False
Don't include passwords in logs.
-Default: True
Logging configuration file. See the Logging page.
-Default:
-In this section additional HTTP headers that are sent to clients can be specified.
-An example to relax the same-origin policy:
- -This page describes the format of the rights file for the from_file authentication backend. The configuration option file in the rights section must point to the rights file.
The recommended rights method is owner_only. If access to calendars and address books outside of the home directory of users (that's /USERNAME/) is granted, clients won't detect these collections and will not show them to the user. This is only useful if you access calendars and address books directly via URL.
An example rights file:
-# The user "admin" can read and write any collection.
-[admin]
-user = admin
-collection = .*
-permission = rw
-
-# Block access for the user "user" to everything.
-[block]
-user = user
-collection = .*
-permission =
-
-# Authenticated users can read and write their own collections.
-[owner-write]
-user = .+
-collection = %(login)s(/.*)?
-permission = rw
-
-# Everyone can read the root collection
-[read]
-user = .*
-collection =
-permission = rThe titles of the sections are ignored (but must be unique). The keys user and collection contain regular expressions, that are matched against the user name and the path of the collection. Permissions from the first matching section are used. If no section matches, access gets denied.
The user name is empty for anonymous users. Therefore, the regex .+ only matches authenticated users and .* matches everyone (including anonymous users).
The path of the collection is separated by / and has no leading or trailing /. Therefore, the path of the root collection is empty.
%(login)s gets replaced by the user name and %(path)s by the path of the collection. You can also get groups from the user regex in the collection regex with {0}, {1}, etc.
This document describes the layout and format of the file system storage (multifilesystem backend).
It's safe to access and manipulate the data by hand or with scripts. Scripts can be invoked manually, periodically (e.g. with cron) or after each change to the storage with the configuration option hook in the storage section (e.g. Git Versioning).
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.
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.
Use the flock utility.
- -Use the flock syscall. Python provides it in the fcntl module.
-Use LockFile for exclusive access or LockFileEx which also supports shared access. Setting nNumberOfBytesToLockLow to 1 and nNumberOfBytesToLockHigh to 0 works.
Radicale logs to stderr. The verbosity of the log output can be controlled with --debug command line argument or the debug configuration option in the logging section.
This is the recommended configuration for use with modern init systems (like systemd) or if you just test Radicale in a terminal.
-You can configure Radicale to write its logging output to files (and even rotate them). This is useful if the process daemonizes or if your chosen method of running Radicale doesn't handle logging output.
-A logging configuration file can be specified in the config configuration option in the logging section. The file format is explained in the Python Logging Module.
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)sYou 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.
-An example handler configuration to write the log output to the file /var/log/radicale/log and rotate it. Replace the section handler_file from the file logging example:
[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 = fullAn example handler configuration to write the log output to the file /var/log/radicale/log and rotate it . Replace the section handle_file from the file logging example:
[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 = fullRadicale is a really small piece of software, but understanding it is not as easy as it seems. But don't worry, reading this short page is enough to understand what a CalDAV/CardDAV server is, and how Radicale's code is organized.
-Here is a simple overview of the global architecture for reaching a calendar or an address book through network:
-| Part | -Layer | -Protocol or Format | -
|---|---|---|
| Server | -Calendar/Contact Storage | -iCal/vCard | -
| Calendar/Contact Server | -CalDAV/CardDAV Server | -|
| Transfer | -Network | -CalDAV/CardDAV (HTTP + TLS) | -
| Client | -Calendar/Contact Client | -CalDAV/CardDAV Client | -
| GUI | -Terminal, GTK, Web interface, etc. | -
Radicale is only the server part of this architecture.
-Please note that:
-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.
-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.
Radicale can be extended by plugins for authentication, rights management and storage. Plugins are python modules.
-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 == passwordInstall the python module by running the following command in the same folder as setup.py:
To make use this great creation in Radicale, set the configuration option type in the auth section to radicale_silly_auth:
You can uninstall the module with:
- -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.
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.
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.
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.
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.
-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.)
-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.
-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.6 with:
- -Radicale 2.x.x only provides htpasswd authentication out-of-the-box. Other authentication methods can be added by creating or using plugins.
-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.
-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.
Want to say something? Join our IRC room: ##kozea on Freenode.
Found a bug? Want a new feature? Report a new issue on the Radicale bug-tracker.
-Interested in hacking? Feel free to clone the git repository on Github if you want to add new features, fix bugs or update the documentation.
-To change or complement the documentation create a pull request to DOCUMENTATION.md.
-Radicale is available on PyPI. To install, just type as superuser:
-$ python3 -m pip install --upgrade radicale
-If you want the development version of Radicale, take a look at the git repository on GitHub, or install it directly with:
-$ python3 -m pip install --upgrade git+https://github.com/Kozea/Radicale
-You can also download the content of the repository as an archive.
-You can download the Radicale package for each release:
-Radicale has been packaged for:
-Radicale is also available on Cloudron and has a Dockerfile.
-If you are interested in creating packages for other Linux distributions, read the "Contribute" page.
-Radicale is a complete calendar and contact storing and manipulating solution. It can store multiple calendars and multiple address books.
-Calendar and contact manipulation is available from both local and distant accesses, possibly limited through authentication policies.
-It aims to be a lightweight solution, easy to use, easy to install, easy to configure. As a consequence, it requires few software dependencies and is pre-configured to work out-of-the-box.
-Radicale is written in Python. It runs on most of the UNIX-like platforms (Linux, *BSD, macOS) and Windows. It is free and open-source software.
-Radicale is a server, not a client. No interfaces will be created to work with the server, as it is a really (really really) much more difficult task.
-CalDAV and CardDAV are not perfect protocols. We think that their main problem is their complexity, that is why we decided not to implement the whole standard but just enough to understand some of its client-side implementations.
-CalDAV and CardDAV are the best open standards available and they are quite widely used by both clients and servers. We decided to use it, and we will not use another one.
-Important global development choices have been decided before writing code. They are very useful to understand why the Radicale Project is different from other CalDAV and CardDAV servers, and why features are included or not in the code.
-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.
-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.
-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.
-Radicale has been started as a (free topic) stupid school project replacing another (assigned topic) even more stupid school project.
-At the beginning, it was just a proof-of-concept. The main goal was to write a small, dirty 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 (many) beers at the very end of 2008 (Python 2.6 and 3.0 were just released). It's now packaged for a growing number of Linux distributions.
-And that was fun going from here to there thanks to you!
-Latest version of Radicale is 2.1.11, released on November 5, 2018 (changelog).
-Radicale 2.1.10 is out!
-This release is compatible with version 2.0.0. See http://radicale.org/1to2/ if you want to switch from 1.x.x to 2.x.x.
-RADICALE_CONFIG from WSGI environRadicale 2.1.9 is out!
-This release is compatible with version 2.0.0. See http://radicale.org/1to2/ if you want to switch from 1.x.x to 2.x.x.
-REPORT method is actually supportedrights file in source distributionmd5 and bcrypt as extrasRadicale 2.1.8 is out!
-This release is compatible with version 2.0.0. See http://radicale.org/1to2/ if you want to switch from 1.x.x to 2.x.x.
-Radicale 2.1.7 is out!
-This release is compatible with version 2.0.0. See http://radicale.org/1to2/ if you want to switch from 1.x.x to 2.x.x.
-BaseAuthis_authenticated2(login, user, password) to BaseAuthD:propname or D:allpropD:propname or D:allpropD:displayname property on all collectionsD:unauthenticated for D:current-user-principal property when not logged inICAL:calendar-color and C:calendar-timezone properties from PROPFIND requests with D:propname or D:allpropD:owner property to calendar and address book objectsD:getetag and D:getlastmodified properties from regular collectionsRadicale 2.1.6 is out!
-This release is compatible with version 2.0.0. See http://radicale.org/1to2/ if you want to switch from 1.x.x to 2.x.x.
-Radicale 2.1.5 is out!
-This release is compatible with version 2.0.0. See http://radicale.org/1to2/ if you want to switch from 1.x.x to 2.x.x.
---verify-storage command-line argumentRadicale 2.1.4 is out!
-This release is compatible with version 2.0.0. See http://radicale.org/1to2/ if you want to switch from 1.x.x to 2.x.x.
-Radicale 2.1.3 is out!
-This release is compatible with version 2.0.0. See http://radicale.org/1to2/ if you want to switch from 1.x.x to 2.x.x.
-Radicale 2.1.2 is out!
-This release is compatible with version 2.0.0. See http://radicale.org/1to2/ if you want to switch from 1.x.x to 2.x.x.
-Radicale 2.1.1 is out!
-This release is compatible with version 2.0.0. See http://radicale.org/1to2/ if you want to switch from 1.x.x to 2.x.x.
-Radicale 2.1.0 is out!
-This release is compatible with version 2.0.0. See http://radicale.org/1to2/ if you want to switch from 1.x.x to 2.1.0.
-owner_only plugin is used (information leakage)remote_user plugin, that gets the login from the REMOTE_USER environment variable (for WSGI server)http_x_remote_user plugin, that gets the login from the X-Remote-User HTTP header (for reverse proxies)Radicale 2.0.0 is out!
-This feature is not compatible with the 1.x.x versions. See http://radicale.org/1to2/ if you want to switch from 1.x.x to 2.0.0.
-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.
-Radicale 1.1.2 is out!
-Radicale 1.1 is out!
-One feature in this release is not backward compatible:
-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:
-Some bugs have been fixed and little enhancements have been added:
-Radicale 1.0 is out!
-As explained in a previous mail, this version is called 1.0 because:
-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:
-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:
-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!
-Radicale 0.10 is out!
-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"?
-Radicale 0.8 is out!
-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.
-Radicale 0.7.1 is out!
-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…
-Radicale 0.7 is out, at least!
-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.
-New year, new release. Radicale 0.6.4 has a really short changelog:
-The bug was in fact caused by a bug in Python 3.1, everything should be OK now.
-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!
-Radicale version 0.6.3 has been released, with bugfixes that could be interesting for you!
-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.
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!
-Being stable is one thing, being cool is another one. If you want some cool new features, you may be interested in:
-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 is out with minor bugfixes.
-As previously imagined, a new 0.6.1 version has been released, mainly fixing obvious bugs.
-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.
-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!
-In the next weeks, new exciting features are coming in the master branch! Some of them are almost ready:
-As you can find in the Radicale Roadmap, tests, rights and filters are expected for 0.7.
-Time for a new release with a lot of new exciting features!
-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)!
-According to the roadmap, a lot of features have been added since Radicale 0.5, much more than expected. It's now time to test Radicale with your favourite client and to report bugs before we release the next stable version!
-Last week, the iCal and iPhone support written by Łukasz has been fixed in order to restore the broken Lightning support. After two afternoons of tests with Rémi, we managed to access the same calendar with Lightning, iCal, iPhone and Evolution, and finally discovered that CalDAV could also be a perfect instant messaging protocol between a Mac, a PC and a phone.
-After that, we've had the nice surprise to see events displayed without a problem (but after some strange steps of configuration) by aCal on Salem's Android phone.
-It was Friday, fun fun fun fun.
-So, that's it: Radicale supports Lightning, Evolution, Kontact, aCal for Android, iPhone and iCal. Of course, before releasing a new tarball:
-Please report bugs if anything goes wrong during your tests, or just let us know by Jabber or by mail if everything is OK.
-Here it is! Radicale is now ready to be launched behind your favourite HTTP server (Apache, Lighttpd, Nginx or Tomcat for example). That's really good news, because:
-The WSGI support has only be tested as a stand-alone executable and behind Lighttpd, you should definitely try if it works with you favourite server too!
-No more features will be added before (quite) a long time, because a lot of documentation and test is waiting for us. If you want to write tutorials for some CalDAV clients support (iCal, Android, iPhone), HTTP servers support or logging management, feel free to fork the documentation git repository and ask for a merge. It's plain text, I'm sure you can do it!
-After a long, long work, the iCal support has finally been added to Radicale! Well, this support is only for iCal 4 and is highly experimental, but you can test it right now with the git master branch. Bug reports are welcome!
-Dear MacOS users, you can thank all the gentlemen who sended a lot of debugging iformation. Special thanks to Andrew from DAViCal, who helped us a lot with his tips and his tests, and Rémi Hainaud who lent his laptop for the final tests.
-The default server address is localhost:5232/user/, where calendars can be added. Multiple calendars and owner-less calendars are not tested yet, but they should work quite well. More documentation will be added during the next days. It will then be time to release the Radicale 0.6 version, and work on the WSGI support.
Two features have just reached the master branch, and the roadmap has been refreshed.
-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.
-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.
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!
-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.
-Radicale 0.5 was released only 8 days ago, but 3 new features have already been added to the master branch:
-Most of the code has been written by Necoro and Corentin, and that was not easy at all: Radicale is now multithreaded! For sure, you can find many bugs and report them on the bug tracker. And if you're fond of logging, you can even add a default configuration file and more debug messages in the source.
-Radicale 0.5 is out! Here is what's new:
-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.
-After a lot of help and testing work from Andrew, Björn, Anders, Dorian and Pete (and other ones we could have forgotten), a simple iPhone support has been added in the git repository. If you are interested, you can test this feature right now by downloading the latest git version (a tarball is even available too if you don't want or know how to use git).
-No documentation has been written yet, but using the right URL in the configuration should be enough to synchronize your calendars. If you have any problems, you can ask by joining our new Jabber room: radicale@room.jabber.kozea.fr.
-Radicale 0.5 will be released as soon as the iCal support is ready. If you have an Apple computer, Python skills and some time to spend, we'd be glad to help you debugging Radicale.
-During the last weeks, Radicale has not been idle, even if no news have been posted since August. Thanks to Pete, Pierre-Philipp and Andrew, we're trying to add a better support on MacOS, Windows and mobile devices like iPhone and Android-based phones.
-All the tests on Windows have been successful: launching Radicale and using Lightning as client works without any problems. On Android too, some testers have reported clients working with Radicale. These were the good news.
-The bad news come from Apple: both iPhone and MacOS default clients are not working yet, despite the latest enhancements given to the PROPFIND requests. The problems are quite hard to debug due to our lack of Apple hardware, but Pete is helping us in this difficult quest! Radicale 0.5 will be out as soon as these two clients are working.
-Some cool stuff is coming next, with calendar collections and groups, and a simple web-based CalDAV client in early development. Stay tuned!
-Radicale 0.4 is out! Here is what's new:
-no-ssl and foreground optionsThis 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!
-Some features have been added in the git repository during the last weeks, thanks to Jerome and Mariusz!
-Personal Calendars Calendars accessed through the htpasswd ACL module can now be personal. Thanks to the personal option, a user called bob can access calendars at /bob/* but not to the /alice/* ones.
HEAD Requests Radicale can now answer HEAD requests. HTTP headers can be retrieved thanks to this request, without getting contents given by the GET requests.
-Last-Modified HTTP header The Last-Modified header gives the last time when the calendar has been modified. This is used by some clients to cache the calendars and not retrieving them if they have not been modified.
-Radicale 0.3 is out! Here is what’s new:
-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.
-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!
-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.
-Radicale now supports another CalDAV client: Evolution, the default mail, addressbook and calendaring client for Gnome. This feature was quite easy to add, as it required less than 20 new lines of code in the requests handler.
-If you are interested, just clone the git repository.
-Radicale 0.2 is out! Here is what’s new:
-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.
-HTTPS connections and authentication have been added to Radicale this week. Command-line options and personal configuration files are also ready for test. According to the TODO file included in the package, the next version will finally be 0.2, when sunbird 1.0 is out. Go, Mozilla hackers, go!
-HTTPS connection HTTPS connections are now available using the standard TLS mechanisms. Give Radicale a private key and a certificate, and your data are now safe.
-Authentication A simple authentication architecture is now available, allowing different methods thanks to different modules. The first two modules are fake (no authentication) and htpasswd (authentication with an htpasswd file created by the Apache tool). More methods such as LDAP are coming soon!
Dropping Twisted dependency was the first step leading to another big feature: Radicale now works with Python 3! The code was given a small cleanup, with some simplifications mainly about encoding. Before the 0.1.1 release, feel free to test the git repository, all Python versions from 2.5 should be OK.
-Good news! Radicale 0.1.1 will support Sunbird 1.0, but it has another great feature: it has no external dependency! Twisted is no longer required for the git version, removing about 50 lines of code.
-Lightning/Sunbird 1.0b2pre is out, adding minor changes in CalDAV support. A new commit makes Radicale work with versions 0.9, 1.0b1 et 1.0b2. Moreover, etags are now quoted according to the RFC 2616.
-Thunderbird 3 is out, and Lightning/Sunbird 1.0 should be released in a few days. The last commit in git should make Radicale work with versions 0.9 and 1.0b1pre. Radicale 0.1.1 will soon be released adding support for version 1.0.
-First Radicale release! Here is the changelog:
-You can download this version on the download page.
-Radicale code has been released on Gitorious! Take a look at the Radicale main page on Gitorious to view and download source code.
-The Radicale Project is launched. The code has been cleaned up and will be available soon…
-Please follow this link.
diff --git a/beta/master.html b/beta/master.html deleted file mode 100644 index 2457d5c3..00000000 --- a/beta/master.html +++ /dev/null @@ -1,1317 +0,0 @@ - - - - - - - - - - - - - -Free and Open-Source CalDAV and CardDAV Server
-Radicale is a small but powerful CalDAV (calendars, todo-lists) and CardDAV (contacts) server, that:
-Radicale is really easy to install and works out-of-the-box.
-$ python3 -m pip install --upgrade radicale
-$ python3 -m radicale --config "" --storage-filesystem-folder=~/.var/lib/radicale/collectionsWhen your server is launched, you can check that everything's OK by going to http://localhost:5232/ with your browser! You can login with any username and password.
-Want more? Why don't you check our wonderful documentation?
-You're new to Radicale and you want to know how to use it? Welcome aboard!
- -Now that you have Radicale running, let's see what we can configure to make it fit your needs.
- -Using is fun, but hacking is soooooooo coooooool. Radicale is a really small and simple piece of code, it may be the perfect project to start hacking!
- -You want to try Radicale but only have 5 minutes free in your calendar? Let's go right now! You won't have the best installation ever, but it will be enough to play a little bit with Radicale.
-When everything works, you can get a client and start creating calendars and address books. The server only binds to localhost (is not reachable over the network) and you can log in with any user name and password. If Radicale fits your needs, it may be time for some basic configuration.
-Follow one of the chapters below depending on your operating system.
-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
-$ python3 -m radicale --config "" --storage-filesystem-folder=~/.var/lib/radicale/collectionsVictory! Open http://localhost:5232/ in your browser! You can login with any username and password.
-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
-C:\Users\User> python -m radicale --config "" --storage-filesystem-folder=~/radicale/collectionsIf you are using PowerShell replace --config "" with --config '""'.
Victory! Open http://localhost:5232/ in your browser! You can login with any username and password.
-To be written.
-Installation instructions can be found on the Tutorial page.
-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.
-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.
The users file can be created and managed with htpasswd:
# 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:bcrypt is used to secure the passwords. Radicale requires additional dependencies for this encryption method:
- -Authentication can be enabled with the following configuration:
- -Create the users file by hand with lines containing the user name and password separated by :. Example:
user1:password1
-user2:password2
-Authentication can be enabled with the following configuration:
- -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:
- -More addresses can be added (separated by commas).
-Data is stored in the folder /var/lib/radicale/collections. The path can be changed with the following configuration:
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.
-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.
- -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.
-Create the file ~/.config/systemd/user/radicale.service:
[Unit]
-Description=A simple CalDAV (calendar) and CardDAV (contact) server
-
-[Service]
-ExecStart=/usr/bin/env python3 -m radicale
-Restart=on-failure
-
-[Install]
-WantedBy=default.targetRadicale will load the configuration file from ~/.config/radicale/config. You should set the configuration option filesystem_folder in the storage section to something like ~/.var/lib/radicale/collections.
To enable and manage the service run:
- -Create the radicale user and group for the Radicale service. (Run useradd --system --home-dir / --shell /sbin/nologin radicale as root.) The storage folder must be writable by radicale. (Run mkdir -p /var/lib/radicale/collections && chown -R radicale:radicale /var/lib/radicale/collections as root.)
Security: The storage should not be readable by others. (Run chmod -R o= /var/lib/radicale/collections as root.)
Create the file /etc/systemd/system/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.targetRadicale will load the configuration file from /etc/radicale/config.
To enable and manage the service run:
- -To be written.
-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!
First install NSSM and start nssm install in a command prompt. Apply the following configuration:
RadicaleC:\Path\To\Python\python.exe-m radicale --config C:\Path\To\ConfigC:\Path\To\Radicale.logSecurity: 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.
-When a reverse proxy is used, the path at which Radicale is available must be provided via the X-Script-Name header. The proxy must remove the location from the URL path that is forwarded to Radicale.
Example nginx configuration:
-location /radicale/ { # The trailing / is important!
- proxy_pass http://localhost:5232/; # The / is important!
- proxy_set_header X-Script-Name /radicale;
- proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
- proxy_pass_header Authorization;
-}
-Example Apache configuration:
-RewriteEngine On
-RewriteRule ^/radicale$ /radicale/ [R,L]
-
-<Location "/radicale/">
- ProxyPass http://localhost:5232/ retry=0
- ProxyPassReverse http://localhost:5232/
- RequestHeader set X-Script-Name /radicale/
-</Location>Be reminded that Radicale's default configuration enforces limits on the maximum number of parallel connections, the maximum file size and the rate of incorrect authentication attempts. Connections are terminated after a timeout.
-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.
-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 9999Use 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.pemExample 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;
-}
-Radicale is compatible with the WSGI specification.
-A configuration file can be set with the RADICALE_CONFIG environment variable, otherwise no configuration file is loaded and the default configuration is used.
Be reminded that Radicale's default configuration enforces limits on the maximum upload file size.
-Security: The None authentication type disables all rights checking. Don't use it with REMOTE_USER. Use remote_user instead.
Example uWSGI configuration:
-[uwsgi]
-http-socket = 127.0.0.1:5232
-processes = 8
-plugin = python3
-module = radicale
-env = RADICALE_CONFIG=/etc/radicale/configExample Gunicorn configuration:
- -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.
This page describes how to keep track of all changes to calendars and address books with git (or any other version control system).
-The repository must be initialized by running git init in the file system folder. Internal files of Radicale can be excluded by creating the file .gitignore with the following content:
.Radicale.cache
-.Radicale.lock
-.Radicale.tmp-*
-The configuration option hook in the storage section must be set to the following command:
The command gets executed after every change to the storage and commits the changes into the git repository.
-Radicale has been tested with:
-Many clients do not support the creation of new calendars and address books. You can use Radicale's web interface (e.g. http://localhost:5232) to create and manage collections.
-In some clients you can just enter the URL of the Radicale server (e.g. http://localhost:5232) and your user name. In others, you have to enter the URL of the collection directly (e.g. http://localhost:5232/user/calendar).
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 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.
Add a new address book on the network with CardDAV. You have to enter the full URL of the collection (e.g. http://localhost:5232/user/addressbook) and your user name.
Add a new calendar on the network with CalDAV. (Don't use iCalendar (ICS)!) You have to enter the full URL of the collection (e.g. http://localhost:5232/user/calendar). If you want to add calendars from different users on the same server, you can specify the user name in the URL (e.g. http://user@localhost...)
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.
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⁵).
-To create a new collection, you have to create the corresponding folder in the file system storage (e.g. collection-root/user/calendar). To tell Radicale and clients that the collection is a calendar, you have to create the file .Radicale.props with the following content in the folder:
The calendar is now available at the URL path /user/calendar. For address books the file must contain:
Calendar and address book collections must not have any child collections. Clients with automatic discovery of collections will only show calendars and addressbooks that are direct children of the path /USERNAME/.
Delete collections by deleting the corresponding folders.
-To create a new calendar run something like:
-$ 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>'To create a new address book run something like:
-$ 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>'The collection /USERNAME will be created automatically, when the user authenticates to Radicale for the first time. Clients with automatic discovery of collections will only show calendars and address books that are direct children of the path /USERNAME/.
Delete the collections by running something like:
- -Radicale can be configured with a configuration file or with command line arguments.
-An example configuration file looks like:
-[server]
-# Bind all addresses
-hosts = 0.0.0.0:5232
-
-[auth]
-type = htpasswd
-htpasswd_filename = /path/to/users
-htpasswd_encryption = bcrypt
-[storage]
-filesystem_folder = ~/.var/lib/radicale/collectionsRadicale tries to load configuration files from /etc/radicale/config, ~/.config/radicale/config and the RADICALE_CONFIG environment variable. This behaviour can be overwritten by specifying a path with the --config /path/to/config command line argument.
The same example configuration via command line arguments looks like:
-python3 -m radicale --config "" --server-hosts 0.0.0.0:5232 --auth-type htpasswd --htpasswd-filename /path/to/htpasswd --htpasswd-encryption bcryptThe --config "" argument is required to stop Radicale from trying to load configuration files. Run python3 -m radicale --help for more information.
In the following, all configuration categories and options are described.
-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.
A comma separated list of addresses that the server will bind to.
-Default: 127.0.0.1:5232
Daemonize the Radicale process. It does not reset the umask.
-Default: False
If daemon mode is enabled, Radicale will write its PID to this file.
-Default:
-The maximum number of parallel connections. Set to 0 to disable the limit.
Default: 20
The maximum size of the request body. (bytes)
-Default: 100000000
Socket timeout. (seconds)
-Default: 30
Enable transport layer encryption.
-Default: False
Path of the SSL certifcate.
-Default: /etc/ssl/radicale.cert.pem
Path to the private key for SSL. Only effective if ssl is enabled.
Default: /etc/ssl/radicale.key.pem
Path to the CA certificate for validating client certificates. This can be used to secure TCP traffic between Radicale and a reverse proxy. If you want to authenticate users with client-side certificates, you also have to write an authentication plugin that extracts the user name from the certifcate.
-Default:
-SSL protocol used. See python's ssl module for available values.
-Default: PROTOCOL_TLSv1_2
Available ciphers for SSL. See python's ssl module for available ciphers.
-Default:
-Reverse DNS to resolve client address in logs.
-Default: True
Message displayed in the client when a password is needed.
-Default: Radicale - Password Required
Encoding for responding requests.
-Default: utf-8
Encoding for storing local collections
-Default: utf-8
The method to verify usernames and passwords.
-Available backends:
-None : Just allows all usernames and passwords. It also disables rights checking.
htpasswd : Use an Apache htpasswd file to store usernames and passwords.
remote_user : Takes the user name from the REMOTE_USER environment variable and disables HTTP authentication. This can be used to provide the user name from a WSGI server.
http_x_remote_user : Takes the user name from the X-Remote-User HTTP header and disables HTTP authentication. This can be used to provide the user name from a reverse proxy.
Default: None
Path to the htpasswd file.
-Default:
-The encryption method that is used in the htpasswd file. Use the htpasswd or similar to generate this files.
-Available methods:
-plain : Passwords are stored in plaintext. This is obviously not secure! The htpasswd file for this can be created by hand and looks like:
user1:password1
-user2:password2
-bcrypt : This uses a modified version of the Blowfish stream cipher. It's very secure. The passlib python module is required for this. Additionally you may need one of the following python modules: bcrypt, py-bcrypt or bcryptor.
md5 : This uses an iterated md5 digest of the password with a salt. The passlib python module is required for this.
sha1 : Passwords are stored as SHA1 hashes. It's insecure!
ssha : Passwords are stored as salted SHA1 hashes. It's insecure!
crypt : This uses UNIX crypt(3). It's insecure!
Default: bcrypt
Average delay after failed login attempts in seconds.
-Default: 1
The backend that is used to check the access rights of collections.
-The recommended backend is owner_only. If access to calendars and address books outside of the home directory of users (that's /USERNAME/) is granted, clients won't detect these collections and will not show them to the user. Choosing any other method is only useful if you access calendars and address books directly via URL.
Available backends:
-None : Everyone can read and write everything.
authenticated : Authenticated users can read and write everything.
owner_only : Authenticated users can read and write their own collections under the path /USERNAME/.
owner_write : Authenticated users can read everything and write their own collections under the path /USERNAME/.
from_file : Load the rules from a file.
Default: owner_only
File for the rights backend from_file. See the Rights page.
The backend that is used to store data.
-Available backends:
-multifilesystem : Stores the data in the filesystem.
Default: multifilesystem
Folder for storing local collections, created if not present.
-Default: /var/lib/radicale/collections
Lock the storage. This must be disabled if locking is not supported by the underlying file system. Never start multiple instances of Radicale or edit the storage externally while Radicale is running if disabled.
-Default: True
Delete sync-token that are older than the specified time. (seconds)
-Default: 2592000
Sync all changes to disk during requests. (This can impair performance.) Disabling it increases the risk of data loss, when the system crashes or power fails!
-Default: True
Command that is run after changes to storage. Take a look at the Versioning page for an example.
-Default:
-The backend that provides the web interface of Radicale.
-Available backends:
-none : Just shows the message "Radicale works!".
internal : Allows creation and management of address books and calendars.
Default: internal
Set the default logging level to debug.
-Default: False
Log all environment variables (including those set in the shell).
-Default: False
Don't include passwords in logs.
-Default: True
Logging configuration file. See the Logging page.
-Default:
-In this section additional HTTP headers that are sent to clients can be specified.
-An example to relax the same-origin policy:
- -This page describes the format of the rights file for the from_file authentication backend. The configuration option file in the rights section must point to the rights file.
The recommended rights method is owner_only. If access to calendars and address books outside of the home directory of users (that's /USERNAME/) is granted, clients won't detect these collections and will not show them to the user. This is only useful if you access calendars and address books directly via URL.
An example rights file:
-# The user "admin" can read and write any collection.
-[admin]
-user = admin
-collection = .*
-permission = rw
-
-# Block access for the user "user" to everything.
-[block]
-user = user
-collection = .*
-permission =
-
-# Authenticated users can read and write their own collections.
-[owner-write]
-user = .+
-collection = %(login)s(/.*)?
-permission = rw
-
-# Everyone can read the root collection
-[read]
-user = .*
-collection =
-permission = rThe titles of the sections are ignored (but must be unique). The keys user and collection contain regular expressions, that are matched against the user name and the path of the collection. Permissions from the first matching section are used. If no section matches, access gets denied.
The user name is empty for anonymous users. Therefore, the regex .+ only matches authenticated users and .* matches everyone (including anonymous users).
The path of the collection is separated by / and has no leading or trailing /. Therefore, the path of the root collection is empty.
%(login)s gets replaced by the user name and %(path)s by the path of the collection. You can also get groups from the user regex in the collection regex with {0}, {1}, etc.
This document describes the layout and format of the file system storage (multifilesystem backend).
It's safe to access and manipulate the data by hand or with scripts. Scripts can be invoked manually, periodically (e.g. with cron) or after each change to the storage with the configuration option hook in the storage section (e.g. Git Versioning).
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.
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.
Use the flock utility.
- -Use the flock syscall. Python provides it in the fcntl module.
-Use LockFile for exclusive access or LockFileEx which also supports shared access. Setting nNumberOfBytesToLockLow to 1 and nNumberOfBytesToLockHigh to 0 works.
Radicale logs to stderr. The verbosity of the log output can be controlled with --debug command line argument or the debug configuration option in the logging section.
This is the recommended configuration for use with modern init systems (like systemd) or if you just test Radicale in a terminal.
-You can configure Radicale to write its logging output to files (and even rotate them). This is useful if the process daemonizes or if your chosen method of running Radicale doesn't handle logging output.
-A logging configuration file can be specified in the config configuration option in the logging section. The file format is explained in the Python Logging Module.
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)sYou 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.
-An example handler configuration to write the log output to the file /var/log/radicale/log and rotate it. Replace the section handler_file from the file logging example:
[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 = fullAn example handler configuration to write the log output to the file /var/log/radicale/log and rotate it . Replace the section handle_file from the file logging example:
[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 = fullRadicale is a really small piece of software, but understanding it is not as easy as it seems. But don't worry, reading this short page is enough to understand what a CalDAV/CardDAV server is, and how Radicale's code is organized.
-Here is a simple overview of the global architecture for reaching a calendar or an address book through network:
-| Part | -Layer | -Protocol or Format | -
|---|---|---|
| Server | -Calendar/Contact Storage | -iCal/vCard | -
| Calendar/Contact Server | -CalDAV/CardDAV Server | -|
| Transfer | -Network | -CalDAV/CardDAV (HTTP + TLS) | -
| Client | -Calendar/Contact Client | -CalDAV/CardDAV Client | -
| GUI | -Terminal, GTK, Web interface, etc. | -
Radicale is only the server part of this architecture.
-Please note that:
-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.
-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.
Radicale can be extended by plugins for authentication, rights management and storage. Plugins are python modules.
-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 == passwordInstall the python module by running the following command in the same folder as setup.py:
To make use this great creation in Radicale, set the configuration option type in the auth section to radicale_silly_auth:
You can uninstall the module with:
- -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.
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.
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.
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.
Want to say something? Join our IRC room: ##kozea on Freenode.
Found a bug? Want a new feature? Report a new issue on the Radicale bug-tracker.
-Interested in hacking? Feel free to clone the git repository on Github if you want to add new features, fix bugs or update the documentation.
-To change or complement the documentation create a pull request to DOCUMENTATION.md.
-Radicale is available on PyPI. To install, just type as superuser:
-$ python3 -m pip install --upgrade radicale
-If you want the development version of Radicale, take a look at the git repository on GitHub, or install it directly with:
-$ python3 -m pip install --upgrade git+https://github.com/Kozea/Radicale
-You can also download the content of the repository as an archive.
-You can download the Radicale package for each release:
-Radicale has been packaged for:
-Radicale is also available on Cloudron and has a Dockerfile.
-If you are interested in creating packages for other Linux distributions, read the "Contribute" page.
-Radicale is a complete calendar and contact storing and manipulating solution. It can store multiple calendars and multiple address books.
-Calendar and contact manipulation is available from both local and distant accesses, possibly limited through authentication policies.
-It aims to be a lightweight solution, easy to use, easy to install, easy to configure. As a consequence, it requires few software dependencies and is pre-configured to work out-of-the-box.
-Radicale is written in Python. It runs on most of the UNIX-like platforms (Linux, *BSD, macOS) and Windows. It is free and open-source software.
-Radicale is a server, not a client. No interfaces will be created to work with the server, as it is a really (really really) much more difficult task.
-CalDAV and CardDAV are not perfect protocols. We think that their main problem is their complexity, that is why we decided not to implement the whole standard but just enough to understand some of its client-side implementations.
-CalDAV and CardDAV are the best open standards available and they are quite widely used by both clients and servers. We decided to use it, and we will not use another one.
-Important global development choices have been decided before writing code. They are very useful to understand why the Radicale Project is different from other CalDAV and CardDAV servers, and why features are included or not in the code.
-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.
-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.
-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.
-Radicale has been started as a (free topic) stupid school project replacing another (assigned topic) even more stupid school project.
-At the beginning, it was just a proof-of-concept. The main goal was to write a small, dirty 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 (many) beers at the very end of 2008 (Python 2.6 and 3.0 were just released). It's now packaged for a growing number of Linux distributions.
-And that was fun going from here to there thanks to you!
-{{ site.description }}
-- {{ site.title }} is a small but powerful CalDAV (calendars, todo-lists) and CardDAV - (contacts) server, that: -
- -- {{ site.title }} is really easy to install and works out-of-the-box. -
- -$ python3 -m pip install --upgrade radicale -$ python3 -m radicale --config "" --storage-filesystem-folder=~/.var/lib/radicale/collections- -
- When your server is launched, you can check that everything's OK by going - to http://localhost:5232/ with your browser! - You can login with any username and password. -
- -- Want more? Why don't you check our wonderful - documentation? -
-- Latest version of {{ site.title }} is {{ latest_release.tag_name }}, - released on {{ latest_release.created_at | date: "%B %-d, %Y" }} - (changelog). -
- -- Latest version of {{ site.title }} is {{ latest_release.tag_name }}, - released on {{ latest_release.created_at | date: "%B %-d, %Y" }} - (changelog). -
- - {% for post in site.posts %} -