Kalender (CalDAV) und Kontakte (CardDAV) Syncronisation mit OwnCloud und Desktop-PC sowie Smartphone - die Hürden
Einleitung / Zusammenfassung
In diesem Artikel geht es um den Versuch, ein eigenes sicheres (verschlüsseltes), Hersteller unabhängiges, im deutschen Rechtssystem installiertes Cloudsystem aufzubauen, um Kalenderdaten und Adressbucheinträge mit PC-Client und Mobiltelefon (Smartphone) zu syncronisieren.
Dropbox, iCloud, Google-Zeugs, etc kamen schon aus Sicherheitsgründen für mich nicht in Frage, unabhängig davon, dass die Daten in den Händen der USA / NSA sind.
Welche Hürden dabei zu nehmen sind bzw genommen werden mussten, soll dieser Artikel aufzeigen.
Mit dem Stand von Anfang September 2016 habe ich leider immer noch keine vollständige Lösung für meinen Ansatz.
die Vorgeschichte
Es herrschte Windows XP auf dem Destop und auf den Laptops und bis dahin war alles gut. Die Syncronisation von Adressen und Kalendereinträgen funktionierte mit dem bis dahin von Microsoft verwendeten ActivSync zur lokalen Syncronisierung per USB-Kabel zwischen meinem Handy (HTC Touch HD / Blackstone) sehr gut.
Auf der PC Seite wurde als Software MS Outlook verwendet, um Kontakte zu pflegen und Kalendereinträge vorzunehmen.
Dann kam Windows 7 und mit der lokalen Synconisierung mit Outlook war Schluss. Microsoft befand, dass ab nun alles per Cloud syncronisiert werden müsse. Microsoft meint damit natürlich seinen Exchange-Server.
Es musste dringend eine neue Lösung her.
Die sah dann wie folgt aus:
In der Kombination Mozilla Thunderbird (17.x) mit Lightning Add-On (1.9.1) sowie der Syncronisierungssoftware Birdie-Sync (2.4.5.2) konnte eine Adressen- und Kalendersyncronisierung wieder per USB-Kabel durchgeführt werden. Meine Welt war ersteinmal wieder in Ordnung. Auf dem HTC-Handy musste noch ein Programm installiert werden, welches die Daten an den PC weiterleitete.
OK, mit Outlook ging das früher geschmeidiger, weil das Activ-Sync immer sofort eine Syncronisierung vornahm, wenn auf einem der Devices sich was geändert hat.
Mit Birdie-Sync klappte das nicht ganz so gut: Änderungen auf dem Handy wurden sofort syncronisiert, aber Änderungen auf dem Destop-PC mussten von Hand angestossen werden.
Doch damit konnte ich leben.
Aufgrund der unterschiedlichen Softwaren in der Syncronisationskette habe ich mich nicht getraut, jemals ein Update von Thunderbird oder Lightning vorzunehmen: das Risiko, dass danach das Birdie-Sync und damit meiner Datensyncronisation nicht mehr läuft, war mir einfach zu gross.
Für die Darstellung von vcards in verschiedenen Clients habe ich auch einen extra Artikel angelegt.
ein neues Handy musste her
Der Akku meines HTC-Handy wurde immer schwächer. Manchmal schaltete sich das Handy einfach aus, obwohl noch 2 Akkubalken vorhanden waren.
Den Handy-Markt zu diesem Zeitpunkt teilten sich nur noch Apple und Android Systeme. Microsoft Phone 10 sowie BlackBerry spielten keine Rolle.
Aus Sicherheitsaspekten heraus - und das war das oberste Ziel - konnte man nur zwischen Pest und Collera wählen.
Recherchen im Internet zu beiden Krankheiten (Systemen), gerade nach der Snowden-Affaire, zeigten kein gutes Bild zur Datensicherheit und für einen Systemwechsel auf.
Dazu zeigte sich auch dort eine Infizierung Microsofts Krankheit zur Cloud-Syncronisierung.
So entschied ich mich erst einmal einen neuen Ersatzakku für mein HTC Touch HD zu bestellen.
Das mit dem Akku war allerdings nur aufgeschoben und verschaffte mir etwas Zeit.
eine eigene sichere Cloud muss her
Nach dem Studium etlicher Webseiten und der Zeitschrift CT, fiel dann die Entscheidung eine eigene sichere Cloud aufzuziehen.
Meine alte NAS QNAP TS-259 PRO war schon 4 Jahre alt und die Festplatten (im RAID 1) sicher bald am Ende des Nutzungszeitraumes angelangt.
Eine neue NAS QNAP TS-453A mit vier Festplatten wurde beschafft und in RAID 6 konfiguriert (im folgenden Daten-QNAP-NAS genannt).
Die alte NAS hingegen wurde neu formatiert und von einem externen Admin mit einem OwnCloud 8.5-System konfiguriert (im folgenden Cloud-QNAP-NAS genannt).
Das übliche Problem bei DSL-Anschlüssen blieb: mit wechselnde IPs kann man nicht von extern auf die NAS bzw auf das OwnCloud-System zugreifen.
An der DSL-BOX von NetCologne konnte ich keinen zuverlässigen und deutschen DynDNS-Anbieter finden.
Das Cloud-QNAP-NAS hingegen konnte den deutschen Anbieter selfhost als DynDNS-Anbieter verwalten.
Dieser kam mir recht gelegen, da er nicht nur seine eigenen Subdomainen für das DynDNS verwalten kann, sondern auch normal reservierte Domainnamen.
Also bei selfhost einen Domainnamen und das DynDNS-Paket gebucht (selfhost: DynDNS-Account).
Bei PSW wurde dann ein SSL-Zertifikat für die Transportverschlüsselung gekauft und vom Admin in die QNAP-NAS implementiert PSW: SSL-Zertifikate.
Somit stand für den externen Zugriff mit einer eigenen verschlüsselten Domain versehener Cloud nichts mehr im Wege.
Ein Problem ergab sich noch für die Clients innerhalb meiner IT-Infrstruktur:
Da ich eine kaskadierte NAT-Router-Infrastruktur im Einsatz habe (um den Zugriff meines DSL-Dienstanbieters auf meine Daten-QNAP-NAS zu verhindern) und ich ein Datenrouting über den externen DNS-Server des öffentlichen Internets vermeiden wollte, musste der NAT-Router in der zweiten Ebene einen Routingeintrag für die Domainnamenauflösung erhalten, um direkt die Datenpakete in die erste Zone (Cloud-QNAP-NAS) meiner Infrastrutur leiten zu können.
Das Daten-QNAP-NAS hängt mit den Clients in einer geschützteren zweiten Zone, wobei der Cloud-QNAP-NAS in der ersten Zone zusammen mit dem DSL-Router hängt.
Somit konnte ich im internen geschützten Netz genauso auf die Cloud-QNAP-NAS zugreifen wie vom öffentlichen Internet aus.
PC-Client-Zugriff auf die OwnCloud mit CalDAV und CardDAV
In der Vorbereitung zu der eigenen Cloud habe ich auch das Thema Clients auf den PCs beleuchtet.
Unten stehend habe ich meine Versuche und die Ergebnisse dazu beschrieben:
Outlook als PC-Client
Mit Outlook, obwohl ich ein paar Lizenzen frei hatte, wollte ich mich nicht mehr einlassen.
Zudem scheint es auch bei Outlook nicht mehr ohne ein AddOn zu gehen, wenn man mit einem CardDAV- und CalDAV-Server Kontakt aufnehmen möchte.
Aussdem hatte ich ja schon genug mit der Pest und der Collera zu tun, da wollte ich die Syphilis nicht auch noch ins Boot holen.
Thunderbird als PC-Client
So fiel wieder der erste Blick auf Mozillas Thunderbird 45, der derweil ab Version 35 das Lightning standardmäßig eingebaut hatte.
Wikipedia: Thunderbird, Wikipedia: Lightning
Blöd nur, dass diese Software von Hause aus keine CardDAV-fähige Kontakteverwaltung hatte.
Das CardBook-AddOn schien diesen Mangel kompensieren zu können Mozilla: CardBook.
Somit stand nun ein Test an, ob sich der Kalender und die Adressen im internen Netzwerk wie aus dem öffentlichen Internet aus syncronisieren lassen.
Der Thunderbird Kalender liess sich einfach für CalDAV einrichten und machte einen guten Eindruck.
Syncronisartionsprobleme gab es nicht. Änderungen in Thunderbird-Kalender wurden direkt mit dem CalDAV-Server syncronisiert.
Selbst die obige Softwarekette mit Thunderbird 17 und Birdie-Sync liess sich weiterhin nutzen, als ich den Kalender von Lokal auf CalDAV umgestellt habe.
Das CardBook-AddOn lässt sich gut installieren und einrichten.
Ursprünglich stand in diesem Artikel: CardBook weist Feldnamen falsch oder stellt sie einfach nicht dar. Feldzuweisungen laufen dann schief und werden beim Syncronisieren dann einfach gelöscht oder ignoriert.
Diese Aussage muss ich zurücknehmen, da der Fehler nicht aus dem CardBook sondern ursprünglich aus dem Adressbuch von the Bat! kam. Dort wurden die Felder falsch ausgefüllt und syncronisiert.
Fazit:
Man kann mit der Kombination Thunderbird (inkl. Lightning) und dem CardBook-AddOn ganz gut die Kalender- und die Kontaktefunktion nutzen und syncronisieren.
EssentialPIM Pro als PC-Client
Bei der Suche auf der CT-Downloadseite bin ich auf das Programm EssentialPIM Pro gestossen, auch EPIM abgekürzt genannt.
EPIM ist ein personal information manager, der E-Mails, Kontakte, Kalender, ToDOs und Notizen bearbeiten kann. Mich interessierten nur die Funktionen Kontakte und Kalender.
Laut Webseite kann das Programm, welche zur Downloadzeit als Version 6.58 vorlag, sowohl direkt OwnCloud-Server, als auch CardDAV- und CalDAV-Server ansprechen und deren Daten verarbeiten Astonsoft: EssentialPIM.
Der Assistent zur Einrichtung von CalDAV- und CardDAV-Servern ist angenehm und die Einrichtung erfolgt problemlos.
Nach der ersten Kontakte-Syncronisation lief EPIM problemlos. EPIM kann sich sogar mit einem Tapi-Server verbinden, um aus der Kontakte-Ansicht direkt eine Telefonverbindung aufzubauen. Diesen Service habe ich dann auch direkt genutzt und meine Auerswald-Telefonanlage per Tapi-Server eingebunden.
Der Erste wie auch der 1265. Versuch die Kalendersyncronisation hinzubekommen, scheiterte mit diversen Fehlermeldungen, wie zum Beispiel "Error loading items" oder "Invalid pointer operation" oder "Access violation at address 004CF9FB".
Über das Support-Forum habe ich diese Fehler gemeldet. Während meiner Testtage gab es neue Releases, die Verion 7.0 und die sehr schnell nachgeschobene Version 7.1, weil die Entwickler derat das User-Interface geändert haben, dass die überwiegende Mehrzahl der Nutzer wieder zurück zur Version 6.58 gegangen sind. Da anscheinden auch die Version 7.1 mit der heissen Nadel gestrickt war, folgte dem auch schnell die Version 7.11, die seit einigen Tagen nun Stabil scheint.
Erst nach einigen Tagen meldete sich ein Forum-Admin mit dem Hinweis, das ältere Programme nicht supported werden können. Ich sollte die 7.1 installieren und nochmals mit der OwnCloud-Methode die Syncronisation einrichten und testen.
Die OwnCloud-Methode hatte ich bis dahin nicht getestet, weil ich im Forum gelesen hatte, dass diese nicht ganz so gut für die Kalender- und Kontakte-Syncronisation geeignet wäre.
Aber ..., schön wärs gewesen.
Ich habe eine Reihe von versuchen unternommen, den Kontakt zwischen EPIM und dem OwnCloud herzustellen:
https://xDomainnamex.de/owncloud/remote.php/webdav/
-> 405 method not allowed
https://xDomainnamex.de/owncloud/remote.php
-> 404 not found
https://xDomainnamex.de/owncloud/
-> 405 method not allowed
https://xDomainnamex.de/
-> 404 not found
https://xDomainnamex.de/owncloud/index.php/
-> 405 method not allowed
https://xDomainnamex.de/owncloud/index.php/apps/
-> 405 method not allowed
https://xDomainnamex.de/owncloud/index.php/apps/files/
-> Tag not found .....
Auch mit der neuen Version 7.11 habe ich versucht mit der CalDAV-Methode die Kalendereinträge syncronisieren zu können.
Wie schon vermutet kam der Fehler "Error loading items" immer wieder.
Fazit:
Ich habe die Hoffnung noch nicht aufgegeben, aber definitiv hat der Hersteller die Syncronistaion mit CalDAV-Servern nicht im Griff.
Zur Zeit nutze ich hiervon nur die Kontaktefunktion.
Darstellung von vcards im EssentialPIM-Client
The Bat! als CardDAV-PC-Client
Ich nutze seit der Version 1.6 das E-Mail-Programm The Bat! und bin mit der E-Mail-Funktionalität sehr zufrieden Ritlabs: The Bat!.
Auch The Bat! hat ein eigenes Adressbuch, welches per CardDAV angebunden werden kann.
Die Praxis zeigte auch hier, dass die Syncronisierung nur auf dem Papier funktioniert.
The Bat! verhält sich sehr störrisch bei der Syncronisierung (bis Version 7.1.18 getestet).
Nur weil man per Hand eine Adressbuchsyncronisierung anstösst, heisst das nicht, dass The Bat! das auch vollständig tut.
Bei der ersten Syncronisierung einer neu aufgesezten Adressdatenbank auf OwnCloud stürzte The Bat! der Art ab, dass ich den PC neu starten musste (ohne Fehlermeldung und es waren nur 250 Kontakte).
Es hört einfach auf, wenn es Lust dazu hat - so scheint es zumindestens.
Dann geht es damit weiter, dass The Bat! Felder falsch zuweist oder gar nicht erst darstellt.
Geänderte Felder syncronisert The Bat! zwar augenscheinlich mit OwnCloud, aber in OwnCloud sind die Änderungen nicht verzeichnet.
Zuvor geänderte Felder werden dann "neu zurück syncronisiert".
Solange nur die Syncronisation CardDAV -> The Bat! genutzt wird, geht es nach ein paar mal halbwegs und man kann die Adressdatenbank im E-Mail-System nutzen.
Wird ein Eintrag in The Bat! geändert und dann syncronisiert, dann macht The Bat! was es will: Die Felder werden geändert oder Einträge einfach gelöscht.
Beim wiederholten Syncronisieren ist dann zu erkennen, dass Feldnamen geändert wurden.
Fazit:
Ich lade mir nur noch die aktuellen Adressen in The Bat! hinein - aber Einträge ändern werde ich dort nicht mehr.
Darstellung von vcards im the Bat!-Client
Smartphone-Zugriff auf die OwnCloud mit CalDAV und CardDAV
Natürlich stand auch auf dem Programm, die Adressen und Kontakte wieder im Handy im aktuellen Stand verfügbar zu machen. Wie oben schon geschrieben, musste ich zwischen Pest und Collera auswählen:
Andriod-Smartphone mit CyanogenOS / CyanogenMod
Den ersten Weg den ich einschlug, war der Weg der Collera (Andriod-Smartphone).
Ein originales Google-Android kam für mich aus Sicherheitsgründen überhaupt nicht in Frage. Übrig blieben dann noch die Smartphones mit installiertem CyanogenOS und die rootbaren Smartphones mit nachträglich installiertem CyanogenMod.
Um mir und meinem Admin ärger zu sparen, viel der weitere Blick auf das CyanogenOS. Bei Recherchen im Internet und Youtube (hier besonders zu erwähnen: Vergleich CyanogenMod mit CyanogenOS) dazu kam ich aber auch schnell zu dem Schluss, dass auch beim CyanogenOS Daten an Dritte versendet werden ohne das ich eine Möglichkeit zur Einflussnahmen darauf habe.
Beim CyanogenMod Betriebssystem verhält es sich so, dass es mit persönlichen Einschränkungen bei der Apps-Auswahl, ein höheres Sicherheitslevel bietet. Das Problem hierbei war aber dann, dass die einfach rootbaren Smartphones alle eines neueren Types sind. Und die haben eine Displaydiagonale von mindestens 5 Zoll. Da ich nicht ein Früstücksbrettchen in meiner Brusttasche mit mir rumschleppen wollte, kamen aber wiederum die großen Smartphones nicht in Frage. Auf den kleineren (und älteren) 4 Zoll Smartphones ging aber das neuste CyanogenMod nicht mehr zu installieren. Die Katze beisst sich in den eigenen Schwanz.
Als ich dann auch noch in einem CT-Artikel gelesen habe, dass Android und seine Ableger nativ gar kein CardDAV und CalDAV können, habe ich diesen Weg beendet.
Apple-Smartphone mit IOS
Als ewiger Apple-Hasser musste ich mich dann doch mit der Pest beschäftigen, denn dort wurde ein neues 4 Zoll IPhone SE angeboten.
Apple IOS kann sich nativ mit der Apple-iCloud, einem Exchange-Server oder aber auch mit CalDAV/CardDAV-Servern verbinden. Die Frage ist nur ob das auch funktioniert.
Im Apple-Shop kostet das IPhone SE knapp 489 Euro, was für einen Versuch, mit der Möglichkeit daran zu scheitern, deutlich zu viel Geld ist.
Aus dem Bekanntenkreis konnte ich mir für meine Versuche ein IPhone 4S ausleihen - so die Idee. Das auf Werkeinstellungen zurück gesetzte IPhone landete dann auch meinem Schreibtisch und ich konnte mit der Einrichtung beginnen. Die Verbindung zum WLAN ging fast Problemlos. Dann wollte das IPhone von mir plötzlich eine SIM-Karte haben. Warum zum Teufel braucht das Teil zum Einrichten eine SIM-Karte? Ich will damit gar nicht telefonieren. Egal wie und wo ich gesucht habe, ohne SIM-Karte geht die Einrichtung nicht weiter. Meine Mini-SIM-Karte passte aber nicht in den Mikro-SIM-Karten-Schlitz. Umtauschen konnte ich meine SIM-Karte ja natürlich auch nicht. Es blieb mir tatsächlich nichts anderes übrig, als eine Prepaid-Mikro-SIM-Karte zu kaufen.
Nach einigen Recherchen, ich wollte ins D-Netz und SIM-Karten für die drei Standards Mini-SIM, Mikro-SIM und Nano-SIM haben, blieb ich bei der LIDL-Connect Classic hängen. Für eine SIM-Karte die ich eigentlich nicht benötige, aber nur knapp 10 Euro kostete, ist die OK. Nach dem einstecken ins IPhone wollte das Smartphone lediglich die PIN der SIM-Karte haben. Ich musste nichte die SIM-Karte beim Netzwerkbetreiber freigeschalten!
Die weitere Einrichtung von Kalender und Kontakten klappte natürlich nicht von anfang an. Das Apple-Ding zeigte mir "Verbindung über SSL unmöglich". Im Internet fand ich im Owncloud-Forum folgenden Threat (Quelle: iPhone 5 + caldav = Probleme):
- neues CalDav Konto anlegen,
- den kompletten Pfad ( ADDRESS/remote.php/caldav/principals/username ) angeben, User und Passwort
- Fehlermeldung mit Weiter und so wegklicken
- im Haupteinstellungsfenster (Überschrift "CalDAV") unter Server nur die Serveradresse eingeben (ohne https und ohne Slash, also bspw: oc.beispiel.net)
- In die "Erweiterte Einstellungen"
- hier SSL an
- korrekten Port (entsprechend Eurer Installation und Portweiterleitung (häufig 443))
- Als Account-URL den kompletten Pfad mit https:// (bspw.: https://oc.beispiel.net/remote.php/cald ... /username/)
- mit Fertig / Speichern und so abschließen
- da muß man auch erst darauf kommen, wie "krank" das umgesetzt ist.
Das obige Verhalten muss an einer älteren iOS-Version gelegen haben. Zum Test nutzte ich ein IPhone 4S und später dann produktiv ein IPhone SE mit einem iOS 9.3.2, wo das Problem nicht auftrat.
Die Darstellung aller Felder funktioniert gut. Sofern die Datenbasis auf dem CardDAV-Server einwandfrei ist, wird die auch im IPhone richtig angezeigt.
