Der Fehlerteufel hat beim letzten Artikel zugeschlagen

Leider ist mir beim erstellen des tar-Files für die Rollen ein Fehler unterlaufen, der LDAP-Server wird leider nach der Installation mit der Rolle nicht starten. Problem ist, das Attribut „olcPasswordHash“ habe ich dort (wie bei anderen Konfigurationen auch) direkt nach cn=config geschrieben, die neuen Passwordhashes wie {TOTP} müssen aber unter {-1}frontend eingetragen werden. Ich habe das entsprechende Skript geändert neu Verlinkt. Wenn Sie die Dateien schon runtergeladen haben, dann einfach erneut runterladen. Oder einfach diesem Link hier folgen, da sind auch die richtigen Dateien hinterlegt. 

Posted in Allgemein | Leave a comment

OpenLDAP 2.5 mit TOPT und autoca

Seit einiger Zeit gibt es nun endlich den OpenLDAP 2.5. Lange wurde er angekündigt. Ich habe hier die Version 2.5.4 genutzt um die beiden neuen Overlays autoca und totp einzurichten und zu testen. Da es noch keine Pakete für Debian 10 gibt, habe ich OpenLDAP aus den Quellen gebaut. Um bei späteren Versionen möglichst schnell einen Server einrichten zu können, habe ich hier wieder voll auf Ansible gesetzt. Ich habe eine neue Rolle definiert, die folgende Tasks durchführt:

  • Installation der Build-Umgebung mit allen Abhängigkeiten
  • Download der Quellen vom OpenLDAP
  • Bauen des OpenLDAP und allen benötigten Modulen
  •  Einrichten der Systemd-Skripte zum Start des OpenLDAP
  • Konfigurieren des OpenLDAP über ein Template
  • Einspielen der ersten Objekte
  • Anlegen eines simpleSecurityObjecs ldap-admin. Dieses Objekt hat alle Rechte an allen Objekten 
  • Anlegen eines simpleSecurityObjects repl-user später für die Replikation genutzt werden soll
  • Einrichten der Overlays autoca und totp

Um totp anschließend testen zu können, habe ich in der rolle openldap25 im Verzeichnis files ein Skript (create-qr.bash) abgelegt, dass den shared-key und den QR-Code für einen Benutzer erstellt.
Das Overlay autoca erzeugt für jeden Benutzer, ein Client-Zertifikat. Das Zertifikat wird bei einer Suche nach dem entsprechenden Attribut im Objekt des Benutzer abgelegt. Auch dieser Schritt wird mit dem Script durchgeführt.
In der aktuellen Konfiguration wird lediglich die Anmeldung mit einem TOTP eingerichtet. Durch Anpassung des Passwort-Hashes ist es auch möglich, auf eine zwei Faktoren Authentifizierung umzustellen. Die Umstellung werde ich hier zu einem späteren Zeitpunkt ergänzen. 

Die benötigten Rollen um den Server einzurichten finden Sie HIER.

Posted in Allgemein | Leave a comment

Benutzer gelöscht

Ich bin heute mal durch die List der hier angemeldeten Benutzer gegangen und habe aufgeräumt. Dabei habe ich alle Konten gelöscht, deren Emaildomäne nicht auflösbar war. Auch habe ich einige Benutzer gelöscht mit kryptischen Namen und die dazu auch keinen echten Namen angegeben haben. Sollte ich jemande gelöscht haben der hier noch aktiv ließt und unter einen der Kategorien gefallen sein, dann tut es mir Leid. Bitte dann einfach neu Anmelden und eine Emailadresse verwenden die  nachvollziehbar ist, In Zukunft werde ich alle Benutzer, die sich mit einer Wegwerfadresse registrieren sofort löschen. Sonst wird das für mich zu unübersichtlich.

Posted in Allgemein | Leave a comment

Ein neues Samba-Buch entsteht

Im Januar dieses Jahres ist die aktuelle Samba-Version 4.14 erschienen, dank Louis van Belle und Björn Baumbach konnte ich vom ersten Tag an auf Pakte für Debian zugreifen und sie für die neue Auflage nutzen.

Das ist das erste Mal, dass ich in so einem frühen Stadium mit dem Schreiben eines neuen Buchs begonnen habe. Wie zu erwarten, wenn man ein Buch mit dem rc1 Release beginnt, habe ich den einen oder anderen Bug gefunden. Gerade bei ganz neuen Möglichkeiten die die neue Version bringt, hakte es dann doch noch an der einen oder anderen Stelle. Diese Bugs wurden aber alle bis zur Version 4.14.2 behoben und so sind jetzt alle von mir beschrieben Neuerungen auch produktiv nutzbar.

Durch den frühen Zugriff wird diese Auflage (die im Juli oder August erscheinen wird) die erste Auflage sein, die auf der aktuellen Samba-Version beim Erscheinen basiert.

Von Anfang an war mir klar, dass ich einige Dinge aus dem Buch nehme will, dafür aber andere Dinge neu aufgenommen werden sollen. Raus gefallen ist der gesamte Abschnitt zum Kompilieren von Samba, denn es gibt heute so viele Möglichkeiten auf aktuelle Pakete zuzugreifen, dass ein selber kompilieren nicht mehr unbedingt erforderlich ist. Durch die Komplexität der neuen Version sind die Abhängigkeiten auch so viele, dass der Abschnitt, hätte ich ihn weiter gepflegt, zu groß geworden wäre. Insgesamt sind gut 50 bis 70 Seiten komplett aus der neuen Auflage raus gefallen, aber die Auflage hat trotzdem fast 100 Seiten mehr als die letzte Auflage. Sie sehen, ich habe viele neue Dinge aufgenommen. Bei den neuen Abschnitten geht es darum bestimmte Techniken der Administration noch besser zu erklären.

Damit Sie schon einmal einen kurzen Überblick über die kommenden Änderungen erhalten, hier eine (nicht vollständige) Auflistung der neuen Inhalte:

  • Erweiterte Verwaltung  von Freigaben
  • Einrichtung der Heimatverzeichnisse via GPO
  • Einrichtung von servergespeicherten Profilen via GPO
  • Umleitung der Ordner aus Profilen via GPO
  • Einrichten der neuen GPOs für Linux-Clients
  • Recovery eine Domäne
  • Neue Möglichkeiten mit dem Kommando samba-tool
  • Einrichten einer Domäne mit mehreren Domaincontrollern mittels Ansible

Selbstverständlich wurden die bestehenden Kapitel alle überarbeitet. So ist in doch relativ kurzer Zeit eine komplett überarbeitete Auflage entstanden. Das es dieses Mal so schnell ging, hat auch was mit der derzeitigen Corona-Situation zu tun, denn dank Homeoffice hatte ich auch viel Zeit am Buch arbeiten zu können.

Ich hoffe das auch diese Auflage wieder ein Erfolg wird und wie immer, freue ich mich über Feedbacks zum Buch. Lob sowieso, Kritik aber auch, solange sie konstruktiv ist.

Jetzt heißt es warten 

Posted in Allgemein, Samba | Tagged | Leave a comment

Die neue Auflage vom Linux-Server Buch ist da

Im Februar 2011 ist die erste Auflage des Linux-Server Buchs erschienen. Jetzt, 10 Jahren später ist es schon die sechste Auflage. Am Anfang waren es noch gerade 900 Seiten, dieses Mal mussten wir aufpassen, dass wir nicht das Maximum von 1300 Seiten überschreiten. Es hat geklappt es sind jetzt fast genau 1300 Seiten. Viele neu Dinge sind ins Buch gekommen und noch mehr wurde überarbeitet. Von mir wurden vor allen Dingen die Kapitel zum LDAP, Kerberos und Samba komplett überarbeitet. Die wohl größte Neuerung ist, dass ich sowohl im Kapitel LDAP als auch im Kapitel Kerberos neben der statischen Konfiguration des LDAPs auch die dynamische Konfiguration beschreibe. Bleibt mir nur, Ihnen viel Spaß beim Lesen zu wünschen.

Posted in Allgemein | Leave a comment

Loghost mit journald

Heute möchte ich mal zeigen, wie einfach es ist mithilfe des journald einen zentralen Loghost einzurichten.

Wie auch mit einigen der älteren Log-Daemons, lässt sich mit dem journald ein Log-Host einrichten um alle Meldungen Ihrer Server zentral an einer Stelle zu speichern. Die Übertragung der Daten wird dabei über TLS verschlüsselt, sodass ein Mitlesen mit einem Netzwerksniffer nicht möglich ist.

Für das Beispiel werde ich einen LDAP-Server als Log-Client einrichten, der seine Log-Informationen dann auf den Log-Host speichert. Auf allen Clients und dem Server installieren Sie das Paket systemd-journal-remote.

Achten Sie bei der Einrichtung des Servers darauf, dass Sie ausreichend Festplattenplatz bereitgestellt haben. Je mehr Clients die Logs dort ablegen und je länger Sie die Logs speichern wollen, um so mehr Plattenplatz wird benötigt. Damit der Server, für den Fall, dass der Plattenplatz nicht ausreicht, nicht abstürzt, lagern Sie das Verzeichnis /var auf eine eigene Partition aus. Die Standardgröße einer Log-Datei ist 8 MB, auch wenn noch keine Meldungen im Log eingetragen sind.

Im ersten Schritt aktivieren Sie den Dienst und den dazugehörigen Socket auf dem Server, über den sich die Clients verbinden. Das folgende Listing zeigt die entsprechenden Kommandos:

root@loghost:~# systemctl enable –now systemd-journal-remote.socket
Created symlink /etc/systemd/system/sockets.target.wants/systemd-
journal-remote.socket -> /lib/systemd/system/systemd-journal-remote.socket.
root@loghost:~# systemctl enable systemd-journal-remote.service

Im ersten Kommando wird der Dienst durch die Option –now sofort gestartet. Der zweite Dienst wird erst gestartet wenn Sie das TLS-Zertifikat bereitgestellt haben. Der Port, der hier verwendet wird, ist der Port 19532. Prüfen Sie mit dem Kommando ss, ob der Port geöffnet wurde.

Erstellen Sie ein Zertifikat für den Server, falls noch keins vorhanden ist.

Auf allen Clients, die sich mit dem Log-Host verbinden sollen, aktivieren Sie jetzt auch den systemd-journal-remote.service. Auch auf den Clients wird der Dienst aber noch nicht gestartet.

Einrichten des Servers

Die Konfiguration des Log-Servers finden Sie in der Datei /etc/systemd/journal-remote.conf. In der Datei sind schon bestimmte Vorgaben vorhanden, die aber alle auskommentiert sind. Im folgenden Listing sehen Sie die Datei für unser Beispiel:

[Remote]
# Seal=false
SplitMode=host
ServerKeyFile=/etc/ssl/zertifikate/loghost-key.pem
ServerCertificateFile=/etc/ssl/zertifikate/loghost-cert.pem
TrustedCertificateFile=/etc/ssl/zertifikate/demoCA/cacert.pem

Die Variablen haben die folgenden Bedeutungen:

Seal
Wenn Sie maximale Sicherheit haben wollen, was das Manipulieren der Einträge angeht, können Sie diese Variable aktivieren und auf true setzen. Dann werden die einzelnen Einträge zusätzlich signiert.

SplitMode
Alle Einträge, werden aufgrund des Hostnamen, in eigene Dateien gespeichert. Das verbessert die Übersichtlichkeit der Daten, gerade wenn Sie viele Hosts auf dem Server loggen wollen.

