Ldap replikation failed

Hallo,

der listener schreit auf allen Servers:

18.07.13 08:38:00.320 LISTENER ( INFO ) : notifier returned = id: 4340 dn: <A8>>=<B5><FC>^? cmd: 18.07.13 08:38:00.320 LISTENER ( INFO ) : updating <A8>>=<B5><FC>^? 18.07.13 08:38:00.321 LISTENER ( ERROR ) : change_update_dn: Invalid DN syntax

Wenn ich mir “/var/lib/univention-ldap/notify/transaction” anschaue, so finde ich immer wieder:

4337 cn=USER-PC,cn=computers,dc=evsteam,dc=local m 4338 cn=Windows Hosts,cn=groups,dc=evsteam,dc=local m 4339 cn=USER-PC,cn=computers,dc=evsteam,dc=local m 4340 <A8>>=<B5><FC>^? <-------------- -101184 <A8>>=<B5><FC>^? a <------------------ 4341 cn=user-pc,cn=computers,dc=evsteam,dc=local m 4342 relativeDomainName=ADMINISTRATOR,zoneName=evsteam.local,cn=dns,dc=evsteam,dc=local a 4343 cn=user-pc,cn=computers,dc=evsteam,dc=local m 4344 cn=user-pc,cn=computers,dc=evsteam,dc=local m 4345 cn=1186,cn=uidNumber,cn=temporary,cn=univention,dc=evsteam,dc=local a 4346 cn=1186,cn=uidNumber,cn=temporary,cn=univention,dc=evsteam,dc=local d 4347 cn=1187,cn=uidNumber,cn=temporary,cn=univention,dc=evsteam,dc=local a 4348 cn=uidNumber,cn=temporary,cn=univention,dc=evsteam,dc=local m 4349 cn=1187,cn=uidNumber,cn=temporary,cn=univention,dc=evsteam,dc=local d 4350 cn=VERKAUFPC1-PC$,cn=uid,cn=temporary,cn=univention,dc=evsteam,dc=local a 4351 cn=VERKAUFPC1-PC,cn=computers,dc=evsteam,dc=local a 4352 cn=VERKAUFPC1-PC$,cn=uid,cn=temporary,cn=univention,dc=evsteam,dc=local d 4353 cn=VERKAUFPC1-PC,cn=computers,dc=evsteam,dc=local m 4354 cn=VERKAUFPC1-PC,cn=computers,dc=evsteam,dc=local m 4355 cn=Windows Hosts,cn=groups,dc=evsteam,dc=local m 4356 cn=VERKAUFPC1-PC,cn=computers,dc=evsteam,dc=local m 4357 relativeDomainName=VERKAUFPC1-PC,zoneName=evsteam.local,cn=dns,dc=evsteam,dc=local a 4358 <A8>>=<B5><FC>^? -102164 <88>@=<B5><FC>^? a 4359 cn=verkaufpc1-pc,cn=computers,dc=evsteam,dc=local m 4360 cn=verkaufpc1-pc,cn=computers,dc=evsteam,dc=local m 4361 cn=verkaufpc1-pc,cn=computers,dc=evsteam,dc=local r 4362 cn=VERKAUFPC1-PC,ou=evs benutzer,dc=evsteam,dc=local a 4363 cn=Windows Hosts,cn=groups,dc=evsteam,dc=local m 4364 cn=verkaufpc1-pc,ou=evs benutzer,dc=evsteam,dc=local r 4365 cn=VERKAUFPC1-PC,ou=evs computer,dc=evsteam,dc=local a

Weiß man, woher “diese Zeichen” herkommen, diese erscheinen immer wieder in der transaction-log auf…

[code]root@evsserver:~# ucr search ^version
version/erratalevel: 130
Errata patchlevel of the UCS version

version/patchlevel: 1
Patchlevel of the UCS version

version/releasename: Findorff
Codename for UCS releases

version/security-patchlevel:
Security patchlevel of the UCS version

version/version: 3.1
Major version of UCS[/code]

lG

Hallo,

seit wann “schreit” es denn? Ist mit dem Master LDAP irgendwas passiert, so daß er jetzt solchen Eintrag replizieren will?

Tauchen diese Zeichen noch mehrere Male auf (im Zitat oben sind es die IDs 4340 und 4358, sind das alle)?

