Das Docker-Image mit der Zimbra Collaboration Suite ist nun fertig und sogar schon seit einigen Wochen im Praxis-Einsatz. Zimbra – derzeit in der Version 8.8.8 – bringt die folgenden Features mit in das Projekt:
- Kontakt-Adressbücher (synchronisierbar mit dem Handy über CardDAV)
- Kalender (synchronisierbar mit dem Handy über CalDAV)
- Taskverwaltung
- Online-Dateiablage
- Anbindung an eine bestehende Owncloud/Nextcloud-Installation zur Realisierung einer noch leistungsfähigeren Dateiablage (für CloudyCube noch geplant)
Bei dem Docker-Image bin ich einen für Docker eher ungewöhnlichen, eigentlich verpönten Weg gegangen. Das Image selbst enthält weder Zimbra noch Dienste, die Zimbra vorraussetzt. Stattdessen sind in dem Image nur Skripte enthalten, die auf einem eingebundenen Docker-Volume ein minimalistisches Ubuntu 16.04 LTS mittels debootstrap installieren und anschließend Zimbra von der offiziellen Website herunterladen und installieren. Der ganze Vorgang ist über Dialoge geführt, so dass manuelle Eingriffe, um das System an die eigenen Anforderungen anzupassen, leicht zu bewerkstelligen sind. Aufgrund der hohen Komplexität der Installation wollte ich von einer automatisierten Konfiguration absehen. Am Ende der Installation befindet sich ein vollständiges Ubuntu 16.04 LTS mit Zimbra und allen dafür benötigten und konfigurierten Diensten auf dem eingebundenen Docker-Volume. Das eigentliche Docker-Image startet dann nur noch die „innere“ Ubuntu-Installation, in der Zimbra lebt. Dieser kleine Kniff erlaubt Zimbra persistente Veränderungen an Systemdiensten sowie die dauerhafte Installation zusätzlicher Softwarepakete oder Zimbra-Erweiterungen (Zimlets). Im Vergleich mit „üblichen“ Docker-Containern ergibt sich die Besonderheit, dass die installierte Software gewartet werden muss. Ein neues Docker-Image aktualisiert nicht automatisch Zimbra und auch nicht die verwendeten Betriebssystemkomponenten! Vom Verhalten her ähnelt dies eher einer virtuellen Maschine oder einem LXD Container, bietet aber dennoch alle Annehmlichkeiten des Docker-Stacks.
Um den Nutzer an diese Aufgabe zu erinnern, schaut apticron regelmäßig nach anstehenden Betriebssystemupdates und benachrichtigt den Administrator bei Bedarf mit einer E-Mail. Eine neue Zimbra-Version muss ebenfalls manuell eingespielt werden. Eine Automatik gibt es auch hier nicht, da nach einem Update auf eine neue Version Änderungen, die von Hand gemacht wurden, wieder nachgepflegt werden müssen.
Sowohl das Webinterface als auch die Mailing-Dienste (SMTP, IMAP, POP) unterstützen – und fordern an einigen Stellen sogar – verschlüsselte Verbindungen. Die dafür benötigten (kostenfreien) X.509 Zertifikate beantragt der ACME-Client certbot automatisch bei der LetsEncrypt CA. Die typischen Probleme mit selbst-signierten Zertifikaten entfallen. Damit dieser Mechanismus funktioniert, muss der Container mit einer IPv4- oder IPv6-Adresse direkt im Internet erreichbar sein und über einen entsprechenden A (IPv4) oder AAAA (IPv6) Eintrag im DNS verfügen. Aufgrund der Knappheit von IPv4-Adressen läuft auf der IPv4-Adresse sehr wahrscheinlich ein Reverse-Proxy, der HTTP-Requests an die eigentlich adressierten Docker-Container weiterleitet. Damit hat der Zimbra-Container keine IPv4-Adresse, unter der er im Internet direkt erreichbar wäre. Viele Provider bieten aber gegen Aufpreis eine weitere IPv4-Adresse an, falls man sich den Luxus leisten möchte. Etwas weniger problematisch geht es mit der IPv6-Adresse, da im Normalfall jeder Container seine eigene Adresse bekommt und damit im Internet direkt erreichbar ist.
Mit der Erreichbarkeit aus dem Internet ergeben sich auch Anforderungen an die Firewall. Der Zimbra-Container kümmert sich darum, indem er nicht öffentlich benötigte Dienste vor Zugriff schützt und häufige Angriffe wie TCP Flooding, Ping of Death und TCP Pakete mit unsinnigen Flags frühzeitig herausfiltert.
Weitere Details zum Image gibt es im Github Repository.