[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#6679) syncrepl does not handle modifyTimestamp



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.

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.


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.