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_modi... 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.