openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#6646) back-hdb dncache disregarded in some searches
by hyc＠symas.com 10 Sep '10

10 Sep '10

ondrej.kuznik(a)acision.com wrote: > Full_Name: Ondrej Kuznik > Version: 2.4.23 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.168.56.1) This fact is already documented in the manpage. This ITS will be closed. -- -- 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#6646) back-hdb dncache disregarded in some searches
by ondrej.kuznik＠acision.com 10 Sep '10

10 Sep '10

Full_Name: Ondrej Kuznik Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.168.56.1) Example: database hdb suffix o=test dncache 1000 is a database that has most of its 1M entries as uid=%d,o=one,o=test. perform an unindexed search: ldapsearch -b o=test uid=1 the entry is first in the db, so is spit out immediately. Watching dn cn=Database 2,cn=Databases,cn=Monitor shows: olmBDBDNCache: 1002 This is OK, but: perform an unindexed search with base o=one,o=test: ldapsearch -b o=one,o=test uid=1 watching dn cn=Database 2,cn=Databases,cn=Monitor shows that all 1M dns are loaded into the cache and only after that the entry uid=1,o=one,o=test is spit out. Then the dncache starts decreasing as the database filters out the remaining entries: olmBDBDNCache: 1000002 Another twist: perform an unindexed search with base o=one,o=test but either kill ldapsearch while hdb is still crunching or add a sizelimit greater than the number of entries that should be returned: ldapsearch -z2 -b o=one,o=test "uid=1*" olmBDBDNCache contains most of the database and never decreases. olmBDBDNCache: 1000002 A dn is later freed from the cache only in case it is referenced, should there be another similar arc e.g. o=another,o=test, its dns are added inside the cache too if we use the same technique. This makes hdb unusable for a large database (whose set of dns alone can eat the entire memory if loaded into dncache) unless one can guarantee that every search is either indexed or with search base == suffix of the db. In the example scenario, the value of cachefree affects almost nothing.

1 0

Re: (ITS#6639) syncrepl failing using SASL/GSSAPI
by hyc＠symas.com 10 Sep '10

10 Sep '10

whm(a)stanford.edu wrote: > --On Friday, September 03, 2010 01:23:17 AM -0700 Bill MacAllister<whm(a)stanford.edu> wrote: > > The problem with the database was only coincidental. Restoring the database > got the failing replica past the problem replication event. > > In the replica pool of 6 servers we have seen the problem on there of the > servers. In thinking about this more it is unlikely that it is a slave > problem since the slaves have been in use for about 6 weeks and we did > not see the problem. Only when we changed the master to 2.4.23 did we > see the problem. I have captured a master debug log of the problem > event. It is at http://www.stanford.edu/~whm/files/master-debug.txt. > > Bill > Please try with this patch: Index: sasl.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/sasl.c,v retrieving revision 1.79 diff -u -r1.79 sasl.c --- sasl.c 13 Apr 2010 20:17:56 -0000 1.79 +++ sasl.c 10 Sep 2010 05:42:22 -0000 @@ -733,8 +733,9 @@ return ret; } else if ( p->buf_out.buf_ptr != p->buf_out.buf_end ) { /* partial write? pretend nothing got written */ - len2 = 0; p->flags |= LDAP_PVT_SASL_PARTIAL_WRITE; + sock_errset(EAGAIN); + len2 = -1; } /* return number of bytes encoded, not written, to ensure -- -- 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#6645) Yet Another LDIF Wrap Patch
by masarati＠aero.polimi.it 10 Sep '10

10 Sep '10

<ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-09-ldif-wrap.2.…> :)

1 0

Re: (ITS#6645) Yet Another LDIF Wrap Patch
by hyc＠symas.com 09 Sep '10

09 Sep '10

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-09-ldif-wrap.1.… > Submission from: (NULL) (129.72.165.135) > Submitted by: ando > > > The subject should be self-explanatory. It is only exploited by slapcat, via > the -o ldif-wrap=<n> option (<n> < 0: default;<n> == 0: no wrap;<n> > 0: wrap > value); extending ldapsearch is trivial. > > I'm *NOT* going to commit this unless there is unanimous consensus ;) Not thrilled with the magic constant 2^31-1. Seems like you should have just used "if ( wrap && len > wrap )" instead of a word-size-dependent magic. -- -- 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#6598
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

Committed to HEAD; please test. Thanks, p.

1 0

ITS#6600
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

Applied (with changes) to HEAD; please test. Thanks, p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

>> Hello, >> we tested this (HEAD code): >> >> 1. ITS 6565 seems to be fixed: Chaining works now with correct search >> base. >> >> 2. If the target server of the chaining is not reachable we get "no such >> object", followed by a SIGSEV (core dump). Stack Trace: >> >> #0 0x0000000400040004 in ?? () >> #1 0x000000000042eb60 in slap_cleanup_play (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:436 >> #2 0x000000000043145a in send_ldap_response (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:621 >> #3 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:750 >> #4 0x00000000004e2154 in ldap_chain_response (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at chain.c:1132 >> #5 0x00000000004833f8 in over_back_response (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at backover.c:237 >> #6 0x000000000042eace in slap_response_play (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:402 >> #7 0x0000000000431437 in send_ldap_response (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:476 >> #8 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at result.c:750 >> #9 0x0000000000497adc in dnssrv_back_referrals (op=0x7fffe40028c0, >> rs=0x7ffff1f70940) at referral.c:118 >> >> 0x0000000400040004 is the address referenced in >> op->o_callback->sc_cleanup(op,rs) . > > Thanks for the report. It would be useful to know how that memory became > stale or dangling. Could you run slapd under valgrind and report any > error message related to accessing that memory? Thanks, p. I've checked a simple configuration (global instance of chain overlay; request for non existing entry, resulting in slapd returning the default referral), and nothing strange appeared (the offending instruction is executed). The issue might be specific to your configuration. You'll probably need to post more details. p.

1 0

(ITS#6645) Yet Another LDIF Wrap Patch
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-09-ldif-wrap.1.… Submission from: (NULL) (129.72.165.135) Submitted by: ando The subject should be self-explanatory. It is only exploited by slapcat, via the -o ldif-wrap=<n> option (<n> < 0: default; <n> == 0: no wrap; <n> > 0: wrap value); extending ldapsearch is trivial. I'm *NOT* going to commit this unless there is unanimous consensus ;) Enjoy. p.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 09 Sep '10

09 Sep '10

> Hello, > we tested this (HEAD code): > > 1. ITS 6565 seems to be fixed: Chaining works now with correct search > base. > > 2. If the target server of the chaining is not reachable we get "no such > object", followed by a SIGSEV (core dump). Stack Trace: > > #0 0x0000000400040004 in ?? () > #1 0x000000000042eb60 in slap_cleanup_play (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:436 > #2 0x000000000043145a in send_ldap_response (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:621 > #3 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:750 > #4 0x00000000004e2154 in ldap_chain_response (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at chain.c:1132 > #5 0x00000000004833f8 in over_back_response (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at backover.c:237 > #6 0x000000000042eace in slap_response_play (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:402 > #7 0x0000000000431437 in send_ldap_response (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:476 > #8 0x00000000004320cd in slap_send_ldap_result (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at result.c:750 > #9 0x0000000000497adc in dnssrv_back_referrals (op=0x7fffe40028c0, > rs=0x7ffff1f70940) at referral.c:118 > > 0x0000000400040004 is the address referenced in > op->o_callback->sc_cleanup(op,rs) . Thanks for the report. It would be useful to know how that memory became stale or dangling. Could you run slapd under valgrind and report any error message related to accessing that memory? Thanks, p.

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