>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am
23.07.2020 um 17:02 in
Nachricht <0227636D6C47485709920FC3(a)[192.168.0.147]>:
‑‑On Thursday, July 23, 2020 3:50 PM +0200 Ulrich Windl
<Ulrich.Windl(a)rz.xn--uniregensburg-dm6g.de> wrote:
> So if I see it correctly, only the entryUUID changed? Actually I wouldn't
> expect the entryUUID to change. Obviously the entry could not have been
> recreated after being deleted, because otherwise some other field would
> have changed, right? Or could this be a late consequence of improper
> slapadd (entryUUIDs not taken from slapcat) long time ago?
Incorrect. What were changed were the "reqMod" attributes (entryCSN,
modifiersname, modifytimestamp). The entryUUID in that entry is for the
accesslogDB, not the primary DB.
Hi Quanah!
It would have been helpful if you quoted the relevant part of the message:
What puzzled me was that entryCSN, modifiersName, and modifyTimestamp were
indicated as changed, but in fact all had the same value as before:
reqOld: entryCSN: 20200722082119.640611Z#000000#003#000000
reqMod: entryCSN:= 20200722082119.640611Z#000000#003#000000
reqOld: modifiersName: cn=Admin,dc=example,dc=org
reqMod: modifiersName:= cn=Admin,dc=example,dc=org
reqOld: modifyTimestamp: 20200722082119Z
reqMod: modifyTimestamp:= 20200722082119Z
So effectively there was virtually no change.
But looking closer, it seems that that particular entry dn:
reqStart=20200722085045.000019Z,cn=audit is a "followp up" for dn:
reqStart=20200722085045.000018Z,cn=audit (only one microsecond earlier) that
actually DID change entryCSN from
20200721064208.377470Z#000000#002#000000 to
20200722082119.640611Z#000000#003#000000 and modifyTimestamp from
20200721064208Z to
20200722082119Z
But even in that entry modifiersName was indicated to be changed when old and
new value were identical.
Could it be that modifiersName is always included in accesslog when any
modification is done? Still it's not obvious why the second entry was created.
Could it be created it there was a sync request, but the server rejected ai as
"already present"?
Actually I found:
slapd[19773]: slap_queue_csn: queueing 0x7f8da011e5e0
20200722082119.640611Z#000000#003#000000
slapd[19773]: slap_graduate_commit_csn: removing 0x7f8da01af550
20200722082119.640611Z#000000#003#000000
slapd[19773]: slap_queue_csn: queueing 0x7f8d9c11e6a0
20200722082119.640611Z#000000#003#000000
slapd[19773]: slap_graduate_commit_csn: removing 0x7f8d9c1135c0
20200722082119.640611Z#000000#003#000000
slapd[19773]: dn_callback : entries have identical CSN
uid=username,ou=people,dc=example,dc=org
20200722082119.640611Z#000000#003#000000
slapd[19773]: syncprov_search_response:
cookie=rid=002,sid=001,csn=20130719093756.074776Z#000000#000#000000;20200702141259.979941Z#000000#001#000000;20200722074119.038113Z#000000#002#000000;20200722082119.640611Z#000000#003#000000
slapd[19773]: do_syncrep2: rid=002
cookie=rid=002,sid=001,csn=20130719093756.074776Z#000000#000#000000;20200702141259.979941Z#000000#001#000000;20200722074119.038113Z#000000#002#000000;20200722082119.640611Z#000000#003#000000
Sorry with the confusion of UUID.
Regards,
Ulrich
‑‑Quanah
‑‑
Quanah Gibson‑Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<
http://www.symas.com>