ServerKeyFile
Der Pfad und der der Name des Keyfiles Ihres Zertifikats.

ServerCertificateFile
Der Name und der Pfad zum Zertifikat.

TrustedCertificateFile
Der Name und Pfad zum root-Zertifikat. Ohne diese Angabe das kann die Gültigkeit der Zertifikate nicht geprüft werden.

Damit die Zertifikate auch vom Log-Daemon genutzt werden können, ist es notwendig, dass Sie die Rechte wie im folgenden Listing anpassen:

root@loghost:~# chgrp systemd-journal-remote /etc/ssl/zertifikate/loghost-*
root@loghost:~# chmod 640 /etc/ssl/zertifikate/loghost-*

Sollten Sie das Zertifikat auch noch für andere Dienste benötigen, setzen Sie die erweiterten Dateisystem-ACLs für die Gruppe.

Erst jetzt können Sie den Dienst mit dem Kommando systemctl start systemd-journal-remote.service starten. Danach ist der Log-Host bereit, die Log-Daten der Clients anzunehmen.

Einrichten des Clients

Nachdem der Server im vorherigen Abschnitt eingerichtet wurde, geht es jetzt darum, den ersten Client anzubinden, der seine Log-Daten an den Log-Server schickt.

Für die Übermittlung der Daten wird ein eigener Benutzer benötigt. Legen Sie einen neuen Benutzer an, indem Sie das Kommando aus dem folgenden Listing übernehmen:

root@loghost:~# adduser –system –home /run/systemd –no-create-home \
–disabled-login –group systemd-journal-upload
Lege Systembenutzer »systemd-journal-upload« (UID 107) an …
Lege neue Gruppe »systemd-journal-upload« (GID 113) an …
Lege neuen Benutzer »systemd-journal-upload« (UID 107) mit \
Gruppe »systemd-journal-upload« an …
Erstelle Home-Verzeichnis »/run/systemd« nicht.

Bei dem neuen Benutzer handelt es sich um einen Systembenutzer, der sich nicht lokal anmelden kann. Vergeben Sie auch kein Passwort für den Benutzer.

Sorgen Sie auf dem Client dafür, dass das Zertifikat von der Gruppe systemd-journal-remote gelesen werden kann.

Auch auf dem Client folgt jetzt die Anpassung der Konfiguration, dieses Mal in der Datei /etc/systemd/journal-upload.conf. Auch auf dem Client ist die Datei schon vorhanden, aber alle Optionen sind noch auskommentiert. Im folgenden Listing sehen Sie die an mein Beispiele angepasste Datei:

[Upload]
URL=https://loghost.example.net:19532
ServerKeyFile=/etc/ssl/zertifikate/provider-stat-key.pem
ServerCertificateFile=/etc/ssl/zertifikate/provider-stat-cert.pem
TrustedCertificateFile=/etc/ssl/zertifikate/demoCA/cacert.pem

Im Unterschied zur Konfiguration des Servers, wird hier die URL angegeben, unter der der Server erreichbar ist. Die drei Zeilen für die Zertifikate sind identisch mit denen auf dem Server.

Starten Sie den Log-Daemon jetzt mit dem Kommando systemctl restart systemd-journal-upload.service auf dem Client.

Testen der Log-Umgebung

Wechseln Sie auf den Log-Server, und lassen Sie sich den Inhalt des Verzeichnisses /var/log/journal/remote anzeigen. Dort sehen Sie jetzt eine neue Datei. Ihr Name enthält den vollständigen Namens des Clients, wie er im Zertifikat genannt ist. Einen Eintrag zu meinem Beispiel sehen Sie im folgenden Listing:

root@loghost:~# ls /var/log/journal/remote/
‚remote-C=DE,ST=SH,L=St.\\x20Michel,O=Adminbuch,OU=CA\
,CN=provider-stat.example.net.journal‘

