Full_Name: Matthew Berg
OS: CentOS 6
Submission from: (NULL) (126.96.36.199)
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.
reqMod: contextCSN:= 20170227211132.933390Z#000000#000#000000
reqMod: contextCSN:= 20170302180943.182601Z#000000#001#000000
reqMod: contextCSN:= 20170302175436.282737Z#000000#002#000000
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.
Full_Name: Quanah Gibson-Mount
Submission from: (NULL) (188.8.131.52)
The keepalive parameter to syncrepl was added after the current replication
documents were written, and needs to be added to the admin guide.