Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- kb [2016/04/23 08:25]
flacco [Paketbenennung und Konfliktverhalten]
+++ kb [2017/01/05 10:41]
flacco [Active Directory und Firewall]
@@ Zeile 25: / Zeile 25: @@
 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 den DNS-Dienst auszulagern, ich habe das mit "ISC bind" bereits erfolgreich getestet.
+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.
@@ Zeile 42: / Zeile 42: @@
 ^Protokoll  ^Transportprotokoll  ^Port  ^Bemerkung  ^
-|Kerberos  |  TCP & UDP  |  88  |    |
+|Kerberos  |  TCP & UDP  |  88  |  Benutzerauthentifizierung  |
-|LDAP  |  TCP & UDP  |  389  |    |
+|LDAP  |  TCP & UDP  |  389  |  Daten-Backend, Benutzerveraltung, DNS, DHCP und invis-Portal  |
-|LDAPs  |  TCP  |  636  |    |
+|LDAPs  |  TCP  |  636  |  s.o.  |
-|DNS  |  TCP & UDP  |  53  |    |
+|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 ====
@@ Zeile 213: / Zeile 216: @@
 Wie gezeigt sind Anpassungen in allen Einzelpaketen erforderlich. Mittels Conflicts und Requires werden die erforderlichen Paketabhängigkeiten gelöst.
-===== Aufbau einer Public Key Infrastruktur mit easy-rsa =====
-Unter anderem zur Nutzung im invis-Server wurde ein easy-rsa 3.x RPM im Repository "spins:invis:common" gebaut. Die nachfolgende Anleitung beschreibt, wie mit easy-rsa eine PKI manuell aufgebaut wird. Die spätere Verwaltung von Zertifikaten übernimmt auf invis-Servern das Script //**inviscerts**//.
-Ab Version 3.0 stellt easy-rsa nur noch ein einziges Script //**easyrsa**// für alle Aufgaben zur Verfügung. Sämtliche Konfigurationsdateien liegen in: <file>/etc/easy-rsa</file>
-Vor dem Aufbau einer PKI muss im genannten Verzeichnis die Datei "vars" an die eigenen Bedürfnisse angepasst werden. Es ist im Unterschied zu älteren easy-rsa Versionen nicht mehr notwendig die Variablen in dieser Datei manuell mittels //**source**// in die aktuelle Shell Umgebung zu laden. Dies erledigt //**easyrsa**//  selbsttätig.
-=== Vorbereitung ===
-Angepasst werden müssen zumindest folgende Zeilen:
-Name der PKI:\\
-(Zeile 65)
-<code>
-...
-set_var EASYRSA_PKI             "$EASYRSA/fsp-net.loc"
-...
-</code>
-PKI individualisieren:\\
-(Ab Zeile 84)
-<code>
-...
-set_var EASYRSA_REQ_COUNTRY     "DE"
-set_var EASYRSA_REQ_PROVINCE    "Hessen"
-set_var EASYRSA_REQ_CITY        "Schotten"
-set_var EASYRSA_REQ_ORG         "FSP Computer und Netzwerke"
-set_var EASYRSA_REQ_EMAIL       "stefan@invis-server.org"
-set_var EASYRSA_REQ_OU          "invis-Server.org"
-...
-</code>
-Die vorgegebene Länge der DH-Parameter ist auf 2048 Bit eingestellt, dies reicht nach gegenwärtigem Stand der Technik aus. Eine Erhöhung auf 4096 Bits verlängert den Bau der DH-Datei immens (Die Rede ist hier von Stunden).
-Voreingestellt sind Gültigkeitsdauern für CA und damit signierte Zertifikate von 10 Jahren. Kann man lassen, die Lebensdauer der Zertifikate im Vergleich zur CA zu verkürzen ist auch OK.
-Jetzt kann die PKI vorbereitet werden:
-<code>
-linux:~ # easyrsa init-pki
-</code>
-Damit wird unter "/etc/easy-rsa" eine Verzeichnisstruktur für die neue PKI angelegt und die Vorbereitungen sind abgeschlossen.
-=== PKI erzeugen ===
-Benötigt werden für OpenVPN folgende Komponenten:
-  - Eine CA zum signieren von Server und Client Zertifikaten
-  - Eine Diffie-Hellman Parameter Datei für sicheren Schlüsselaustausch
-  - Eine CRL Datei um Zertifikate zurückzuziehen
-**CA erstellen:**
-Auch hier genügt ein einziger Befehl:
-<code>
-linux:~ # easyrsa build-ca
-</code>
-Beim Bau der CA wird ein Passwort erfragt, dieses Passwort wird später beim signieren von Zertifikaten benötigt. Dieses Passwort darf nicht in falsche Hände gelangen.
-**Diffie-Hellman Parameter erstellen:**
-<code>
-linux:~ easyrsa gen-dh
-</code>
-**CRL erzeugen**
-<code>
-linux:~ easyrsa gen-crl
-</code>
-Hierfür wird wieder das CA-Passwort benötigt.
 ===== DNS-Server bind und LDAP (invis Classic) =====
@@ Zeile 870: / Zeile 789: @@
 ...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.