Autor: Sascha

Es ist das Docker-Image wordpress hinzugekommen, dass auf nginx-php7 aufbaut und die neueste Version von WordPress 4.x, die auf GitHub verfügbar ist, enthält.

Nähere Informationen gibt es hier.

Es ist das Docker-Image nginx-php7 hinzugekommen, dass auf base-supervisord aufbaut und sowohl den Webserver NGINX als auch PHP7-FPM bereitstellt. Das Image erlaubt über Umgebungsvariablen die Konfiguration von Parametern, die für die Performance von entscheidender Bedeutung sind. Das Image ist damit für schmalbrüstige Adminpanels genauso geeignet wie für Websites mit hoher Last.

Nähere Informationen gibt es hier.

Ich habe das Docker-Image base-supervisord fertiggestellt, das als Grundstock für alle anderen Images dienen wird. Es basiert auf Ubuntu 16.04 LTS und bringt als Init-System supervisord mit. Ein eigenes mit Plugins erweiterbares Python 3 Container-Startup-System sollte die weitere Entwicklung von abgeleiteten Images vereinfachen.

Nähere Informationen gibt es hier.

 

Die Administration soll – wenn möglich – ausschließlich über eine Weboberfläche laufen. Tools, die auf einem separaten System installiert werden müssen, versuche ich zu meiden. Der Zugriff auf diese Administrationstools sollte nur über VPN möglich sein, um möglichen Angreifern aus dem Internet keine zusätzliche Angriffsfläche zu bieten. Ein Zugang zum Adminbereich lässt sich leichter kontrollieren und sichern als eine Vielzahl von einzelnen Tools, von denen  jedes ein anderes Sicherheitskonzept verfolgt.

OpenSwan

Als VPN-Server zur Entkopplung der Administrationstools vom Internet kommt OpenSwan zum Einsatz. Es ist etabliert, stabil und wird aktiv weiterentwickelt. Bisher habe ich OpenVPN genutzt, das die Installation einer separaten Client-Software voraussetzt. Damit torpediert es das Bestreben, ohne Installation von zusätzlicher Software auf einem Client auszukommen. OpenSwan hingegen nutzt das L2TP (Layer 2 Tunneling Protocol) für das Tunneling von Paketen in Verbindung mit IPSec (Internet Protocol Security) für die Verschlüsselung. Diese Protokolle werden von den meisten Betriebssystemen von Haus aus unterstützt und gelten als sicher. Einziger Wermutstropfen ist, dass mit L2TP/IPSec Protokolle verwendet werden, die von anderem Traffic unterschieden – und damit geblockt – werden können. Wem die Verschleierung der Verbindung wichtig ist, sollte OpenVPN auf Port 443/TCP benutzen, da der Traffic dann nicht mehr von normalem HTTPS-Traffic mit einer Website zu unterscheiden ist. Wie oben angesprochen, erfordert OpenVPN allerdings eine spezielle Client-Software.

Update 30.07.2017: OpenSwan gilt mittlerweile als inaktiv, als Ersatz wird das ausgereifte und aktiv entwickelte StrongSwan gehandelt, so dass dies zum Einsatz kommen wird.

phpMyAdmin

Zur Administration der MariaDB-Datenbanken kommt phpMyAdmin zum Einsatz. Es ist sehr solide und wird aktiv weiterentwickelt – ein Tool, an dem man als Admin eigentlich nicht vorbei kommt.

phpLDAPadmin

Der Zugriff auf den Zimbra LDAP Server (OpenLDAP) erfolgt über phpLDAPadmin. Das Projekt galt zwischenzeitlich als verwaist, hat nun aber einen neuen Maintainer, der die Entwicklung weiterführt.

ELK-Stack

Der ELK-Stack besteht aus ElasticSearch, LogStash und Kibana, den drei großen Säulen eines Logsystems, das von der Firma Elastico entwickelt wird.

ElasticSearch ist für die Haltung von Logdaten, deren Indizierung sowie Suchen und Analysen im Datenbestand zuständig.

LogStash orchestriert simultane Datenströme, die in das Log fließen sollen, nimmt Formatanpassungen vor und leitet die Daten an ElasticSearch weiter. LogStash unterstützt dabei eine Vielzahl von Quellen. So können z. B. klassische Logdateien über das Elastic Beats Framework, das Windows Event Log oder das Linux-typische syslog eingebunden werden. Auch etwas exotischere Datenquellen wie das Auslesen eines IMAP-Mailaccounts, die Abfrage von SQLite-Datenbanken oder die Anbindung an Github Webhooks sind möglich.

