Hi,
I stumbled on this ticket in openldap ITS (id=8559) and its originating thread on this list) about the duplicate modifies in a single operation and I was somewhat disappointed that there was no solution or patch attached not even a: fixed in upstream, do not use the openldap provided by your distribution....
:o)
@Matheus did you ever find a solution?
I'm having a similar problem that a closed source ldap modifying application is generating such a ldif and breaking my syncrepl to the slaves, but not my master node.
I'm on RHEL7.4 with the openldap provided by RH.(2.4.44-5.el7)
On the Master I see that the ldapserver combines the modify in a single 'op' on the same attribute (independent of its particular value (doesn't have to be a duplicate value)).
Feb 22 14:34:20 mldap001 slapd[29341]: conn=1157 op=1 MOD attr=vuGeboorteDatum vuGeboorteDatum
on the slave I get the same error:
Feb 22 14:34:20 sldap001 slapd[31735]: syncrepl_message_to_op: rid=001 mods check (vuGeboorteDatum: multiple values provided)
The accesslog overlay:
dn: reqStart=20180222133420.000001Z,cn=deltalog objectClass: auditModify reqStart: 20180222133420.000001Z reqEnd: 20180222133420.000002Z reqType: modify reqSession: 1157 reqAuthzID: cn=admin_ldp,dc=vu reqDN: uid=qqq378,ou=people,dc=vu reqResult: 0 reqMod: vuGeboorteDatum:= 07-05-2019 reqMod: vuGeboorteDatum:= 07-05-2020 reqMod: entryCSN:= 20180222133420.216313Z#000000#001#000000 reqMod: modifiersName:=cn=admin_ldp,dc=vu reqMod: modifyTimestamp:= 20180222133420Z reqEntryUUID: 2376636e-aa94-1037-9689-55c62441b105
Any news? Or bug the application developper...
Pascal Kolijn Vrije Universiteit Amsterdam
On 01/06/2017 09:02 PM, Quanah Gibson-Mount wrote:
--On Friday, January 06, 2017 6:50 PM +0000 Matheus Eduardo Bonifacio Morais matheus_morais@sicredi.com.br wrote:
Issue 8559 opened.
I'm trying to work on a patch but I'm not sure if the best solution is to fix accesslog to avoid duplicated values or if the sample LDIF (in its description) should result in a constraint violation. What do you think?
The accesslog should never write an operation that can't be replicated. If the MOD is a valid LDAP operation (which I think it is), then it should be accepted at the frontend. The issue may be more in delta-syncrepl's handling of the write op than anything else.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com