[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#8607) Second master in MMR config logging contextCSN changes to accesslog



Full_Name: Matthew Berg
Version: 2.4.43+
OS: CentOS 6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (38.97.88.240)


While debugging replication issues in a Zimbra installation, I discovered a
significant number of accesslog entries with an empty reqDN and specifying
values for contextCSN; e.g.

dn: reqStart=20170302180943.186147Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20170302180943.186147Z
reqEnd: 20170302180943.190880Z
reqType: modify
reqSession: 100
reqAuthzID: cn=config
reqDN:
reqResult: 0
reqMod: contextCSN:= 20170227211132.933390Z#000000#000#000000
reqMod: contextCSN:= 20170302180943.182601Z#000000#001#000000
reqMod: contextCSN:= 20170302175436.282737Z#000000#002#000000
entryUUID: 27b9f34c-93bf-1036-9636-3fa0e78444ec
creatorsName: cn=config
createTimestamp: 20170302180943Z
entryCSN: 20170302180943.182601Z#000000#001#000000
modifiersName: cn=config
modifyTimestamp: 20170302180943Z

I was able to reproduce this behavior in a test lab with two freshly installed
servers and no existing data.  Given two servers, A and B, a write to A will
result in the expected audit object being written to the access log on A, but
when B applies the change it logs an additional auditModify (likewise B will
cause the same additional entry on A).

This particular environment was running a patched build of 2.4.44.  I audited
our other production environments and did not see the same behavior with prior
builds (primarily 2.4.39).

In order to rule out the possibility that this was introduced by any patched
Zimbra applied I built out a new package from stock OpenLDAP sources and was
able to reproduce with both 2.4.44 and 2.4.43, but not with 2.4.42 and earlier.