openldap-bugs December 2006

openldap-bugs@openldap.org

23 participants
120 discussions

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

21 Dec '06

robb(a)wtg.cw.com wrote: > 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: I'll note that unless you defined it yourself, "dn" is not a valid attribute name. I suspect your back-sql meta-data generates an entry that doesn't pass schema checking, otherwise I don't see a chance for that error to be reported. 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. 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 Kurt＠OpenLDAP.org 21 Dec '06

21 Dec '06

At 01:51 PM 12/20/2006, fcusack(a)fcusack.com wrote: >But still you can do the bind async, and just close the fd on the client >side on timeout. If you are waiting on a timeout, you're not truely async. Truely async implies never blocking, including not blocking for a time. > 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) My comments were for truely async. -- Kurt

1 0

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

20 Dec '06

On December 20, 2006 9:18:18 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > fcusack(a)fcusack.com wrote: >> On December 19, 2006 7:04:15 PM -0800 "Kurt D. Zeilenga" >> <Kurt(a)OpenLDAP.org> wrote: >> >>> At 05:32 PM 12/19/2006, fcusack(a)fcusack.com wrote: >>> >>>> Full_Name: Frank Cusack >>>> Version: 2.3.27 >>>> OS: any >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (209.76.127.62) >>>> >>>> connect() is always done synchronously. Any idea when this will be >>>> fixed? >>>> >>> It's actually not considered a bug. ldap_sasl_bind(3) is async >>> in doesn't wait for the LDAP response. There is no LDAP restart >>> API, as would be needed if the API didn't block on various >>> system calls. >>> >> >> Why is that required here? >> >> ldap_sasl_bind() >> ldap_result() >> if (timeout) { >> ldap_abandon() >> if (just_return_on_error) { >> return error >> } else { >> do_something_else >> } >> } >> >> To restart a bind, just abandon and bind again. >> > There was a discussion recently on the subject (look in hte ITS). A bind > cannot be abandoned as per RFC 4511-19; you need to ldap_unbind_ext and > recreate a fresh connection. OK, I see that abandon isn't really the right thing here. 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) -frank

1 0

(ITS#4786) back-sql searching with dn attribute selected causes object class violation
by robb＠wtg.cw.com 20 Dec '06

20 Dec '06

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:

1 0

(ITS#4785) back-sql objectclass searches fail unless there is data in ldap_entry_objclasses
by robb＠wtg.cw.com 20 Dec '06

20 Dec '06

Full_Name: Robert Brooks Version: 2.3.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.49.19.14) 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. +----------+----------+ | entry_id | oc_name | +----------+----------+ | 0 | dcObject | +----------+----------+

1 0

(ITS#4784) a small patch for back-sql
by robb＠wtg.cw.com 20 Dec '06

20 Dec '06

Full_Name: Robert Brooks Version: 2.3.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/openldap-2.3.30-tracesql.patch Submission from: (NULL) (62.49.19.14) back-sql fails to compile with BACKSQL_TRACE defined, I think this is the correct fix.

1 0

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

20 Dec '06

fcusack(a)fcusack.com wrote: > On December 19, 2006 7:04:15 PM -0800 "Kurt D. Zeilenga" > <Kurt(a)OpenLDAP.org> wrote: > >> At 05:32 PM 12/19/2006, fcusack(a)fcusack.com wrote: >> >>> Full_Name: Frank Cusack >>> Version: 2.3.27 >>> OS: any >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (209.76.127.62) >>> >>> connect() is always done synchronously. Any idea when this will be >>> fixed? >>> >> It's actually not considered a bug. ldap_sasl_bind(3) is async >> in doesn't wait for the LDAP response. There is no LDAP restart >> API, as would be needed if the API didn't block on various >> system calls. >> > > Why is that required here? > > ldap_sasl_bind() > ldap_result() > if (timeout) { > ldap_abandon() > if (just_return_on_error) { > return error > } else { > do_something_else > } > } > > To restart a bind, just abandon and bind again. > There was a discussion recently on the subject (look in hte ITS). A bind cannot be abandoned as per RFC 4511-19; you need to ldap_unbind_ext and recreate a fresh connection. > I am not all that familiar with the LDAP API, so forgive me if I'm > way off base here. > 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#4780) ACL set memory leak
by dhawes＠vt.edu 20 Dec '06

20 Dec '06

On Tuesday 19 December 2006 23:42, hyc(a)symas.com wrote: > David Hawes wrote: > > Here's the valgrind output with the set clause in place: > > > > http://filebox.vt.edu/users/dhawes/valgrind-with-set.log > > > > Here's the valgrind output without the set clause (for reference): > > > > http://filebox.vt.edu/users/dhawes/valgrind-without-set.log > > > > The following patch causes memory use to stabilize with my SLAMD test: > > Try the patch in HEAD sets.c 1.29 -> 1.30. I haven't tested the patch with valgrind yet, but I no longer see the memory leak with my SLAMD test. Thanks for your help with this. dave

1 0

ITS#3971 slapo-glue and slapo-rwm
by hyc＠symas.com 20 Dec '06

20 Dec '06

This issue has been fixed in HEAD with the patches for ITS#4638. This ITS will be closed in favor of #4638. -- -- 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#4780) ACL set memory leak
by hyc＠symas.com 20 Dec '06

20 Dec '06

David Hawes wrote: > Here's the valgrind output with the set clause in place: > > http://filebox.vt.edu/users/dhawes/valgrind-with-set.log > > Here's the valgrind output without the set clause (for reference): > > http://filebox.vt.edu/users/dhawes/valgrind-without-set.log > > The following patch causes memory use to stabilize with my SLAMD test: Try the patch in HEAD sets.c 1.29 -> 1.30. -- -- 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

← Newer
1
2
3
4
5
6
7
...
12
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2006