Gibt es (wodurch auch immer) im LDAP einen solchen Eintrag (in /var/backups in den slapd-Sicherungen schauen)? Wurde mit der LDAP Backend Datenbank irgendwas gemacht oder beobachtet? (Hardware defekt, Platte voll o.ä.)

Wenn es nur ums Beheben geht: die Transaktionsdatei an den entsprechenden Stellen editieren (vorher Listener/Notifier anhalten) und sinnvolle Transaktionseinträge rein schreiben, danach müssen die Systeme neu gejoint werden, bei denen die Replikation außer Tritt gekommen ist.

Gruß
Frank Greif.

Hallo,

Listener schreit seit 11.6.

Ja, ganze 4x (~alle 30 Zeilen).

Eigentlich ist gar nichts am System passiert, auch Updates wurden keine Installiert…
slapcat bzw. die ldap-backups enthalten diese Zeichen auch nicht, daher frage ich mich, woher diese kommen?

1.) Ich werde in einem Wartungsfenster ein “slapcat” durchführen, ldap vom master löschen, und das slapcat via slapadd wieder importieren.
2.) transkationseinträge sinnvoll befüllen
3.) Slave neu joinen.

Danke!

Und leider schon wieder das Problem.
Besteht die Möglichkeit, irgendwelche Log- Files hochzudrehen?

Ich werde fürs erste mal das autidlog Modul im slapd einbinden, damit kann ich schon mal jede Änderung im LDAP protokollieren lassen…

Hallo,

mal angenommen, das Problem ist durch Sonderzeichen verursacht, die in der Synchronisationskette falsch konvertiert wurden, könnte man versuchen, sich den zeitlichen Beginn des Problems im Listener-Log herauszusuchen und zu schauen, ob ggf. kurz vorher etwas im connector-s4.log passiert ist.

Viele Grüße,
Dirk Ahrnke

[quote=“DBGTMaster”]
Ich werde fürs erste mal das autidlog Modul im slapd einbinden, damit kann ich schon mal jede Änderung im LDAP protokollieren lassen…[/quote]

Hab gerade noch den Hinweis auf das UCS-Handbuch Revisionssichere LDAP-Protokollierung bekommen. Hiermit nachgereicht.

So, Problem besteht wieder, diesmal mit etwas mehr Informationen.

Im transaction Log steht:

4933 cn=NBPFRIEMER2$,cn=uid,cn=temporary,cn=univention,dc=tttteam,dc=local d 4934 cn=NBPFRIEMER2,cn=computers,dc=tttteam,dc=local m 4935 cn=NBPFRIEMER2,cn=computers,dc=tttteam,dc=local m 4936 cn=Windows Hosts,cn=groups,dc=tttteam,dc=local m 4937 cn=NBPFRIEMER2,cn=computers,dc=tttteam,dc=local m 4938 ¨þw^G<85>^? ^M -102165 ¨þw^G<85>^? a 4939 cn=nbpfriemer2,cn=computers,dc=tttteam,dc=local m 4940 relativeDomainName=NBPfriemer2,zoneName=tttteam.local,cn=dns,dc=tttteam,dc=local a 4941 cn=nbpfriemer2,cn=computers,dc=tttteam,dc=local m 4942 cn=Domain Computers,cn=groups,dc=tttteam,dc=local m 4943 cn=desk1,ou=ttt computer,dc=tttteam,dc=local d 4944 cn=Windows Hosts,cn=groups,dc=tttteam,dc=local m

In der audit Log ist zu Eintrag 4938 folgender Eintrag zu finden:

[code]# add 1391613582 dc=tttteam,dc=local cn=admin,dc=tttteam,dc=local IP=192.168.0.11:40897 conn=9826389
dn: cn=S-1-5-21-2571874275-507096557-1054715309
-102165,cn=sid,cn=temporary,cn=univention,dc=tttteam,dc=local
changetype: add
objectClass: top
objectClass: lock
lockTime: 1391613882
cn:: Uy0xLTUtMjEtMjU3MTg3NDI3NS01MDcwOTY1NTctMTA1NDcxNTMwOQ0KLTEwMjE2NQ==
structuralObjectClass: lock
entryUUID: ae873a66-22c4-1033-80f7-9b63f68c2088
creatorsName: cn=admin,dc=tttteam,dc=local
createTimestamp: 20140205151942Z
entryCSN: 20140205151942.427566Z#000000#000#000000
modifiersName: cn=admin,dc=tttteam,dc=local
modifyTimestamp: 20140205151942Z

