LDAP Replikation auf Debian Lenny

UCS - Univention Corporate Server
#1

Hallo NG,

ich versuche gerade einen Debian Lenny Server an das Univention LDAP anzubinden. Der Lenny Server soll per Syncrepl vom UCS System abgeglichen werden. Dabei bin ich nach dem Howto unter

sdb.univention.de/content/3/119/ … eplikation

vorgegangen. Allerdings lässt sich das auf dem DC erstellte LDIF File nicht auf dem Lenny System importieren. Der Importvorgang bricht mit

bdb_monitor_db_open: monitoring disabled; configure monitor database to enable str2entry: invalid value for attributeType objectClass #2 (syntax 1.3.6.1.4.1.1466.115.121.1.38) slapadd: could not parse entry (line=124)

ab. Die Schema Files sind auf beiden Systemen identisch. Mein Befürchtung ist, das der Fehler auftritt weil auf den Systemen unterschiedliche LDAP-Versionen eingesetzt werden. Das Lennysystem hat openldap-2.4.11. Univention setzt dagegen openldap-2.4.15 ein. Klappt die Sync nur zwischen identischen LDAP-Versionen?

lg
Sebastian

#2

Hallo,

grundsätzlich sollte die Replikation zwischen LDAP-Servern der 2.4er Serie problemlos möglich sein. Ggf. sollten Sie die Konfigurtion sowie die Schema-Dateien des externen Servers noch einmal prüfen und kontrollieren was sich in besagter Zeile 124 befindet.

Mit freundlichen Grüßen
Janis Meybohm

#3

Vielen dank für die Nachricht. In der Zeile befindet sich

dn: cn=default containers,cn=univention,dc=local, .....

ich hab mich gefragt, ob das Leerzeichen zwischen default und containers in Ordnung ist.

#4

Hallo,

das könnten Sie testen indem Sie das Objekt aus dem LDIF entfernen oder versuchen einen Container mit Leerzeichen im Namen direkt im Debian LDAP anzulegen.

Mit freundlichen Grüßen
Janis Meybohm

#5

Egal ob ich das Leerzeichen setze oder nicht, bekomme ich trotzdem die folgende Fehlermeldung:

str2entry: invalid value for attributeType objectClass #2 (syntax 1.3.6.1.4.1.1466.115.121.1.38) slapadd: could not parse entry (line=132)

Ich vermute es hat eher etwas mit den Schemata zu tun. Der Eintrag stammt aus dem core.schema. Das Objekt “default container” scheint zu brauchen:

objectClass: top objectClass: univentionDirectory objectClass: oxDirectory

Allerdings existieren auf beiden Servern die gleichen Schemata. Oder kann man da noch etwas übersehen? Ich hatte die Schema Dateien in einem anderen Verzeichnis und habe sie in /etc/ldap/schema/ verschoben und die slapd.conf angepasst. Leider aber auch ohne Erfolg.

#6

Hallo,

ist die Datei “directory.schema” vorhanden und wird diese korrekt in der slapd.conf inkludiert? Nach der Anleitung sollten die Schemadateien unter “/usr/share/univention-ldap/schema” liegen und von der auf dem UCS System erstellten und kopierten slapd.conf inkludiert werden.

Vor einem erneuten Einspielen, sollte der Inhalt des Verzeichnis “/var/lib/ldap/.” in einen Sicherungsordner verschoben werden.

mkdir /var/tmp/ldap_backup_dir
mv /var/lib/ldap/*.* /var/tmp/ldap_backup_dir

Mit freundlichen Grüssen
Tobias Scherer

#7

Hallo,
nachdem das Projekt der externen LDAP Anbindung bei uns immer wieder verschoben worden ist, habe ich nun endlich Zeit die Sache wieder anzugehen.

Im Prinzip bin ich noch nicht wirklich weitergekommen. Auf dem externen Linux Server (der angebunden werden soll) lässt sich das zuvor vom DC_Master kopierte data.ldif nicht importieren. Ich dachte es könnte daran liegen, das die LDAP Version auf dem Debian Linux Server nicht mehr das slapd.conf File verwendet. Aber laut openldap.org kann man das file explizit angeben. Es erscheint folgende Ausgabe:

slapadd -f /etc/ldap/slapd.conf -l /root/data.ldiff bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2). Expect poor performance for suffix "dc=suffix,dc=der,dc=domain". bdb_monitor_db_open: monitoring disabled; configure monitor database to enable str2entry: invalid value for attributeType objectClass #2 (syntax 1.3.6.1.4.1.1466.115.121.1.38) slapadd: could not parse entry (line=136) _ 0.72% eta 07s elapsed none spd 212.5 k/s Closing DB...

Die Schema Dateien sind alle an der entsprechenden Stelle vorhanden, und werden auch in der slapd.conf referenziert. Kann es sein, das aufgrund von Anpassungen, noch weitere Dateien kopiert werden müssen?

#8

Hallo,

da dieses Thema ja schon etwas älter ist, wären die aktuell eingesetzten Versionen von UCS und Debian interessant.

Mit freundlichen Grüßen
Tobias Scherer

#9

Hallo Herr Scherer,

Es sind UCS 2.4-2-3 und Debian GNU/Linux 6.0.2 (squeeze).

Gruß

#10

Hallo,

der SDB Artikel wurde aktualisiert. Sie sollten diesen erneut durchgehen. Das dort geschilderte Vorgehen ist mit UCS 2.4 und Debian 6 erfolgreich getestet.

Mit freundlichen Grüßen
Tobias Scherer

#11

Danke für die Nachricht.
Aber mir fällt gerade auf: es müsste doch dann im LDAP auch einen entsprechenden rootdn mit dem Namen “cn=update,dc=meine,dc=domain” geben, oder? Denn der wird ja auch wieder in der slapd.conf referenziert. In unserem bisherigen LDAP Auszug existiert dieser dn nämlich nicht …

Grüße

#12

Hallo,

der rootdn “cn=update,dc=meine,dc=domain” muss nur auf dem externen LDAP bestehen und wird hier dazu verwendet um Änderungen in die LDAP Datenbank zu schreiben. Definiert, mit einem Passwort versehen und als updatedn konfiguriert, wird der rootdn in diesem Block der “/etc/ldap/slapd.conf” auf dem externen LDAP Server:

rootdn "cn=update,dc=univention,dc=test" rootpw "REMOTE_UPDATE_PASSWORD" updatedn "cn=update,dc=univention,dc=test"
Details dazu können Sie auch der Man Page entnehmen:

man slapd.conf

Viele Grüße
Tobias Scherer

Mastodon