.. -*- coding: utf-8; mode: rst -*-
.. _xref_radicale_Server:
===============
Radicale Server
===============
* Radicale: http://radicale.org
Ich habe mich für Radicale entschieden, da es sich auf CalDAV und CardDAV
beschränkt und keine Groupware ist, die mehr Lösungen anbietet als ich brauche.
Weiter lies sich Radicale gut *hinter* dem Apache unter einer Präfix URL
(``radicale``) platzieren (https://hostname/radicale). Andere Lösungen siehe
Alternativen_.
.. hint::
Letztes Release ist v2.x (https://github.com/Kozea/Radicale/releases), der
**master** Branch wurde inzwischen jedoch stark überarbeitet. Im Zuge dieser
Überarbeitung werden z.T. andere Settings benötigt, als sie noch in der
offiziellen Dokumentation beschrieben werden. Die hier vorgestellte
Installation basiert auf dem **master** Branch und verwendet immer die
*aktuellen* Settings.
Die CalDAV und CardDAV Server Installation (Radicale) erfolgt in eine bestehende
Apache Instanz (siehe :ref:`xref_apache_setup`). Die hier vorgestellt
Installation verwendet das interne WEB-Frontend von Radicale. Als Alternative
bietet sich eine vollwertige WEB-Anwendung für Adressbuch und Kalender an. So
gibt es z.B. für `InfCloud
`_ eine Integration
`RadicaleInfCloud `_), die jedoch
nicht zu den aktuellen Änderungen im **master** Branch passt.
Sharing
=======
Radicale ist ein leichtgewichitiger CalDAV & CardDAV Server, der allerdings kein
echtes Sharing von (z.B.) Kalendern über CalDAV vorsieht. Die sogenannten
*Vertreter-* Regelungen, die es auch für CalDAV gibt sind im Radicale nicht
vorgesehen (wäre zu ausufernd und nicht alle Clients *sprechen* exakt das
gleiche Protokoll).
Es ist jedoch möglich über Plugins die Zugriffsrechte auf die *Collection* zu
steuern. In `/etc/radicale/rights`_ ist eine Konfiguration zu sehen, bei der
dezidierte Lese-Berechtigungen vergeben werden. Die URL zu einem seiner Kalender
kann man über sein Login ermitteln. Bei https://hostname/raidcale anmelden,
dort kann man die URLs bestehender Kalender sehen oder auch neue Kalender
anlegen. Will man seinem Kollegen den Kalender bereit stellen, muss man ihm nur
diese URL geben, die er als *Abo* in seinen Kalender mit aufnimmt.
radicale.wsgi
=============
Seit commit `54b999 `_ gibt
es den Schlüssel ``[logging]-->config`` nicht mehr::
[logging]
# config=/etc/radicale/logging ... no longer exists
Um das Logging Setup aus `/etc/radicale/logging`_ dennoch zu aktivieren, muss
die Konfiguration (z.B. in der WSGI Datei) geladen werden:
.. code-block:: python
#!/usr/bin/env python3
"""Radicale WSGI file (mod_wsgi and uWSGI compliant)."""
import logging.config
logging.config.fileConfig('/etc/radicale/logging', disable_existing_loggers=False)
from radicale import application
Authentifizierung
=================
Die Authentifizierung wird in diesem Setup vom Apache übernommen. In der
`/etc/radicale/config`_ wird dazu als Authentifizierung ``remote_user`` gewählt:
.. code-block:: cfg
[auth]
type = remote_user
Die Apache Konfiguration sieht dann in etwa wie folgt aus. Hier im Beispiel
wird eine Basic-Authentifizierung mit :man:`pwauth` verwendet:
.. code-block:: apache
WSGIScriptAlias /radicale /var/www/pyApps/radicale.wsgi
SecRuleEngine Off
Require valid-user
Order deny,allow
Deny from all
Allow from fd00::/8 192.168.0.0/16 fe80::/10 127.0.0.0/8 ::1
AuthType Basic
AuthBasicProvider external
AuthName "radicale"
AuthExternal pwauth
Zusammengefasst ergibt sich::
Basis-URL: https:///radicale
Benutzername:
Passwort:
Der ```` ist der Benutzername des Logins (``pwauth``). Benutzername und
Passwort ergeben sich aus den LDAP- und System Benutzern (posix)."
/etc/radicale/config
====================
In der exemplarischen Konfiguration unten wird für das Rechte Management das
Plugin ``from_file`` gesetzt, als Konfiguration wird die Datei
`/etc/radicale/rights`_ verwendet. Damit ist ein detaillierteres
Rechte-Management möglich, wer das nicht braucht, sollte das Plugin
``owner_only`` für das Rechte-Management nutzen.
.. code-block:: cfg
# -*- mode: conf -*-
[server]
# !!! We use WSGI behind apache, so nothing to configure here in the 'server'
# !!! section
[auth]
# Authentication method
# Value: none | htpasswd | remote_user | http_x_remote_user
# remote_user: plugin, that gets the login from the ``REMOTE_USER``
# environment variable (for WSGI server)
type = remote_user
[rights]
# Rights backend
# Value: none | authenticated | owner_only | owner_write | from_file
type = from_file
# File for rights management from_file
file = /etc/radicale/rights
[storage]
# Storage backend
type = multifilesystem
# Folder for storing local collections, created if not present
filesystem_folder = /var/www/pyApps/Radicale.data/collections
[web]
# Web interface backend
type = internal
[logging]
# Threshold for the logger
# Value: debug | info | warning | error | critical
level = info
/etc/radicale/rights
====================
Der Pfad wird in der `/etc/radicale/config`_ gesetzt:
.. code-block:: cfg
[rights]
type = from_file
file = /etc/radicale/rights
Unten ist ein exemplarisches Setup, bei dem dezidierte Lese-Berechtigungen
vergeben werden. Die Vergabe der **W** und **R** Berechtigungen war
erforderlich um die interne WEB-Seite zum laufen zu bekommen (**master**
Branch).
.. code-block:: cfg
# -*- mode: conf -*-
# 1. The user "admin" can read and write any collection.
[admin]
user: admin
collection: .*
permissions: RWrw
# 2. Example: dedicated sharing with 3 users
[user001]
user: user001
collection: user002(/.*)?
permissions: r
[user002]
user: user002
collection: user001(/.*)?|user003(/.*)?
permissions: r
[user003]
user: user003
collection: user002(/.*)?
permissions: r
# 3. Authenticated users can read and write their own collections.
[owner-write]
user: .+
collection: %(login)s(/.*)?
permissions: RWrw
# 4. Added 'R' to get WEB interface running
[read]
user: .+
collection: .*
permissions: R
/etc/radicale/logging
=====================
Das Logging entspricht dem `Configuration file format
`_
des Python Logging. Hier im Beispiel wird ein *Rotating-Log* in der Datei
``/var/log/radicale/radicale.log`` angelegt.
.. code-block:: cfg
# -*- mode: conf -*-
[loggers]
keys = root
[logger_root]
handlers = file
[handlers]
keys = file
[handler_file]
class = logging.handlers.RotatingFileHandler
args = ('/var/log/radicale/radicale.log', 'a', 100000, 10)
formatter = full
[formatters]
keys = full
[formatter_full]
format = %(asctime)s - [%(thread)x] %(levelname)s: %(message)s
Alternativen
============
Baikal (http://sabre.io/baikal) ist ein ebenfalls oft genutzter Cal- und CardDAV
Server. Er basiert auf 'sabre/dav' (http://sabre.io) was eine PHP
Implementierung des CardDAV, CalDAV und WebDAV ist (das wird auch von OwnCloud
genutzt). Ich hatte Baikal auch schon mal vor vielen Jahren installiert, dann
wurde das aber zwischenzeitlich *kaputt-gebastelt*. Die Arbeit an der Version 2
wurde wohl ganz eingestellt. Das alles und der Umstand, dass es sich um eine
PHP Implementierung handelt, läßt mich von Baikal abstand nehmen.
Wer eine Groupware sucht, der sollte sich evtl. folgende Projekte anschauen.
* SOgo: https://sogo.nu
Es gibt drei *main* Versionen SOgo2, Sogo3 und SOgo4. Ab Version 3 gibt es
ein WEB-Interface. Alle Versionen nutzen die gleiche Implementierung der SOGo
und SOPE Protokolle: LDAP, IMAP, SQL, CardDAV, CalDAV und Microsoft Enterprise
ActiveSync. Mit letzterem bietet SOgo ein Sync-Protokoll (Microsoft
ActiveSync) an, dass auch vom Outlook *verstanden* wird (ich hab es aber noch
nicht gestet).
* Cozy: https://cozy.io (https://github.com/cozy/cozy-stack )
Das Cozy hat sich inzwischen stark weiter entwickelt, Erfahrungen hab ich damit
noch keine, man könnte sich aber bei Gelegenheit mal die `Self-hosted Lösung
`_ anschauen.