openldap-bugs March 2013

openldap-bugs@openldap.org

24 participants
63 discussions

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hyc＠symas.com 14 Mar '13

14 Mar '13

Marc Patermann wrote: > Howard, > > hyc(a)symas.com schrieb (14.03.2013 15:14 Uhr): >> hans.moser(a)ofd-z.niedersachsen.de wrote: > >>> I think we had situations like this before... >>> >>> How about having a test for this? >>> What is the test which is nearest to this situation where a test could >>> be based on? >> >> test045. Feel free to submit patches for this test script. > If I'm not mistaken, > - in lines 262-264 the consumer is stopped > - in lines 266-284 changes are made to the provider > - in lines 286-294 the consumer is started again. Sounds reasonable but your line numbers don't match anything in our tree. Please send an actual patch, e.g. from git format-patch (or just diff -u.) > > But the changes do > - delete cn=Rosco P. Coltrane, ou=Retired, ou=People, dc=example,dc=com > (lines 269-270) > - modify cn=Bjorn Jensen, ou=Information Technology Division, ou=People, > dc=example,dc=com (lines 272-275) > - add cn=Rosco P. Coltrane, ou=Retired, ou=People, dc=example,dc=com > _again_ (lines 277-282) > So while the consumer is down Coltrane is deleted and added again. > We miss a scenario where an object is still deleted, when the consumer > is back again. > > There is no object, which is not used later on, so we should add a new > object first: > > (before line 239) > > dn: cn=Invisible Man, ou=Information Technology Division, ou=People, > dc=example,dc=com > changetype: add > objectclass: OpenLDAPperson > cn: Invisible Man > sn: Man > uid: invisibleman > description: Ghost > > And delete the object while the consumer is down: > > (before line 284) > > dn: cn=Invisible Man, ou=Information Technology Division, ou=People, > dc=example,dc=com > changetype: delete > > > That would do, I think. > > > Sorry for not patching it myself, I'm not too familiar with it. > > > Marc > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hans.moser＠ofd-z.niedersachsen.de 14 Mar '13

14 Mar '13

Howard, hyc(a)symas.com schrieb (14.03.2013 15:14 Uhr): > hans.moser(a)ofd-z.niedersachsen.de wrote: >> I think we had situations like this before... >> >> How about having a test for this? >> What is the test which is nearest to this situation where a test could >> be based on? > > test045. Feel free to submit patches for this test script. If I'm not mistaken, - in lines 262-264 the consumer is stopped - in lines 266-284 changes are made to the provider - in lines 286-294 the consumer is started again. But the changes do - delete cn=Rosco P. Coltrane, ou=Retired, ou=People, dc=example,dc=com (lines 269-270) - modify cn=Bjorn Jensen, ou=Information Technology Division, ou=People, dc=example,dc=com (lines 272-275) - add cn=Rosco P. Coltrane, ou=Retired, ou=People, dc=example,dc=com _again_ (lines 277-282) So while the consumer is down Coltrane is deleted and added again. We miss a scenario where an object is still deleted, when the consumer is back again. There is no object, which is not used later on, so we should add a new object first: (before line 239) dn: cn=Invisible Man, ou=Information Technology Division, ou=People, dc=example,dc=com changetype: add objectclass: OpenLDAPperson cn: Invisible Man sn: Man uid: invisibleman description: Ghost And delete the object while the consumer is down: (before line 284) dn: cn=Invisible Man, ou=Information Technology Division, ou=People, dc=example,dc=com changetype: delete That would do, I think. Sorry for not patching it myself, I'm not too familiar with it. Marc

1 0

Re: (ITS#7528) ldapadd not working while adding attribute having long list of values
by hyc＠symas.com 14 Mar '13

14 Mar '13

omkar(a)mithi.com wrote: > Full_Name: Omkar Phadke > Version: 2.4.30 > OS: Red Hat Enterprise Linux Server release 6.0 (Santiago) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (115.111.211.142) > > > I am trying to add bellow ldif file. Read the ldif(5) manpage. You appear to have line breaks in the data which breaks the format. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hyc＠symas.com 14 Mar '13

14 Mar '13

hans.moser(a)ofd-z.niedersachsen.de wrote: > Hi, > > jsynacek(a)redhat.com schrieb (27.02.2013 12:25 Uhr): > >> The setup is a master with an ldap backend and a slave consumer. If the master >> is running and slave is not, delete operation results in the master being >> stuck. A patch for this is now in git master, please test. > I think we had situations like this before... > > How about having a test for this? > What is the test which is nearest to this situation where a test could > be based on? test045. Feel free to submit patches for this test script. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hans.moser＠ofd-z.niedersachsen.de 14 Mar '13

14 Mar '13

Hi, jsynacek(a)redhat.com schrieb (27.02.2013 12:25 Uhr): > The setup is a master with an ldap backend and a slave consumer. If the master > is running and slave is not, delete operation results in the master being > stuck. I think we had situations like this before... How about having a test for this? What is the test which is nearest to this situation where a test could be based on? Marc

1 0

Re: (ITS#7538) mdb_add: txn_commit failed : MDB_PAGE_FULL: Internal error - page has no more space
by hyc＠symas.com 12 Mar '13

12 Mar '13

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.34 > OS: linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.196.25.250) > > > 2.4.34 + d74330128ac0c5b1ba3a06a199238f9780f685fd This bug was caused by the above patch for ITS#7536. Since it is now resolved, I'm closing this ITS, it should not have been tracked separately. > > Seeing the following when writing to MDB under load: > > Mar 11 10:49:57 zqa-376 slapd[22478]: mdb_add: txn_commit failed : > MDB_PAGE_FULL: Internal error - page has no more space (-30786) > > I do not see this error in a build of RE24 that has everything in 2.4.34 except > 1f7b6c1199ccb986a240871a8b54f5dc9041136d > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7538) mdb_add: txn_commit failed : MDB_PAGE_FULL: Internal error - page has no more space
by quanah＠zimbra.com 11 Mar '13

11 Mar '13

--On Monday, March 11, 2013 6:02 PM +0000 quanah(a)OpenLDAP.org wrote: Another side effect -- DB entries are being created out of order, meaning slapcat dumps are not loadable via ldapadd. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7539) Bug in JLDAP LDAPAttributeSchema.java code
by maleks＠gmail.com 11 Mar '13

11 Mar '13

Full_Name: Aleksandar M. Version: JLDAP OS: Windows 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.73.228.218) Hello, This is not a bug in OpenLDAP but in the Java client library, JLDAP. The LDAPAttributeSchema.java file is not parsing attributes correctly. The issue is in the method: public LDAPAttributeSchema(String raw) It doesn't set the usage and collective fields when using that method. The fix is to add the following code: this.usage = parser.getUsage(); this.collective = parser.getCollective(); I have added it and uploaded the changed file to the incoming directory. The file is named AleksandarM-LDAPAttributeSchema-20130311.java

1 0

(ITS#7538) mdb_add: txn_commit failed : MDB_PAGE_FULL: Internal error - page has no more space
by quanah＠OpenLDAP.org 11 Mar '13

11 Mar '13

Full_Name: Quanah Gibson-Mount Version: 2.4.34 OS: linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) 2.4.34 + d74330128ac0c5b1ba3a06a199238f9780f685fd Seeing the following when writing to MDB under load: Mar 11 10:49:57 zqa-376 slapd[22478]: mdb_add: txn_commit failed : MDB_PAGE_FULL: Internal error - page has no more space (-30786) I do not see this error in a build of RE24 that has everything in 2.4.34 except 1f7b6c1199ccb986a240871a8b54f5dc9041136d

1 0

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by jsynacek＠redhat.com 11 Mar '13

11 Mar '13

On 03/02/2013 02:59 AM, hyc(a)symas.com wrote: > jsynacek(a)redhat.com wrote: >> On 02/27/2013 02:48 PM, jsynacek(a)redhat.com wrote: >>> On 02/27/2013 12:25 PM, jsynacek(a)redhat.com wrote: >>>> Full_Name: Jan Synacek >>>> Version: RE24 (7b03a58) >>>> OS: Linux - Fedora 18 >>>> URL: ftp://ftp.openldap.org/incoming/jsynacek-reproducer.tar.gz >>>> Submission from: (NULL) (209.132.186.34) >>>> >>>> >>>> The setup is a master with an ldap backend and a slave consumer. If the master >>>> is running and slave is not, delete operation results in the master being >>>> stuck. >>>> >>>> Steps to reproduce: >>>> 1. Start master. >>>> 2. Add the example ldif. >>>> 3. Delete one of the test org units. >>>> 4. Observe the error. >>>> >>>> I would expect the master to honor the retry setting. >>>> >>> >>> During the reproduction, it may be necessary to first have both master and slave >>> running, delete a testing test org unit (so the first replication is >>> successful), stop the slave and then continue to step 3. >>> >> >> URL: >> ftp://ftp.openldap.org/incoming/jsynacek-20130103-syncrepl-retry.patch > > This patch is clearly unacceptable. Your goto obviously skips over two _free() > invocations, thus introducing a memory leak. > I'm sorry that I didn't notice this before sending the patch. New URL: ftp://ftp.openldap.org/incoming/jsynacek-20130311-syncrepl-retry.patch -- Jan Synacek Software Engineer, Red Hat

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2013