Normalerweise bin ich eher zurückhaltend und verwende nicht Wörter wie „Desaster“.
Aber hier blieb mir nach meiner Meinung keine andere Wahl.
Für einen Kunden sollte ich einen privaten lokalen Kalender einrichten, der eben nicht über die Cloud läuft und der über das „iPhone“ zu verwalten ist.
Nach einer sehr langen Installationsphase lief es schließlich zufriedenstellend. Es gab immer wieder Probleme wegen des xfs-Dateisystems, z.B. bei Upgrades des Debian-Systems, aber es lief. Jahrelang.
Dann, schon vor einiger Zeit, wurde „calendarserver“ datenbankbasiert und nicht mehr dateisystembasiert umprogrammiert.
Das Paket ist ursprünglich, wenn das stimmt, was ich in Erfahrung bringen konnte, von Apple.
Fakt ist, daß diese „mitgelieferte“ Routine, die alten Daten hochzuhieven auf die Datenbank, nie funktioniert hat. Und ich habe sie auch nicht zum Laufen bekommen. Ich bin in einem riesigen komplexen Abhängigkeitskonstrukt von Python-Paketen gelandet, verschiedenen Python-„deprecated“-Problematiken (2.7) und habe es nicht zum Laufen bekommen und zum Kunden gesagt: Ich weiß nicht, ob der Code überhaupt funktioniert, es wird einfach zu teuer. Wir sollten an dieser Stelle abbrechen.
Jetzt sollte ich einen neuen Anlauf wagen und stelle fest: Das Paket „calendarserver“ gibt es gar nicht mehr unter „Debian“.
Es ist eine Bestätigung für den Kurs, den ich seit langem fahre: Als Programmierer sollte man davon ausgehen, daß die eigenen Programme viel länger laufen, als man denkt. Größere Umarbeiten sollten dann nicht notwendig sein. Wenn dann die zugrundeliegende Programmiersprache wie „Python“ auf einmal in entscheidenden Bereichen „deprecated“ ist oder ganze Bibliotheken abgekündigt werden oder es Funktionen nicht mehr gibt (wie in „php“), sollte man sich vorher gut überlegen – mit dem Kunden gemeinsam – in welcher Programmiersprache man ein Projekt überhaupt angeht und auf welche externe Bibliotheken man sich verläßt.
Das „objektorientierte“ Perl habe ich vor dem Hintergrund auch nicht verstanden. Es gibt Perl-Programme von mir, die laufen jetzt seit über 20 Jahren.
Teil 2: Installation von „radicale“ unter Debian Linux (Bookworm)
Als Alternative für einen lokalen Kalender – also komplett ohne „Cloud“ habe ich „radicale“ ausgewählt.
Nur: Es lief und lief nicht.
Ursprünglich wollte ich komplett ohne „ssl“, aber dann ging es gar nicht mit der „iPhone“-Kalender-„App“.
Also mit „ssl“, den „snakeoil“-Zertifikaten.
Allerdings sind nicht alle Kalenderprogramme („iPhone“) zufrieden mit selbstsignierten Zertifikaten, also doch „letsencrypt“.
Hier ließ sich seltsamerweise der Dateiname überhaupt nicht verwenden.
Mit folgenden Schritten lief es dann:
- addgroup radicale ssl-cert [den Benutzer „radicale“ der Gruppe „ssl-cert“ hinzufügen]
- cp -a /etc/letsencrypt/archive/muc.hinner.de/privkey22.pem /etc/ssl/private/ssl-cert-snakeoil.key
- chmod 440 ssl-cert-snakeoil.key
- chown :ssl-cert ssl-cert-snakeoil.key
- cp /etc/letsencrypt/archive/muc.hinner.de/fullchain22.pem /etc/ssl/certs/ssl-cert-snakeoil.pem
Es kamen dann noch weitere Fehler, man muß im „log“ nachschauen und den Benutzer „radicale“ zum „Owner“ machen der Verzeichnisse, in die geschrieben werden soll.
Ich bin nicht sicher, ob das je jemand ausprobiert hat, meiner Meinung nach kann die Standard-Installation überhaupt nicht funktionieren.