Interesting delta-syncrepl failure

[Francis Swasey]

Platform: Red Hat Enterprise Linux 5, update 5, 64-bit
OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl.

The following modify ldif successfully applies to the master:

dn: uid=fcswasey,ou=People,dc=uvm,dc=edu
changetype: modify
replace: sn
sn: Swasey
-
replace: sn
sn: Swasey
-

In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn"
attribute is presented twice. In OpenLDAP 2.4 -- it works, but the
delta-syncrepl replica pukes on it with this error:

syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more
than once)

If the OpenLDAP 2.4.22 server accepts it, processes it, and feeds it out
-- shouldn't the OpenLDAP 2.4.22 delta-syncrepl consumer eat it without
complaining?

[Quanah Gibson-Mount]

--On Wednesday, May 05, 2010 10:31 AM -0400 Francis Swasey

Post by Francis Swasey
In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn"
attribute is presented twice. In OpenLDAP 2.4 -- it works, but the
syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more
than once)
If the OpenLDAP 2.4.22 server accepts it, processes it, and feeds it out
-- shouldn't the OpenLDAP 2.4.22 delta-syncrepl consumer eat it without
complaining?

There's definitely something wrong here, yes. I suggest you file an ITS.
Either 2.4 shouldn't have taken the change, or the accesslog should have
written it in a way the replica would accept.

--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration

[Matheus Morais]

I'm having the same issue here. There are some news on this subject?

Thanks,

Matheus Morais

--On Wednesday, May 05, 2010 10:31 AM -0400 Francis Swasey <
In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn"

Post by Francis Swasey
attribute is presented twice. In OpenLDAP 2.4 -- it works, but the
syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more
than once)
If the OpenLDAP 2.4.22 server accepts it, processes it, and feeds it out
-- shouldn't the OpenLDAP 2.4.22 delta-syncrepl consumer eat it without
complaining?

There's definitely something wrong here, yes. I suggest you file an ITS.
Either 2.4 shouldn't have taken the change, or the accesslog should have
written it in a way the replica would accept.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration