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> > >
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature