Re: (ITS#6679) syncrepl does not handle modifyTimestamp

[jonathan@phillipoux.net]

Le 20/10/2010 14:43, pcernko+openldap@mpi-sws.org a écrit :
> Full_Name: Patrick Cernko
> Version: 2.4.23
> OS: Debian Lenny
> URL: http://www.mpi-inf.mpg.de/~pcernko/syncrepl_does_not_transfer_or_update_modifyTimestamp.tar.bz2
> Submission from: (NULL) (139.19.3.67)
>
>
> Hi OpenLDAP-Programmers,
>
> we discovered a possible bug in the syncrepl code. When objects get modified on
> the master server, all changed get propagated to the slaves. However, the for
> hidden attributes creatorsName, createTimestamp, modifiersName, modifyTimestamp
> seem to be not handled in a reasonable way:
>
> Obviously, the creat* attributes should only be written once (on creation). The
> modif* attributes are set to the same values as their creat* counterparts on
> creating. After replication, all these values can be found on the slave as
> well.
>
> When an object is modified now (for the first time!), the master correctly
> updated the modif* attributes. The slave replicates the modification correctly
> but neither does update the modif* attributes nor replicates their contents from
> the server. Especially the modifyTimestamp attribute does still contain the old
> value (equal to createTimestamp). This is wrong as the object WAS modified
> later.

The syncrepl configuration in your slave.conf file contains "attrs=*".

This configuration explicitly requests synchronizing user attributes 
only. creatorsName, createTimestamp, modifiersName, modifyTimestamp are 
operational attributes and would be synchronized with "attrs=+".

To synchronize all attributes, you should set "attrs=*,+". This is the 
default value, as indicated in the man page slapd.conf(5).

> More interesting, if you do another modification, the master will handle it the
> same way as before, but now, the slave will completely REMOVE the four hidden
> attributes, as you can verify in the slapcat of the slave's database.

The expected result is that operational attributes are not replicated to 
the slave's database. It is however surprising that this behaviour 
varies between replicating an ADD operation and a MODIFY operation...

> To demonstrate and reproduce this behaviour, I have combined a set of files in
> the linked tarball:
>
> Extract to an empty folder, unpack openldap-2.4.23 into it and
> configure-make-make-install it (a suggested configuration can be found in the
> boundled configure.sh). The you can start the master and server with the
> corresponding sh-Scripts.
>
> You can use the following commands to search or slapcat the servers:
> install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL
> modifyTimestamp
> install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/  -b ou=openldap -LLL
> modifyTimestamp
> install/sbin/slapcat -f master.conf
> install/sbin/slapcat -f slave.conf
>
> The mod.py script can be used to trigger a change:
> python mod.py mod-child
>
> Now check the modifyTimestamp on the slave, it is still the old one:
> install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/  -b ou=openldap -LLL
> modifyTimestamp
> install/sbin/slapcat -f slave.conf
>
> After the second modification, the attributes are gone on the slave:
> python mod.py unmod-child
> install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/  -b ou=openldap -LLL
> modifyTimestamp
> install/sbin/slapcat -f slave.conf
>
>
> I would really appreciate a reasonable behaviour for this in the next releases.
> If you have reasons not to REPLICATE but UPDATE the modif* attributes (with the
> replication timestamp instead of the master's one), that's ok, too.
>
> Thanks.


-- 
--------------------------------------------------------------
Jonathan Clarke - jonathan@phillipoux.net
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------