--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
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@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@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.
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
--On Thursday, February 22, 2018 5:42 PM +0100 Pascal kolijn p.kolijn@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
openldap-technical@openldap.org
-
Matheus Eduardo Bonifacio Morais -
Pascal kolijn -
Quanah Gibson-Mount