openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

Re: (ITS#7109) Slapd Freezing
by quanah＠zimbra.com 12 Dec '11

12 Dec '11

--On Saturday, December 10, 2011 7:07 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Unfortunately OpenLDAP installation strips debugging symbols by default, > which makes backtraces nearly useless. You can prevent that by > configuring with > ./configure --enable-memberof ac_cv_prog_STRIP=: You can also do it at install time by simply typing: make install STRIP="" --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

Re: (ITS#7050) meta stop at the first unreachable candidate
by hyc＠symas.com 12 Dec '11

12 Dec '11

llg(a)portaildulibre.fr wrote: > Does anybody knows if and when this patch will be included in future > versions ? No, the patch is wrong. A new fix is in git master now. -- -- 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#7109) Slapd Freezing
by h.b.furuseth＠usit.uio.no 10 Dec '11

10 Dec '11

nikolay.bogdanov(a)flant.ru writes: > Version: 2.4.23 > (...) What can you advice for us? Upgrade, building from the source at www.openldap.org. There are several possibly-related bugfixes since 2.4.23. Then report back whether nor not that fixed the problem. If it is: > And what information should we provide to solve this problem? (strace, gdb > log, db_stat or something else?) Server log from slapd, and gdb 'thread apply all backtrace'. Unfortunately OpenLDAP installation strips debugging symbols by default, which makes backtraces nearly useless. You can prevent that by configuring with ./configure --enable-memberof ac_cv_prog_STRIP=: -- Hallvard

1 0

(ITS#7109) Slapd Freezing
by nikolay.bogdanov＠flant.ru 10 Dec '11

10 Dec '11

Full_Name: Nikolay Bogdanov Version: 2.4.23 OS: Debian/Ubuntu URL: ftp://ftp.openldap.org/incoming/sysinfo.txt Submission from: (NULL) (95.221.182.198) Dear ñolleagues, We used open ldap for three years. But some weeks ago we disided to restructurate our LDAP server. We did it, but there are a lot of users in the company. So we enabled the "rwm" overlay and added "oldDn" field in a schema. Futhermore, we use "memberof" overlay. As a result users can bind with their old dn. But after that slapd stops with deadlock everyday. What can you advice for us? And what information should we provide to solve this problem? (strace, gdb log, db_stat or something else?) With best regards, Nikolay Bogdanov. CJSC Flant.

1 0

Re: (ITS#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hume-ol＠bofh.ca 09 Dec '11

09 Dec '11

I have reproduced the problem on 2.4.27. The mentioned ldapsearch query seems to have a high probability of success if run immediately after server start, which also seems true on 2.4.28. I threw in an extra Debug() line and op->op_protocol == 2 at the check. I'm rebuilding with as many debugging symbols enabled as possible to try to figure out what's going on.

1 0

Re: (ITS#7050) meta stop at the first unreachable candidate
by llg＠portaildulibre.fr 09 Dec '11

09 Dec '11

Does anybody knows if and when this patch will be included in future versions ? Thanks llg

1 0

Re: (ITS#7104) refreshOnly syncrepl out of sync during bulk update/delete operations
by hyc＠symas.com 08 Dec '11

08 Dec '11

mkrz(a)free.fr wrote: > Full_Name: Martin Krzaczek > Version: 2.4.28 > OS: CentOS 5.7 > URL: > Submission from: (NULL) (83.202.204.201) > > > Hello, > > I noticed an issue with "refreshOnly" syncrepl when a large number of records is > added, updated and deleted. At the end of synchronization the contextCSN is > equal on all servers, but the data is out of synchronization for some deleted > records that remains undeleted on consumer/slave servers. > > Restarting the consumer or forcing a synchronization with "slapd ... -c > 'rid=1,csn=0' " does not help. This appears to caused by the sessionlog overflowing due to incoming modifies that occur after the refresh operation has begun. I would call this a misconfigured server, since the sessionlog can only ever be useful if you size it large enough to accomodate all of your update traffic. I don't have any plans to fix this issue; fix the server configuration. > > A similar issue was submitted few weeks ago (ITS#7052), but I'm not sure the > problem is the same. > > My configuration : > - CentOS 5.7 + OpenLDAP 2.4.28 + BDB 5.1.29 > (the same issue occurs with CentOS 5.7 + OpenLDAP 2.4.26 + BDB 5.1.25) > - one main provider where all modification operations are performed > - one 'first level' consumer synchronizing data on the main provider > and providing data for 'second level' consumers > - one 'second level' consumer synchronizing data on the 'first level' > consumer/provider > > I tried several combinations of configurations (refreshOnly/refreshAndPersist, > syncprov-sessionlog) and noticed that when refreshOnly mode is used, some > records may be not deleted on consumer/slave servers. The number of undeleted > records varies depending on the configuration. > So with a higher value of "syncprov-sessionlog" (for example 5000 instead of > 500) the number of lost records is reduced. > > I have an application that sequentially (i.e. in a single thread) adds about > 12000 records, modifies about 25000 records and deletes about 1000 records. > Add/update/delete operations are mixed i.e. it is possible a have sequences such > as add/add/delete/update/update/update/delete/add/... > > With a small amount of records to add/update/delete the synchronization properly > works without any data loss. > So it seams that if all modifications may be cached and transmitted to consumers > then deleted records are not lost. > There is no data loss for added and updated records whatever is the number of > operations. > > > Regards, > Martin > > > -- -- 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#7108) syncrepl loses updates when replica is down
by hyc＠symas.com 08 Dec '11

08 Dec '11

ml+openldap(a)esmtp.org wrote: > Full_Name: Claus Assmann > Version: 2.4.28 > OS: Red Hat Enterprise Linux Server release 5.3 > URL: ftp://ftp.openldap.org/incoming/claus-assmann-111208.patch > Submission from: (NULL) (63.211.143.38) > > > This is a followup to ITS 7037 which has been fixed in 2.4.28. > It is the same setup and test -- I've uploaded a "patch" that > includes the test program (sorry if it doesn't follow all > the OpenLDAP conventions, I hope it is sufficient to reproduce > the problem). > > It looks like some changes to the OpenLDAP master are not transferred to the > replica (the test prg demonstrates that). > > Note: in my test runs it doesn't always fail, but almost all the time. > > Please let me know whether my test is broken or whether there is a problem in > slapd. I would consider this test invalid. You're deleting the replica database while the consumer is still running. The slapd consumer code assumes that it is the only thing that can make changes to a consumer database. -- -- 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#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hyc＠symas.com 08 Dec '11

08 Dec '11

hume-ol(a)bofh.ca wrote: > Full_Name: Brandon Hume > Version: 2.4.28 > OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 > URL: http://den.bofh.ca/~hume/ol_v3_fail_syslog.txt > Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) > > > OpenLDAP 2.4.28 compiled with BerkeleyDB 5.2.36, attempting to configure for > multi-master replication. Problems occurred with the second server complaining > about operations errors while attempting to replicate the cn=config tree; I've > been able to reproduce the problem from the command line using ldapsearch from > the same compile. > > The host is RHEL 6.1 running inside VMWare. Version of OpenLDAP is 2.4.28, > compiled with BerkeleyDB 5.2.36 (no patches available from Oracle at the time I > downloaded). Configuration options used are visible in > http://den.bofh.ca/~hume/config_ol_sh.txt > > The problem does *not* seem to be consistent, as *sometimes* it will work but > most of the time not. I've run the example query once, had it fail, run it > again immediately and had it succeed, and then again fail a dozen times in a > row. Wireshark traces showed the connection was established using LDAPv3; > putting the server in debug "Any" mode also confirms the same. The syslogs > generated are viewable at http://den.bofh.ca/~hume/ol_v3_fail_syslog.txt > > I've compiled 2.4.27 with the same options and it *seemed* to behave, though I > may have merely gotten lucky. Only two source files are changed between 2.4.27 and 2.4.28, and neither of the changes affect cn=config, syncrepl, or Bind operations. If you're seeing a difference in behavior here then I can only conclude that your build environment is corrupted. > Example ldapsearch invocation: > > $ /appl/ldap/bin/ldapsearch -x -D 'cn=config' -h kil-ds-3.its.dal.ca -b > cn=config -w bindpass -s sub -E sync=rp -e manageDSAit 'objectclass=*' > # extended LDIF > # > # LDAPv3 > # base<cn=config> with scope subtree > # filter: objectclass=* > # requesting: ALL > # with manageDSAit control > # > > # search result > search: 2 > result: 2 Protocol error > text: controls require LDAPv3 > > # numResponses: 1 > ldap_result: Can't contact LDAP server (-1) > > > These servers are not yet in production and I have ~two weeks to play and tweak > to generate more debugging information if you'd find it useful. > > -- -- 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

(ITS#7108) syncrepl loses updates when replica is down
by ml+openldap＠esmtp.org 08 Dec '11

08 Dec '11

Full_Name: Claus Assmann Version: 2.4.28 OS: Red Hat Enterprise Linux Server release 5.3 URL: ftp://ftp.openldap.org/incoming/claus-assmann-111208.patch Submission from: (NULL) (63.211.143.38) This is a followup to ITS 7037 which has been fixed in 2.4.28. It is the same setup and test -- I've uploaded a "patch" that includes the test program (sorry if it doesn't follow all the OpenLDAP conventions, I hope it is sufficient to reproduce the problem). It looks like some changes to the OpenLDAP master are not transferred to the replica (the test prg demonstrates that). Note: in my test runs it doesn't always fail, but almost all the time. Please let me know whether my test is broken or whether there is a problem in slapd. this is the failure output from running ./run syncrepl-ldap in the tests/ directory: test failed - master and slave databases differ 79,83d78 < dn: dc=com < dc: com < objectClass: top < objectClass: domain < 101,115d95 < dn: dc=example,dc=com < dc: example < objectClass: organization < objectClass: domainRelatedObject < objectClass: dcObject < l: Anytown, Michigan < st: Michigan < o: Example, Inc. < o: EX < o: Ex. < description: The Example, Inc. at Anytown < postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US < telephoneNumber: +1 313 555 1817 < associatedDomain: example.com

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs