View Attach Info

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. (siehe auch hier oder hier) 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).

Clients connecten #

Ohne weiter Konfiguration hat der Server einen Benutzer "test" mit dem Passwort "test".

Thunderbird #

Als erstes habe ich einen aktuellen Thunderbird probiert. Historisch betrrachtet gab es ein Kalender-Plugin für den Thunderbird, das man installieren konnte und eine Version, die direkt inklusive Kalender ausgeliefert wurdfe. Die akteulle in Debian verwendete Version enthält den Kalender und Punkt. Wer also keinen hat, sollte rechercheiren, wie er am besten bei seiner Version und Betriebssystem vorgeht.

In Thunderbirds richtete sich der Kalender quasi von alleine ein. Wer es mit Bildchen haben möchte, kann im Debian Wiki nachsehen.

Android #

Ich benutze auf meinem Android Handy mit einem 7.x Bestriebssystem die freie App DavDroid, die ich vom F-Droid App Store geladen habe. Auch hier legte sich der Kalender quasi von selber an. In den Einstellungen unter Konten wählt man ein neues Davdroid-Konto an und gibt als URL dann http://caldavserver.loc:8008/principals/users/test ein. Und schon kann ich Termine zwischen dem Thunderbird und dem Handy austauschen.

Fazit #

Der Server läuft jetzt und ich kann mit Thunderbird Kontakte anzeigen. Leider ist der gesamte Server unsäglich schlecht dokumentiert. Ich muss mich korrigieren - er ist einfach überhaupt nicht dokumentiert. Die Tatsache, das es auch keine aktuellen Artikel über eine Installation gibt (sagen wir mal: wie meiner hier) und das man es tatsächlich geschafft hat, wegen einem eigentlich relativ simplen Versionskonflikt in einer Bibliothek aus der akteullen Debian-Distribution herauszuschiessen, macht mich zusätzlich etwas nervös, wie gross die Nutzerbasis des Servers wohl ist.

Bei meinem alten Server (OwnCloud) konnte man pro Benutzer mehrere Kalender einrichten und diese dann später getrennt ein- uznd ausblenden und teilen (sagen wir mal einen Urlaubskalender in der Firma teilen oder die Familientermine mit seinen Liebsten). Ich vermute, das geht über sogenannte Gruppen, die wie User in der Konfigurationsdatei angelegt werden können, aber probiert habe ich das noch nicht.

Der Server arbeitet mit einem ordentlichen Datenbank-Backend, in dem ich die interessanten Informationen auch wiederfinde. Allerdings sind die Infos nicht so abgelegt, das man direkt was damit anfangen kann. So habe ich z.B. noch nicht raus, wie man per einfachem SQL Termine einer Woche herausfinden kann. Hierzu muss man jeweils den VCalendar-Texdt parsen, was mir weder einfach noch effektiv vorkommt. Vielleicht habe ich aber auch die Datenbankstruktur noch nicht weit genug erforscht. Oder kann man das einfach mit SQL-Stringfunktionen erreichen?!?

Den Zugriff per https habe ich ebenfalls noch nicht konfiguriert, der sollte aber möglich sein.

Meine Anforderungen waren: Zuverlässigkeit, Sicherheit Kompatibilität mit verschiedenen Clients, Zugriff auf die Daten von außerhalb, Zugriff per Datenbank-Report.

Ob ich den Zugriff per Datenbank-Report hinbekomme, ist noch so eine Frage. Wenn das bedeutet, das ich erst einen Zwischenschritt brauche, um aus den VCalender-Daten eine Tabelle zu machen, kann ich das im Grunde ja auch tun, indem ich mir einen Java-Client schreibe, der auf irgendeinen beliebigen Server zugreift. Der Gedanke war ja, die Datenbank direkt zur Verfügung zu haben. Auch die Frage, ob man direkt Einträge in der Datenbank einfügen oder ändern kann, ist noch nicht geklärt. Auch das wäre natürlich mit einem Client am sichersten lösbar.

Ich denke, ich habe noch etwas nachzudenken. :-) Bis hierhin kann ich aber sagen, das der Calenderserver mich bis auf die nicht vorhandene Dokumentation in diesem Experiment nicht enttäuscht hat.

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

Tags:  ServerDienste, Cloud

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-5) was last changed on 15-Jul-2017 15:56 by ThomasBayen