[Davical|https://www.davical.org/] ist ein CalDav Kalenderserver für einen [LinuxKalender]. 

ThomasBayen hat sich seit Anfang 2021 Davical ausgesucht, um für eine Weile damit zu arbeiten.

= Installation und Aufbau =

Die Installation unter Debian Buster war sehr einfach.

Davical basiert auf PHP (nicht so meine Lieblingssprache) und legt die Daten in einer PostgreSQL-Datenbank ab (find ich gut).

== Datenbank-Struktur ==

Wichtige Daten liegen dort direkt per SQL zugänglich in einer Datenbank-Struktur, aber dennoch findet man auch die kompletten VCARD bzw. VCALENDAR Daten als Text in der Tabelle caldav_data. Was davon man beim Hacken lieber hat, muss jeder selber wissen. Die Datenbank-Struktur sieht so verständlich aus, das man vielleicht auch von außen direkt daran manipulieren kann.

== LDAP Authentifizierung ==

Ich habe es sogar relativ einfach geschafft, meine Benutzer automatisch aus meinem Firmen-LDAP anzulegen - für mich ist das ein echter Vorteil. Es gibt eine Admin-Weboberfläche, mit der man komplexe Rechtevergaben, neue Kalender, etc. einstellen kann. Man fügt einen Block mit LDAP-Einstellungen zur Datei /etc/davical/config.php hinzu. Die Daten werden dann vom admin-Benutzer auf der Weboberfläche im Menüpunkt "Tools" synchronisiert (also nicht vollautomatisch). Man kann bis zu einem gewissen Punkt konfigurieren, was genau synchronisiert wird.

Ich habe in meinem LDAP z.B. das Feld employeeType benutzt, um dort "caldav" hineinzuschreiben für die Benutzer, die Davical anlegen soll. Dann kann ich die in der LDAP-Konfiguration direkt filtern. ''(Ein Filter nach Gruppen ist übrigens nicht so einfach und muss im Server extra konfiguriert werden - google mal nach OpenLDAP und memberOf)''.

Was mich bei meinen verschiedenen Experimenten immer wieder aufgehalten hat war, das mein interner LDAP-Server ein selbstsigniertes Zertifikat hat. Um den anzusprechen, muss man eine Zeile "TLS_REQCERT never" in die Datei /etc/openldap/ldap.conf schreiben.

==  Tipps und Tricks ==

=== Zugriffsrechte auf gemeinsame Ressourcenkalender ===

Die Permissions, die man verteilen kann, sind recht komplex. Irgendwie habe ich dabei immer wieder das Problem, das das nicht richtig zu funktionieren scheint. Am Ende war ich aber nicht ganz sicher, ob es daran lag, das ich zu kompliziert gedacht habe. Falls jemand z.B. einen gemeinsamen Kalender (oder Adressbuch) in einer Ressource einzurichten, macht man sich das Leben am einfachsten, wenn man in der gesamten Ressource alle Zugriffsrechte sperrt und dann wirklich auf der tiefsten Ebene der einzelnen Benutzer je Kalender/Adressbuch Rechte vergibt. Oder man gibt die ganze Ressource frei und hat dann eben seine Kalender/Adressbücher für alle Benutzer.

Für kleine Installationen dürfte es übrigens völlig ausreichen, wenn ein Benutzer einen zweiten Kalender einrichtet und dieses dann mit anderen Benutzern teilt. Ressourcen und Gruppen werden bei normalen Anwendungen deshalb nicht wirklich benötigt.


=== gemeinsame Kalender in der Praxis ===

Nachdem ich mit dem Einstellungen im Server und den ganzen Rechten und Properties und Grants und so weiter länger herumgesprielt habe, bin ich zu der Erkenntnis gekommen, das das Ganze irgendwie überhaupt nicht funktioniert. Um das mal kurz festzuhalten, hatte ich folgende Probleme:

Sowohl DAVx5 als auch Thunderbird konnten aus sowohl Gruppen- als auch Ressourcenkalendern keine Einträge lesen. Mit curl auf der Kommandozeile ging es allerdings, so das ich keine Ahnung habe, woran es scheiterte. vdirsyncer hatte dieselben Probleme. Beide können übrigens neue Todo-Einträge anlegen - nur keine lesen, ich nicht den selbst angelegten, wenn es darauf ankommt. Bei DAV5x verschwindet der Eintrag dann auch auf dem Handy nach der nächsten Synchronisation, bei Thunderbird bleibt er stehen. Nach einigem hin und her und ausprobieren aller möglichen Rechte habe ich ausser curl keinen Client gefunden, der Todo-Einträge lesen wollte.

Langer Rede kurzer Sinn: Ich habe es auf dem normalen Weg über die Rechtevergabe nicht hinbekommen, mit einem Client in einen Gruppenkalender zu schauen - also einen, der nicht mein eigener ist.

Was dann jedoch ging, war der *Umweg über Tickets*. Man legt in der Resource ein Ticket an. Dann merkt man sich dessen Namen. Nun geht man in den Benutzer und trägt ganz unten eine neue Bindung ein. Das ist sozusagen ein Softlink, mit dem der Kalender dann unter dem Benutzer selbst aufgerufen werden kann. Diese Zeile hat aber nur dann eine Wirkung, wenn man das soeben gemerkte Ticket einträgt. Und Voila! So geht's!

Warum das jetzt so ist, ist mir ein Rätsel. Ich kann mir unmöglich vorstellen, das die Davical-Entwickler all diesen Aufwand für das mehrstufige Rechtesystem gemacht haben und das mit zwei so bekannten Clients einfach nicht geht. Womöglich ist hier doch irgendwo der Wurm drin. Wer also dahinterkommt, bitte melden!

=== Kalenderfarben ===

Ich hätte gerne zentral eine Farbe für meinen Kalender gesetzt, (weil das vorher in Owncloud auch ging). In der Davical-Oberfläche oder in der Anleitung steht da leider gar nichts zu. Allerdings brachte mich [dieser Mailinglisten-Thread|http://davical-general.89287.n3.nabble.com/Davical-general-Set-calendar-color-property-td4026743.html] dazu, zu verstehen, das diese Farben durch sogenannte Properties geregelt werden und diese wiederum sehr wohl von Davical unterstützt werden - nur halt nicht in der Oberfläche. Ich vermute, das ein Client mit entsprechenden Möglichkeiten diesen Wert setzen könnte - vielleicht tut der dort angesprochene Apple-Client das ja ([So steht es hier zumindest|http://davical-general.89287.n3.nabble.com/Davical-general-calendar-color-on-iphone-td2205840.html]). (Interessanterweise ist der ganze Kram nirgendwo dokumentiert oder auch erwähnt. Vielleicht bin ich aber ja auch nur zu blöde, das zu finden.)

Auf jeden Fall habe ich mit folgendem direkten Befehl in der Datenbank die Property für die Farbe für meinen Kalender gesetzt. Danach eine neue Synchronisierung mit DAV5x auf meinem Android und zack! hatten die Kalendereinträge die gewünschte Farbe! :-)

  insert into property 
    (dav_name, property_name, property_value, changed_on, changed_by) 
    values ('/myuser/calendar/', 'http://apple.com/ns/ical/:calendar-color', '#0E61B9', now(), 1002)
  ;

bzw. zum ändern:

  update property 
    set property_value='#c000c0', changed_on=now() 
    where dav_name='/myuser/calendar/' and property_name='http://apple.com/ns/ical/:calendar-color';

= Clients =

== Android ==

Eine Verbindung mit meinem __Android__ per [DAVx5|https://www.davx5.com/] ergab eine einfache und perfekte Anbindung für Kalender, Aufgaben und Kontakte.

Als URL musste ich nur http://caldav.servername.org/benutzer/ angeben. Alle Kaleneder- und Adressbuch-Ressourcen wurden daraufhin automatisch gefunden (Das mag daran liegen, das ich auch die Redirect-Kommandos in der Apache Konfiguration für die well known urls gesetzt habe). Wer sich über die Konfigurationsfrage nach der Kontaktgruppen-Methode wundert, wählt am besten die Vorgabe "Gruppen sind VCARDs" (siehe https://www.davx5.com/tested-with/davical).

== Thunderbird (mit Cardbook) für Kontakte ==

Außerdem setze ich auf dem Desktop die [CardBook-Erweiterung|https://gitlab.com/CardBook/CardBook] für den __Thunderbird__ ein. Man kann sie im Standard Add-On Store auswählen. Diese Erweiterung ist wirklich leistungsfähig und versucht wohl gerade, das bisherige Adressbuch im Core Thunderbird zu ersetzen.

Man kann ein Adressbuch im Cardbook auch offline betreiben. Dann wird das Adressbuch nicht sofort angezeigt, sondern bei einer Suche jeweils online abgefragt. Diese Funktion war (mit einem Davical-Server im lokalen Netz) rasend schnell. Alle Daten sind so immer auf dem aktuellen Stand und Änderungen werden sofort synchronisiert. Der einzige Nachteil ist, das man nie die gesamte Liste sieht (und diese z.B. auch nicht herunterladen kann).

Apropos herunterladen... Die Export-Funktion des Thunderbird Cardbook ist eine schöne Methode für ein Backup der Daten als vcf-Datei, das man eventuell hin und wieder haben möchte.

Im Thunderbird CardBook muss ich als URL https://mein-server.domain.org/username/addresses angeben. Außerdem hatte ich in meinen ersten Tests ein selbstsigniertes Zertifikat, das dazu führte, das die Verbindung ohne weitere Erklärung oder Fehlermeldung nicht aufgebaut wurde. Sehr ärgerlich. Abhilfe gab mir dann [dieser Artikel|https://gitlab.com/CardBook/CardBook/-/issues/838]

== Kommandozeile ==

Aufgrund meiner Probleme mit geteilten Kalendern habe ich alles mögliche versucht, um das zu debuggen. Dabei habe ich [vdirsyncher|http://vdirsyncer.pimutils.org/en/stable/tutorial.html] und khal gefunden (beide als Debian-Pakete verfügbar), das echt spannend ist, um CalDAV auf der Kommandozeile zu benutzen.

Wer es ganz basic mag, kann natürlich auch curl benutzen. Beim Debuggen war das auch hilfreich. Dazu vielleicht noch folgende Links:

* https://www.atmail.com/blog/caldav-carddav/
* https://www.calendarserver.org/CalDAVClientLibrary.html


= Installation im Container =

Da ich in den letzten Tagen auch mit [Podman] erste Schritte gemacht habe, habe ich mich mal umgeschaut, ob es fertige Container-Images für Davical gibt. Dabei bin ich auf https://github.com/datze/davical gestossen.

Das Image erlaubt zwei externe Volumes, die in den Container eingebunden werden, aber ausserhalb liegen: Eines für die PostgreSQL-Datenbank und eines für die Konfiguration. Um dieses config-Verzeichnis zu füllen, ist es am sinnvollsten, zuerstmal das git-Projekt herunterzuladen und die vier genannten Konfigurationsdateien nach /var/davical/config/ zu kopieren. Außerdem legt man /var/davical/data/ an.

Um SSL zu benutzen, erzeugt man ein passendes SSL-Zertifikat (z.B. mit [LetsEncrypt] und kopiert die Zertifikatsdateien nach /var/davical/config/ssl/.

Im Grunde installiert und konfiguriert sich das Ding fast von ganz alleine. Ich habe die apache.conf angepasst, um ssl zu nutzen und um meine Zertifikate einzubinden. Daraufhin konnte man den Container starten mit:

  podman run -d --name davical -p 443:443 \
    -v /var/davical/data:/var/lib/postgresql/data -v /var/davical/config/:/config \
    -e HOST_NAME="caldav.thomasbayen.de" -e TIME_ZONE='Europe/Berlin' \
    datze/davical_https

Außerdem habe ich danach noch die Konfiguration in davical.php angepasst, um die von mir gewünschte LDAP-Authentifizierung zu nutzen (das ist aber natürlich für normale Anwender gar nicht nötig). Mein Spezialproblem mit dem selbstsignierten LDAP-Server habe ich behoben mit

  podman exec -l bash -c 'echo "TLS_REQCERT never" >>/etc/openldap/ldap.conf'

Die Installation war sofort erreichbar und ich konnte loslegen. Das admin-Passwort sollte man sofort ändern und dann steht einem fröhlichen Kalendern nichts mehr im Weg.

Wer generell Zugriff in den Container braucht, kann das mit podman exec erreichen. Zum Beispiel dient folgender Befehl dazu, eine SQL Kommandozeile in der davical Datenbank zu bekommen. Die Option "-l" bedeutet, das man den zuletzt benutzen Container anspricht (also keinen Containernamen angeben braucht), die Option "-ti" öffnet ein interaktives Terminal, da wir in diesem Fall nicht nur eine Ausgabe haben wollen.

  podman exec -l -ti bash -c 'su postgres -c "psql davical"'


[{Tag ServerDienste Cloud EigeneWolke Container}]