openldap-bugs

openldap-bugs@openldap.org

1 participants
21000 discussions

(ITS#4797) back-bdb crashes during test34-translucent
by ando＠sys-net.it 08 Jan '07

08 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD OS: Linux SuSE 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando Apparently, the cache lru is not initialized. Backtrace: masarati@xxx:~/yyy/ldap-devel/tests> gdb ../servers/slapd/slapd core.1900 GNU gdb 6.3 <snip> #0 0x00000000004f9e13 in bdb_cache_delete_internal (cache=0x817b50, e=0x8efbc0, decr=1) at cache.c:1240 1240 LRU_DEL( cache, e ); (gdb) bt #0 0x00000000004f9e13 in bdb_cache_delete_internal (cache=0x817b50, e=0x8efbc0, decr=1) at cache.c:1240 #1 0x00000000004f9bdf in bdb_cache_delete (bdb=0x817af0, e=0x8c5bf8, locker=2147483683, lock=0x41801820) at cache.c:1155 #2 0x00000000004fde8f in bdb_delete (op=0x8d94e0, rs=0x41801d50) at delete.c:520 #3 0x00000000004b0011 in overlay_op_walk (op=0x8d94e0, rs=0x41801d50, which=op_delete, oi=0x819310, on=0x0) at backover.c:507 #4 0x00000000004b0215 in over_op_func (op=0x8d94e0, rs=0x41801d50, which=op_delete) at backover.c:559 #5 0x00000000004b035f in over_op_delete (op=0x8d94e0, rs=0x41801d50) at backover.c:611 #6 0x00000000004580ca in fe_op_delete (op=0x8d94e0, rs=0x41801d50) at delete.c:180 #7 0x0000000000457cbc in do_delete (op=0x8d94e0, rs=0x41801d50) at delete.c:91 #8 0x0000000000438689 in connection_operation (ctx=0x41801e90, arg_v=0x8d94e0) at connection.c:1128 #9 0x0000000000438b6c in connection_read_thread (ctx=0x41801e90, argv=0xd) at connection.c:1256 #10 0x0000000000592587 in ldap_int_thread_pool_wrapper (xpool=0x7d99a0) at tpool.c:704 #11 0x00002aaaab0befa5 in start_thread () from /lib64/tls/libpthread.so.0 #12 0x00002aaaab28acb2 in clone () from /lib64/tls/libc.so.6 #13 0x0000000000000000 in ?? () <snip> (gdb) p cache[0] $1 = {c_eifree = 0x0, c_idtree = 0x8ebaa0, c_lruhead = 0x0, c_lrutail = 0x0, c_dntree = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0 '\0', bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_e = 0x0, bei_kids = 0x8ec040, bei_kids_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0}, c_maxsize = 1000, c_cursize = 4, c_minfree = 1, c_eiused = 3, c_leaves = 1, c_purging = 0, c_locker = 6, c_rwlock = 0x817db0, c_lru_mutex = { __m_reserved = 1, __m_count = 0, __m_owner = 0x100000771, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_count_mutex = { __m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_eifree_mutex = { __m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}} (gdb) p e[0] $2 = {bei_parent = 0x8e2cc0, bei_id = 7, bei_lockpad = 0 '\0', bei_state = 139, bei_finders = 0, bei_nrdn = {bv_len = 11, bv_val = 0x8e26f0 "uid=someguy"}, bei_e = 0x8c5bf8, bei_kids = 0x0, bei_kids_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x100000771, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0}

1 0

Re: (ITS#4494) connections are not asynchrounous
by ando＠sys-net.it 08 Jan '07

08 Jan '07

lrm(a)interlinknetworks.com wrote: > I have already tried this. It does not have any affect on SSL connection > negotitation. > > There is a very interseting comment in the code which indicates someone was > aware of the problem. From the 2.3.20 source distribution, file > libraries/libldap/tls.c (line 1445): > > /* > * Fortunately, the lib uses blocking io... > */ > if ( ldap_int_tls_connect( ld, conn ) < 0 ) { > ld->ld_errno = LDAP_CONNECT_ERROR; > return (ld->ld_errno); > } > > And in ldap_int_tls_connect(), there is a call to SSL_connect( ssl ) that has no > provision for asynchronous operation. There is no setting of the non-blocking > option that I can find in this code sequence. > > > To reproduce the problem, simply point your ldaps: URL to a TCP server port that > accepts connections, and does nothing with them. The LDAP client will hang > forever (or until the server ephemeral port is closed). Is it an option for you to use Start TLS instead of ldaps? In this case, code in right HEAD should fix all non-blocking issues, as soon as you specify a network timeout and LDAP_OPT_CONNECT_ASYNC (undocumented yet, it's been committed just hours ago). The usage I suggest is to set LDAP_OPT_NETWORK_TIMEOUT to a positive value; then set LDAP_OPT_CONNECT_ASYNC to TRUE before performing the first operation, and reset it to FALSE after the first operation succeeds. In your case, the first operation would be ldap_start_tls[_s](3). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by ando＠sys-net.it 08 Jan '07

08 Jan '07

robb(a)wtg.cw.com wrote: > Pierangelo Masarati wrote: >> In any case, since the behavior you report is very data and meta-data >> dependent, you don't provide enough info for debugging, and at a very >> first glance this is not indicative of a software bug. > > Pierangelo, > > the problem is indeed with the meta-data: > > the object at the root of the sql tree "dc=sql,dc=example,dc=org" was > defined purely as dcObject, it needs a structural objectClass in order > to be valid. > > If we define it as an organizationalUnit and dcObject (using > ldap_entry_objclasses) then all works as expected. > > Oddly doing the opposite doesn't seem to work. Because somewhere a constraint stepped in, which requires objectClasses in ldap_objectclasses to be structural; it makes sense, all in all. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by robb＠wtg.cw.com 08 Jan '07

08 Jan '07

Pierangelo Masarati wrote: > In any case, since the behavior you report is very data and meta-data > dependent, you don't provide enough info for debugging, and at a very > first glance this is not indicative of a software bug. Pierangelo, the problem is indeed with the meta-data: the object at the root of the sql tree "dc=sql,dc=example,dc=org" was defined purely as dcObject, it needs a structural objectClass in order to be valid. If we define it as an organizationalUnit and dcObject (using ldap_entry_objclasses) then all works as expected. Oddly doing the opposite doesn't seem to work. Many thanks, Rob -- Robert Brooks, Network Manager, Cable & Wireless UK <robb(a)wtg.cw.com> http://wtg.cw.com/ Tel: +44 (0)20 7339 8600 Fax: +44 (0)20 7339 8601 - "What was your username again?" - BOFH -

1 0

(ITS#4796) Contribution: JLDAP support for simple paging of results (RFC 2696)
by radovan＠skolnik.info 06 Jan '07

06 Jan '07

Full_Name: Radovan Skolnik Version: JLDAP CVS version OS: Windows/Java URL: http://www.skolnik.info/LDAPPagedResults.zip Submission from: (NULL) (82.119.120.128) Hello, I hope this is the right place to make this submission ;-) Recently I found that JLDAP does not support simple paging mechanism via control as stated in RFC2696 (control OID 1.2.840.113556.1.4.319). So I made an attempt to implement it and it seems to me it works as it's supposed to. I would like to contribute it to the project for the benefit of others. The files can be found at http://www.skolnik.info/LDAPPagedResults.zip If there is something more needed from me please let me know. Best regards Radovan Skolnik

1 0

Re: (ITS#4795) dsiallow bind_simple_unprotected
by hyc＠symas.com 29 Dec '06

29 Dec '06

hugo.monteiro(a)fct.unl.pt wrote: > Full_Name: Hugo Monteiro > Version: 2.3.27 > OS: GNU/Linux Debian Sarge > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.139.79.96) > > > Though it's been deprecated for a long time now, the documentation still referes > to dsiallow bind_simple_unprotected, leading people into mistake, and some > headaches. Hm, according to CVS, it was removed from the release man page slapd.conf(5) in 2.1.21, May 2003. There's certainly no trace of it in the 2.3.27 man page. Ah, it's still in the Admin Guide... You should be more specific next time. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4795) dsiallow bind_simple_unprotected
by hugo.monteiro＠fct.unl.pt 29 Dec '06

29 Dec '06

Full_Name: Hugo Monteiro Version: 2.3.27 OS: GNU/Linux Debian Sarge URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.139.79.96) Though it's been deprecated for a long time now, the documentation still referes to dsiallow bind_simple_unprotected, leading people into mistake, and some headaches. Keep up the good work. Cheers, Hugo Monteiro.

1 0

Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by ando＠sys-net.it 28 Dec '06

28 Dec '06

robb(a)wtg.cw.com wrote: > Full_Name: Robert Brooks > Version: 2.3.31 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.49.19.14) > > > an ldapsearch like this works > > ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" cn > > dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org > cn: Robert Brooks > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > however this does not: > > ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" dn cn > > # search result > search: 2 > result: 65 Object class violation > > # numResponses: > This is working just fine in HEAD/re23 (using the built-in test data): bash-3.00$ ../clients/tools/ldapsearch -x -H ldap://:9011 -b dc=example,dc=com -LLL cn=*mit* cn dn # refldap://localhost:9012/dc=example,dc=com??sub dn: cn=Mitya Kovalev,dc=example,dc=com cn: Mitya Kovalev That's why I suspect it's related to some issue (or inconsistency) within your data/metadata. Could you post more? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4785) back-sql objectclass searches fail unless there is data in ldap_entry_objclasses
by ando＠sys-net.it 28 Dec '06

28 Dec '06

robb(a)wtg.cw.com wrote: > objectclass searches fail (with back-sql/mysql) if there is no data in the > ldap_entry_objclasses table. Just a simple dummy entry like this is enough to > fix the problem. > I see. A solution I see would be to use UNION to merge the results of a query with and one without the outer join to ldap_entry_objclasses. This, however, requires some extensive code manipulation, and likely would be much less efficient, so I believe the workaround of having one row in ldap_entry_objclasses is better. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 28 Dec '06

28 Dec '06

On December 28, 2006 10:06:40 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > Frank Cusack wrote: >> >> Oh, in that case I am definitely missing a lot. Since my understanding >> of the timeout value passed to ldap_sasl_bind() is that it is a *bind* >> timeout, which I assumed would be because some artibrary SASL mechanism >> might take some arbitrarily long amount of time. If there is no bind >> timeout, then why is LDAP_OPT_NETWORK_TIMEOUT implemented? The timeout >> passed to ldap_sasl_bind() should just be the connect() timeout then. > ldap_sasl_bind() cannot be passed any timeout. What timeout are you > referring to? grrr ... I would have sworn there was a timeout arg! I must have confused it with ldap_search(). The Netscape API does not have a timeout arg either. I'd implemented my thread wrapper (w/ timeout) before I learned of the LDAP_OPT_NETWORK_TIMEOUT option (LDAP_X_OPT_CONNECT_TIMEOUT for Netscape API). I guess when I found that option, I falsely remembered that ldap_sasl_bind_s() had a timeout arg. > I must disagree with the above. As far as I understand. > LDAP_OPT_NETWORK_TIMEOUT does what you expect: it makes connect() time > out as required. ldap_sasl_bind() should return as soon as the packet > with the request has been sent, and the rest of the timeout policy for > the bind only part should be dealt with by the client using the > ldap_result() timeout arg as appropriate. I've recently tested that > behavior for customers who wanted some certain timelimit on all > operations, not just searches, and that required some extensive > modifications to the proxy backends, but the client library (libldap) was > not touched at all. In that case, the code basically uses > ldap_sasl_bind() to wrap simple binds (that's what the proxy backends > mostly do), and using LDAP_OPT_NETWORK_TIMEOUT makes it work as expected. > I can't speak for truly SASL bind as I didn't experiment timeouts with > that. Sounds right. In the case of a truly SASL bind where there might be a long delay, async ldap_sasl_bind() should be enough. Thanks for your patience. -frank

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