Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by ando＠sys-net.it
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
------------------------------------------
14 years, 11 months
Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by Kurt＠OpenLDAP.org
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
14 years, 11 months
Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com
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
14 years, 11 months
(ITS#4786) back-sql searching with dn attribute selected causes object class violation
by robb＠wtg.cw.com
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:
14 years, 11 months
Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it
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
------------------------------------------
14 years, 11 months
