Select Page

OpenLDAP: N-Way Master Replication

by | Jun 14, 2012 | OpenLDAP

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.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

More posts on the topic OpenLDAP

Aufzeichnung des LConf-Webinars ist online!

Die Aufzeichnung unseres gestern geführten Webinars steht ab sofort zum Ansehen auf YouTube bereit. Vielen Dank nochmal an alle Teilnehmer für die Aufmerksamkeit. Im Webinar wurden folgende Punkte durchgesprochen: Kurzvorstellung NETWAYS Einführung LDAP...

FLOSS UK 2013 in Newcastle

Letzte Woche war ich wie bereits angekündigt in Newcastle unterwegs um bei der diesjährigen Spring Conference teilzunehmen. Nachdem ich am Starbucks Schiphol wie angekündigt nicht vorbeigekommen bin, bin ich kurz vor Mitternacht in Newcastle angekommen und sofort in...