Eigene Daten besitzen, Teil 1: Integration einer selbst gehosteten Kalenderlösung
(emilygorcenski.com)- Durch häufige Dienstreisen und Reisen sowie die Pflege von Kontakten über mehrere Zeitzonen hinweg entstand der Bedarf an einem eigenen Kalendersystem, das die Abhängigkeit von Big Tech reduziert und die direkte Kontrolle über Termindaten ermöglicht
- Die neue Architektur stellt den Baïkal-CalDAV-Server in den Mittelpunkt, sammelt Airtrail, IMAP-E-Mails und ICS-Dateien der Sprachschule, speist sie in CalDAV ein und veröffentlicht sie anschließend wieder als gemeinsam nutzbare
.ics-Dateien - Der Ansatz, Termine in YAML zu schreiben und in CI/CD in ICS umzuwandeln, reichte für den Prototyp aus, führte aber zu vielen manuellen Fehlern und hohem Pflegeaufwand, sodass der statische Datei-Ansatz ersetzt wurde
- Ein Python-Skript sammelt und klassifiziert alle 15 Minuten Events, erstellt getrennte ICS-Dateien für Familie und Arbeit und markiert einige Events im Arbeitskalender als PRIVATE
- Google Calendar und Google Script werden nur für die Synchronisierung des Arbeitskalenders genutzt; nach der Airtrail-API-Integration erscheint ein einmal eingetragener Flug innerhalb von 15 Minuten im privaten Kalender und innerhalb von 1 Stunde im Arbeitskalender
Warum Kalenderverwaltung kompliziert wurde
- Wegen häufiger Ortswechsel war es für Familie, Freunde und Kolleginnen schwer zu erkennen, in welcher Zeitzone man sich gerade befindet oder ob man im Flugzeug sitzt; für Termine über mehrere Zeitzonen hinweg war ständig Zeitumrechnung nötig
- Flüge, Züge, geblockte Zeit vor dem Boarding und Transferzeiten zum Flughafen mussten mehrfach an verschiedenen Stellen eingetragen werden, was den Aufwand für die Terminverwaltung erhöhte
- Die Unannehmlichkeiten bestehender Kalender-Ökosysteme betrafen Standards, Frontend-Apps und die gesamte User Experience
- Selbst wenn ein E-Mail-Anbieter Kalendereinträge für Flüge erstellt, können Anschlussflüge fehlen oder Zeitzonen falsch sein
- Da der Organizer der erzeugten Einträge nicht der Nutzer ist, können Teilen oder Bearbeiten schwierig sein
- Die Anforderungen gingen über einfache Terminspeicherung hinaus und umfassten auch Teilen und Kontrolle
- Events müssen im Arbeitskalender als blocker erscheinen
- Der Ehepartner muss den Kalender abonnieren können
- Events sollen höchstens einmal eingegeben werden müssen
- Änderungen müssen auf mehreren Geräten möglich sein
- Die Daten müssen direkt kontrolliert werden
- Den Arbeitskalender mit dem Ehepartner zu teilen, ist keine Option
- Zusätzliche Anforderungen umfassten den Import von
.ics-E-Mail-Anhängen, den Import von HTTP-ICS-Dateien des Sprachschulkalenders, die Integration des selbst gehosteten Flugtrackers Airtrail, Farbcodierung, ein Privat-Flag für den Arbeitskalender, häufiges Aktualisieren und die Nutzung beliebiger Frontends
Wo der YAML- und ICS-Ansatz an Grenzen stieß
- Bestehende Sharing-Ansätze bieten oft nur dann den vollen Funktionsumfang, wenn eine gemeinsame Plattform oder dieselbe Account-Umgebung vorhanden ist
- Gmail- oder Outlook.com-Ökosystem
- Account-Sharing in derselben Umgebung wie Exchange
- Übliche Workarounds gab es zwei
- iCal-Daten per HTTP bereitstellen und einen schreibgeschützten Kalender veröffentlichen
- iCal-
.ics-Dateien per E-Mail versenden
- Die erste Version lud
.ics-Dateien unter einer öffentlichen, aber schwer zu erratenden URL der Website hoch und nutzte mehrere URLs für verschiedene Zwecke - Event-Daten wurden in YAML geschrieben und in einer CI/CD-Pipeline mit einem kleinen Skript wieder zu ICS-Dateien serialisiert
- Für den Prototyp reichte das aus, aber mit wachsendem Umfang häuften sich Fehler beim manuellen Schreiben von YAML, und eine eigentlich aufwandsarme Aufgabe wurde belastend
Die neue Architektur mit CalDAV und Baïkal
- Die neue Architektur verabschiedet sich von statischen Dateien und wechselt zu einem gehosteten CalDAV-basierten System
- CalDAV ist eine Erweiterung der WebDAV-Spezifikation für verteiltes Authoring und stellt Funktionen bereit, die Kalenderanwendungen benötigen
- Mit einem CalDAV-Server lassen sich Events über ausgewählte Frontend-Apps auf mehreren Geräten wie Laptop und Smartphone anzeigen und verwalten
- Da es nicht viele CalDAV-Server gibt, die sich ohne Authentifizierung leicht abonnieren lassen, wurde ein Skript benötigt, das den Server regelmäßig pollt, Events extrahiert und als iCal-Datei auf der Website veröffentlicht
- Der gesamte Ablauf sieht so aus
- Events aus Datenquellen pollen
- Events programmatisch in CalDAV veröffentlichen
- Alle Events aus CalDAV abrufen und in
.ics-Dateien schreiben .ics-Dateien per HTTP bereitstellen
Baïkal-Installation und Client-Anbindung
- Das gewählte Tool ist Baïkal, ein leichtgewichtiger, selbst gehosteter CalDAV/CardDAV-Server zur Verwaltung von Kalendern und Kontakten
- Per Docker Compose wird das Image
ckulka/baikal:0.9.5ausgeführt; Ports und lokale Volumes werden angegeben und der Start erfolgt mitdocker compose up -d - Baïkal kann auch MySQL verwenden, funktioniert aber ebenso mit SQLite; SQLite ist einfacher zu verwalten
- Für die Webveröffentlichung kommt ein nginx Reverse Proxy zum Einsatz
- Verbindung zum lokalen Baïkal-Port über
proxy_pass - 301-Redirect von
/.well-known/caldavaufdav.php - Dieser Redirect ist nötig, wenn der Kalender in der Kalender-App von iPhone oder Mac hinzugefügt wird
- Verbindung zum lokalen Baïkal-Port über
- TLS wurde mit Let’s Encrypt und
certboteingerichtet;certbotaktualisiert die nginx-Konfigurationsdatei automatisch - Nach dem Aufruf der Domain im Browser wird ein Admin-Konto angelegt, anschließend werden Nutzer und Kalender erstellt
- Die Verbindung wurde mit den Standard-Kalender-Apps von macOS und iOS hergestellt; in den macOS/iOS-Einstellungen werden dabei manual settings verwendet, nicht automatisch oder advanced
Event-Klassifizierung und Sichtbarkeit im Arbeitskalender
- Die iCalendar-Spezifikation enthält zwar die optionale Eigenschaft
CATEGORIESfürEVENT-Komponenten, doch die verwendeten Tools wie macOS Calendar, iOS Calendar und Google Calendar implementieren dieses Feld nicht - Freitext-Klassifizierung ist schwer konsistent zu halten, daher werden Event-Typen mit Python-Enums modelliert
- Beispiele:
TerminType,CultureType,SocialType,AwayType,TransportType - Enthalten sind Werte wie
MEETUP,CONFERENCE,CLASS,APPOINTMENT,MEETING,EXAM
- Beispiele:
- Die Aufteilung der Enums in mehrere Gruppen dient dazu, Event-Typen konzeptionell zu ordnen
- Das Klassifizierungssystem enthält auch Logik zur Sichtbarkeit im Arbeitskalender
- Zweistellige Enum-Werte werden im Arbeitskalender standardmäßig als private behandelt
- Events wie Arzttermine werden in einer separaten Arbeitskalender-Datei privat serialisiert
- Diese Klassifizierung verbessert Auffindbarkeit und visuelle Erkennbarkeit von Events und sorgt in Frontends mit Farbcodierung für bessere Übersicht
Python-Synchronisierungsskript und ICS-Veröffentlichung
- Für die Automatisierung ist ein Python-Skript an einen cron job angebunden
- Das Skript sammelt mehrere Eingaben, speist sie in Baïkal ein und exportiert sie wieder als teilbare ICS-Dateien
- Events per IMAP aus E-Mails importieren
- Flug-Events aus der Airtrail-API extrahieren
- Gehostete ICS-Datei der Sprachschule abrufen
- Gesammelte Events nach Baïkal pushen
- Alle Events aus Baïkal abrufen und erneut in eine oder mehrere gemeinsam nutzbare ICS-Dateien serialisieren
- Die IMAP-Integration importiert per E-Mail erhaltene Kalendereinladungen automatisch und fügt sie dem Kalender hinzu, ähnlich wie Google Calendar
- Das Einstiegsskript für cron erstellt jeweils einen
Calendarfür Familie und Arbeit, ruft Events aus Baïkal ab und verarbeitet sie verzweigt- Events werden der Familien-ICS hinzugefügt
- Der Arbeits-ICS werden sie nur hinzugefügt, wenn die berufliche E-Mail-Adresse nicht im serialisierten Event-Ergebnis vorkommt
- Je nach Ergebnis von
is_work_publicwird die classification aufPUBLICoderPRIVATEgesetzt
- Das Baïkal-Integrationsskript ruft Remote-Events mit
PROPFIND-Requests und HTTP-Digest-Authentifizierung ab - Wenn die Event-Beschreibung ein
CATEGORIES:-Muster enthält, wird die Kategorie aus dem Beschreibungsfeld extrahiert, inevent.categorieseingetragen und der entsprechende String aus der Beschreibung entfernt - Die gemeinsam nutzbaren ICS-Dateien werden von nginx unter schwer zu erratenden URLs bereitgestellt; die URLs werden aus zufälligen, gesalzenen Hash-Strings erzeugt
- Dieser cron job läuft alle 15 Minuten
Synchronisierung mit dem Arbeits-Google-Calendar
- Es ging nicht nur darum, Events im privaten Kalender zu sehen; Reise- und Flugtermine sollten im Arbeitskalender auch als geblockte Zeit erscheinen, damit Kolleginnen den Status erkennen können
- Zum Kopieren in den Arbeitskalender wird Google Script Engine verwendet
- Das Basisskript ist eine modifizierte Version von GAS-ICS-Sync
- Die modifizierte Version liest die Kalender-Eigenschaft
CATEGORIESund wendet Farbcodierung im Arbeitskalender an - Google Script läuft im 30-Minuten-Intervall
- Die Nutzung von Google Calendar steht zwar im Widerspruch zum Ziel, die Abhängigkeit von Big Tech zu reduzieren, wird aber als Vorgabe der Arbeitsumgebung und nicht als private Abhängigkeit eingeordnet
Betriebsergebnis und Kosten
- Dieses System wird seit etwa 6 Monaten mit kleineren Änderungen und Ergänzungen genutzt
- Die jüngste Änderung ist die Integration der Airtrail-API
- Wird ein Flug gebucht, werden die Daten in den Flugtracker eingetragen
- Innerhalb von 15 Minuten erscheint er im privaten Kalender
- Innerhalb von 1 Stunde wird er automatisch in den Arbeitskalender kopiert
- Bei komplexen Mobilitätsanforderungen hat sich der Zeitaufwand für Kalenderverwaltung deutlich reduziert und zu einer Verbesserung der Lebensqualität geführt
- Die Gesamtkosten lassen sich minimieren; der Betrieb ist auch auf einem heimischen NAS einfach möglich
- Derzeit werden zum Ausführen der Website und der Integrationen Serverstunden in der Schweiz für etwa 100 US-Dollar pro Monat abonniert
- Diese Kosten sind etwas überdimensioniert und sollen mit der Zeit optimiert werden
- Dass die Einrichtung auf einem Docker-Host einer VM-Instanz schnell möglich war, rechtfertigte die zusätzlichen Kosten; die einfachere Kalenderverwaltung spart Zeit im Gegenwert von 100 US-Dollar pro Monat
1 Kommentare
Hacker-News-Kommentare
Ich rechne mit Widerspruch, aber ich finde, CalDAV ist nicht besonders gut
Wenn es wirklich einfach und großartig wäre, gäbe es viel mehr selbst gehostete CalDAV-Lösungen und die Usability wäre besser; auch Radicale hat mich nicht überzeugt
Eigentlich wollte ich einen eigenen CalDAV-Server implementieren, weil ich praktisch nur eine einzige Kalenderdatei bereitstellen wollte, aber selbst das Freigeben einer einzelnen Datei war so wenig intuitiv und kompliziert, dass ich aufgegeben habe
Wenn man einen Kalender mit anderen Personen über CalDAV-kompatible Apps teilen muss, verstehe ich den Bedarf, aber zum Hosten eines Kalenders nur für mich selbst fühlt es sich fast wie Zeitverschwendung an
Stattdessen habe ich anfangs eine dynamisch aktualisierte iCal-Datei in einen S3-Bucket gelegt und sie mit ICSx5 unter Android synchronisiert. HTTPS allein reichte, ganz ohne CalDAV
Allerdings fehlen für Android weiterhin gute freie Open-Source-Kalender-Apps, und ICSx5 läuft unter GrapheneOS nicht gut, daher nutze ich jetzt Proton Calendar, das direkte Links auf iCal-Dateien unterstützt, auf fast dieselbe Weise
Der Ansatz mit dem iCalendar-Format ist gut, aber der Umfang der iCalendar-Unterstützung unterscheidet sich je nach Kalender-Software stark, sodass ich am Ende die meisten Metadaten statt in dedizierte Properties ins Beschreibungsfeld schiebe
Mein Anwendungsfall ist eine Software, die Daten von verschiedenen Websites wie Eventbrite, Meetup, Pub-Quiz-Anbietern und öffentlichen Veranstaltungskalendern holt, nur die für mich interessanten sozialen Events herausfiltert und sie zu einem einzigen Kalender zusammenführt, den ich in meiner normalen Kalender-App sehen kann
Außerdem hatten wir enorme Mühe, mit den nicht standardkonformen CalDAV-Servern von Exchange und Google umzugehen, und die Nutzer haben uns die ganze Schuld daran gegeben
Jetzt, wo ich bei Google arbeite, sehe ich, dass die gCal-Apps ein komplett anderes Protokoll verwenden
Statt ein leichtgewichtiges Format zu sein, wurde es überdesignt, weil es zu viel auf einmal leisten sollte, und am Ende wurde daraus ein Protokoll wie ein verfilztes Knäuel aus unterschiedlichen Ideen
Dadurch liegt es außerhalb dessen, was viele Dienste tatsächlich wollen, weshalb sie gar nicht erst versuchen, die gesamte Spezifikation vollständig einzuhalten
W3C-Spezifikationen für Datenformate scheinen immer so zu enden; bei Low-Level-Protokollspezifikationen wirkt es vergleichsweise weniger so
Es ist 15 Jahre her, dass ich es gelesen habe, aber ich erinnere mich, dass es auch teilweise darum ging, wie solche Protokolle im Designprozess in Komitees die Orientierung verlieren
Allein die Tatsache, dass dieses Projekt etwa 2001 begann, zeigt, was für ein altes Dauerproblem Kalender sind
Wenn man wissen will, warum es nicht gut ist, ist es empfehlenswert; außerdem ist es auch als Geschichte über den Konflikt zwischen Startups und Open Source, Produktentwicklung und Softwareentwicklung allgemein gut
http://www.dreamingincode.com/ ; https://en.m.wikipedia.org/wiki/Dreaming_in_Code
Für die Android-Synchronisierung nutze ich DAVX5, eine Open-Source-App ohne Root, die einen Hintergrund-Sync-Dienst betreibt; die Einrichtung war ziemlich problematisch, möglicherweise wegen Unterschieden in der CalDAV-Implementierung. Auch die Synchronisierung von DAVX5 mit dem ZOHO-Kalender dauert lange
Evolution unter Ubuntu hat recht gute CalDAV-Unterstützung, aktualisiert aber jedes Mal den gesamten Kalender, wenn man zwischen Mail- und Kalenderansicht wechselt. Das Aktualisieren des ZOHO-Kalenders dauert lange, und ZOHOs Rate Limits sind streng, sodass man praktisch weich blockiert wird
Im aktuellen Thunderbird gibt es eine CalDAV-Inkompatibilität, weil ein anderer erfolgreicher HTTP-Statuscode erwartet wird. ZOHO liefert 200, Thunderbird erwartet aber einen anderen Code. Nebenbei: Der Thunderbird-CalDAV-Code ist in JS geschrieben
Dieses Problem tritt nur beim zweiten Kalender auf, und sobald man den zweiten hinzufügt, beginnt es zu scheitern. Zumindest mit ZOHO ist es ziemlich schmerzhaft
Ein weiterer empfehlenswerter CalDAV-Server ist Radicale
Er ist in Python geschrieben und ziemlich modular aufgebaut, sodass man Plugins für Authentifizierung, Autorisierung usw. einbinden kann
Die Daten werden als einfache Textdateien gespeichert, die ich mit git nachverfolge und sichere
Mit der Zeit habe ich einige interessante Anpassungen angesammelt. Die Authentifizierung läuft über pam des Hostsystems, und für das Teilen von Kalendern lasse ich ein periodisches Skript laufen, das Kalender für alle berechtigten Nutzer per Symlink verknüpft. Allerdings gibt es dabei ein kombinatorisches Explosionsproblem
Außerdem habe ich mit einem Berechtigungs-Plugin, das eigene CalDAV-Properties nutzt, und einem modifizierten Web-Plugin Zugriffskontrolllisten hinzugefügt
Öffentliche Kalender erhalten per ACL Leserechte für den Benutzer
public, und ein nginx-Hack erlaubt umfassenden Zugriff für LeseoperationenDieser öffentliche Kalender ist in einem Webkalender einsehbar: https://gitlab.nomagic.uk/popi/js_calendar_from_ics
Ich sollte wohl einen Blogpost über dieses Setup schreiben
Genau der Artikel, den ich gebraucht habe
Auf meinem privaten Server nutze ich den SoGO-Kalender von Mailcow, für meinen Arbeitskalender Fastmail, aber die beiden harmonieren nicht gut miteinander
Ich habe keinen Weg gefunden, den Mailcow-Kalender sauber mit anderen Tools zu verbinden, und verbringe daher Zeit mit halbmanueller Synchronisierung
Ich wollte Kalender schon länger trennen, aber die einzige Alternative, die ich kannte, war Nextcloud, und das halte ich für etwas schwergewichtig
Baïkal sieht gut aus, und ich möchte es bald ausprobieren. Damit könnte ich auch erkunden, Mailcow durch einen anderen selbst gehosteten Maildienst zu ersetzen
Ich bin in letzter Zeit ziemlich aggressiv dabei, aus der Cloud auszusteigen. Es waren Hunderte GB an Daten, aber die Migration hat selbst mit Unterbrechungen keine zwei Wochen gedauert und funktioniert deutlich besser als erwartet.
Der einzige ausgelagerte Dienst ist E-Mail, weil ich keine Lust habe, mich mit MX-Records und IMAP/SMTP herumzuschlagen.
Bei allem anderen hat ein Asus PN40 mit Dual-Core-Celeron-CPU sehr geholfen. Er ist gut zugänglich und hat Slots für M.2-NVMe- und SATA-Laufwerke, was eine sichere Backup-Konfiguration an einem Ort ermöglicht.
Ich stimme zu, dass CalDAV etwas fragwürdig ist, aber Nextcloud hat die meisten meiner Anforderungen erfüllt. Auch mit Redis können manche Vorgänge langsam sein, aber Kalender, Dropbox-/Google-Drive-Ersatz, Dokumente, Fotos, Backups und automatische Synchronisierung erledigt es gut.
Ergänzt man das um mehrere Open-Source-Lösungen, sind auch Musik- und Videostreaming, Monitoring, Benachrichtigungen, VPN, Reader, Admin-Tools und diverse Utilities abgedeckt.
Dieser Mini-PC ist zwar eher leistungsschwach, aber dank eines hervorragenden ISP bewältigt er alles mit reichlich Reserven und könnte problemlos noch 5–6 Leute wie mich zusätzlich aufnehmen.
Es fühlt sich an, als würde etwas Altes wieder neu werden.
Anfang der 2000er habe ich mit Mozilla Sunbird Kalender über das IIS-WebDAV-Modul auf meinem privaten Win2k-Server gehostet.
CardDAV gab es damals meiner Erinnerung nach noch nicht, aber ich kann mich irren.
Am Ende habe ich all diese Daten in Google Calendar importiert, und wenn man weit zurückgeht, sind sogar noch Dinge wie Uni-Aufgaben erhalten, was ziemlich amüsant ist.
Einige Termine wurden nicht auf den Server hochgeladen und gingen verloren; ich nutzte es zusammen mit einem DAViCal-Server über CalDAV.
Sunbird wurde eingestellt, und ich habe in letzter Zeit nicht nachgesehen, ob es unter Windows einen brauchbaren Ersatz gibt.
Baikal sieht interessant aus.
Früher habe ich DAViCal verwendet, um Kalender zwischen einigen Apple-iOS-Geräten zu teilen. Wenn es funktionierte, funktionierte es gut, aber mit wechselnden iOS-Versionen schien es instabil zu werden, also habe ich es schließlich aufgegeben.
Wenn ich mir das irgendwann wieder ansehe, werde ich DAViCal und Radicale prüfen, und jetzt auch Baikal.
https://www.davical.org/
https://radicale.org/v3.html
Kürzlich bin ich zu Nextcloud gewechselt, weil mein Shared-Hosting-Anbieter die Bereitstellung übernimmt und es eine integrierte Web-UI gibt, wodurch der Konfigurationsaufwand deutlich geringer ist.
Ich nutze Baikal seit einigen Jahren, und es ist ziemlich robust. Allerdings nutze ich es allein und habe nicht alle Anforderungen aus dem Originalbeitrag.
Auf dem Desktop verbinde ich es mit dem integrierten Kalender von Thunderbird, auf dem Smartphone nutze ich DAVx5 aus F-Droid und Fossify Calendar.
Fossify Calendar ist ein Fork der Calendar-App von Simple Mobile Tools, aber trotz des Namens ist es die funktionsreichste Kalender-App, die ich bisher gesehen habe.
Mir gefällt die Einfachheit, dass alle Optionen direkt angezeigt werden, statt einen durch mehrere Menüs und Dialoge zu schicken.
Bei der Arbeit nutze ich Outlook, zu Hause Google Calendar, und die Synchronisierung per HTTP ist völlig unzuverlässig.
Offenbar werden Zeitzonen ständig vermurkst; mal wird in UTC veröffentlicht, mal nicht, sodass Meeting-Zeiten immer falsch sind.
Ich verstehe nicht, warum diese beiden großen Anbieter so eine grundlegende Funktion nicht reparieren können.
Wenn mein eigenes System das lösen würde, würde ich es sofort machen, aber ich habe Sorge, dass genau dasselbe passiert und ein in Outlook erstelltes Meeting mit zwei Stunden Abweichung importiert wird.
Außerdem verbieten viele Unternehmen die Synchronisierung zwischen privaten und beruflichen Kalendern wegen möglicher Datenlecks tatsächlich.
So etwas möchte ich auch für Fotos machen. Ich will schon seit einer Weile von Dropbox und Google weg, und meine Prioritäten sind zwei Dinge.
Erstens möchte ich aus meinen Fotos so etwas wie Erinnerungsfunktionen erstellen und ans Smartphone schicken können. Also Gruppierungen nach Kriterien wie Jahrestagen, ähnlichen Aktivitäten,
ich und X (X ist Ehepartner, Familie, Freunde usw.)oder Veränderungen im Laufe der Zeit.Zweitens sollen die auf Geräten aufgenommenen Fotos auf meinem Server gespeichert werden können.
Ich habe drei TrueNAS-Maschinen mit jeweils 2 TB Speicher an unterschiedlichen Standorten bereitgestellt und möchte diese Funktion nach und nach aufbauen.
https://www.synology.com/en-global/dsm/feature/photos
https://www.synology.com/en-global/dsm/feature/moments
Eine andere Möglichkeit ist, ganz ohne Server DecSync zu verwenden.
Thunderbird oder Evolution synchronisieren mit der Android-App, und Kalender, Kontakte, Aufgaben sowie RSS werden auf andere Peers repliziert. Es ist auch über F-Droid verfügbar.
https://github.com/39aldo39/DecSync