Sollten Sie, so wie im Beispiel, ein Leerzeichen im Namen des Zertifikats haben, dann wird das Leerzeichen durch die Zeichenfolge \x20 ersetzt. Der Backslash muss später, beim einlesen der Datei, zusätzlich mit einem Backslash entwertet werden, auch wenn Sie den Pfad in gerade Hochkommata setzen.

Ist die Datei vorhanden, hat alles geklappt und der Server nimmt Meldungen vom Client entgegen. Sie können jetzt warten, bis der Client eine Nachricht generiert und auf den Server überträgt. Sie können aber auch selber eine Testmeldung mit dem Kommando logger generiert,  so wie im folgenden Listing:

root@provider-stat:~# logger -p syslog.debug „Das ist ein Test vom \\
Client provider-stat“

Auf dem Log-Server können Sie jetzt das Log genau so auswerten, wie ich es in den Abschnitten vorher beschrieben habe, aber mit einen Unterschied, als Quelle geben Sie die Datei des Clients an, den Sie auswerten wollen. In folgenden Listing sehen Sie das Kommando und das Ergebnis der durch logger erzeugten Meldung:

root@loghost:~# journalctl –file=’/var/log/journal/remote/remote-C=DE\
,ST=SH,L=St.\\x20Michel,O=Adminbuch,OU=CA,CN=provider-stat.\
example.net.journal‘

Jan 11 19:48:18 provider-stat root[1081]: Das ist ein Test vom Client\ provider-stat\

So können Sie jetzt alle weiteren Clients einrichten und testen und haben damit eine zentrale Log-Umgebung geschaffen.

Posted in Allgemein | Tagged , | Leave a comment

OpenLDAP und Kerberos, es wächst zusammen was zusammen gehört

Immer wieder sehe ich  bei Kunden, dass sie zwar einen OpenLDAP-Server einsetzen, den in den meisten Fällen auch via TLS absichern, wenn es um Verbindungen zum und zwischen den OpenLDAP-Server geht, aber in den seltensten Fällen wird zusätzlich Kerberos eingesetzt um die Sicherheit zu erhöhen. Die folgenden Gründe werde dann immer angeführt:

  • Der Aufwand ist zu hoch.
  • Nur ein geringer Sicherheitsgewinn.
  • Die Pflege des Kerberos ist zu aufwendig.
  • Die Schulung der Mitarbeiter ist zu aufwendig.
  • Zu lange Einarbeitungszeiten.

Noch besser sind dann die folgenden Argumente die auch immer mal wieder auftauchen:

  • Wir nutzen doch schon TLS das muss reichen.
  • Hier kommt eh niemand rein.
  • Viel zu kompliziert.

Aber was stimmt denn nun?
Klar, Kerberos ist nicht in einem Tag gelernt, verstanden und implementiert. Die Einführung von Kerberos benötigt eine gute Planung und ausgebildete Administratoren. Aber der Sicherheitsgewinn rechtfertigt die Einführung auf jeden Fall. 