end add 1391613582[/code]

Besteht das Problem vielleicht im Zeilenumbruch der DN im auditlog?
Wenn man das genau betrachtet:
auditlog:

[quote]dn: cn=S-1-5-21-2571874275-507096557-1054715309
-102165,cn=sid,cn=temporary,cn=univention,dc=tttteam,dc=local[/quote]
transaction:

[quote]4938 ¨þw^G<85>^? ^M
-102165 ¨þw^G<85>^? a[/quote]

Folgender ldapmodify funktioniert aber problemlos (in der dritten Zeile musste ich zu Beginn eine Leertaste anfügen):

[code]# add 1391613582 dc=evsteam,dc=local cn=admin,dc=evsteam,dc=local IP=192.168.0.11:40897 conn=9826389
dn: cn=S-1-5-21-2571874275-507096557-1054715319
-102165,cn=sid,cn=temporary,cn=univention,dc=evsteam,dc=local
changetype: add
objectClass: top
objectClass: lock
lockTime: 1391613882
cn:: Uy0xLTUtMjEtMjU3MTg3NDI3NS01MDcwOTY1NTctMTA1NDcxNTMwOQ0KLTEwMjE2NQ==

end add 1391613582

[/code]

lG

Hallo,

Das ist ja schon mal ein Fortschritt… irgendwas zerhaut diesen DN. Der DN von veränderten Objekten ist auch das einzige, was zwischen Notifier und Listener übertragen wird. Ich würde mal glauben, im Master-LDAP ist der Eintrag [quote]dn: cn=S-1-5-21-2571874275-507096557-1054715309-102165,cn=sid,cn=temporary,cn=univention,dc=tttteam,dc=local[/quote] ganz normal vorhanden und auch wieder ordentlich gelöscht worden (es handelt sich um ein Objekt, das nur für die Dauer bestimmter UDM-Transaktionen angelegt und am Ende wieder gelöscht wird).

Wenn es so ist, daß der Fehler auf allen Servern erscheint, die ein LDAP-Replikat erhalten, würde ich eher zuerst auf dem Master suchen, also ob es nicht bereits der Notifier ist, der den DN falsch übermittelt. Was waren die letzten Updates, die auf dem Master am oder vor dem 11.06. eingespielt wurden? Errata 130 (UCS 3.1) ist vom 17. Mai, da wurden auch LDAP Pakete aktualisiert, allerdings nur die vom LDAP selbst (slapd, libldap, libldap2-dev und ldap-utils) aber keine Univention-Pakete.

Mein Testsystem ist bereits auf 3.2 aktualisiert, da hab ich testweise mal ein Objekt mit einem entsetzlich langen DN erzeugt, dabei ist allerdings kein Fehler aufgetreten, weder beim Notifier noch bei einem der Listener.

viele Grüße
Frank Greif.

Hallo,

ich habe (meiner Meinung nach) das selbe Problem wie DBGTMaster und das Problem tritt auch wieder am selben Server auf. Leider habe ich in diesem Beitrag keine Lösung gefunden bzw. würde auch gerne die root-Cause des Problems herausfinden.

Zum Problem: seit dem 13.10.2014 geht die Replikation nicht mehr wegen einer invalid DN syntax:

04.11.14 17:00:39.857 LISTENER ( ERROR ) : change_update_dn: Invalid DN syntax 04.11.14 17:00:39.857 LISTENER ( ERROR ) : listener: 34

In /var/lib/univention-ldap/notify/transaction sehe ich wieder einen Eintrag, der meiner Meinung nach das Problem verursacht:

5486 cn=NBHANS,cn=computers,dc=tttteam,dc=local m 5487 <A8>^<D7>r<C1>^? -102168 <A8>^<D7>r<C1>^? a 5488 cn=nbhans,cn=computers,dc=tttteam,dc=local m

Der Eintrag dazu im ldap Log sieht folgendermaßen aus:

