Kalender radikal

Ich wollte schon immer mal einen Kalender auf Handy und Tablet syncen, war aber nicht so davon überzeugt, alle meine Daten Google in den Rachen zu werfen. Kommt Urlaub, kommt Zeit, kommt Selfhosting, wie man so sagt.

Das Stichwort für sowas ist CalDAV-Server (CalDAV ist im wesentlichen ein Protokoll, um einen iCal-Kalender über HTTP verfügbar zu machen). Da ich etwas möglichst Simples (ich verwalte ja keine Firma mit 300 Mitarbeitern) und einfach Wartbares haben will (ich will keinen Sicherheitsupdates hinterherlaufen, ich habe keine IT-Abteilung für Serverbetreuung), ist meine Wahl auf radicale gefallen, das gibt es nämlich als offizielles Debian-Paket.

radicale-Server

Radicale selbst ist schnell eingerichtet, man muss es nach der Paketinstallation eigentlich nur starten. Das geht entweder standalone oder unterhalb eines bereits laufenden Webservers wie z.B. Apache.

Da ich es einfach halten wollte und nicht so der Apache-Experte bin, habe ich mich mit der Standalone-Installation beschäftigt. Außerdem heißt es im Kleingedruckten der radicale-Anleitung, dass manche CalDAV-Clients nicht damit zurechtkommen, wenn die Kalender nicht direkt im Wurzelverzeichnis des Webservers liegen. Da ich so ohne weiteres keine Subdomains einrichten kann und auf meinem Webserver das Wurzelverzeichnis zufällig schon in Benutzung ist, bot sich der Standalone-Server, der standardmäßig auf Port 5232 läuft, an.

Authentifizierung

Da man die Kalender vermutlich nicht öffentlich zugänglich haben will, braucht man Zugriffssschutz, z.B. per Username und Passwort. Und damit Username und Passwort nicht jeder mitlesen kann, braucht man Verschlüsselung, in diesem Fall SSL bzw. HTTPS. Dazu steht auch wieder was in der Radicale-Anleitung, nämlich unter Authentication:

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.

Das hat mich leicht mißtrauisch werden lassen. Was mich dann erschreckt hat, war der Blick in die Konfigurationsdatei:

Moment mal, SSLv2? Das ist doch broken! Und SSLv3 will man eigentlich auch nicht mehr. Da ich von den Python-Libs keine Ahnung habe, habe ich mir das mal in der Doku des SSL-Moduls angeguckt: Die Konstante SSLv23 ist tatsächlich die einzige, die es ermöglicht, frei aus allen angebotenen TLS-Implementierungen zu wählen. Heilige Namensverwirrung, Batman! SSLv2 und SSLv3 kann (sollte!) man abschalten (die will man ja nicht), dafür gibt es die Konstanten OP_NO_SSLv2 und OP_NO_SSLv3. Ob das nun so schon default ist, man das nun von Hand machen muss und wenn ja, wie man das überhaupt in die radicale-Konfiguration kippen kann, hat sich mir nicht erschlossen.

Da ich jetzt keinen Python-Grundlagenkurs hinter mich bringen wollte, hab ich das also erstmal gelassen und mich stattdessen der Variante „läuft im Apache“ zugewandt, denn da ist mein SSL schon fertig konfiguriert. Auch muss ich mir da nicht erst noch wieder was basteln, um die Let’s Encrypt-SSL-Zertifikate so bereitzustellen, dass der radicale-Server sie findet, lesen darf und zu passender Zeit neu lädt.

zur Untermiete im Apache

Was radicale kann, kann Apache auch: Ich habe den Port 5232 einfach dem Apachen zugeschlagen, dann kommen sich die Kalender nicht mit irgendwelchen regulären Dingen auf Port 80 ins Gehege. Das war erstaunlich einfach: Erstmal in der ports.conf einen neuen Eintrag für den Port eingetragen:

In der entsprechenden (neuen) site-Konfiguration steht dann passend dazu ganz außenrum <VirtualHost www.example.com:5232>

Die eigentliche Konfiguration zum Aufruf des Skripts findet sich in der Anleitung und ist fix gemacht: Der wsgi-Wrapper ist im Debian-Paket schon enthalten und liegt unter /usr/share/radicale/radicale.wsgi (nicht vergessen, das Paket libapache2-mod-wsgi zu installieren). Für die Zugriffsberechtigung habe ich einfach folgenden Block in das <Directory /usr/share/radicale> mit aufgenommen und eine entsprechende passwd-Datei mit htpasswd(1) angelegt:

Wenn ich nichts vergessen habe (das ist bereits zwei Wochen her), war’s das auch schon.

Fallstricke

Auf folgenden zwei Dingen habe ich in einem Konglomerat von zwei miteinander vermischten Fehlersituationen ein paar Stunden rumgekaut:

Multiuser-Probleme in Apache

Die Apache-Beispielkonfiguration enthält folgende Zeilen:

Klar, irgendein Regexp, aber bevor man den auseinanderpflückt und versteht, kopiert man den lieber einfach so. Und der passende Hinweis darüber ist auch etwas verklausuliert:

You can then restrict the access: allow the alice user to access /alice/* URLs, and everything should work as expected.

Klartext: Die RewriteCond sorgt dafür, dass Username und erster Pfadnamenteil gleich sein müssen, sonst gibt es einen HTTP-Fehler 403.

Da ich hier gleich die Kür machen wollte (getrennte User für mich und meine Frau mit verschiedenen Passwörtern, aber gegenseiter Zugriff auf die Kalender), bin ich da voll reingerannt und habe viel zu lange Fehler in der Rechtekonfiguration gesucht (Variante from_file), statt zu merken, dass der Apache bereits die „Querzugriffe“ ablehnt.

Eine mögliche Lösung ist z.B. sowas:

Multiuser-Probleme in Thunderbird/Lightning

Zum clientseitigen Testen habe ich das Lightning-Plugin von Thunderbird genommen, weil Thunderbird hier sowieso installiert war. Generell ist die Einrichtung einfach und wie bei radicale beschrieben.

Wenn man aber wie ich die Kalender zweier verschiedene User auf dem gleichen Server hat (ich wollte sehen, ob die Anmeldung sowohl für mich als auch für meine Frau klappt und der jeweilige Querzugriff – ja, zu dem Zeitpunkt kannte ich ihr Passwort, das hab ich ja selbst in die passwd geschrieben), dann fällt man ganz unerwartet auf einen uralten Lightning-Bug rein: Lightning kann nur einen User pro Host.

Ich präsentiere Bug 247486, der von 2004(!) bis 2014(!) offen war. Gefixt ist er trotzdem nicht. Die Lösung ist ganz naheliegend und mit viel Rumgesuche in diesem und einem anderen Bug auch zu finden: Man geht in das about:config-Äquivalent unter Thunderbird, nämlich nach Preferences :: Advanced :: Config Editor… und setzt dort den Eintrag calendar.network.multirealm auf true. Anschließend ggf. alle Kalender und/oder Passwörter nochmal löschen und Thunderbird neu starten, dann kann man sich tatsächlich mit verschiedenen Usern am gleichen Server anmelden. Hallelujah!

(Auch das hat mich mindestens ne Stunde gekostet und in den Wahnsinn getrieben und jetzt brauche ich das gar nicht mehr, weil ja inzwischen der „Querzugriff“ funktioniert: ich melde mich nur mit meinem User an, kriege aber trotzdem Lesezugriff auf den Kalender meiner Frau.)

Android-Anbindung

Es gibt einen Haufen CalDAV-Plugins im PlayStore, allerdings scheinen sich die Programmierer abgesprochen zu haben: Die kosten allesamt Kohle! Meist gibt es eine 1-Wochen-Testversion, aber das war es dann auch. Nach einiger Sucherei bin ich schließlich auf Caldav Sync Free Beta gestoßen, der funktioniert trotz des „Beta“ im Namen bisher sehr gut. Leider bietet er keine Möglichkeit, die Sync-Intervalle individuell zu setzen oder z.B. auf „im WLAN“ zu beschränken.

Auf einem Gerät hier ist noch ein Uralt-Android im Einsatz, das sieht obige App im Appstore gar nicht, dort habe ich mir mit ICalSync2 beholfen. Funktioniert auch, kostet nichts und ist sogar konfigurierbar, was das Synchronisieren angeht. Schade, dass das auf neueren Geräten nicht verfügbar ist. Moment mal, compatible with all of your devices? Das muss ich mir nochmal angucken, vielleicht kommt das doch auf alle Geräte :-)

Datensicherung

Der radicale-Ordner liegt bei mir ganz normal im Backup, das sind ja auch nur ein paar Textdateien, das frisst kein Brot. Um kleinteiliger zu sichern und ggf. ein „mein Handy hat beim Synchronisieren alles gelöscht“ mit einem aktuellen Datenbestand heilen zu können, kann radicale ein git-Backend benutzen, so dass jede Änderung eines Kalenders einen git-Commit erzeugt.

Auch das ist einfach einzurichten (zumindest unter Python 2.7, unter Python 3 soll das git-Modul Probleme machen):

• dulwich installieren (der Python-git-Adapter, unter Debian als python-dulwich)
• git init im radicale-Datenverzeichnis machen
• einen initialen Commit machen, sonst existiert noch kein HEAD! (das steht so nicht in der Anleitung, aber ich meine, dass das ohne nicht funktioniert hat)
• die nächste Änderung in einem Kalender erzeugt dann von alleine einen Commit

Kontakte

Radicale kann neben Kalendern (CalDAV) auch Kontakte (CardDAV) synchronisieren. Das habe ich mir aber noch nicht wirklich tief angeschaut, weil ich irgendwie mit Android noch nicht ganz klar komme:

Wenn ich Kontakte aus mehreren Konten zusammenführe, werden dann auch die Daten ausgetauscht? Oder nur gemeinsam angezeigt? Wie kriege ich eine Telefonnummer aus einem bestehenden Kontakt rüber in den zusammengefügten Kontakt aus dem anderen, neuen radicale-Konto?

Softwaremäßig habe ich bereits folgendes aufgestöbert:

Android:

Contacts Account plus Contacts CardDAV Sync

PC:

pycarddav für Kommandozeile

Ganz klar: Baustelle. Ein zukünftiger Artikel? Publikumstipps?