Kibana bildet die Benutzerschnittstelle und bedient sich für die Visualisierung der Logs aus dem Datenbestand von ElasticSearch. Kibana kann neben der klassischen Logdarstellung in Listenform Daten auch grafisch aufbereiten und in Histogrammen, Graphen, Kreisdiagrammen, Ringdiagrammen und mehr darstellen. Alle interessanten Daten lassen sich so auf einem Dashboard zusammenfassen.

Die Wahl der Software für die Webpräsenz orientiert sich – wie eigentlich immer – am Einsatzgebiet und den damit verbundenen Anforderungen. Visual4 hat einen ausführlichen Artikel über die großen Open Source Content Management Systeme (CMS) Joomla!, TYPO3, Plone, WordPress, Drupal und Contao veröffentlicht, mit dem ich die Suche abgekürzt habe. Auf tagelages Evaluieren wie bei der Groupware wollte ich gerne verzichten. Und letztendlich ist das CMS bei Nichtgefallen später auch leichter auszutauschen als die gewählte Groupware, die das Fundament des Systems darstellt.

Genau genommen brauche ich eigentlich nur einen Blog, in dem ich chronologisch meine Gedanken, Erkenntnisse und Entscheidungen festhalten kann und ein paar Seiten, auf denen ich ab und zu mal Informationen zu bestimmten Themen zusammenstellen kann.

WordPress – was ich für den Blog ohnehin schon nutze – ist am Nächsten an den Anforderungen dran. Die Idee, auf ein komplexeres CMS mit mehr Möglichkeiten umzusatteln, war zuerst zwar ganz reizvoll, ist für mich persönlich aber wohl eher hinderlich, da ich ein eher informationsbezogener Charakter bin und für optische Spielereien nur wenig übrig habe. Es muss vernünftig aussehen – das reicht schon. Wichtiger ist der Inhalt.

Nach einem Blick auf die Liste der Anforderungen, die der Server erfüllen soll, fällt schnell auf, dass dies in erster Linie Anforderungen sind, die auch an Softwarelösungen für die Zusammenarbeit von Gruppen in Unternehmen gestellt werden. Es liegt also nahe, Produkte aus dem Bereich dieser sog. Groupwares bevorzugt näher zu betrachten. In Frage kommen nur Produkte aus dem Bereich Open Source, für die keine (bestenfalls geringe) Kosten anfallen. Folgende Produkte erfüllen laut Featurebeschreibungen die wesentlichen Anforderungen, so dass ich sie evaluiert habe:

• EGroupware (Version 16.1)
• Kolab (Version 16)
• Kopano (ehemals Zarafa, WebApp v3.3.0, Kopano Core v8.3.0)
• SoGo (ehemals Scalable OpenGroupware.org, Version 3.2.9)
• Zimbra (Version 8.7.10)

EGroupware

Die Oberfläche von EGroupware ist funktional, schlicht und im Wesentlichen in Grautönen mit wenigen Akzenten gehalten. Die Bedienung ist leicht verständlich, wenn man sich erst einmal einen Überblick über die Vielzahl der Funktionen verschafft hat. Die verschiedenen Applikationsteile sind sehr gut miteinander verknüpft.

EGroupware erfüllt alle an den Webmailer gestellten Anforderungen und noch vieles mehr. Es ist eine ausgewachsene Groupware, die zudem auch mit weiteren Features wie Wiki, Ressourcenplanung, Zeiterfassung, Ticketsystem, Tools zum Projektmanagement und Customer Relationship Management (CRM) aufwarten kann. Ein Großteil der Features gibt es in der freien Community-Version, die etwas unternehmensspezifischeren Features nur in der kostenpflichtigen Enterprise-Version.

Die Dokumentation ist sehr spartanisch. Außer ein paar Zeilen Code, mit denen man EGroupware auf verschiedene Linux-Distributionen installiert, habe ich leider nichts finden können. Ich nehme an, dass die EGroupware GmbH für diese Zwecke gerne gegen Münzeinwurf behilflich ist. Bemerkenswert ist allerdings eine Reihe von Videos, die sehr schön die wesentlichen Features der Software vorführen und wie man sie bedient.

