2020-11-11 11:47:10 +01:00
---
title: Radicale
template: docs
taxonomy:
2020-11-14 14:14:50 +01:00
category: docs, apps
2020-11-11 11:47:10 +01:00
---
2014-06-17 09:25:57 +02:00
2020-11-11 11:47:10 +01:00
Radicale is a calendar and contact server CalDAV/CardDAV. It does not have a graphical administration interface.
2015-10-04 01:24:53 +02:00
2020-11-11 11:47:10 +01:00
Radicale is installed by default with the web client InfCloud that will view and edit your calendars and address books.
2014-06-17 09:25:57 +02:00
2016-04-13 12:29:10 +02:00
To connect another client to radical, we must inform these addresses:
2014-06-17 09:25:57 +02:00
2016-04-28 17:32:25 +02:00
### Complete CalDAV/CardDAV collection of a user
- URL: https://domain.tld/path/user/
- Exemple : https://example.org/radicale/me/
2014-06-17 09:25:57 +02:00
2016-04-28 17:32:25 +02:00
### To connect a calendar in particular
- URL: https://domain.tld/path/user/calendar.ics/
- Exemple: https://example.org/radicale/me/calendar.ics/
2014-06-17 09:25:57 +02:00
2016-04-28 17:32:25 +02:00
### To connect an address book in particular
- URL: https://domain.tld/path/user/AddressBook.vcf/
- Exemple: https://example.org/radicale/me/AddressBook.vcf/
2016-04-13 12:29:10 +02:00
2016-04-28 17:32:25 +02:00
### Create a new schedule or a new address book
2020-11-11 11:47:10 +01:00
Create a new schedule or a new address book is very simple with Radicale, just go there! Radicale creates all new calendar or notebook to nonexistent addresses if you try to access it.
2016-04-13 12:29:10 +02:00
So just log on (as before) to a calendar or a nonexistent address book to create it.
This can be done simply with a browser, to appear in a collection already connected to a client.
2016-04-28 17:32:25 +02:00
### Go to a calendar or an address book of another user
2016-04-13 12:29:10 +02:00
Previous addresses also work to access resources not owned by the authenticated user.
> Example:
> User1 can connect to the collection of user2
> https://example.org/radicale/user2/
> Simply to indicate the login and password of user1.
> It's sharing rules (see below) that will allow or not to user1 to see the contents of the collection of user2.
> By default, no sharing is allowed.
---
2016-04-28 17:32:25 +02:00
### Configure the access rights and sharing of calendars and address books
2016-04-13 12:29:10 +02:00
By default, any user has the right to read and write on its own calendars and address books.
It is possible to refine these default rules and to allow sharing by allowing users to access their resources do not own.
The rules governing these rights should be included in the */etc/radicale/rights*
Each rule is in this form:
2016-04-27 16:49:20 +02:00
```bash
2016-04-13 12:29:10 +02:00
# Comment before rule and explaining that (optional of course):
[Rule Name]
user: user concerned
collection: calendar, book or collection concerned.
permission: permission, r (read), w (write) or rw (read/write)
2016-04-27 16:53:34 +02:00
```
2016-04-13 12:29:10 +02:00
*Rights* file contains several examples that can be exploited.
2020-09-14 15:32:07 +02:00
To validate changes to the */etc/radicale/rights* file, radical must be recharged via uWSGI service.
2016-04-27 16:49:20 +02:00
```bash
2016-04-13 12:29:10 +02:00
sudo service uwsgi restart
2016-04-27 16:53:34 +02:00
```
2016-04-13 12:29:10 +02:00
2016-04-28 17:32:25 +02:00
### Share resources
2016-04-13 12:29:10 +02:00
To share a calendar or address book, just write a rule permitting. Sharing can be done with another user.
2016-04-27 16:49:20 +02:00
```bash
2016-04-13 12:29:10 +02:00
user: ^user1$
collection: ^user2/shared2.ics$
permission: rw
2016-04-27 16:53:34 +02:00
```
2016-04-13 12:29:10 +02:00
Or publicly for a remote user does not use the same server.
2016-04-27 16:49:20 +02:00
```bash
2016-04-13 12:29:10 +02:00
user: .*
collection: ^user2/shared2.ics$
permission: r
2016-04-27 16:53:34 +02:00
```
2016-04-13 12:29:10 +02:00
In both cases, the sharing works only using the full address of the calendar or collection. In other words, the shares do not appear in the collection of a user.
This limitation may be blocking for clients managing a single collection, as InfCloud. In this particular case, a solution overcomes this problem.
2016-04-28 17:32:25 +02:00
#### Share resources directly in the collection of a user
2020-09-14 15:32:07 +02:00
> This solution is functional, but is an hack...
2016-04-13 12:29:10 +02:00
To enable sharing to occur directly in the collection of a user, it must exploit the use of files in Radicale.
By simply creating a symbolic link to the resource sharing.
2016-04-27 16:49:20 +02:00
```bash
2016-04-13 12:29:10 +02:00
ln -sr user2/shared.ics user1/user2_shared.ics
2016-04-27 16:53:34 +02:00
```
2016-04-13 12:29:10 +02:00
The shared resource becomes a resource from the collection of user1, while it physically remains in the collection of user2.
However, without recourse to the rules for each resource in the collection of user1, the general rule applies. user1 gets so read and write access by default on the shared resource because it is part of his collection.
---
2016-04-28 17:32:25 +02:00
### Making Radical log more verbose
2016-04-13 12:29:10 +02:00
By default, the Radical log is set to INFO. This method savings the hard drive but does not debug Radicale in case of problems.
2020-09-14 15:32:07 +02:00
To pass Radicale in DEBUG mode, edit the */etc/radicale/logging* and change INFO to DEBUG in sections *[logger_root]* and *[handler_file]* . Then reload the uWSGI service.
2016-04-13 12:29:10 +02:00
Now, the log displays all requests that are made to Radicale and analysis of *rights* file.
However, do not stay on this mode because the log is filled very quickly.
---
2016-04-28 17:32:25 +02:00
### Change config of InfCloud
2016-04-13 12:29:10 +02:00
The configuration of InfCloud is in the *infcloud/config.js* file
To load any changes in the *config.js* file (or other file of InfCloud) must reload the cache with the script provided.
2016-04-27 16:49:20 +02:00
```bash
2016-04-13 12:29:10 +02:00
sudo ./cache_update.sh
2016-04-27 16:53:34 +02:00
```