Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- kb [2012/11/15 15:45]
flacco [Gegenmaßnahmen]
+++ kb [2017/01/05 10:41]
flacco [Active Directory und Firewall]
@@ Zeile 3: / Zeile 3: @@
 Diese Seite schließt eine Lücke im Wiki. Sie soll Hintergrund und Basiswissen vermitteln, welches dabei hilft sich an der Entwicklung des invis-Servers zu beteiligen bzw. genutzte Techniken und Konfigurationen zu verstehen.
-===== DNS-Server bind und LDAP =====
+===== invis-Server & Active Directory =====
+"Active Directory" ist das Herz des invis-Servers ab Version 10.0, das erklärt aber kaum was es genau ist.
+==== Microsoft Actice Directory ====
+"Active Directory" ist eine von Microsoft entwickelte Kombination aus [[https://de.wikipedia.org/wiki/Kerberos_%28Informatik%29|Kerberos]], [[https://de.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol|LDAP]]-Verzeichnis und Domain-Name-Service. Dabei dient Kerberos der Benutzer-Authentifizierung und ermöglicht sogenanntes "Single-Sign-On", das LDAP-Verzeichnis dient als zentraler Informationsspeicher und DNS wird für eine Technik namens "Service Location" genutzt. Eingeführt wurde "Active Directory" mit Einführung des "Microsoft Servers 2000".{{ :active-directory_ms.png?300|}}
+[[https://de.wikipedia.org/wiki/Single_Sign-on|Single-Sign-On]] (SSO) ermöglicht, dass nur eine Anmeldung am System auch als Autorisierung für alle im Netzwerk angebotenen Dienste gilt. D.h. es genügt beispielsweise sich am eigenen PC mit Benutzernamen und Passwort anzumelden um danach ohne weitere Angabe von Benutzernamen oder Passwort auch Zugriff auf Dienste wie beispielsweise einen Exchange-Server zu erhalten.
+Kerberos seinerseits verwaltet keinerlei eigenen Datenbestand. Die Daten auf die Kerberos zurückgreift werden in einem sogenannten LDAP-Verzeichnis abgelegt. Das LDAP-Verzeichnis stellt somit den zentralen Informationsspeicher des Active Directories dar. LDAP (Lightweight Directory Access Protocol) steht dabei sowohl für das Netzwerkprotokoll über welches auf die Informationen im Verzeichnis zugegriffen wird, als auch den Informationsspeicher selbst. Der Datenspeicher arbeitet "objektorientiert" und somit gänzlich anders als eine relationale Datenbank. Der objektorientierte Ansatz ermöglicht es Netzwerk- oder Organisationsstrukturen eins zu ein im Datenspeicher abzubilden.
+Die letzte Komponente "Domain Name Service" (DNS) wird neben der normalen Namensauflösung für Service Location genutzt. Service Location ist eine Technik mit der Clients im Netzwerk die Server finden können, die bestimmte Dienste anbieten. Im AD dient sie dazu den Clients mitzuteilen auf welchem Server Kerberos- und LDAP-Dienst laufen.
+Zusätzlich kann auch ein DHCP-Dienst an das AD angelagert werden. Dabei nutzt der DHCP-Dienst ebenfalls das LDAP-Verzeichnis als Informationsspeicher.
+==== Active Directory auf invis-Server ====
+{{ :active-directory_invis-server.png?350|}}Die Verwendung eines LDAP-Verzeichnisses als zentralen Informationsspeicher für Benutzerverwaltung, DNS- & DHCP-Server sowie weitere Zwecke zu nutzen ist für invis-Server nicht neu. Mit openLDAP verfügte auch der invis Classic schon immer über ein LDAP-Verzeichnis. Was fehlte waren Kerberos und Service Location.
+Mit Einführung von Samba 4.0 brachte Samba eine eigene Implementation von Microsofts Active Directory mit. Dies ermöglichte uns den Umstieg von openLDAP auf Active Directory. Um alle Informationen die der invis Classic im LDAP speicherte auch im AD speichern zu können mussten wir eigene Schemaerweiterungen einspielen und darüber hinaus auch den von uns verwendeten DHCP-Server des ISC (Internet Systems Consortium) patchen.
+Als DNS-Server verwenden wir nicht den "Samba Internal DNS", sondern weiterhin "bind" (ebenfalls vom ISC). Dies wird allerdings von Samba direkt unterstützt. Die Anbindung erfolgt hier über einen DLZ-Treiber ([[http://bind-dlz.sourceforge.net/|Dynamic Loadable Zone]]) den Samba selbst mitbringt. Nebenbei bemerkt ist es auch in Microsoft AD-Umgebungen möglich den DNS-Dienst auszulagern, ich habe das mit "ISC bind" bereits erfolgreich getestet.
+Für die Benutzerverwaltung haben sich die Vorzeichen umgekehrt. Beim invis Classic wurden im LDAP prinzipiell POSIX-kompatible Benutzerkonten angelegt, die um Windows- respektive Samba-Attribute ergänzt wurden. Mit Active Directory bilden jetzt Windows-Benutzerkonten die Basis, die um POSIX-Attribute erweitert werden. Da Microsoft dies selbst unter Verwendung der eigenen Erweiterung "Services for UNIX" (SFU) anbietet, bricht es nicht die Kompatibilität zur MS-Welt. Unter Samba wird diese Ergänzung "RFC 2307 Erweiterung" genannt.
+Die Anbindung von Linux-Clients wird über eine Kombination aus Samba und [[https://fedoraproject.org/wiki/Features/SSSD|SSSD]] (System Security Services Daemon) realisiert. Dabei wird Samba genutzt um (genau wie Windows Clients) der Domäne beizutreten und SSSD ist für die Abbildung der Benutzerkonten via PAM auf Linux-Systemen sowie die Benutzeranmeldung selbst zuständig. Selbstverständlich wird auch hier Kerberos verwendet.
+Genau wie es für Windows-Domänenmitglieder möglich ist, ermöglicht der SSSD auch für Linux-Clients Offline-Logins an der Domäne.
+Grundsätzlich beherrschen invis-Server damit auch Single Sign On, leider haben wir dass noch nicht für die Dienste des invis-Servers umgesetzt.
+==== Active Directory und Firewall ====
+Die vielen an AD beteiligten Netzwerkprotokolle erfordern ein besonderes Augenmerk auf eine zwischen geschaltete Firewall. invis-Server nutzen beispielsweise immer die "SuSEfirewall2" auch zwischen dem Server selbst und dem lokalen Netzwerk (interne Zone).
+Die folgende Tabelle gibt einen Überblick über die beteiligten Protokolle und zugehörigen Ports:
+^Protokoll  ^Transportprotokoll  ^Port  ^Bemerkung  ^
+|Kerberos  |  TCP & UDP  |  88  |  Benutzerauthentifizierung  |
+|LDAP  |  TCP & UDP  |  389  |  Daten-Backend, Benutzerveraltung, DNS, DHCP und invis-Portal  |
+|LDAPs  |  TCP  |  636  |  s.o.  |
+|DNS  |  TCP & UDP  |  53  |  Namensauflösung und Service-Location  |
+|    |  TCP  | 1024  | Zugriff auf DNS-Daten mittels RSAT
+|GC  |  TCP  |  3268  |  Global Catalog  |
+|GC  |  TCP  |  3269  |  Global Catalog SSL  |
+|SMB/CIFS  |  TCP & UDP  |  445  |  Zugriff auf sysvol Freigabe  |
+|RPC  |  TCP  |  135  |Früheres Microsoft Messaging Protokoll, wird genutzt für die Replikation der sysvol Freigabe. Dies wird von Samba noch nicht unterstützt.  |
+|    |  TCP & UDP  |  464  |  Replication, User and Computer Authentication, Trusts  |
+==== ISC DHCP mit ActiveDirectory ====
+Um den DHCP-Server des ISC mit einem Active Directory als Backend zu verwenden, muss dieser so gepatcht werden, dass er andere LDAP-Attribut- und Objektklassen-Namen akzeptiert. Dies ist notwendig, da Microsoft für seinen DHCP-Server teils identische Namen für Attribute und Objektklassen verwendet. Ohne das Patchen führt der Versuch einen ISC DHCP-Server Datenbestand aus einem OpenLDAP Verzeichnis in ein Active Directory zu migrieren zu "Objectclass Violations" die nicht zu beheben sind.
+=== LDAP Patch erzeugen ===
+Den Patch zu erstellen ist etwas umständlich, da im openSUSE-Paket bereits Patches auf die von uns zu patchenden Dateien angewendet werden. D.h. um unseren Patch zu erzeugen müssen zunächst die anderen Patches auf den Quellcode angewendet werden.
+Zu patchen sind folgende Dateien:
+  * server/ldap.c
+  * contrib/ldap/README.ldap
+  * contrib/ldap/dhcpd-conf-to-ldap
+  * contrib/ldap/dhcp.shema
+Im ersten Schritt müssen aus dem Repository "network:dhcp" (https://build.opensuse.org/package/show/network:dhcp/dhcp) des openSUSE Buildservice das Quellcode-Archiv (dhcp-4.x.y.tar.gz), sowie die beiden Patches "0007-dhcp-4.2.6-ldap-mt01.patch" und "0022-dhcp-4.2.x-contrib-conf-to-ldap-reorder.886094.patch" heruntergeladen werden.
+Das Quellcode-Archiv ist in ein Arbeitsverzeichnis zu extrahieren. Danach sind die beiden heruntergeladenen Patches darauf anzuwenden:
+<code>
+heinzb@knurps:~/baustelle/dhcp-4.2.6> patch -p1 server/ldap.c 0007-dhcp-4.2.6-ldap-mt01.patch
+heinzb@knurps:~/baustelle/dhcp-4.2.6> patch -p1 contrib/ldap/dhcpd-conf-to-ldap 0022-dhcp-4.2.x-contrib-conf-to-ldap-reorder.886094.patch
+</code>
+Treten dabei Fehler auf, sind diese in einer auf **.rej** endenden Datei im Verzeichnis der zu patchenden Datei zu finden. Sind die Fehler überschaubar, lassen sich die Änderungen auch manuell durchführen.
+Jetz sind per suchen und ersetzen der Attributnamen und Objektklassen mit **//sed//** neue Dateien mit den gewünschten Änderungen zu erzeugen:
+<code>
+heinzb@knurps:~/baustelle/dhcp-4.2.6> cat server/ldap.c | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > server/ad.ldap.c
+heinzb@knurps:~/baustelle/dhcp-4.2.6> cat contrib/ldap/README.ldap | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > contrib/ldap/ad.README.ldap
+heinzb@knurps:~/baustelle/dhcp-4.2.6> cat contrib/ldap/dhcpd-conf-to-ldap | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > contrib/ldap/ad.dhcpd-conf-to-ldap
+heinzb@knurps:~/baustelle/dhcp-4.2.6> cat contrib/ldap/dhcp.schema | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > contrib/ldap/ad.dhcp.schema
+</code>
+Jetzt werden mit //**diff**// einzelne Patches für jede der Dateien erzeugt:
+<code>
+heinzb@knurps:~/baustelle/dhcp-4.2.6> diff -u server/ldap.c server/ad.ldap.c > ../ldap.c.patch
+heinzb@knurps:~/baustelle/dhcp-4.2.6> diff -u contrib/ldap/README.ldap contrib/ldap/ad.README.ldap > ../README.ldap.patch
+heinzb@knurps:~/baustelle/dhcp-4.2.6> diff -u contrib/ldap/dhcpd-conf-to-ldap contrib/ldap/ad.dhcpd-conf-to-ldap > ../dhcpd-conf-to-ldap.patch
+heinzb@knurps:~/baustelle/dhcp-4.2.6> diff -u contrib/ldap/dhcp.schema contrib/ldap/ad.dhcp.schema > ../dhcp.schema.patch
+</code>
+Jetzt müssen noch die Kopfzeilen der Einzelpatches angepasst werden. Aus:
+<code>
+--- server/ldap.c       2015-03-26 14:24:44.905456906 +0100
++++ server/ad.ldap.c    2015-03-26 17:12:52.783318249 +0100
+</code>
+wird:
+<code>
+--- a/server/ldap.c       2015-03-26 14:24:44.905456906 +0100
++++ b/server/ldap.c    2015-03-26 17:12:52.783318249 +0100
+</code>
+Danach werden alle Einzelpatches zum Gesamtpatch zusammengesetzt:
+<code>
+heinzb@knurps:~/baustelle> cat ldap.c.patch > 0099-AD-LDAP.patch
+heinzb@knurps:~/baustelle> cat README.ldap.patch >> 0099-AD-LDAP.patch
+heinzb@knurps:~/baustelle> cat dhcpd-conf-to-ldap.patch >> 0099-AD-LDAP.patch
+heinzb@knurps:~/baustelle> cat dhcp.schema.patch >> 0099-AD-LDAP.patch
+</code>
+Danach den Patch in unser Testing-Repositorie hochladen und die Spec-Datei des dhcp-Paketes anpassen:
+Ab Zeile 138 (ca.)
+<code>
+# invis-server.org Stefan Schaefer
+Patch99:        0099-AD-LDAP.patch
+</code>
+Ab Zeile: 282 (ca.)
+<code>
+%if %{with_ldap}
+# Stefan Schaefer - invis-server.org
+%patch99 -p1
+%endif
+%endif
+## clean up after patching
+find . -type f -name \*.orig\* -exec rm -f {} \;
+find . -type f -name \*.rej\* -exec rm -f {} \;
+</code>
+Die Zeilenangaben sind natürlich nicht genau, das sich das Spec-File mit jeder neuen Version ändern kann. Wichtig ist nur, dass unser Patch als letzter angewendete wird.
+=== Paketbenennung und Konfliktverhalten ===
+Um nicht mit den regulären DHCP-Paketen in den SUSE Repositories in Konkurrenz zu geraten, haben wir unsere Pakete umbenannt. Sie tragen jetzt die Vorsilbe "invis":
+  * invisdhcp
+  * invisdhcp-server
+  * invisdhcp-client
+  * invisdhcp-relay
+  * invisdhcp-devel
+  * invisdhcp-doc
+Die Umbenennung erfolgt im Specfile. Weiterhin wurde in den Paketen die Direktive "Conflict" im Specfile verwendet. Dadurch können nur entweder die ungepatchten oder die gepatchten Pakete auf einem System installiert werden. Auch dies wird im Specfile eingetragen:
+**Namensdefinition**
+ab Zeile 35:
+<code>
+Name:           invisdhcp
+%define originname		dhcp
+....
+Source0:        dhcp-%{isc_version}.tar.gz
+Source1:        dhcp-%{isc_version}.tar.gz.asc
+Source2:        %{originname}.keyring
+</code>
+Die Variable %originname musste hinzugefügt werden, da der Originalname weiterhin beim Paketbau benötigt wird.
+**Conflict & Requires Direktiven**
+ab Zeile 146
+<code>
+Conflicts: dhcp
+%package server
+Summary:        ISC DHCP Server
+Group:          Productivity/Networking/Boot/Servers
+Requires:       invisdhcp = %{version}
+Requires:       net-tools
+Conflicts:	dhcp-server
+PreReq:         %insserv_prereq %fillup_prereq /bin/cat /bin/mkdir /bin/cp /usr/sbin/useradd
+%package client
+Summary:        ISC DHCP Client
+Group:          Productivity/Networking/Boot/Clients
+Requires:       /sbin/arping
+Requires:       /usr/bin/host
+Requires:       invisdhcp = %{version}
+Requires:       iproute2
+Requires:       net-tools
+Conflicts:	dhcp-client
+PreReq:         %insserv_prereq %fillup_prereq /bin/cat /bin/mkdir /bin/cp /bin/grep
+%package relay
+Summary:        ISC DHCP Relay Agent
+Group:          Productivity/Networking/Boot/Servers
+Requires:       invisdhcp = %{version}
+Requires:       net-tools
+Conflicts:	dhcp-relay
+PreReq:         %insserv_prereq %fillup_prereq /bin/cat /bin/mkdir /bin/cp
+%package devel
+Summary:        Header Files and Libraries for dhcpctl API
+Group:          Development/Libraries/C and C++
+Requires:       invisdhcp = %{version}
+Conflicts:	dhcp-devel
+Conflicts:      bind-devel
+%if %{with_doc_package}
+%package doc
+Summary:        Documentation
+Conflicts:	dhcp-doc
+Group:          Productivity/Networking/Boot/Servers
+%endif
+</code>
+Wie gezeigt sind Anpassungen in allen Einzelpaketen erforderlich. Mittels Conflicts und Requires werden die erforderlichen Paketabhängigkeiten gelöst.
+===== DNS-Server bind und LDAP (invis Classic) =====
 Schon von Anfang an setzen wir ein LDAP-Verzeichnis als Daten-Backend für den DNS-Server //bind// ein. Der zugrunde liegende Patch, welchen wir schon seit einiger Zeit selbst in die Software-Pakete einbauen müssen, wird inzwischen kaum noch weiter entwickelt. Statt dessen gehört der sogenannte DLZ (dynamic loadable zone) Treiber seit etwa openSUSE 11.2 (oder so) fest zum Funktionsumfang der openSUSE-Pakete. Die Nutzung dieses Treibers würde uns eine Menge Arbeit ersparen, da wir keine eigenen //bind// Pakete mehr im openSUSE-Buildservice pflegen müssten.
@@ Zeile 340: / Zeile 554: @@
   * Dovecot als SASL-Authentifizierungsbackend für Postfix zu nutzen.
-  * Dovecots Deliver als MDA einzusetzen.
+  * Dovecots LMTP-Dienst zur Mail-Einlieferung zu verwenden
-  * IMAP-ACLs zu ermöglichen.
+  * IMAP-ACLs / Shared Folders zu ermöglichen.
+  * Sieve-Filter zu ermöglichen
   * Amavis als content_filter zu nutzen.
+Das Ganze gilt natürlich nur, wenn kein Zarafa eingesetzt wird. Zarafa integriert den Email-Speicher und Funktionen wie Zugriffsrechte und Filterregeln, kommt also ohne externen IMAP-Server aus.
 Die genannten Anforderungen ergeben ein recht komplexes Setup, daher widme ich mich hier den Hintergründen. Zunächst allerdings nur dem Teil der Einlieferung neuer Mails via //**fetchmail**//.
 Größte Schwierigkeit hierbei ist ein sauberes Mailrouting durch alle Komponenten. Dies beginnt bereits beim Fetchmail-Daemon. Zunächst ein schematischer Überblick über die Wege einer eingehenden Email:
+//**Hinweis:** Die Grafik ist nicht aktuell, der Dovecot Delivery Agent fällt jetzt weg, die Einlieferung erfolgt direkt via LMTP.//
 {{:invis-postfix_dovecot.png|Überblick}}
@@ Zeile 501: / Zeile 720: @@
 //**Achtung:** In einigen der jüngeren invis-Releases (7.0/7.1) habe ich darüber hinaus die Option "-o local_header_rewrite_clients=" gesetzt. Dies wird auch an anderer Stelle so angegeben. Diese Option sorgt allerdings dafür, dass das zuvor vorgenommene Address-Rewriting (aus lokaler Mail-Adresse mache externe Adresse) beim Rückliefern der Mail wieder rückgängig gemacht wird. Bedeutet die Empfänger einer solchen Mail sehen als Absende-Adresse die lokale Email-Adresse des Absender, die aber im Internet-Mailverkehr keine Gültigkeit hat.//
-Postfix ist zwar durchaus in der Lage Mails direkt in sogenannte "Maildirs" einzuliefern, allerdings ist dieser direkte Weg mit allerlei Nachteilen verbunden, da dadurch einige Stärken von Dovecot ungenutzt bleiben. Besser ist es die Verteilung der Mails in die jeweiligen Postfächer Dovecots eigenem MDA //**deliver**// zu übertragen.
+Postfix ist zwar durchaus in der Lage Mails direkt in sogenannte "Maildirs" einzuliefern, allerdings ist dieser direkte Weg mit allerlei Nachteilen verbunden, da dadurch einige Stärken von Dovecot ungenutzt bleiben. Besser ist es die Verteilung der Mails in die jeweiligen Postfächer Dovecots zu überlassen und die Übergabe an Dovecot via LMTP (Local Mail Transfer Protocol) zu erledigen.
 Üblicherweise sind Maildirs in den Home-Verzeichnissen der Benutzer zu finden. Dies birgt einige Nachteile und Gefahren in sich. Die größte Gefahr dabei, geht wohl von den Nutzern selbst aus, die in der Lage sind diese Verzeichnisse einfach zu löschen. Dass ein Benutzer im "Aufräumrausch" einfach mal Verzeichnisse löscht, mit denen er nichts anfangen kann, dürfte wohl keine Seltenheit sein.
@@ Zeile 522: / Zeile 741: @@
 </code>
-Damit Postfix weiß, auf welchem Weg es Mails lokal zuzustellen hat, muss dies in Abhängigkeit zur Empfänger-Domain bekannt gemacht werden. Genutzt werden für diesen Zweck entsprechende Lookup-Tables. Hintergrund ist hier, dass Postfix über die Empfänger keine Kenntnis hat oder braucht. Es bekommt einfach nur gesagt, welche Domains lokal "relayed" werden und wer sich um die Zustellung kümmert. Für beide Zwecke gibt es mit //relay_domains// und //transport_maps// eigene Lookup-Tables. Da in unserem Fall beide Tables den gleichen Inhalt haben, werden Sie an die selbe Datenquelle gebunden. Vorgenommen wird diese Konfiguration wieder in der Datei: <file>/etc/postfix/main.cf</file>
+Damit Postfix weiß, auf welchem Weg es Mails lokal zuzustellen hat, muss dies in Abhängigkeit zur Empfänger-Domain bekannt gemacht werden. Genutzt werden für diesen Zweck entsprechende Lookup-Tables. Hintergrund ist hier, dass Postfix über die Empfänger keine Kenntnis hat oder braucht. Es bekommt einfach nur gesagt, welche Domains lokal "relayed" werden und wer sich um die Zustellung kümmert. Für beide Zwecke gibt es mit //relay_domains// und //transport_maps// eigene Lookup-Tables. Da in unserem Fall beide die Relay-Domains Table den gleichen Aufbau hat wie die normale Transport-Table, wird Sie an als zusätzliche Transport-Table eingebunden. Vorgenommen wird diese Konfiguration wieder in der Datei: <file>/etc/postfix/main.cf</file>
 <code>
 # Relay Domains und Transportwege-Regelungs Tabelle bekannt machen
-relay_domains = hash:/etc/postfix/relay
+relay_domains = hash:/etc/postfix/relay_domains
-transport_maps = hash:/etc/postfix/relay
+transport_maps = hash:/etc/postfix/transport, $relay_domains
 </code>
-Die in der Konfiguration benannte Datei muss manuell angelegt und mit folgendem Inhalt versehen werden:
+Die in der Konfiguration benannte Datei "relay_domains" muss manuell angelegt und mit folgendem Inhalt versehen werden:
 <code>
 # for relaying domain
 # domain.de OK
-invis-net.loc   dovecot:
+invis-net.loc   lmtp:unix:private/dovecot-lmpt
 </code>
-Darin enthält Spalte 1 die Domain und Spalte 2 den zugehörigen Transportweg. Letzterer muss natürlich in der Datei <file>/etc/postfix/master.cf</file> noch angelegt werden:
+Darin enthält Spalte 1 die Domain und Spalte 2 den zugehörigen Transportweg.
+Das Beispiel zeigt eine LMTP-Anbindung via UNIX-Socket. Die entsprechende Socket-Datei muss von Dovecot bereit gestellt werden. Alternativ wäre auch ein TCP/IP-Socket über die Localhost-Schnittstelle möglich.
 <code>
-## Dovecot Transport -- invis-server.org -- Stefan Schaefer
+# for relaying domain
-dovecot   unix  -       n       n       -       -       pipe
+# domain.de OK
-    flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver
+invis-net.loc   lmtp:[127.0.0.1]
-    -f $sender -d $recipient
 </code>
-Benannt werden hier vor allem der Benutzer unter dessen Kennung der MDA (deliver) ausgeführt wird, der zu verwendende Delivery-Agent selbst, Absender- und Empfängeradresse sowie ein paar Flags, die das Verhalten des Delivery-Agents beeinflussen.
+Die TCP/IP Methode ist etwas einfacher in der Konfiguration, da seitens Dovecot kein Socket definiert werden muss. UNIX-Sockets sind allerdings etwas performanter, da die übertragene Datenmenge durch Wegfall des TCP/IP bedingten Overheads geringer ist.
 ==== Letzte Etappe - Dovecot ====
-Ab invis-Server Version 7.1-R3 kommt Dovecot in Version 2.1 zum Einsatz. Erwähnenswert ist das, da sich an dessen Konfiguration mit Einführung von V. 2.x einiges geändert hat. Einerseits betrifft dies Namen von Konfigurationsoptionen und andererseits den Aufbau der Konfiguration an sich. Unter openSUSE wurde die Konfiguration der Übersicht halber in mehrere Dateien gesplittet. Im Verzeichnis "/etc/dovecot" ist nach wie vor eine (wenn auch stark geschrumpfte) Datei "dovecot.conf" zu finden. Sie dient quasi als Hauptkonfigurationsdatei in die alle weiteren Dateien inkludiert werden. Ähnlich wie das bereits beim Apache-Webserver der Fall ist.
+Ab invis-Server Version 7.1-R3 kommt Dovecot in Version 2.1, inzwischen schon Version 2.2 zum Einsatz. Erwähnenswert ist das, da sich an dessen Konfiguration mit Einführung von V. 2.x einiges geändert hat. Einerseits betrifft dies Namen von Konfigurationsoptionen und andererseits den Aufbau der Konfiguration an sich. Unter openSUSE wurde die Konfiguration der Übersicht halber in mehrere Dateien gesplittet. Im Verzeichnis "/etc/dovecot" ist nach wie vor eine (wenn auch stark geschrumpfte) Datei "dovecot.conf" zu finden. Sie dient quasi als Hauptkonfigurationsdatei in die alle weiteren Dateien inkludiert werden. Ähnlich wie das bereits beim Apache-Webserver der Fall ist.
 Alle weiteren Dateien sind logisch unterteilt im Verzeichnis "/etc/dovecot/conf.d" zu finden.
+Bei aller Freude über Peer Heinleins neues Dovecot Buch, ist doch festzustellen, dass die Aufgabenstellung die sich für die Dovecot-Konfiguration auf einem invis-Server stellt, mit dem Buch allein nicht zu bewältigen ist. Peer trennt im Prinzip zwischen einer Installation mit lokalen Benutzern und einer Hosting-Situation mit virtuellen Benutzern. Auf einem invis-Server haben wir es zwar mit lokalen Benutzern zu tun, aufgrund der Vorzüge, die das mit sich bringt, möchte ich sie aber lieber wie virtuelle Benutzer behandeln, da dies einige Vorteile mit sich bringt.
+**Definieren wir zunächst die Ziele:**
+  * Zugriff auf die LDAP-Benutzerkonten via PAM
+  * Ordner-Freigaben über IMAP-ACLs
+  * Sieve Filter und sei es nur für Abwesenheitsbenachrichtigungen
+  * Quotas, wenn auch nur zum Warnen
+  * Lokale Email-Zustellung via LMTP
+  * SASL-Auth Schnittstelle für Postfix (wird im nächsten Abschnitt beschrieben)
+==== Mailversand - SMTP-Auth mit Dovecot-SASL ====
+...to be continued.
+===== Autostart von Docker Containern mittels Systemd =====
+Docker Container, die einen Dienst anbieten sollen natürlich beim Start eines Systems möglichst automatisch starten. Außer der Docker-eigenen "Restart=always" Möglichkeit, die bisweilen ein wenig nervig sein kann, bietet sich die Verwendung von **//systemd//** an.
+Leider ist die in der Docker-Dokumentation beschriebene Service-Unit Vorlage ein wenig zu simpel gestrickt. Sie funktioniert nicht immer. Es kommt vor, dass es mit dieser Vorlage während des Systemstarts unzählige scheiternde Versuche gibt einen Container zu starten und **//systemd//** dann irgendwann aufgibt.
+Daher hier eine Vorlage, die auch mit störrischen Containern funktioniert:
+<code>
+[Unit]
+Description=BlaBlaBla Firebird-Server Container
+Requires=docker.service
+After=docker.service network.service
+[Service]
+Restart=on-failure
+RestartSec=10
+ExecStart=/usr/bin/docker run --volume=/srv/docker/blablafb/data:/data --publish=3050:3050 --name=leberwurst blablablasoftware/db_server
+ExecStop=/usr/bin/docker stop -t 2 leberwurst
+ExecStopPost=/usr/bin/docker rm -f leberwurst
+[Install]
+WantedBy=multi-user.target
+</code>
+Dieser Vorlage unterscheidet sich an mehreren Punkten von der in der Docker-Doku gezeigten.
+Zunächst wird für die Restart-Option der Parameter "on-failure" statt "always" genutzt. Dies verhindert unnötige Neustarts. Ich vermute, dass die Rückmeldungen von Docker nicht dem entsprechen, was //**systemd**// erwartet und daher mit "always" Neustarts ausgelöst werden, die nicht notwendig sind.
+Auch im Fehlerfall sollte zwischen den Neustarts eine Pause liegen, da der Docker-Container ggf. nicht so schnell agiert, wie //**systemd**// das erwartet. "RestartSec=10" setzt diese Pause auf 10 Sekunden.
+Da ich im Beispiel dem Container mit "--name=" einen reproduzierbaren Namen gebe, scheitern zu schnelle Neustarts oft daran, dass bereits ein Container mit diesem Namen existiert (...auch wenn dieser nicht funktioniert). Mit "ExecStopPost=" wird nach einem Stoppen des Containers dieser auch entfernt. Damit steht er einem Neustart unter gleichem Namen nicht im Weg.
+Gespeichert werden die Container-Service-Unit Dateien unter: <file>/etc/systemd/system</file>
+Eine Veränderung dieser Dateien muss mit
+<code>
+linux:~ # systemctl daemon-reload
+</code>
+übernommen werden.