12:02 p.m.
--On Friday, January 06, 2017 6:50 PM +0000 Matheus Eduardo Bonifacio
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.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
12:14 p.m.
New subject: Syncrepl and multipe values
Yes, you're right. I'll try to work on this.
Matheus Eduardo Bonifácio Morais
Analista de Infraestrutura de TI,
Plataforma e Aplicações
Confederação Sicredi
Centro Administrativo Sicredi – Porto Alegre
+55 51 3358 7143
sicredi.com.br
[1474907760585_sicredilogo.png]
________________________________
De: Quanah Gibson-Mount <quanah(a)symas.com>
Enviado: sexta-feira, 6 de janeiro de 2017 18:02:25
Para: Matheus Eduardo Bonifacio Morais; OpenLDAP Technical List
Assunto: Re: Syncrepl and multipe values
--On Friday, January 06, 2017 6:50 PM +0000 Matheus Eduardo Bonifacio
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.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Esta mensagem é somente para uso do destinatário informado e pode conter informações
privilegiadas, proprietárias ou privadas. Se você recebeu esta mensagem por engano, por
favor, notifique o remetente imediatamente e apague a original. Qualquer outro uso deste
e-mail é proibido.
This message is for the designated recipient only and may contain privileged, proprietary,
or otherwise private information. If you have received it in error, please notify the
sender immediately and delete the original. Any other use of the email by you is
prohibited.
8:42 a.m.
New subject: [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(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.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
12:01 p.m.
New subject: Syncrepl and multipe values
--On Thursday, February 22, 2018 5:42 PM +0100 Pascal kolijn
<p.kolijn(a)vu.nl> wrote:
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....
I'm on RHEL7.4 with the openldap provided by RH.(2.4.44-5.el7)
ITS#8559 is a duplicate of ITS#6545, which was fixed in 2.4.45. I've
updated ITS#8559 appropriately.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
2036
days inactive
2450
days old
openldap-technical@openldap.org
3 comments
3 participants
participants (3)
-
Matheus Eduardo Bonifacio Morais -
Pascal kolijn -
Quanah Gibson-Mount