Puppet Modul für Corosync oder "Die Puppen tanzen jetzt auf mehreren Kisten"

Ziel für diesen Blog war es eigentlich, den Post selbst kürzer als die Überschrift zu halten. Dies wird mir, wie ich gerade feststelle, nicht ganz gelingen.
puppetlabsDa ich im Puppet Modul puppetlabs-corosnyc die Möglichkeiten vermisste Resourcen zu klonen, Resourcen Standards zu setzen oder mit Locations zu arbeiten, habe ich dieses Modul kurzerhand auf github geforkt und um die genannten Typen (cs_clone, cs_rsc_defaults u. cs_location) erweitert. Mit cs_location ist es nicht nur möglich eine Resource an einen Knoten zu binden, sondern die Verteilung auch regelbasiert vornehmen zu lassen.punda_github
Eine ausführliche Dokumentation befindet sich im Readme.md des Moduls und somit auch auf meiner Projektseite.
Das Schreiben eigener Typen und Provider in Ruby vermitteln wir übrigens auch in unserer nächsten Extending Puppet Schulung Anfang Juli.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

OpenLDAP: N-Way Master Replication

In diesem Artikel möchte ich kurz beschreiben, wie man aus einem einzelnen OpenLDAP-Server eine hochverfügbare Farm aufbauen kann. Voraussetzung sei hierfür ein eingerichteter Standalone-Server mit dynamischer Konfiguration im LDAP selbst (cn=config) und konfiguriertem LDAPS bzw. SSL auf Port 638. Für die hier exemplarisch verwendeten LDAP-Client-Kommandos muss zusätzlich die IPC-Unixsocket (ldapi) Schnittstelle des Servers aktiviert sein.
Für die Replikation von einem Master auf einen Slave LDAP-Server wird jeweils eine Abstarktionsschicht, Overlay genannt, im jeweiligem Server selbst “eingezogen”. Hierbei wird der Slave im LDAP-Jargon als Consumer und er Master als Provider bezeichnet. Für eine Multi-Master-Umgebung muss also jeder LDAP-Knoten Provider wie auch Consumer sein.
Zuerst machen wir aus unserem Standalone-Server einen Provider. Hierfür soll das nachfolgende Listing als provider.ldif abgespeichert sein.

dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 0x001 ldaps://kdc01.netways.int
olcServerID: 0x002 ldaps://kdc02.netways.int

Wie dem Listing zu entnehmen ist, haben wir neben der Konfiguration cn=config, bisher lediglich einen weiteren Baum bzw. Datenbank im DBD-Format in unseren LDAP abgelegt. Bei einer weiteren Datenbank, ist ein weiterer ensprechender DN hinzuzufügen. Soll die Farm aus mehr als zwei Servern bestehen müssen ebenfalls weitere ServerIDs angefügt werden. Mit

# ldapmodify -Y EXTERNAL -H ldapi:/// -f provider.ldif

kann nun die Konfiguration erweitert werden. Hier kann man nun auch erahnen, dass jede Datenbank einzeln synchronisiert wird. Das folgende Listing auth.ldif macht dies klarer ersichtlich, da wir hier für jede Datenbank die Authenfizierung anpassen werden.

dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=config

add: olcRootPW
olcRootPW: {SSHA}4KIL4Ob3SLaLqbe/AyMO80KALdBUWj6M

Dieses Listing ist jedoch nur mit

# ldapmodify -Y EXTERNAL -H ldapi:/// -f auth.ldif

hinzuzufügen, wenn in der Datenbank cn=config für den Benutzer cn=config noch kein Passwort gesetzt hat. Bei unserer zweiten Datenbank {1}bdb gehen wir davon aus, dass der RootDN cn=admin,dc=netways,dc=int lautet und ein Passwort gesetzt ist.
Die beiden folgenden Listings consumer_0.ldif und consumer_1.ldif konfigurieren unseren LDAP-Server zusätzlich als Consumer.

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldaps://kdc01.netways.int binddn=”cn=config” bindmethod=simple credentials=PASSWORD searchbase=”cn=config” type=refreshAndPersist retry=”5 +” timeout=1
olcSyncRepl: rid=002 provider=ldaps://kdc02.netways.int binddn=”cn=config” bindmethod=simple credentials=PASSWORD searchbase=”cn=config” type=refreshAndPersist retry=”5 +” timeout=1

add: olcMirrorMode
olcMirrorMode: TRUE

dn: olcDatabase={1}bdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=003 provider=ldaps://kdc01.netways.int binddn=”cn=admin,dc=netways,dc=int” bindmethod=simple credentials=PASSWORD searchbase=”dc=netways,dc=int” type=refreshAndPersist interval=00:00:00:10 retry=”5 +” timeout=1
olcSyncRepl: rid=004 provider=ldaps://kdc02.netways.int binddn=”cn=admin,dc=netways,dc=int” bindmethod=simple credentials=PASSWORD searchbase=”dc=netways,dc0int” type=refreshAndPersist interval=00:00:00:10 retry=”5 +” timeout=1

add: olcMirrorMode
olcMirrorMode: TRUE


# ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_0.ldif
# ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_1.ldif

aktivieren den jeweiligen Consumer, der nun via LDAPS und Simple Authentification, die zu synchronisierenden Daten vom jeweilgen Provider ausliest. Um die Performance der Synchronisation zu erhöhen sollte man unbedingt noch jeweils einen Index auf entryUUID und entryCSN setzen.

dn: olcDatabase={1}bdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq
olcDIndex: entryCSN eq

Das wars schon. Jetzt beschäftigen wir uns mit dem zweiten Knoten unserer Farm. Dieser wird zunächst wie ein Standalone Server konfiguriert. Zubeachten ist, dass z.B. die Zertifikate unter dem selben Pfad und mit dem selben Namen abzulegen sind, da wir auf beiden Knoten, die selbe Konfiguration verwenden werden. Nachdem wir auf unserem fertig konfigurierten Knoten, die Konfiguration mit

# slapcat -n 0 -l config.ldif

gesichert haben und auf unseren zweiten Knoten kopiert haben, spielen wir diese auf dem neuen Knoten mit

# slapadd -F /etc/openldap/slapd.d -n 0 -l config.ldif

wieder ein und starten den LDAP-Server. Von nun an werden beide Datenbanken repliziert.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

SMS versenden – aber möglichst günstig

Um den Admin auch Nachts und am Wochenende zu alarmieren, gibt es zu SMS eigentlich kaum eine Alternative. Handy hat inzwischen jeder und nichts ist kompatibler mit allen Endgeräten. Im Vergleich zu den letzten Jahren, kommen SMS inzwischen auch vergleichsweise zuverlässig an, wenn das Nagios System nicht gerade an Weihnachten oder Sylvester ein Probleme melden will.
3194571738_970b4a62fb_oUm die SMS technisch zu versenden gibt es inzwischen unzählige Möglichkeiten: Vom speziellen SMS Dienstleister über ISDN Dialup, bis hin zu eigenen SMS Modems. In diesem Artikel soll es aber nicht darum gehen, was die besten Methode ist eine SMS Benachrichtigung zu implementieren, sondern welche Methode am einfachsten und am kostengünstigsten eingerichtet werden kann: Inzwischen bieten alle vier deutschen GSM Anbieter ihren Kunden eine eMail2SMS Schnittstelle. Nach der einmaligen Freischaltung per SMS braucht man nur noch eine eMail an seine persönliche SMS E-Mail Adresse zu senden und hat das ganze nur Sekunden später als SMS auf dem Handy. Schneller und billiger kommt man nicht zu den SMS.

Wir funktioniert das ganze nun?

Ganz einfach. Aus der nachfolgenden Tabelle sucht man sich die passenden Daten zu seinem Mobilfunkanbieter und schickt den Aktivierungstext per SMS an die angegebene Nummer. Danach bekommt man vom Provider eine Bestätigungs-SMS zuruck und das Gateway ist freigeschaltet. Um eine SMS zu verschicken, benutzt man einfach die angebenene E-Mail Adresse und ersetzt xxx mit der Mobilnummer inkl. Vorwahl, also beispielsweise 01721234567@vodafone-sms.de.

Vodafone T-Mobile E-Plus O2
Nummer 3400 8000 7676245 6245
Aktivierung OPEN OPEN START OPEN
Deaktivierung CLOSE CLOSE STOP STOP
Preis 0,20 EUR 0,19 EUR 0,20 EUR 0,19 EUR
E-Mail Adresse xxx@vodafone-sms.de xxx@t-mobile-sms.de xxx@smsmail. eplus.de xxx@o2online.de

Bei E-Plus muss der komplette Inhalt der Nachricht in der Betreff Zeile der E-Mail stehen. Die anderen Anbieter verwenden Betreff und Inhalt der E-Mail und hängen beides in der SMS einfach hintereinander.
Auch wenn die Einrichtung dieser SMS Benachrichtigungen schnell und einfach funktioniert, sollen die Nachteile auch nicht verschwiegen werden: Im Fehlerfall muss Ihr Nagios Server immer noch eine E-Mail an einen externen Empfänger senden können und das verlangt eine Vielzahl funktionierender Systeme. Es müssen Internetanbindung, Mailserver, DNS, Firewall und vermutlich viele andere Komponenten noch verfügbar sein und gerade bei einem Ausfall ist das nicht immer sicher. Dazu kommen die vergleichsweise hohen Kosten pro SMS. Wenn der Nagios Server nicht optimal konfiguriert ist, kann es gut sein, dass Nagios bei einem Switchausfall mehrere Hundert SMS versenden will. Und das würde schnell sehr teuer für den Handybesitzer werden, denn diese SMS werden vom Empfänger bezahlt. Wenn man auf Nummer sicher gehen will, kommt man also an einem eigenen SMS Gateway kaum vorbei. Will man allerdings nur mal schnell SMS in Betrieb nehmen, ist die vorgestellte Lösung sicher eine gangbare Alternative.

Julian Hein
Julian Hein
Executive Chairman

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.