Hi!
I found this accesslog entry, caused by a server-sync it seems (some strings replaced consistently for privacy): --- dn: reqStart=20200722085045.000019Z,cn=audit objectClass: auditModify structuralObjectClass: auditModify reqStart: 20200722085045.000019Z reqEnd: 20200722085045.000060Z reqType: modify reqSession: 6 reqAuthzID: cn=Admin,dc=example,dc=org reqDN: uid=username,ou=people,dc=example,dc=org reqResult: 0 reqMod: entryCSN:= 20200722082119.640611Z#000000#003#000000 reqMod: modifiersName:= cn=Admin,dc=example,dc=org reqMod: modifyTimestamp:= 20200722082119Z reqOld: entryCSN: 20200722082119.640611Z#000000#003#000000 reqOld: modifiersName: cn=Admin,dc=example,dc=org reqOld: modifyTimestamp: 20200722082119Z reqEntryUUID: 2d063f78-7ced-1032-948d-cf46530da60d entryUUID: 2cefa3e8-6044-103a-8b01-193e5edbb211 creatorsName: cn=audit createTimestamp: 20200722082119Z entryCSN: 20200722082119.640611Z#000000#003#000000 modifiersName: cn=audit modifyTimestamp: 20200722082119Z ---
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?
Regards, Ulrich
--On Thursday, July 23, 2020 3:50 PM +0200 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.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.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 23.07.2020 um 17:02 in
Nachricht <0227636D6C47485709920FC3@[192.168.0.147]>:
‑‑On Thursday, July 23, 2020 3:50 PM +0200 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.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
openldap-technical@openldap.org
-
Quanah Gibson-Mount -
Ulrich Windl