October 2013 - openldap-bugs

Re: (ITS#7719) configure delayed response time

by quanah＠zimbra.com

--On Tuesday, October 08, 2013 3:59 AM +0000 rashtrapathy(a)gmail.com wrote: > Full_Name: Rashtrapathy > Version: 2.4.36 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.163.217.105) > > > Dear All, > > I want my openldap server to send a delayed searchResEntry & > searchResDone for any searchRequest. > > Where i need to change the configuration file for this delayed response? The ITS system is for reporting bugs, not asking usage questions. I would however suggest you look at contrib modules like the noop module to see about how to insert a delay into the slapd stack. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

9 years, 11 months

1
0
0 / 0

Re: (ITS#7718) mdb_cursor_del() segfault on last entry

by hyc＠symas.com

matthew.monaco(a)colorado.edu wrote: > Full_Name: Matthew Monaco > Version: mdb-0.9.8, mdb-d327a36 > OS: linux-3.11.4 > URL: http://pastie.org/8385142 > Submission from: (NULL) (128.138.64.206) > > > I'm getting a segfault with MDB when using mdb_cursor_del() on the last entry in > the database. Example on pastie.org [1]. Thanks for the report and testcase, fixed now in mdb.master/ > > [1] http://pastie.org/8385142 > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

9 years, 11 months

1
0
0 / 0

(ITS#7719) configure delayed response time

by rashtrapathy＠gmail.com

Full_Name: Rashtrapathy Version: 2.4.36 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.163.217.105) Dear All, I want my openldap server to send a delayed searchResEntry & searchResDone for any searchRequest. Where i need to change the configuration file for this delayed response? Please help me ASAP. Thanks, Rash.

9 years, 11 months

1
0
0 / 0

(ITS#7718) mdb_cursor_del() segfault on last entry

by matthew.monaco＠colorado.edu

Full_Name: Matthew Monaco Version: mdb-0.9.8, mdb-d327a36 OS: linux-3.11.4 URL: http://pastie.org/8385142 Submission from: (NULL) (128.138.64.206) I'm getting a segfault with MDB when using mdb_cursor_del() on the last entry in the database. Example on pastie.org [1]. [1] http://pastie.org/8385142

9 years, 11 months

1
0
0 / 0

Re: (ITS#7717) Sudden memory increase leading to Master LDAP crash

by quanah＠zimbra.com

--On Thursday, October 03, 2013 1:14 PM +0000 marcon.bruno(a)free.fr wrote: > The problem is very easy to replay : one master and one slave are > sufficient. Then run 9 windows with a script adding an entry and > modifying an entry. Please provide full configuration details. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

9 years, 11 months

1
0
0 / 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops

by ck＠cksoft.de

Hi Michael, On Sun, 6 Oct 2013, michael(a)stroeder.com wrote: > I've updated the test data with LDIF files and a README describing the LDAP > operations to perform: > > http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 > > I consider this to be a serious issue which could be the cause for other > replication issues including dead-locks we're experiencing. (Maybe there are > similar issues in slapo-refint since dead-locks in our deployment arised when > moving entries into different subtree.) I can confirm that I can see the same bug with your testcase. It seems that restarting the second slapd instance fixes the contextCSN issue just because it scans all it's entries and does the right thing. Even a slapcat of both directories shows the issue. Things that I find disturbing: After applying the group membership the member dn: gets it's memberOf attribute updated accordingly. But the entryCSN stays unchanged. Entry before applying group membership: # michael, users, example.com dn: uid=michael,ou=users,dc=example,dc=com uid: michael objectClass: account objectClass: simpleSecurityObject userPassword:: dGVzdHNlY3JldA== description: test entryCSN: 20131006193757.912740Z#000000#002#000000 Entry after applying group membership is obviously updated but still has the same entryCSN: # michael, users, example.com dn: uid=michael,ou=users,dc=example,dc=com uid: michael objectClass: account objectClass: simpleSecurityObject userPassword:: dGVzdHNlY3JldA== memberOf: cn=admins,ou=groups,dc=example,dc=com memberOf: cn=testgroup1,ou=groups,dc=example,dc=com description: test entryCSN: 20131006193757.912740Z#000000#002#000000 I can also confirm the subsequent contextCSN mismatch. I too consider this a serious issue. If I read Howards reply correctly and from what I see in the source code of the memberOf overlay the strategy here seems to be not to replicate the side effect of adding the memberOf: entry. OpenLDAP relies on the side effect happening on the replicas through the same codepath when the member: attribute in the group gets updated through replication. This sounds very similar to the difference between: 1. statement replication in sql databases ala mysql 2. log based replication ala postgresql OpenLDAP is doing 1. here while 2. would perhaps have been the better option. I understand turning this around is propably too late at this point in time. Looks like we will just have to work out the bugs the hard way. I am using slapo-lastbind and slapo-ppolicy extensively in my current project and will keep my eyes open for similar issues resulting from not replicating the side effects that these overlays produce. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

9 years, 11 months

1
0
0 / 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops

by michael＠stroeder.com

Christian Kratzer wrote: > This sounds very similar to the difference between: > > 1. statement replication in sql databases ala mysql > > 2. log based replication ala postgresql > > OpenLDAP is doing 1. here while 2. would perhaps have been the better option. >From my understanding 2. is OpenLDAP's delta-syncrepl. Ciao, Michael.

9 years, 11 months

1
0
0 / 0

Re: (ITS#7716) slapd crashes after search immediately followed by (abandon+) unbind

by quanah＠zimbra.com

--On Wednesday, October 02, 2013 12:32 PM +0000 michael.vishchers(a)7p-group.com wrote: > Full_Name: Michael Vishchers > Version: 2.4.23 This release is years old, and has numerous known issues. It sounds like you are using RedHat's package. If you absolutely have to use that package, then you need to report this issue with RedHat. Otherwise, I suggest upgrading to the latest release. If you don't feel comfortable building OpenLDAP yourself, you can easily use the packages from the LTB project: <http://ltb-project.org/wiki/download#openldap> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Architect - Server Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

9 years, 11 months

1
0
0 / 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops

by michael＠stroeder.com

I've updated the test data with LDIF files and a README describing the LDAP operations to perform: http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 I consider this to be a serious issue which could be the cause for other replication issues including dead-locks we're experiencing. (Maybe there are similar issues in slapo-refint since dead-locks in our deployment arised when moving entries into different subtree.) Ciao, Michael. The README copied here for direct access: ---------------------------------------------------------------------------- 0. Start both servers by invoking start-slapd1.sh and start-slapd2.sh ---------------------------------------------------------------------------- 1. Add test entries on first server: $ ldapadd -H ldap://localhost:2071 -D "uid=diradm,dc=example,dc=com" -w testsecret -f 1_ldapadd.ldif adding new entry "dc=example,dc=com" [..] adding new entry "cn=replicas,ou=groups,dc=example,dc=com" You can now see contextCSN value of first server on both servers (as expected): $ for I in 1 2 ; do (echo ldap://localhost:207$I ; ldapsearch -LLL -H ldap://localhost:207$I -D "uid=diradm,dc=example,dc=com" -w testsecret -b "dc=example,dc=com" -s base "(objectClass=*)" contextCSN ) ; done ldap://localhost:2071 dn: dc=example,dc=com contextCSN: 20131006154300.921415Z#000000#001#000000 ldap://localhost:2072 dn: dc=example,dc=com contextCSN: 20131006154300.921415Z#000000#001#000000 ---------------------------------------------------------------------------- 2. Send a simple modification to second server: $ ldapmodify -H ldap://localhost:2072 -D "uid=diradm,dc=example,dc=com" -w testsecret -f 2_ldapmodify.ldif modifying entry "uid=michael,ou=users,dc=example,dc=com" You can now see contextCSN value of second server on both servers (as expected): $ for I in 1 2 ; do (echo ldap://localhost:207$I ; ldapsearch -LLL -H ldap://localhost:207$I -D "uid=diradm,dc=example,dc=com" -w testsecret -b "dc=example,dc=com" -s base "(objectClass=*)" contextCSN ) ; done ldap://localhost:2071 dn: dc=example,dc=com contextCSN: 20131006154300.921415Z#000000#001#000000 contextCSN: 20131006154406.940154Z#000000#002#000000 ldap://localhost:2072 dn: dc=example,dc=com contextCSN: 20131006154300.921415Z#000000#001#000000 contextCSN: 20131006154406.940154Z#000000#002#000000 ---------------------------------------------------------------------------- 3. Modification of group membership on first server: $ ldapmodify -H ldap://localhost:2071 -D "uid=diradm,dc=example,dc=com" -w testsecret -f 3_ldapmodify.ldif modifying entry "cn=testgroup1,ou=groups,dc=example,dc=com" Now the contextCSN values differ: $ for I in 1 2 ; do (echo ldap://localhost:207$I ; ldapsearch -LLL -H ldap://localhost:207$I -D "uid=diradm,dc=example,dc=com" -w testsecret -b "dc=example,dc=com" -s base "(objectClass=*)" contextCSN ) ; done ldap://localhost:2071 dn: dc=example,dc=com contextCSN: 20131006154449.514135Z#000000#001#000000 contextCSN: 20131006154406.940154Z#000000#002#000000 ldap://localhost:2072 dn: dc=example,dc=com contextCSN: 20131006154300.921415Z#000000#001#000000 contextCSN: 20131006154406.940154Z#000000#002#000000

9 years, 11 months

1
0
0 / 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops

by michael＠stroeder.com

Hmmpf, the attachment did not come through. Download config here: http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2

9 years, 11 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2013