ubuntuusers.de

Ich bin grad dabei, meinen PDC durch einen BDC "abzusichern". Dazu gehört auch das OpenLDAP-Verzeichnis. Ich hab die Beschreibung von

https://help.ubuntu.com/10.04/serverguide/C/openldap-server.html

verwendet. Leider werden die Daten nicht repliziert. Daher die Frage: Müssen auf dem Slave alle Schemata installiert werden? Sollte dass nicht auch per Replikation gehen? Oder bezieht sich dass hier nur auf die eigentlichen Daten (und nicht die cn=config)?

Vielleicht kann mir da ja jemand einen Antwort geben, da ich dann erahnen kann, was fehlt

Replikation bezieht sich immer nur auf den eigentlichen DIT. Das cn=config Backend wird nicht mitrepliziert, d.h. musst du auf den Slave die Konfiguration entsprechend (inkl. Schemata) alles neu Einrichten, mit den Abänderungen für die Replikation.

So, ich bin schon mächtig weitergekommen.

Durch einen Link auf das OpenLDAP 2.4 Praxisbuch, bin ich nun soweit, dass ich alles repliziert bekomme. Nun, das ALLES darf ja nicht sein. Ich muss ja was ausschließen.

Im Buch wird die slapdd.conf Methode beschrieben. Meine LDAP-Instanzen haben aber die Konfiguration in der cn=config. Das Umarbeiten hat ein paar Tage in Anspruch genommen. Aber im Prinzip klappt es ja - bis auf eine winzige Kleinigkeit.

Auf dem Server (Master) habe ich nun folgenden LDIF-Datei eingelesen:

dn: cn=config
changetype: modify
add: olcReferral
olcReferral: "ldap://ldap.example.de"

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov

dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: rid=002 provider=ldap://ldap.example.de type=refreshAndPersist retry="5 +" searchbase="cn=config" filter="(!(olcDatabase={0}config))" bindmethod=simple binddn="cn=admin,dc=example,dc=de" credentials=secret
add: olcUpdateRef
olcUpdateRef: ldap://ldap.example.de

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://ldap.example.de type=refreshAndPersist retry="5 +" searchbase="dc=example,dc=de" bindmethod=simple binddn="cn=admin,dc=example,dc=de" credentials=secret
add: olcUpdateRef
olcUpdateRef: ldap://ldap.example.de

Der Client-Server hat folgede Datei eingelesen bekommen:

dn: cn=config
#objectClass: olcGlobal
#cn: config
changetype: modify
add: olcReferral
olcreferral: ldap://ldap.example.de

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcSyncRepl: rid=002 provider="ldap://ldap.example.de" binddn="cn=admin,dc=example,dc=de" bindmethod=simple credentials=secret searchbase="cn=config" filter="(!olcDatabase={0}config)" type=refreshAndPersist retry="10 +"
olcRootDN: cn=admin,dc=example,dc=de
olcUpdateRef: ldap://ldap.example.de

Ergebniss: Direkt nach dem Einlesen der Datei auf dem Slave, werden alle Informationen auch repliziert. Wenn ich den LDAP-Explorer öffne, kann ich alle Einträge und Schemata sehen auf dem 2. Server.

Starte ich den Slave-Server aber neu, dann kommmt die Meldung:

Starting OpenLDAP: slapd - failed.
The operation failed but no output was produced. For hints on what went
wrong please refer to the system's logfiles (e.g. /var/log/syslog) or
try running the daemon in Debug mode like via "slapd -d 16383" (warning:
this will create copious output).

Below, you can find the command line options used by this script to
run slapd. Do not forget to specify those options if you
want to look to debugging output:
  slapd -h 'ldap:/// ldapi:///' -g openldap -u openldap -F /etc/ldap/slapd.d/

In der Datei syslog finde ich folgenden Hinweis:

Nov  9 20:54:03 SMS002092 slapd[3376]: @(#) $OpenLDAP: slapd 2.4.21 (Jun  2 2011 19:36:19) $#012#011buildd@allspice:/build/buildd/openldap-2.4$
Nov  9 20:54:03 SMS002092 slapd[3376]: config error processing olcDatabase={2}config,cn=config:
Nov  9 20:54:03 SMS002092 slapd[3376]: slapd stopped.
Nov  9 20:54:03 SMS002092 slapd[3376]: connections_destroy: nothing to destroy.

Welches auch klar ist, weil es auf dem Slave nun ZWEI olcDatabases mit dem Namen config gibt (einmal mit {0} und einmal mit {2} - die 2 ist unvollständig - wird durch die Replikation erzeugt - und wird gar nicht benötigt)

FRAGE: Wie kann ich das erstellen der 2. cn=config verhindern? Was ist an meinem SyncRepl-Filter eigentlich falsch?

Vielen Dank schon mal für den einen oder anderen Tipp