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

Re: [Spam] Re: Syncrepl and multipe values



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