Evaluieren konnte ich EGroupware dank der Demo-Installation, zu der man nach Angabe der eigenen Kontaktdaten Zugriff bekommt.

Ich hab den Eindruck gewonnen, dass EGroupware zwar eine Community-Version der Software bereitstellt, aber nicht so gerne die Community mitarbeiten lässt. Eine Plugin-Schnittstelle, an der man ggf. eigene Erweiterungen anbauen könnte, habe ich leider nicht gefunden. Falls es eine geben sollte, bitte kurze Rückmeldung an mich!

Update (07.12.2019): Erweiterbarkeit 
Am 1.12.2019 habe ich von Stefan U. von EGroupware einige zusätzliche Informationen zum Thema „Erweiterbarkeit“ von EGroupware bekommen. An dieser Stelle vielen Dank dafür! Es gibt in EGroupware die Möglichkeit, Applikationen zu entwickeln, die sich in EGroupware  integrieren und deren Funktionen nutzen können. Dazu gehören:

• Benutzerverwaltung
• Dokumentengenerierung
• E-Mail
• Dateiablage/-Verwaltung
• Verlinkungen
• … und mehr

Nach Aussage von EGroupware haben Unternehmen und Universitäten eigene Anwendungen entwickelt, z. B. eine Zeiterfassung für Landwirte oder eine Workflow-Engine zum Automatisieren von EGroupware. Eine andere Möglichkeit ist die Anbindung von weiterer Software wie aktuell Collabora Online und Rocket.Chat. Durch die Integration eines OpenID/OAuth2-Servers benutzt Rocket.Chat z. B. die EGroupware-Benutzer.

Update (07.12.2019): Mitarbeit der Community
Der Source Code von EGroupware liegt auf Github. Die Community ist eingeladen, sich an der Weiterentwicklung zu beteiligen. Hilfe bei der Verwendung von EGroupware gibt es in einem offiziellen Support-Forum. EGroupware hat sogar Community-Betreuer, die dort aktiv sind und versuchen, die Community zu fördern.

Update (07.12.2019): Docker-Container
EGroupware gibt es nun auch fertig verpackt in einem Docker Container direkt vom Docker Hub.

Kolab

Kolab macht auf den ersten Blick einen sehr gefälligen, funktionalen und modernen Eindruck. Das Standard-Skin der Community-Edition von Kolab (Chameleon) sieht in Anthrazit mit orangefarbenen Akzenten durchaus ansprechend aus. Alternativ bietet das Skin Larry eine kühlere Farbkomposition in Anthrazit mit blauen Akzenten. Animationen sind sparsam eingesetzt und runden den Eindruck angenehm ab.

Kolab erfüllt die an den Webmailer gestellten Anforderungen voll und ganz und wirft neben synchronisierbarem Adressbuch und Kalender auch noch eine Notizfunktion sowie Aufgaben- und Dateimanagement mit ins Rennen. Kolab gibt es in einer kostenfreien Community-Version und einer kommerziellen Version. Schon in der Community-Version bietet Kolab den vollständigen Funktionsumfang. Den Unterschied macht nur der Support. Nutzer der kommerziellen Version erhalten professionellen Support bei Einrichtung und evtl. auftretenden Problemen. Wer Probleme mit der Community-Version hat, findet allerdings häufig im Forum Unterstützung.

Die Dokumentation macht einen guten Eindruck und ist auch bei der Community-Version gut strukturiert und recht detailliert. Sie reicht von der Installation von Kolab auf CentOS 7 (andere Distributionen werden scheinbar nicht unterstützt) über die Konfiguration von einzelnen Diensten, um sie in die bestehende Umgebung zu integrieren, bis zur Beschreibung der administrativen Tools.

Kolab ist eine „Rundum-Sorglos-Lösung“, die alles selbst mitbringt, was sie zum Betrieb braucht. Dazu gehört ein Postfix-Server (SMTP), ein Cyrus-Server (IMAP), ein 389 Directory Server (LDAP) sowie Manticore für die Online-Bearbeitung von .odt (Open Document) Dateien. Recherchen zeigen, dass man Postfix ohne Probleme durch einen anderen MTA (wie Sendmail) ersetzen kann, während das Ersetzen von Cyrus durch einen anderen IMAP-Server – wie zum Beispiel Dovecot – ein größeres Problem darstellt. Die Entwickler begründeten dies damit, dass der IMAP-Server bestimmte Features unterstützen müsse. Bei Dovecot wäre das (noch) nicht gegeben. Laut Dokumentation müsste man den 389 Directory Server auch durch OpenLDAP ersetzen können, doch leider ist dieser Abschnitt in der Dokumentation leer.

Eine Folge der Rundum-Sorglos-Lösung ist aber auch, dass Kolab ein Nutzer- und Gruppenmanagement bietet, in dem auch gemeinsam nutzbare Adressbücher, Kalender und Dateiablagen konfiguriert werden können.

Eine Demo-Installation von Kolab gibt es leider nicht, so dass ich mir die Software selbst in einer virtuellen Maschine installiert habe. Die Installation verlief problemlos nach Anleitung und am Ende stand eine funktionsfähige Kolab-Installation – bis auf Manticore. Größere Schwierigkeiten kamen erst auf, als ich versucht habe, einen Reverse-Proxy mit SSL-Termination vor den Webserver zu schalten, um den Betrieb in einer Docker-Umgebung zu simulieren. Damit kam Kolab an vielen Stellen nicht klar. Meine im Issue-Tracker von Kolab gemeldeten Bugs wurden aber aufgegriffen und fast alle gelöst. Auf meinem Test-System gibt es noch Probleme mit dem File-Plugin, das in der Vorschau keine Inhalte zeigt. Der Browser beklagt sich über Mixed Content, d. h. die Seite wurde über HTTPS aufgebaut, der Inhalt im Previewfenster aber mit HTTP angefordert – also ohne Verschlüsselung. Dieses Verhalten konnte die Entwicklung nicht nachvollziehen und daher auch nicht fixen.

Da Kolabs Webmail-Interface (inkl. Adressbuch, Kalender, Notizen, Aufgaben und Dateimanagement) auf der Webmail-Software Roundcube basiert und Roundcube über ein sehr ausgefeiltes Plugin-System verfügt, ist es auch möglich, den Funktionsumfang der Weboberfläche zu erweitern und auch Plugins zu verwenden, die ursprünglich für Roundcube geschrieben wurden.

Kopano

Kopano (ehemals Zarafa) hat eine moderne, aufgeräumte, selbsterklärende und ansprechende Oberfläche.

Kopano erfüllt alle an den Webmailer gestellten Anforderungen und bietet dabei zusätzlich auch eine Notizfunktion sowie Aufgaben- und Dateimanagement.

Die kostenfreie Open Source Version von Kopano enthält den vollständigen Funktionsumfang und ist immer auf dem neuesten Stand. Das heißt unverblümt aber auch, dass der Community nur der Master-Branch mit dem aktuellen Development-Stand zur Verfügung steht. Der Pre-Final Branch, der Pakete enthält, die sich gerade im Qualitätssicherungsprozess befinden, und der Final Branch, der Pakete enthält, die den Qualitätssicherungsprozess erfolgreich durchlaufen haben, steht nur zahlenden Kunden und nicht der Community zur Verfügung. Genauere Informationen dazu gibt es hier.

Es gibt zwar auch Pakete, in die die Community Bugfixes eingebracht hat, doch ist mir die Unsicherheit, die damit verbunden ist, zu groß. Kopano kommt damit nicht mehr in Frage.

SOGo

SOGo macht auf den ersten Blick einen modernen und peppigen Eindruck. Die Bedienung ist auch ohne Einarbeitung verständlich, flüssig und dezent animiert.

SOGo erfüllt wie die anderen zuvor betrachteten Lösungen auch die Anforderungen an den gesuchten Webmailer. Eine Notizfunktion und Dateimanagement gibt es nicht.

Die Dokumentation ist geradezu ungewöhnlich detailliert und gut nachvollziehbar. Sie führt strukturiert von den Systemanforderungen, über die Installation und Konfiguration bis hin zu Tuning-Hinweisen.

SOGo bringt keine eigenen Mailserver-Dienste mit und erzwingt auch keinen bestimmten SMTP-, IMAP-, LDAP-Server, wie dies bei Kolab der Fall ist. Lediglich der SQL-Server muss MySQL, PostgreSQL oder Oracle sein.

Ein Management von Nutzern oder ein Webinterface für die Parametrierung von Mailserver-Diensten (außer Sieve) gibt es nicht, da dies außerhalb des Einflussbereichs von SOGo liegt. Darum muss sich der Administrator des Systems selbst kümmern.

SOGo ist eine in Objective-C geschriebene, in sich geschlossene Applikation, die keine Plugin-Schnittstelle vorsieht. Man muss also mit dem gebotenen Funktionsumfang auskommen. Die bereits integrierten Authentifizierungsbackends (LDAP, SQL, C.A.S. und SAML2) sowie die bewusste Entscheidung auf Standards (SMTP, IMAP, Sieve, CardDAV und CalDAV) zu setzen, dürften aber dafür sorgen, dass sich SOGo ohne größere Probleme in die meisten Umgebungen integrieren lässt.

Zimbra

Zimbra macht einen aufgeräumten funktionalen Eindruck ohne viel Eye-Candy. Die Farbkomposition lässt sich mit einer Reihe von Themes an den eigenen Geschmack anpassen. Animationen sind sehr sparsam eingesetzt. Ein moderneres UI (Universal UI) ist derzeit in der Entwicklung, erste Screenshots sehen vielversprechend aus.

Auch Zimbra erfüllt die an den Webmailer gestellten Anforderungen und bringt darüber hinaus auch noch eine Notiz- und Aufgabenfunktion sowie Funktionen zum Dateimanagement mit. Zimbra gibt es in einer kostenfreien OpenSource-Version und in einer kostenpflichtigen Network-Version. Beide Versionen haben die gleiche Codebasis, nur erweitert die Network-Version noch den Funktionsumfang der OpenSource-Version um Features, die vor allem im Unternehmensumfeld benötigt werden. Hervorzuheben ist dabei die MAPI-Schnittstelle, die für eine saubere Integration mit Outlook von großem Wert ist. Für den privaten Einsatz, wo man mit Outlook nicht zwangsweise in Kontakt kommt, ist die OpenSource-Version aber mehr als ausreichend. Sowohl für die OpenSource-Version als auch die Network-Version gibt es kostenpflichtigen Support, so dass man auch bei der Nutzung der kostenfreien OpenSource-Version nicht zwangsläufig im Regen steht.

Die Dokumentation macht einen ausgesprochen guten und detaillierten Eindruck. Sie liegt im PDF-Format vor und schon die Anleitung zur Administration sprengt locker 300 Seiten. Ich war ehrlich angenehm überrascht.

Wie bei Kolab auch gibt es von Zimbra keine Demo-Installation. Ich habe mir die Software also auf einer virtuellen Maschine installiert. Die Installation auf Ubuntu 16.04 LTS verlief problemlos mittels interaktivem Skript. Bemerkenswert ist allerdings der Ressourcenhunger, den Zimbra schon bei der Installation an den Tag legt. Die kleine Jiffybox mit 2GB (Cloudlevel 1) kam schnell an ihre Grenzen, so dass ich ihr 8GB RAM spendieren musste. Damit lief Zimbra dann problemlos.

Die Administration von Zimbra kann man komplett über das Webinterface abwickeln, die Kommandozeile kann man nutzen, muss man aber nicht. Das Adminpanel vereint die Konfiguration von allen Komponenten der Groupware – vom LDAP-Server über den MTA und die Mailbox-Verwaltung bis hin zur Einbindung von SSL-Zertifikaten. Und genau dabei zeigt sich, dass man einzelne Komponenten in dieser Groupware besser nicht durch andere ersetzt, da spätestens im Adminpanel dann einiges nicht mehr funktioniert.

Die Weboberfläche von Zimbra kann durch Plugins, sog. Zimlets, erweitert werden. Es gibt eine rege Community, die ihre Eigenentwicklungen für die verschiedensten Funktionen bereitstellt.

Entscheidung

Nach sorgfältigem Abwägen der Vor- und Nachteile der aufgeführten Groupware-Lösungen, bin ich zu dem Schluss gekommen, Zimbra zu verwenden, da Zimbra alle geforderten Features vereint, über eine ansprechende Oberfläche verfügt und zudem das Adminpanel umfassend und komfortabel das komplette Groupware-Management abbildet.

Alle Dienste, die der Server bereitstellt, sollen in ausführbare, in sich geschlossene Module verpackt werden, um das Deployment zu vereinfachen und reproduzierbar zu machen.

Zu allererst denkt man dabei vermutlich an eine klassische virtuelle Maschine, in der ein vollständiges Betriebssystem inkl. betreffendem Dienst läuft. Man unterscheidet dabei verschiedene Virtualisierungstechnologien: Hardwareemulation, Hardwarevirtualisierung, Paravirtualisierung und Betriebssystemvirtualisierung.

Bei der Hardwareemulation werden sämtliche Hardwarekomponenten emuliert. Das Gastbetriebssystem kann also unverändert bleiben. Die Emulation ist jedoch aufwändig und führt zu deutlichen Performance-Einbußen. Ein Vertreter dieser Sparte ist Windows VirtualPC.

Bei der Hardwarevirtualisierung werden bis auf die CPU die meisten Hardwarekomponenten emuliert. Einige CPU-Instruktionen werden abgefangen und angepasst. Dies führt dazu, dass ein Gastbetriebssystem nur mit der CPU arbeiten kann, die auch tatsächlich auf dem Hostsystem installiert ist. Dafür ist die Performance um ein Vielfaches besser. Gastbetriebssysteme können ohne Veränderung in einer solchen Umgebung laufen. Vertreter dieser Kategorie sind zum Beispiel vmware, Microsofts Hyper-V, Oracles VirtualBox und das XEN Projekt (mit HVM).

Bei der Paravirtualisierung geht man noch einen Schritt weiter und emuliert auch keine Hardware mehr. Stattdessen stellt der Host dem Gast definierte Softwareschnittstellen zur Verfügung, mit denen er interagieren kann. Eine Anpassung des Gastbetriebssystems ist damit unumgänglich. Die Performance ist höher als bei der Hardwarevirtualisierung.

Bei der Betriebssystemvirtualisierung löst sich die Isolation zwischen Host und Gast noch weiter auf, da das Gastbetriebssystem den selben Kernel benutzt wie der Host. Damit kann der Gast auch nur das gleiche Betriebssystem benutzen wie der Host (Linux auf Linux). Unterschiedliche Distributionen sind allerdings möglich. Diese Art der Virtualisierung ist sehr leichtgewichtig, da die Interaktion mit dem Kernel nicht mehr durch mehrere Abstraktionsschichten laufen muss. Gastbetriebssysteme können innerhalb von Sekunden gestartet und gestoppt werden, da der eigentliche Bootvorgang des Kernels entfällt. Vertreter dieser Kategorie sind zum Beispiel Linux Containers, OpenVZ/Virtuozzo und Docker.

Aus Kostengründen wird der Server, auf dem das System später laufen soll, sicherlich ein VPS (Virtual Private Server), der im Rechenzentrum bei einem größeren Anbieter läuft. Diese Server sind wie der Name schon sagt, selbst virtualisiert. Auf diesen virtuellen Servern sind Virtualisierungslösungen, die ihrerseits die Hardware wieder virtualisieren oft zwar möglich, werden aber vom Anbieter unterbunden und nur gegen Aufpreis freigeschaltet. Wirklich performant ist das nicht. Es kommt also nur eine Betriebssystemvirtualisierung – auch als Container bekannt – in Frage.

In die nähere Wahl kamen Linux Containers und Docker.

Linux Containers (LXC)

Kurz zusammengefasst kann man sagen, dass Linux Containers (LXC) ein Verfahren zur Virtualisierung auf Betriebssystemebene ist, während LXD die sehr komplexe Bedienung von LXC mit Tools und einer REST-API komfortabel nutzbar macht.

LXC/LXD kapselt in einem Container eine vollständige Linux-Distribution, die längerfristig betrieben und auch wiederholt upgedatet werden kann. In diesem Sinne könnte man einen solchen Container am ehesten als eine besonders leichtgewichtige virtuelle Maschine verstehen.

Für die reproduzierbare Einrichtung eines LXD Containers können Standardlösungen für automatisierte Installation – wie z. B. RedHats kickstart – verwendet werden. Ein LXD Container startet normalerweise wie ein reales Linux auch mit dem Init-Prozess (derzeit sicherlich am häufigsten systemd) und fährt – wie ein reales System auch – wieder geordnet herunter.

Die Infrastruktur, die rund um LXD existiert, ist eher dünn, was vermutlich auch daran liegt, dass das LXD Projekt noch sehr jung ist. Es wurde im November 2014 gestartet. Es gibt Image-Server, von denen man Betriebssystem-Images laden kann, um darauf dann die für die gewünschten Dienste benötigten Pakete zu installieren.

Docker

Während LXC langlebige Container vorsieht, verfolgt Docker geradezu ein Wegwerf-Konzept. Docker-Container werden erzeugt, gestartet und nach dem Shutdown wieder gelöscht. Ein Update eines laufenden Docker-Containers ist eher unüblich. Stattdessen aktualisiert man das Image, von dem der Container erzeugt wird. Das Docker-Konzept sieht vor, dass in einem Container nur ein Prozess läuft, um eine bestmögliche Isolation der Prozesse  und damit verbunden die größtmögliche Sicherheit zu erreichen. Schaut man sich allerdings einmal bei Docker Hub, dem Repository für Docker-Images um, so fällt schnell auf, dass in sehr vielen Containern mehr als nur ein Prozess läuft. Das Argument der Isolation der Prozesse zieht also manchmal auch in die entgegengesetzte Richtung und führt eher dazu, dass Dienste, die sehr eng zusammen arbeiten, sich auch einen Container teilen dürfen. Im Gegensatz zu den Image Repositories, die man bei LXD findet und in denen in erster Linie Images mit einer Basisinstallation verschiedener Linux-Distributionen liegen, gibt es im Docker Hub mehr als 100.000 fertig konfigurierte Images mit den unterschiedlichsten Diensten für verschiedene Einsatzszenarien.

Der Docker Hub stellt neben den verschiedenen offiziellen Images der bekannten Distributionen und Softwarehersteller auch automatisierte Image-Builds zur Verfügung. Die automatisierten Builds verfügen über eine Ankopplung an ein Github-Repository mit der Bauanleitung (dem Dockerfile) des Images sowie den dafür benötigten Ressourcen und werden neu ausgelöst, wenn Änderungen in das Repository gepusht werden. Dieser Automatismus schafft ein gewisses Vertrauen in die Images, da der Erstellungsprozess transparent ist und der gesamte Quellcode auf Github eingesehen werden kann. Man bekommt hier zwar ein fertiges Image, aber dennoch keine Black Box – solange man der Docker-Infrastruktur vertraut.

Bei der Evaluierung von Docker musste ich allerdings feststellen, dass Docker und systemd nicht sehr gut miteinander spielen, was bei LXD überhaupt kein Problem ist. Pakete, die bei der Installation ein laufendes systemd voraussetzen, lassen sich dann häufig nicht oder nicht vollständig installieren. Aber wo Licht ist, ist wohl auch Schatten…

Entscheidung

Die Vorteile von Docker sind zahlreicher als die Nachteile, so dass ich wohl mit Docker arbeiten werde.

Hier kommt die Liste mit den wesentlichen Anforderungen und Eckdaten, die ich bei der Softwareausstattung des Servers anstrebe. Sie soll als Richtschnur bei der Suche nach den Softwarepaketen dienen und dabei helfen, die Features der verschiedenen Pakete möglichst optimal miteinander zu kombinieren.

Mail-Server-Stack

• Opportunistische TLS Verschlüsselung mit Zertifikaten von Letsencrypt
• Senden über SMTP
• Zugriff auf Mailbox über POP3 und IMAP4
• SPF (Sender Policy Framework)
• DANE (DNS-based Authentication of Named Entities)
• DMARC (Domain-based Message Authentication, Reporting and Conformance)
• DKIM (Domain Keys Identified Mails)
  • Signierung von ausgehenden Mails
  • Signaturprüfung von empfangenen Mails
• Sieve (Regeln für empfangene Mails)
  • Kopieren/Verschieben in Unterordner
  • Markieren
  • Weiterleitung
• Spamfilterung
• Virenscan

Webmail

• Komfortable Bedienung
• Kontakt-Adressbuch, mit dem Handy synchronisierbar (CardDAV)
• Kalender, mit dem Handy synchronisierbar (CalDAV)
• Konfiguration des Regelwerks für empfangene Mails
• Dateiablage
• Notizen

Webpräsenz

• Modernes, leicht bedienbares Blog
• Alternativ: Einfaches Content Management System

Administration

• Webinterface für häufige Aufgaben
  • Domains hinzufügen und löschen
  • Nutzer- und Gruppen hinzufügen, ändern und löschen
  • Rechtemanagement
• Logs
  • Zusammenführung von verschiedenen Log-Quellen
  • Webinterface mit Überblick über das gesamte System