Antw: Re: Replication issue? Data is different between master and consumer with same entryCSNs

["Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>]

>>> Dave Steiner <steiner@rutgers.edu> schrieb am 07.09.2018 um 21:10 in Nachricht
<44b66794-4e1b-8de1-57f3-55f280c85358@oit.rutgers.edu>:

> On 9/7/2018 12:59 PM, Quanah Gibson-Mount wrote:
>> --On Thursday, September 06, 2018 5:43 PM -0400 Dave Steiner 
>> <steiner@rutgers.edu> wrote:
>>
>>> 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
> 
> Hi Quanah,
> 
> We are running 2.4.44 so there maybe something fixed between that and the 
> latest 
> version....
> 
> So I've look at the ldap_audit.log and this person initially set their mail 
> attribute at 20180813215911Z and then changed it to a more readable version 
> at 
> 20180813220044Z.  This makes sense given our account activation flow for new 
> 
> students.  So it seems that the second change didn't get out to the 
> particular 
> consumer. Unfortunately this is long enough ago that it won't be in the 
> accesslog or in the ldap_access.log files on the consumers.  I'll see if I 
> can 
> find a more recent case.

Hi!

What comes to my mind is this: For the email example the CSN does not necessarily refect the cange of the emmail attribute, especially if you are using password policy. Maybe the incorrect sync happened in the past with a buggy version of OpenLDAP?

Regards,
Ulrich

> 
> I checked all 13 of our consumers and while the modifyTimestamp and entryCSN 
> are 
> all consistent with the master(s), the mail attribute was not updated on 3 
> of 
> the consumers.  It's correct on the other 10.
> 
> Thanks for all your help,
> ds