Calendarserver
Back to current versionRestore this version

Auf der Suche nach einem guten LinuxKalender habe ich mich entschlossen, den Calendarserver von Apple auszuprobieren. Dieser ist ein reiner Server für CalDAV und CardDAV-Daten. Er hat keine Oberfläche oder so etwas. Der Zugriff auf die Daten kann dann also z.B. mit einem Android Kalender, dem Thunderbird Kalendermodul oder ähnlichen Oberflächen geschehen.

Hier möchte ich dokumentieren, wie ich den Servber installiert habe und welche ersten Erfahrungen ich damit gemacht habe.

Installation #

Basissystem #

Ich habe mich entschlossen, einen ganz neuen Server hierfür aufzusetzen, um alle fremden Einflüsse auszuschliessen. Als System habe ein aktuelles Testing (Debian Buster vom 15.7.17) gewählt. Das dürfte zur Zeit nicht viel Unterschied vom offiziellen Stretch-Release haben, weil dieses noch nicht sehr lange her ist.

Ich habe folgende Pakete zusätzlich zu einem Mini-Buster installiert. (Kann sein, das manche nicht wirklich nötig gewesen wären, aber das hier ist, was ich gemacht habe): 

  joe, sshd, aptitude, xattr, postgresql-client binutils gcc

postgresql #

Da ich einen eigenen, grossen Postgres-Server im Netz betreibe und die Daten dort gerne weiterverarbeiten möchte, habe ich diesen als externen Server benutzt. Das variiert die Installation natürlich und macht sie etwas einfacher. Informationen, wie der Server in beiden Stellen einzurichten ist, stehen aber gut erklärt in der Datei /usr/share/doc/calendarserver/README.Debian.gz

xattr #

Die Calendarserver-Dokumentation sagt, das auf dem Filesystem xattr-Attribute eingeschaltet werden müssen. Dies kann man mit folgendem Befehl prüfen, der die Ausgabe "user_xattr" ergeben sollte. 

  # cat /proc/fs/ext4/sda1/options | grep xattr

Versionsauswahl #

Der erste Schreck war, das es auf Grund einer scheinbaren Inkompatibilität kein offizielles Debian-Paket in Debian Stretch gibt. Ich habe ein bisschen recherchiert. Es gibt eine Version 3.2 in Wheezy und eine 7.0 in Sid. Und es gibt einen grave Bug auf Grund einer Inkopatibilät mit einer aktuelleren Bibliothek, die in Buster enthalten ist, an dem wohl zur Zeit gearbeitet wird. Upstream ist die Version 9.0 aktuell. Ich möchte es dennoch lieber mit der aktuelleren Version 7.0 versuchen...

https://serverfault.com/questions/22414/how-can-i-run-debian-stable-but-install-some-packages-from-testing

Das Problem konnte dann (nach dieser GRundeinstellung des APT-Systems) gelöst werden, indem ich zusätzlich zu Buster (meine eigentliche Revision) und Sid (um den Calendarserver zu installieren) auch noch Jessie (das die sqlparse-Bibliothek ohne die neue Inkompatibilität enthält) in meiner {sources.list} angegeben habe und dann folgendes gemacht habe: 

  apt-cache policy python-sqlparse
  aptitude install python-sqlparse=0.1.13-2

Konfiguration #

Datenbank #

Erst habe ich wie in der README-Datei angegeben, eine Datenbank {caldav} und einen Datenbank-User {caldavd} auf dem PostgreSQL-Server erstellt. Dann habe ich die entsprechende Schema-Datei gestartet, die die Datenbank eingerichtet hat: 

  psql -h postgresql.local -f /usr/lib/python2.7/dist-packages/txdav/common/datastore/sql_schema/current.sql caldav caldavd

Nun habe ich in der Datei {/etc/caldavd/caldavd.plist} den Eintrag für den DBType angepasst: 

    <!-- TB -->
    <key>DBType</key>
    <string>postgres</string>
    <key>DatabaseConnection</key>
    <dict>
        <key>endpoint</key>
        <string>tcp:postgresql.local</string>
        <key>database</key>
        <string>caldav</string>
        <key>user</key>
        <string>caldavd</string>
        <key>password</key>
        <string>geheimescaldavdpassword</string>
    </dict>

IPV6-Probleme vermeiden #

Nach dem Starten des Servers hat der erste Zugriff mit dem Thunderbird bei mir leider nicht funktioniert. Im Log {/var/log/caldavd/error.log stand eine Fehlermeldung, der Methode gethostbyaddr "{socket.error: Address family not supported by protocol}". Das konnte ich nach einiger Recherche beheben. Richtig verstanden habe ich das Problem nicht, aber es tritt wohl auf, weil das System irgendwo aus Versehern IPv6 benutzt, das aber nicht korrekt in meinem ganzen Netzwerk konfiguriert ist (ich benutze es auch normalerweise nicht). Abholfe schafft folgender Eintrag in der Konfiguration. Dadurch bindet der Server explizit an die externe IP-Adresse des Rechners, die hier eine IPv4-Addresse ist. 

  <!-- List of IP addresses to bind to [empty = all] -->
  <key>BindAddresses</key>
  <array>
    <!-- TB -->
    <string>192.168.2.110</string>
  </array>

Server aktivieren #

In {/etc/default/calendarserver} das starten des Servers aktivieren und dann mit 

  /etc/init.d/calendarserver restart

starten.

Man kann in der Prozessliste mit 

  ps waxu | grep cal

nachsehen, ob der Server läuft und ggf. im Systemlog sehen, was schiefgegangen ist (zumindest war das bei obigem PRoblem mit der sqlparse-Bibliothek so).

Diese Links haben im weitesten Sinne mit dem Thema zu tun und sind mir bei meiner Arbeit aufgefallen.

Tags:  ServerDienste, Cloud