5:50 a.m.
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
8:02 a.m.
--On Thursday, July 23, 2020 3:50 PM +0200 Ulrich Windl
<Ulrich.Windl(a)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>
11:46 p.m.
New subject: Antw: [EXT] Re: Q about add accesslog entry
>> 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>
1046
days inactive
1047
days old
openldap-technical@openldap.org
2 comments
2 participants
participants (2)
-
Quanah Gibson-Mount -
Ulrich Windl