# add 1413213904 dc=tttteam,dc=local cn=admin,dc=evsteam,dc=local IP=192.168.0.11:52764 conn=60906626
dn: cn=S-1-5-21-2571874275-507096557-1054715309
-102168,cn=sid,cn=temporary,cn=univention,dc=tttteam,dc=local
changetype: add
objectClass: top
objectClass: lock
lockTime: 1413214204
cn:: Uy0xLTUtMjEtMjU3MTg3NDI3NS01MDcwOTY1NTctMTA1NDcxNTMwOQ0KLTEwMjE2OA==
structuralObjectClass: lock
entryUUID: d999fdae-e738-1033-8807-01979fa94be2
creatorsName: cn=admin,dc=tttteam,dc=local
createTimestamp: 20141013152504Z
entryCSN: 20141013152504.217604Z#000000#000#000000
modifiersName: cn=admin,dc=tttteam,dc=local
modifyTimestamp: 20141013152504Z
# end add 1413213904

Ich sehe den Lock auch mittels udm:

# udm settings/lock list <snip> DN: cn=S-1-5-21-2571874275-507096557-1054715309 -102168,cn=sid,cn=temporary,cn=univention,dc=tttteam,dc=local ARG: None locktime: 1413214204 name: S-1-5-21-2571874275-507096557-1054715309 -102168

Zur Lösung der Problems denke ich mal sollte man ein slapcat am Master machen, die LDAP-DB am Slave wegwerfen und dem LDAP-Dump wieder einspielen (zumindest würde ich dies so auf nem “normalen” OpenLDAP so machen), oder gibt es hier eine andere Lösung (z.B. kann ich einen Eintrag von der Replikation ausnehmen - also den Problematischen nicht replizieren)?

Was mir absolut komisch vorkommt ist die Tatsache, dass die DNs sowie der name (im udm settings/lock list) einen Zeilenumbruch hat. Ich gehe mal davon aus, dass es sich hier um einen Fehler handelt? Hat hier jemand eine Idee wie ich das weiter Troubleshooting könnte?

Danke,
René

Ein slapcat scheint mir da wenig sinnvoll zu sein, u.a. da der lokale LDAP von SDCs soviel ich weiß nicht den vollständigen LDAP-Baum der Domain enhält.
Ich würde es daher mit einem rejoin versuchen, würde aber vorher die Meinung von jemand andaren abwarten.

Hallo,

Danke für die Information.
Bei einem Rejoin werden doch ebenfalls die LDAP-Einträge des Masters auf den Backup gesynct. Funktioniert dies nicht über den Listener? Wenn über den Listener wird das Problem aber das Selbe sein, dass der Eintrag nicht gesynct werden kann, oder?

Danke,
René

Also ich weiß nicht wie es tatsächlich funktioniert, aber ich vermute, daß es beim join über einen anderen Mechanismus funktioniert. Denn beim initialen Join soll ja erstmal nur der LDAP befüllt werden. Der Notifier-Mechanismus ist meinem Verständnis dafür da, daß darüber dann die Objekte erkannt werden können, die sich verändert haben, damit diese wiederum übernommen werden können.

Hallo,

auch die initiale Synchronisation wir über das “replication” Listener-Modul abgehandelt.
Wenn es auf dem System immer wieder zu solchen Problemen kommt würde ich versuchen die Daten aus dem LDAP einmal mit “slapcat” auszulesen. Den Dump kann man dann evtl. manuell korrigieren (sollten da wirklich Zeilenumbrüche in DNs sein, Bitte beachten, dass “ldapsearch” Ausgaben standardmäßig auch umgebrochen werden) und anschließend wieder einspielen. Danach sollten alle weiteren Systeme natürlich neu gejoint werden.

Ich habe das natürlich nicht getestet, auch ist mir nicht bekannt, dass wir sowas schon mal in einer Umgebung gesehen haben.

Mit freundlichen Grüßen
Janis Meybohm

Herzlichen Dank für die Antwort.
Ich werde dies Anfang Dezember im Wartungsfenster testen.

Danke,
René

Kurz der Vollständigkeit halber: Im Support wurde festgestellt, dass die SambaSID des Domänenobjekts im Mai 2013 geändert wurde und auf einen Carriage Return endet.
So wurde bei jeder SID-Vergabe ein Zeilenumbruch übergeben.

Mit freundlichen Grüßen,
Tim Petersen

Mastodon