Ok, bad example... Here's another example that's rather different: $ searchn -H ldap://ldapmaster.rutgers.edu uid=XXXX mail createTimestamp modifyTimestamp entryCSN dn: uid=XXXX,ou=People,dc=rutgers,dc=edu createTimestamp: 20180504140010Z mail: xxxxxxxxx.xxxx@rutgers.edu entryCSN: 20180831205041.549496Z#000000#001#000000 modifyTimestamp: 20180831205041Z $ searchn -H ldap://ldapconsumer1.rutgers.edu uid=XXXX mail createTimestamp modifyTimestamp entryCSN dn: uid=XXXX,ou=People,dc=rutgers,dc=edu createTimestamp: 20180504140010Z mail: yyyyy@rutgers.edu entryCSN: 20180831205041.549496Z#000000#001#000000 modifyTimestamp: 20180831205041Z
Hi Dave,That's certainly a more interesting case. Do you know when the discrepancy arose? Clearly the entry was modified on 8/31, but you'd have to parse the accesslog to see what the actual change was that was made to the entry. Generally to track down replication related issues, there are a number of various bits that need to be examined in the logs (provider and consumer) along with the data in the accesslog. One would also need to have knowledge on the version of OpenLDAP that's in use since it may be subject to bugs that could cause such issues (ITS#8444 for example, fixed in 2.4.46).
Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>