- openldap-bugs - openldap.org

(ITS#4798) idassert mode=self doesn't proxyauthz for anonymous operations
by ando＠sys-net.it 08 Jan '07

08 Jan '07

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See <http://www.openldap.org/lists/openldap-software/200701/msg00062.html>. A fix is coming.

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 08 Jan '07

08 Jan '07

ando(a)sys-net.it wrote: > fcusack(a)fcusack.com wrote: >> But still you can do the bind async, and just close the fd on the client >> side on timeout. I don't see why connect() timeout can't be handled >> the same way. (ignoring the problem that there is no API call AFAICT >> to just drop the connection) >> > I'll note that there's been some interest in that area --- I loosely > have the same need (see > <http://www.openldap.org/lists/openldap-devel/200611/msg00000.html>) but > unfortunately it's not in my priority list, considering that it might > have relevant impact on the client library. Eventually, this got on top of my priority list, and it's now implemented in HEAD. One needs to: - set LDAP_OPT_NETWORK_TIMEOUT to a value greater than 0 - set LDAP_OPT_CONNECT_ASYNC to TRUE - perform the first operation asynchronously (e.g. ldap_sasl_bind(3)) the library call might return LDAP_X_CONNECTING if poll(2)'ing after connect(2) didn't succeed yet and LDAP_OPT_NETWORK_TIMEOUT didn't expire yet. In that case, the client should resubmit the request until it either succeeds or LDAP_OPT_NETWORK_TIMEOUT expires. Note that, right now, there's no means to set LDAP_OPT_CONNECT_ASYNC other than via ldap_set_option(3), and none is foreseen, because only specially crafted clients would be able to handle LDAP_X_CONNECTING appropriately. Please test. 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

(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

(ITS#4794) Value return filters leak
by ando＠sys-net.it 28 Dec '06

28 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Members of the vrf list are malloc'ed on the heap but freed as if in the thread's slab.

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 28 Dec '06

28 Dec '06

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? >> ldap_initialize() doesn't actually establish any connection, >> it just sets up the handler, and the connection is established by the >> first operation that requires it. the asynchronous bind, muck like any >> other asynchronous operation, simply returns after sending the packet(s) >> containing the request. > > That much I do understand. (Although I thought the async bind() > functions > weren't actually implemented async.) They are. > >> But, of course, the first of them requires the >> connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT >> comes into play. Doing a really asynchronous connect() implies >> returning >> some sort of LDAP_X_INPROGRESS, keeping track of the status of the >> connection and polling it for response for each subsequent call until >> the >> connection is established before actually sending any request. In this >> sense the change should be intrusive: in this design, client code should >> be able to handle the LDAP_X_INPROGRESS return code and resubmit the >> request until the connection is ready. A "smarter" design would cache >> the request, poll for connect() response during calls to ldap_result(), >> and submit the actual request when the connection is established. > > Sure, I understand that also (now). > > What I'm saying is that most folks probably don't really need an async > connect(), they just need a non-blocking one that returns in some known > amount of time. LDAP_OPT_NETWORK_TIMEOUT doesn't do that, since it > only controls the connect() part, and not the subsequent bind (important > since you can only get to connect() via the ldap_bind() or other > calls, ie > there is no ldap_connect() and ldap_open() is deprecated). But a new > LDAP_OPT_CONNECT_BIND_TIMEOUT option could do it. 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. 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 9:34:36 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > fcusack(a)fcusack.com wrote: >> I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is >> close to the desired functionality. AFAICT it implements a *separate* >> timeout for the connect() (and maybe unbind/close()?) part of an ldap >> connection. Why someone would want to distinguish between connect() >> and bind I don't know, especially when they don't get feedback about >> how long connect() took. >> >> It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT >> which would be the total time for connect() and bind, given that >> non-blocking connect() is already implemented. That would probably >> solve a lot of folk's need for a working async bind. >> >> > I think you're missing a point: there's no bind timeout because there's > no need for it. The delay (or the hang) you likely see when dong > ldap_sasl_bind() is actually spent doing a connect() to establish a > connection. 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_initialize() doesn't actually establish any connection, > it just sets up the handler, and the connection is established by the > first operation that requires it. the asynchronous bind, muck like any > other asynchronous operation, simply returns after sending the packet(s) > containing the request. That much I do understand. (Although I thought the async bind() functions weren't actually implemented async.) > But, of course, the first of them requires the > connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT > comes into play. Doing a really asynchronous connect() implies returning > some sort of LDAP_X_INPROGRESS, keeping track of the status of the > connection and polling it for response for each subsequent call until the > connection is established before actually sending any request. In this > sense the change should be intrusive: in this design, client code should > be able to handle the LDAP_X_INPROGRESS return code and resubmit the > request until the connection is ready. A "smarter" design would cache > the request, poll for connect() response during calls to ldap_result(), > and submit the actual request when the connection is established. Sure, I understand that also (now). What I'm saying is that most folks probably don't really need an async connect(), they just need a non-blocking one that returns in some known amount of time. LDAP_OPT_NETWORK_TIMEOUT doesn't do that, since it only controls the connect() part, and not the subsequent bind (important since you can only get to connect() via the ldap_bind() or other calls, ie there is no ldap_connect() and ldap_open() is deprecated). But a new LDAP_OPT_CONNECT_BIND_TIMEOUT option could do it. -frank

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 28 Dec '06

28 Dec '06

fcusack(a)fcusack.com wrote: > Unfortunately I won't be able to contribute a patch as I've worked > around it in my application (I created a separate thread to handle > the ldap connect) so I can't afford to invest the time. Plus I needed > a solution that would work with the Netscape API as well as OpenLDAP. > > I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is > close to the desired functionality. AFAICT it implements a *separate* > timeout for the connect() (and maybe unbind/close()?) part of an ldap > connection. Why someone would want to distinguish between connect() > and bind I don't know, especially when they don't get feedback about > how long connect() took. > > It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT > which would be the total time for connect() and bind, given that > non-blocking connect() is already implemented. That would probably > solve a lot of folk's need for a working async bind. > > I think you're missing a point: there's no bind timeout because there's no need for it. The delay (or the hang) you likely see when dong ldap_sasl_bind() is actually spent doing a connect() to establish a connection. ldap_initialize() doesn't actually establish any connection, it just sets up the handler, and the connection is established by the first operation that requires it. the asynchronous bind, muck like any other asynchronous operation, simply returns after sending the packet(s) containing the request. But, of course, the first of them requires the connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT comes into play. Doing a really asynchronous connect() implies returning some sort of LDAP_X_INPROGRESS, keeping track of the status of the connection and polling it for response for each subsequent call until the connection is established before actually sending any request. In this sense the change should be intrusive: in this design, client code should be able to handle the LDAP_X_INPROGRESS return code and resubmit the request until the connection is ready. A "smarter" design would cache the request, poll for connect() response during calls to ldap_result(), and submit the actual request when the connection is established. 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 27 Dec '06

27 Dec '06

On December 22, 2006 10:56:40 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > fcusack(a)fcusack.com wrote: >> But still you can do the bind async, and just close the fd on the client >> side on timeout. I don't see why connect() timeout can't be handled >> the same way. (ignoring the problem that there is no API call AFAICT >> to just drop the connection) >> > I'll note that there's been some interest in that area --- I loosely have > the same need (see > <http://www.openldap.org/lists/openldap-devel/200611/msg00000.html>) but > unfortunately it's not in my priority list, considering that it might > have relevant impact on the client library. Unfortunately I won't be able to contribute a patch as I've worked around it in my application (I created a separate thread to handle the ldap connect) so I can't afford to invest the time. Plus I needed a solution that would work with the Netscape API as well as OpenLDAP. I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is close to the desired functionality. AFAICT it implements a *separate* timeout for the connect() (and maybe unbind/close()?) part of an ldap connection. Why someone would want to distinguish between connect() and bind I don't know, especially when they don't get feedback about how long connect() took. It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT which would be the total time for connect() and bind, given that non-blocking connect() is already implemented. That would probably solve a lot of folk's need for a working async bind. -frank

1 0

(ITS#4793) connection_get race condition on Windows
by hyc＠OpenLDAP.org 26 Dec '06

26 Dec '06

Full_Name: Howard Chu Version: HEAD OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc test039 was consistently failing in an assert() in slapd_set_read() called from connection_read(). The problem was that connection_get() was returning a connection structure that got closed and immediately reused. The problem may also be in RE23 since they're using the same connection manager now, but I haven't built RE23 on Windows recently to verify.

1 0

Re: (ITS#4791) privileged connections handling in proxy backends
by hyc＠symas.com 26 Dec '06

26 Dec '06

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: > >> The patch is coming. > > Something's missing... My fault, sorry. Had an old back-ldap.h. Builds fine now. -- -- 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

Re: (ITS#4791) privileged connections handling in proxy backends
by hyc＠symas.com 26 Dec '06

26 Dec '06

ando(a)sys-net.it wrote: > The patch is coming. Something's missing... gcc -g -O2 -I../../../include -I../../../../head/include -I.. -I../../../../head/servers/slapd/back-ldap/.. -I/usr/local/include -I/usr/local/BerkeleyDB.4.2/include -c ../../../../head/servers/slapd/back-ldap/config.c -o config.o ../../../../head/servers/slapd/back-ldap/config.c: In function `slap_idassert_authzfrom_parse': ../../../../head/servers/slapd/back-ldap/config.c:567: error: `LDAP_BACK_AUTH_AUTHZ_ALL' undeclared (first use in this function) ../../../../head/servers/slapd/back-ldap/config.c:567: error: (Each undeclared identifier is reported only once ../../../../head/servers/slapd/back-ldap/config.c:567: error: for each function it appears in.) -- -- 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

Re: ITS#3707 filters
by hyc＠symas.com 25 Dec '06

25 Dec '06

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> I've had a patch for the Filter handling sitting here half-finished for >> quite a while. The intent is to preserve all of the original filter data >> so that it can be reused directly. > > This is now in HEAD. I haven't yet caught all the cases in get_ssa or > get_mra that drop the info when validation fails, but otherwise it's > usable. Instead of using the distinct SLAPD_FILTER_COMPUTED type for > filter components with unknown attributes, it now ORs the > SLAPD_FILTER_UNDEFINED flag onto the existing filter choice. This way > the original filter structure can be preserved. back-ldap's filter munging strategy still needs to be adapted to the new code. Probably it shouldn't use the filterstr at all. Any filter component with an unknown attribute is now logged with a '?' prefix, e.g. "(foo=a*b)" becomes "(?foo=a*b)". -- -- 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

Re: ITS#3707 filters
by hyc＠symas.com 25 Dec '06

25 Dec '06

hyc(a)symas.com wrote: > I've had a patch for the Filter handling sitting here half-finished for > quite a while. The intent is to preserve all of the original filter data > so that it can be reused directly. This is now in HEAD. I haven't yet caught all the cases in get_ssa or get_mra that drop the info when validation fails, but otherwise it's usable. Instead of using the distinct SLAPD_FILTER_COMPUTED type for filter components with unknown attributes, it now ORs the SLAPD_FILTER_UNDEFINED flag onto the existing filter choice. This way the original filter structure can be preserved. > On a related note, RFC4511 changes the behavior of presence matching on > unknown attributes to be Undefined now instead of FALSE. So presumably > we should update our code accordingly. This is now in HEAD as well. -- -- 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#4792) not able to install Slapd i.e. when I install openldap it does'nt install server module
by azia＠techxact.com 25 Dec '06

25 Dec '06

Full_Name: Ahmad Zia Version: openldap-2.3.31 OS: Redhat ES 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.227.142.2) I have successfully compiled, make openldad but when I get to the point where I have to run "make test" it says cannot connect to the openldap server after timing out. When I use this command , I get the following: [root@TXDXB openldap]# rpm -qa | grep openldap openldap-devel-2.2.13-6.4E openldap-2.2.13-6.4E openldap-clients-2.2.13-6.4E its not listing openldap-server-2.2.13-6.4E and in my /etc/openldap directory I only have ldap.conf and I do not have slapd.conf, so what I gather so far is that I am not able to install the server module. I have used the parameter --enable-slapd with ./configure command but its still the same thing. Can you please tell me what am I doing wrong

1 0

Re: (ITS#4790) re23 hangs during shutdown after test033
by hyc＠symas.com 24 Dec '06

24 Dec '06

---- <ando(a)sys-net.it> wrote: > > Full_Name: Pierangelo Masarati > Version: re23 (2.3.31) > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.28.220.33) > > > Apparently, one thread is unable to terminate correctly, so the test succeeds, > but then slapd hangs forever in ldap_pvt_thread_pool_destroy(). I couldn't > investigate this in depth right now, but I could easily reproduce it on two > different systems (different kernels and so), so I'm positive I can easily > reproduce it. This is a bad patch to connections_shutdown in RE23, there is a "continue" after checking for a client session that shouldn't be there. This line is not present in HEAD and the bug doesn't exist in HEAD. Strange that it got there since we just recently sync'd RE23 with HEAD's connection.c. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support

1 0

(ITS#4791) privileged connections handling in proxy backends
by ando＠sys-net.it 24 Dec '06

24 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando Privileged connections, under special circumstances, are cached and shared among client-side connections. This may result in very heavy traffic between the proxy and the remote server(s) on a single connection. As a consequence, multiple issues may arise: - heavy contention on the handler's resources - requests limitation at the remote server side on a single connection (this occurs if the remote server is OpenLDAP, but other implementations may follow similar design) - bottelneck whenever the shared connection needs be regenerated, i.e. because it expires (conn-ttl) As a workaround, a pool of privileged connections is proposed. A fixed maximum side pool is deisgned, so that whenever a privileged connection is requested, the related list of connections is walked looking for an idle one (refcnt == 0). If found, it's moved to the tail, to provide a simple round-robin mech to avoid reusing the same connections. If none is found, a new connection is generated, if use-temporary-conn is set to yes or the size limit is not reached, or the thread idles waiting for one to become available. If a new connection is created and there's room for it in the list, it's appended. Tests show a clear benefit on Linux when binding through back-ldap, since this nicely works around the bottleneck created by sharing the bind connection when operations are always proxied authz, to save network resources. Another benefit is represented by a clear smoothing of the response rates. Previously, frequent transients would occur, giving uneven response rates over time, while right now steady rates under steady conditions are observed. The patch is coming. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs