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....
@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: conn=1157 op=1 MOD
on the slave I get the same error:
Feb 22 14:34:20 sldap001 slapd: syncrepl_message_to_op: rid=001
mods check (vuGeboorteDatum: multiple values provided)
The accesslog overlay:
reqMod: vuGeboorteDatum:= 07-05-2019
reqMod: vuGeboorteDatum:= 07-05-2020
reqMod: entryCSN:= 20180222133420.216313Z#000000#001#000000
reqMod: modifyTimestamp:= 20180222133420Z
Any news? Or bug the application developper...
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
Morais <matheus_morais(a)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.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: