openldap-bugs

openldap-bugs@openldap.org

1 participants
21000 discussions

Re: (ITS#4494) connections are not asynchrounous
by lrm＠interlinknetworks.com 09 Jan '07

09 Jan '07

I have patched the 2.3.20 code to make all connections non-blocking. I did not address referrals, and I'm sure there are other features I overlooked as well. Would it be helpful to see what I have done to get around the problem? I would be happy to send you a patch. That's all for now, --Larry Morris Interlink Networsk, LLC. lrm(a)interlinknetworks.com On Tue, 2007-01-09 at 19:23, Pierangelo Masarati wrote: > Larry Morris wrote: > > Your efforts are appreciated. > > > > Please see my additional responses inline below. > > > > My single-threaded application requires that multiple connection > > attempts may be in-progress simultaneously, in conjunction with other > > activities that need timely attention. In other words, I need to have > > multiple connections in non-blocking SSL_connect() at the same time, > > with the application doing select() on all the LDAP connection sockets > > as needed. The fix you have provided will allow this? > > > No, at a first glance it's not going to have any impact on that portion > of code. I'll try to sort out if and how anything similar can be done > in that area. > > What is the time-frame for this to be available in a "stable" version? > > > There's no definite timeframe. It's not going to appear in OpenLDAP > 2.3, since it's feature frozen and this does not represent a significant > bug fix, but rather a new, marginal feature. 2.4 is on its way, and > this code will surely be in the next 2.4 release. Whether this will be > still alpha or release, I have no idea right now. > > 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#4799) kbind removal
by Kurt＠OpenLDAP.org 09 Jan '07

09 Jan '07

At 04:48 PM 1/9/2007, Kurt(a)OpenLDAP.org wrote: >At 02:23 PM 1/9/2007, quanah(a)OpenLDAP.org wrote: >>Full_Name: Quanah Gibson-Mount >>Version: HEAD/2.4 >>OS: NA >>URL: ftp://ftp.openldap.org/incoming/ >>Submission from: (NULL) (171.66.155.86) >> >> >>kbind was slated for removal in 2.2, but was missed. Before 2.4 goes out, kbind >>should be finally removed from HEAD & 2.4. > >There is no KBIND support in current HEAD. s/no/no longer/ Ando had me thinking I had already axed it. But it's now axed. Kurt

1 0

Re: (ITS#4799) kbind removal
by Kurt＠OpenLDAP.org 09 Jan '07

09 Jan '07

At 02:23 PM 1/9/2007, quanah(a)OpenLDAP.org wrote: >Full_Name: Quanah Gibson-Mount >Version: HEAD/2.4 >OS: NA >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (171.66.155.86) > > >kbind was slated for removal in 2.2, but was missed. Before 2.4 goes out, kbind >should be finally removed from HEAD & 2.4. There is no KBIND support in current HEAD. Kurt

1 0

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

09 Jan '07

Larry Morris wrote: > Your efforts are appreciated. > > Please see my additional responses inline below. > > My single-threaded application requires that multiple connection > attempts may be in-progress simultaneously, in conjunction with other > activities that need timely attention. In other words, I need to have > multiple connections in non-blocking SSL_connect() at the same time, > with the application doing select() on all the LDAP connection sockets > as needed. The fix you have provided will allow this? > No, at a first glance it's not going to have any impact on that portion of code. I'll try to sort out if and how anything similar can be done in that area. > What is the time-frame for this to be available in a "stable" version? > There's no definite timeframe. It's not going to appear in OpenLDAP 2.3, since it's feature frozen and this does not represent a significant bug fix, but rather a new, marginal feature. 2.4 is on its way, and this code will surely be in the next 2.4 release. Whether this will be still alpha or release, I have no idea right now. 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#4799) kbind removal
by quanah＠OpenLDAP.org 09 Jan '07

09 Jan '07

Full_Name: Quanah Gibson-Mount Version: HEAD/2.4 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) kbind was slated for removal in 2.2, but was missed. Before 2.4 goes out, kbind should be finally removed from HEAD & 2.4.

1 0

Re: (ITS#4494) connections are not asynchrounous
by lrm＠interlinknetworks.com 09 Jan '07

09 Jan '07

Your efforts are appreciated. Please see my additional responses inline below. My single-threaded application requires that multiple connection attempts may be in-progress simultaneously, in conjunction with other activities that need timely attention. In other words, I need to have multiple connections in non-blocking SSL_connect() at the same time, with the application doing select() on all the LDAP connection sockets as needed. The fix you have provided will allow this? What is the time-frame for this to be available in a "stable" version? That's all for now, --Larry Morris Interlink Networks, LLC. lrm(a)interlinknetworks.com On Mon, 2007-01-08 at 08:39, Pierangelo Masarati wrote: > Is it an option for you to use Start TLS instead of ldaps? In this I could try using ldap_start_tls() as a quick-and-dirty test to verify that you have fixed the connection issues, but it is not acceptable for our production use. We must support LDAPv2, which does not allow the use of start TLS. Are you planning to support this for ldaps: URLs in the future? Do you need/want me to verify that using start TLS with your patches fixes the connection issues? I would prefer to hold off until the ldaps: support is in place. > 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). What is the "right HEAD" CVS branch? Do I have access to that branch via anonymous CVS? I am not very familiar with CVS, a sample command line to retrieve the correct sources would be quite helpful. > > 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). Can I leave LDAP_OPT_CONNECT_ASYNC set to TRUE always? I would like referrals, if used, to be non-blocking as well. Could you make this automatic in ldap_int_tls_start()?

1 0

Re: (ITS#4796) Contribution: JLDAP support for simple paging of results (RFC 2696)
by Kurt＠OpenLDAP.org 08 Jan '07

08 Jan '07

At 03:28 PM 1/6/2007, radovan(a)skolnik.info wrote: >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. Your submission lacks both a notice of origin and a rights statement, as required of contributions. See <http://www.openldap.org/devel/contributing.html#notice>. Though submissions such as this should be in the form of patch file (with notices placed above the patch in the file), a zip file is acceptable. In this case, just place the required notice and statement in a file called NOTICE. Please revise. -- Kurt

1 0

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

08 Jan '07

ando(a)sys-net.it wrote: > Apparently, the cache lru is not initialized. Backtrace: > works for me, now. Thanks, 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#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

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