Welchen Mehrwert bietet mir Kerberos in Zusammenarbeit mit OpenLDAP? 
Da sich nicht nur Benutzer authentifizieren müssen, sondern die Authentifizierung auf Dienste und Hosts erweitert wird, steigt die Sicherheit. Denn nur System und Dienste die im Kerberos ein Konto (Principal) besitzen können sich überhaupt gegen den Kerbeors-Server authentifizieren und die Anmeldetickets (TGT) der Benutzer zur Authentifizierung nutzen. Ein weiterer wichtiger Punkt ist der, dass bei der Authentifizierung zu keiner Zeit Passwörter, seien sie verschlüsselt oder gar unverschlüsselt, über das Netzwerk übertragen werden. Der gesamte Authentifizierungsprozess findet über Tokens statt. Auch die Übertragung von Daten kann, wie zum Beispiel bei der Datenübertragung über NFS, mittels Kerberos verschlüsselt werden, so dass die Daten nicht im Netz abgefangen werden können. Auf einen kerbereisierten NFS-Server kann so auch neben der Hostauthentifizierung eine Benutzerauthentifizierung durchgeführt werden. Denn ein Benutzer der keine TGT besitzt, kann auch nicht mehr auf den NFS-Server zugreifen. Die Sicherheit im Netz steigt.
Zusammen mit Kerberos können Sie alle Abfragen an den OpenLDAP-Server mittels strong-bind durchführen und sind nicht mehr auf den simple-bind angewiesen. Der Vorteil dabei liegt ganz klar auf der Hand. Beim simple-bind ist es notwendig die Passwörter, für zum Beispiele die Replikation der OpenLDAP-Server, in Klartext in die Konfgurationsdatei zu schreiben. Bei der Verwendung von strong-bind mittels Kerberos findet die Authentifizierung bei der Replikation über Tickets statt. Der Dienst authentifiziert sich mit seinem Principal und einer verschlüsselten Keytab-Datei. So können keine Passwörter mehr aus der Konfiguration gelesen werden.
Einen ganz großen Vorteil habe ich hier noch gar nicht erwähnt: In einer vollständig kerbereisierten Umgebung geben die Benutzer nur noch einmal, bei der Anmeldung am System, ihr Passwort ein. Alle weiteren Anmeldungen an Hosts oder Services werden, automatisch und im Hintegrund, über Tickets durchgeführt. Sie erhalten eine Singel-sign-on Umgebung.
Das sind nur ein paar der Vorteile die Ihnen Kerberos bietet.

Aber Kerberos ist doch so kompliziert!
Das Verfahren wie die Authentifizierung durchgeführt wird ist schon recht komplex und Sie benötigen schon einige Zeit um die komplette Funktion des Kerberos zu verstehen. Aber muss man da alles verstehen? Verstehen Sie die vollständige Arbeitsweise vom Active Directory (Was im übrigen auch Kerberos nutzt) oder können Sie mir erklären wie die Assistentssysteme Ihres Autos funktionieren? Aber Sie fahren Auto oder :-)?
Gerade wenn Sie Kerberos zusammen mit OpenLDAP nutzen und für die Verwaltung der Objekte dann noch den LDAP Account Manger in der Pro Version einsetzen, dann ist die Verwaltung der LDAP-Umgebung einfach. Klar können Sie OpenLDAP und Kerberos auch komplett ohne grafisches Werkzeug nutzen, aber so ein grafisches Werkzeug erleichtert die Sache manchmal und lässt Ihnen die Möglichkeit Aufgaben der Benutzerverwaltung zu delegieren. Wenn Sie Kerberos zusammen mit OpenLDAP betreiben fällt auch die Replikation der Kerberos-Datenbank weg, denn alle Kerberos-Informationen liegen im LDAP und die Ausfallsicherheit realisieren Sie über die Replikation der LDAP-Server. Die Kerberos-Server verbinden sich alle gegen den LDAP und nutzen den selben Datenbestand.

Wie funktioniert Kerberos?
Das hier komplett zu erklären würde den Rahmen erheblich sprengen, aber trotzdem möchte ich das ganze mal versuchen recht einfach zu erklären:
Jeder Teilnehmer an der Authentifizierung über Kerberos benötigt einen Prinicipal mit einem Credential (Passwort) in der Datenbank. Bei Benutzern ist es das Passwort, das der Benutzer bei der Anmeldung angeben muss,  Hosts und Services könne schlecht selber ein Passwort eingeben, sie bekommen eine Keytab-Datei mit einem verschlüsselten Passwort. So können sich alle  Teilnehmer gegen den Kerberos-Server authentifizieren. Ein Benutzer der sich Angemeldet hat, erhält vom Kerberos-Server ein Ticket (TGT). Dieses Ticket hat nur eine begrenze Gültigkeit. Wenn der Benutzer jetzt auf einen Dienst eines anderen Server zugreifen möchte, wird der Service, der sich ja auch gegen den Kerberos authentifiziert hat, das Ticket anfordern. Im Hintergrund wird das TGT an den Service übertragen, da der Service dem Kerberos-Server vertraut und das TGT vom Kerberos-Server ausgestellt wurde, vertraut der Service dem TGT und fragt nicht mehr den Kerberos-Server. Nach der erfolgreichen Anmeldung übermittelt der Service eine Service-Ticket an den Client des Benutzers. Das Ticket wird dort gespeichert und bei einem weiteren Zugriff überträgt der Client das Service-Ticket, da das Service-Ticket vom Kerberos-Server erstellt wurde, vertraut der Client dem Service-Ticket. 
Klar, der gesamte Prozess ist etwas komplizierter (wie ihr ABS im Auto) aber um die Funktion annähernd zu erklären, denke ich, reicht es aus.

Fazit:
Keine Angst vor Kerberos

Posted in LDAP | Leave a comment

Jetzt auch mit Videokonferenz

Ab sofort kann ich Schulungen und Consulting auch via Videokonferenz anbieten. Dank mailbox.org geschieht das ganze DSGVO-konform und ohne zusätzliche Software, einfach über einen Browser. Verwendet wird dort die opensource Lösung jitsi. Bis zu 9 Teilnehmern sind möglich. Alle meine Themen können durchgeführt werden. Für bis zu vier Teilnehmern kann ich auch die Schulungsumgebung einrichten und via SSH bereitstellen.

Posted in Allgemein | Leave a comment

Kurze Einführung in Business Intelligence von checkmk

Heute geht es mal um ein ganz anderes Thema, um checkmk. Wer bereits checkmk einsetzt wird vielleicht schon mal über das WATO-Modul Business Intelligence (BI) gestolpert sein. Für die, die sich noch nie mit dem Thema auseinandergesetzt haben, soll dieses kleine Beispiel sein.

Mit BI können Sie zusammenhängende Dienste in Abhängigkeit bringen und das Gesamtergebnis darstellen.

Stellen Sie sich vor, Sie betreiben eine Webseite die über mehrer Webserver bereitgestellt wird, zusätzlich kommen noch mehrere Datenbank-Server im Cluster dazu. Jede einzelne Komponente, sprich Sever, kann bei einem Ausfall die Bereitstellung der Webseite nicht unterbrechen. Alle Dienste sind redundant ausgelegt. Fällt also einer von drei Webserver und zusätzlich noch einer von drei Datenbankserver aus, kann der Service „Webseite“ immer noch bereitgestellt werden. Diese Abhängigkeiten können mit BI abgebildet werden. In dem kleinen Beispiel (die Anleitung finden Sie hier) sehen Sie, wie Sie die Internetverbindung Ihres Unternehmens mit BI darstellen können und wie Sie die Darstellung auch dafür nutzen können beim Ausfall des Internets eine Meldung zu erzeugen.

In der aktuellen Version gibt es zwar eine einfachere Lösung der Überprüfung des Internets, aber darum solle es hier nicht gehen. Dieser Artikel soll Ihnen BI an Hand eines kleine Beispiels näherbringen.

Viele Spaß beim Ausprobieren

Posted in checkmk | Leave a comment

OpenLDAP delta-syncrepl mit Ansible

Im ersten Teil habe ich die Einrichtung von OpenLDAP-Servern mit einfacher Replikation beschrieben. Hier geht es jetzt um die Replikation mit delta-syncrepl. Die komplette Einrichtung aller Server wird via Ansible durchgeführt. Die Konfiguration der OpenLDAP-Server wird im Backend cn=config erstellt. Im Gegensatz zur Konfiguration über die slpad.conf ist es hier wichtig die richtige Reihenfolge der Overlays und Datenbanken einzuhalten. HIER finden Sie die Rollen für Ansible. Die Anleitung liegt in den entsprechenden REDME-Dateien. 

Posted in Ansible | Leave a comment