LDAP - Replication der accesslog DB

[McAldo]

Ich versuche eine Replikation der accesslog DB auf einen "Consumer" einzurichten.

Das Overlay accesslog ist mit den Standardeinstellungen auf Provider und Consumer aktiviert (Modul auch geladen) und eingerichtet und steht über den DN "cn=accesslog" zur Verfügung. Für die synrepl wird das auch genutzt (also deltasync), was auch funktioniert.

Eine Replication der vorhandenen DB auf einen consumer scheiterte komplett, auch weil alles per onlineconfig administriert wird. Ich habe also auf einem Consumer die Replication von cn=config komplett entfernt und dann eine neue "olcDatabase: hdb" auf Provider und Consumer angelegt. Diese ist nun als cn=accesslogall vorhanden. Im Bereich für die DB, welche alle Userdaten enthält, habe ich ein neues overlay eingefügt, welches Änderungen nach olcAccessLogDB: cn=accesslogrepli schreibt.

Das funktioniert auch soweit alles gut und auf dem Provider wird schön in die neue DB geschrieben.
Auf dem Consumer hab ich syncrepl mit diesem Parametern für diese DB eingerichtet:

Code: Alles auswählen

olcSyncrepl: {0}rid=091 provider=ldap://ldapprovider.lan bindmethod=simple binddn="uid=replic,ou=user,dc=lan" credentials="secret" starttls=yes tls_cacert=/etc/ssl/ca.crt searchbase="cn=accesslogall" type=refreshAndPersist retry="5 10 30 +" scope=sub attrs="*,+"

Starte ich den slapd auf dem Consumer bekomme ich diese Debug-Meldung:

Code: Alles auswählen

do_syncrep2: rid=091 got empty syncUUID with LDAP_SYNC_ADD
do_syncrepl: rid=091 rc -1 retrying (9 retries left)

Ein ldapsearch mit dem repli-User liefert alle Einträge, die Abfrage funktioniert also. Ich stehe jetzt total auf dem Schlauch.

Bei meiner schon langen und bisher nicht sehr erfolgreichen Suche durchs Inet habe ich folgendes gefunden:
http://eole.orion.education.fr/oldwiki/ ... ntr.C3.A9s
http://www.openldap.org/lists/openldap- ... 00191.html

Welche Infos fehlen vielleicht zur Fehleranalyse?

[McAldo]

Die Lösung ist ziemlich einfach, man muss nur drauf kommen.

Wird die DB für das accesslog auf dem "Provider" angelegt, bekommt diese kein Attribut entryUUID. Dieses ist aber erforderlich für die Replikation. Man kann dieses Attribut aber nicht einfach hinzufügen sondern muss die DB exportieren und wieder importieren. Hier die Arbeitsschritte. Angenommen wird, die DB liegt in /var/log/ldap/accesslog und hat den DN: cn=accesslog und LDAP läuft als Online-Config. Alle Arbeitsschritte als root.

Sichern der DB und sofortiges Anhalten des slapd, damit keine neuen Einträge hinzukommen.

Code: Alles auswählen

/usr/sbin/slapcat -b cn=accesslog > /tmp/accesslog.ldif && /etc/init.d/slapd stop

Nun muss der entsprechende Eintrag in die ldif Datei eingefügt werden.

Code: Alles auswählen

vi /tmp/accesslog.ldif

Code: Alles auswählen

dn: cn=accesslog
objectClass: auditContainer
cn: accesslog
entryCSN: 20130410114628.332080Z#000000#000#000000
entryUUID: c1f8c330-0216-1121-83c4-18de2d4e02d5
structuralObjectClass: auditContainer
contextCSN: 20130411074510.732455Z#000000#000#000000

^^^^ Es wurde die Zeile mit entryUUID eingefügt.
Speichern der Datei.

Jetzt muss die DB geleert werden, damit der Import korrekt verläuft.

Code: Alles auswählen

rm -f /var/log/ldap/accesslog/*

Macht man das nicht, fehlt entryUUID nach einem Import weiterhin.

Jetzt erfolgt der Import und anschließend müssen die Berechtigungen wieder für den slapd-User gesetzt werden.

Code: Alles auswählen

/usr/sbin/slapadd -v -c -b cn=accesslog -F /etc/ldap/slapd.d/ -l /tmp/accesslog.ldif && chown -R openldap: /var/log/ldap/accesslog/*

Nun den slapd neu starten, oder erstmal im Konsolen-Debugmodus schauen ob alles läuft:

Code: Alles auswählen

slapd -h "ldap:/// ldaps:///" -u openldap -g openldap -d 256 sync -F /etc/ldap/slapd.d/

Wenn man nun den Consumer startet mit "-d sync", sieht man die Syncronisation und hat im DIT die neue Datenbank stehen.

[McAldo]

Da die Replication der Accesslog-DB auf einen Consumer funktioniert, kommt nun ein neues Problem.

Mittels "logpurge" kann man festlegen, wann Logdaten entfernt werden. Das funktioniert auch auf dem Master. Es wird aber nicht zum Consumer durchgereicht und somit wird die DB dort immer größer.

Dazu habe ich das gefunden: http://www.openldap.org/lists/openldap- ... 00191.html
Leider auch ohne Lösung. Hat hier jemand eine Idee?

[McAldo]

Um die DB-Files von der Platte zu entfernen gibt man im jeweiligen DB-Bereich in der slapd.conf folgende Option an:

Code: Alles auswählen

dbconfig set_flags DB_LOG_AUTOREMOVE

[McAldo]

Einige Links zum Thema:

- http://linuxtechres.blogspot.de/2012/12 ... -file.html

- http://www.openldap.org/lists/openldap- ... 00165.html

- http://www.zytrax.com/books/ldap/ch6/bdb.html