python-ldap-dev — discussion among developers

Re: patch to compile with OpenLDAP 2.0.7

[David L. <dav...@ds...>]

Hi everyone. I'm in germany at the moment

hey these patches look ok

i have a medium concern, something that i've been guilty of and would like to
see go away, and that is conditional existance of interfaces.

eg  ufn_search_s() might be #ifdef'd out and some python program that wants
to use it will get a NameError when it tries to use it. A better exception
would be NotImplementedError.

ie instead of writing

	#ifdef LDAP_API_THING
	ldap_ufn_search_s(PyObject blah, blah) {
		blah;
	}
	#endif

it ought to be

	ldap_ufn_search_s(PyObject blah, blah) {
	#ifdef LDAP_API_THING
		blah;
	#else
		return Py_ErrObject(Py_NotImplementeError);
	#endif
	}

A similar problem arises with 'constants'.. I'm not sure what to do here..
make all undefined cosntants equal None?

also there should be some nice way of reliably determining the
underlying library's api version ... maybe _ldap.api_version...
any suggestions on how that might be done nicely are welcome.

tschuss!

d

On Fri, 17 Nov 2000, Konstantin Chuguev typed thusly:

> Hello Jeffrey and all.
>
> Attached are recent version of my patches, if you are interested. They
> provide the following:
>
>    * automatic recognition of OpenLDAP-1.2.x or OpenLDAP-2.0.x at compilation
>      time, building different sets of Python LDAP constants and error
>      exception objects for different OpenLDAP versions;
>    * special tuples for continuation references: (None, [list_of_URLs]).
>      Compare to normal entry tuples: (DN, {dict_of_attributes}). Both types
>      of tuples can be returned from search methods;
>    * new type of result type in the result method: SEARCH_REFERENCE.
>    * a few new ldap object attributes, among them: referrals - disables (0)
>      or enables (1) following referrals; is set to 1 after ldap object
>      initialisation; version (2 or 3) - sets LDAP protocol version (default
>      is 2).
>
> Any comments/suggestions/fixes are welcome.
>
>
> Regards,
>     Konstantin.
>
> "Jeffrey C. Ollie" wrote:
>
> > On Thu, Nov 16, 2000 at 11:55:57PM +0100, Michael Ströder wrote:
> > > "Jeffrey C. Ollie" wrote:
> > > >
> > > > I've gotten today's CVS version to compile against OpenLDAP 2.0.7.
> > >
> > > Ooops. Double efforts. I'm currently testing patches by Konstantin
> > > (Cc:-ed) which also allow to retrieve search continuation references
> > > (LDAPv3 referrals).
> > >
> > > He made some changes to attributes of LDAPObject. Especially setting
> > > the options is different.
> >
> > I didn't know that anyone else was working on it...  The list has been
> > quiet for some time now.  It looks like Konstantin's work goes beyond
> > what I intended to accomplish.  I wasn't looking to add any
> > functionality, just to get python-ldap to compile and work.  But I'd
> > be happy to test out other patches and perhaps fix a bug or two.
> >
> > Jeff
> >
> >   ------------------------------------------------------------------------
> >    Part 1.2Type: application/pgp-signature
>
> --
>           * *        Konstantin Chuguev - Application Engineer
>        *      *              Francis House, 112 Hills Road
>      *                       Cambridge CB2 1PQ, United Kingdom
>  D  A  N  T  E       WWW:    http://www.dante.net
>
>
>

-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Cassette tapes have an almost unlimited capacity for data.
  - Commodore 64 Programmer's Reference Guide (1983)

Re: patch to compile with OpenLDAP 2.0.7

[Konstantin C. <Kon...@da...>]

Hello Jeffrey and all.

Attached are recent version of my patches, if you are interested. They
provide the following:

   * automatic recognition of OpenLDAP-1.2.x or OpenLDAP-2.0.x at compilation
     time, building different sets of Python LDAP constants and error
     exception objects for different OpenLDAP versions;
   * special tuples for continuation references: (None, [list_of_URLs]).
     Compare to normal entry tuples: (DN, {dict_of_attributes}). Both types
     of tuples can be returned from search methods;
   * new type of result type in the result method: SEARCH_REFERENCE.
   * a few new ldap object attributes, among them: referrals - disables (0)
     or enables (1) following referrals; is set to 1 after ldap object
     initialisation; version (2 or 3) - sets LDAP protocol version (default
     is 2).

Any comments/suggestions/fixes are welcome.


Regards,
    Konstantin.

"Jeffrey C. Ollie" wrote:

> On Thu, Nov 16, 2000 at 11:55:57PM +0100, Michael Ströder wrote:
> > "Jeffrey C. Ollie" wrote:
> > >
> > > I've gotten today's CVS version to compile against OpenLDAP 2.0.7.
> >
> > Ooops. Double efforts. I'm currently testing patches by Konstantin
> > (Cc:-ed) which also allow to retrieve search continuation references
> > (LDAPv3 referrals).
> >
> > He made some changes to attributes of LDAPObject. Especially setting
> > the options is different.
>
> I didn't know that anyone else was working on it...  The list has been
> quiet for some time now.  It looks like Konstantin's work goes beyond
> what I intended to accomplish.  I wasn't looking to add any
> functionality, just to get python-ldap to compile and work.  But I'd
> be happy to test out other patches and perhaps fix a bug or two.
>
> Jeff
>
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature

--
          * *        Konstantin Chuguev - Application Engineer
       *      *              Francis House, 112 Hills Road
     *                       Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E       WWW:    http://www.dante.net

Re: patch to compile with OpenLDAP 2.0.7

[Jeffrey C. O. <je...@ol...>]

On Thu, Nov 16, 2000 at 11:55:57PM +0100, Michael Str=F6der wrote:
> "Jeffrey C. Ollie" wrote:
> >=20
> > I've gotten today's CVS version to compile against OpenLDAP 2.0.7.
>=20
> Ooops. Double efforts. I'm currently testing patches by Konstantin
> (Cc:-ed) which also allow to retrieve search continuation references
> (LDAPv3 referrals).
>=20
> He made some changes to attributes of LDAPObject. Especially setting
> the options is different.

I didn't know that anyone else was working on it...  The list has been
quiet for some time now.  It looks like Konstantin's work goes beyond
what I intended to accomplish.  I wasn't looking to add any
functionality, just to get python-ldap to compile and work.  But I'd
be happy to test out other patches and perhaps fix a bug or two.

Jeff

Re: patch to compile with OpenLDAP 2.0.7

[Michael <mi...@st...>]

"Jeffrey C. Ollie" wrote:
> 
> I've gotten today's CVS version to compile against OpenLDAP 2.0.7.

Ooops. Double efforts. I'm currently testing patches by Konstantin
(Cc:-ed) which also allow to retrieve search continuation references
(LDAPv3 referrals).

He made some changes to attributes of LDAPObject. Especially setting
the options is different.

Would be nice if you coordinate your work. Thanks to both of you.

Ciao, Michael.

patch to compile with OpenLDAP 2.0.7

[Jeffrey C. O. <je...@ol...>]

I've gotten today's CVS version to compile against OpenLDAP 2.0.7.  It
seems that the OpenLDAP people dropped a number of macros between v1
and v2.  A fairly simple patch that #ifdefs the dropped macros and
everything compiles fine.  Oh yeah, I did have to use "LIBS=-lresolv
./configure" to get the configure script to properly: apparently the
RedHat RPM for OpenLDAP introduces a depencency because the configure
script fails with an undefined reference to __dn_expand and
__res_query.

I've attached the patch and also entered a bug on sourceforge.

Jeff

Comme convenu..

[RICO <eri...@ca...>]

Voici le site de jeux sur lequel Michèle a gagné 10 000 Balles.

www.duoloto.com


A+

Eric ;-)) 

Re: patch: l_ldap_result() now properly raising exceptions

[Michael <mi...@st...>]

David Leonard wrote:
> 
> fix committed

Now I have problems doing an CVS update:

michael@junker:~/src/python-ldap/python-ldap > cvs update .
str...@cv...'s password: 
cvs server: Updating .
cvs server: failed to create lock directory in repository
`/cvsroot/python-ldap/python-ldap': Permission denied
cvs server: failed to obtain dir lock in repository
`/cvsroot/python-ldap/python-ldap'
cvs [server aborted]: read lock failed - giving up

Hmm, this used to work...

Ciao, Michael.

Re: patch: l_ldap_result() now properly raising exceptions

[David L. <dav...@cs...>]

On Tue, 17 Oct 2000, Michael Ströder typed thusly:

> Konstantin Chuguev wrote:
> > 
> > Oughh. After some late hacking tonight, here we are :-)
> 
> GREAT!!! It works.
> 
> I have attached Konstantin's patch to this message. Could someone
> with more Python/C knowledge look into the patched LDAPObject.c
> function l_ldap_result() to make sure that we do not introduce new
> memory leaks with this patch?
> 
> Note: Since the result() method now properly raises exceptions
> caused by LDAP errors one might have to add additional exception
> handling to the calling Python code.

fix committed

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Curses! - Mojo Jojo

Re: web2ldap with patched python-ldap

[Michael <mi...@st...>]

Konstantin Chuguev wrote:
> 
> > > The only problem is, if the search done in w2lsearch.py returns 
> > > both
> > > normal entries and referral(s), an exception will be raised in 
> > > the end,
> > > passing the control to w2lreferral.py, and the list of normal 
> > > values will
> > > be lost. Perhaps you should handle except ldap.PARTIAL_RESULTS in
> > > w2lsearch.py itself?
> >
> > Hmm, I think if doing a search with scope one/sub and a search
> > continuation is received together with normal search results
> > l_ldap_result() should return a different result type instead of
> > raising ldap.PARTIAL_RESULTS. I could then gracefully handle the
> > search continuation in the while loop. Do you think this could be
> > done based on the OpenLDAP 1.2.x libs?
> >
> 
> For a one-level search (browsing mode), it would be nice if entries referenced
> by referrals and thus held on other servers were shown almost like local
> entries in the list

I tried this with the new patch.

Unfortunately if a referral (search continuation) during one level
search raises an exception there will no results returned
afterwards. The next call of result() method (ldap_result() function
of C API) blocks. Also the exception object does neither contain the
full LDAP URL or the DN of the referral entry.

=> there's currently no way to retrieve search continuations and
normal search results together without modifying python-ldap.

Ciao, Michael.

patch: l_ldap_result() now properly raising exceptions

[Michael <mi...@st...>]

Konstantin Chuguev wrote:
> 
> Oughh. After some late hacking tonight, here we are :-)

GREAT!!! It works.

I have attached Konstantin's patch to this message. Could someone
with more Python/C knowledge look into the patched LDAPObject.c
function l_ldap_result() to make sure that we do not introduce new
memory leaks with this patch?

Note: Since the result() method now properly raises exceptions
caused by LDAP errors one might have to add additional exception
handling to the calling Python code.

Ciao, Michael.

Newbe help

[Xander v. E. <xa...@bo...>]

Hello,

Could anybody tell me where i can find the documentation of the =
python-ldap
module?
Where there is clearly explained wich functions there are and how they =
work.
I've some trouble with adding persons to the ldap server. I managed to =
add
organisationalunits.
I use this code:

try:
 dn =3D "cn=3DJorgen, dc=3DPeople, dc=3DMailinglist,o=3Dbos,c=3Dnl"
 print "Updating", repr(dn)

        l.add_s(dn,
         [
            ("cn", ["Jorgen"]),
            ("givenname", ["Jorgen"]),
            ("objectclass",["top"]),
            ("objectclass",["person"]),
            ("objectclass",["organizationalperson"]),
            ("Phone", ["065464894"]),
            ("description", ["Miljonair"])
         ]
       )

except ldap.LDAPError:
        pass

l.unbind()

I get no error's but after i execute it, it isn't inserted........

Best. Regards,

Xander van Es

LET OP!: nieuw adres (tel. + fax ongewijzigd).
Bos pioneers in web-building
Telefoonweg 44 b
6712 GD Ede
tel +31 318 693111
fax + 31 318 693042
http://www.bos.nl

(no subject)

[Xander v. E. <xa...@bo...>]

Hello,

Could anybody tell me where i can find the documentation of the =
python-ldap
module?
Where there is clearly explained wich functions there are and how they =
work.
I've some trouble with adding persons to the ldap server. I managed to =
add
organisationalunits.
I use this code:

try:
 dn =3D "cn=3DJorgen, dc=3DPeople, dc=3DMailinglist,o=3Dbos,c=3Dnl"
 print "Updating", repr(dn)

        l.add_s(dn,
         [
            ("cn", ["Jorgen"]),
            ("givenname", ["Jorgen"]),
            ("objectclass",["top"]),
            ("objectclass",["person"]),
            ("objectclass",["organizationalperson"]),
            ("Phone", ["065464894"]),
            ("description", ["Miljonair"])
         ]
       )

except ldap.LDAPError:
        pass

l.unbind()

I get no error's but after i execute it, it isn't inserted........

Best. Regards,

Xander van Es

LET OP!: nieuw adres (tel. + fax ongewijzigd).
Bos pioneers in web-building
Telefoonweg 44 b
6712 GD Ede
tel +31 318 693111
fax + 31 318 693042
http://www.bos.nl

Re: web2ldap with patched python-ldap

[Michael <mi...@st...>]

Konstantin,

sorry for answering so late.

Konstantin Chuguev wrote:
> 
> I could not resist to try the patch I proposed on my web2ldap.

You patched python-ldap?

> Unsurprisingly, it does not work, raising the DECODING_ERROR exception:
> [..]
> I think this can happen when ldap_result() method returns Py_None, as
> your code always assume there is a tuple returned.

Yes.

Can you please send patches to the python-ldap-dev list? Even if
they don't work they are a start of coding the error handling in the
asynchronous calls.

I think David should have a look at it.

Ciao, Michael.

Re: Referrals...

[Konstantin C. <Kon...@da...>]

Michael Ströder wrote:

> Konstantin Chuguev wrote:
> >
> >      LDAP_BEGIN_ALLOW_THREADS( self );
> >      result_type = ldap_result( self->ldap, msgid, all, tvp, &msg
> >      );
> >      result = ldap_result2error( self->ldap, msg, 0 );
> >      LDAP_END_ALLOW_THREADS( self );
>
> Hmm, my slapd logs the occurence of the referral right after calling
> the search() method of the LDAP object. I guess the function
> ldap_result2error() should be called in l_ldap_search() either.
>

I think, this just means the LDAP server could answer immediately
(because of this low load and fast database). The result was probably
sent to the client and was caught by the LDAP library in some buffers.
You could issue other search requests and then start collecting results
of all the requests one by one with ldap_result() until LDAP library
buffers are empty. This is how I understand the asynchronous mode.

The l_ldap_result() python-ldap function is correct in the sense that it
just wraps the corresponding ldap_result() C function, no more no less.
Exception is raised only in case of LDAP or system error. But then msg
is converted to Python format (dictionary) and its C representation is
destroyed before exiting the function. It's not possible anymore to
provide data for ldap_result2error, even if there was a Python wrapper
for it. So the only solution I see is combining both C functions -
ldap_result() and ldap_result2error() in one wrapper.
No return data is lost because of Python exceptions.

I've attached a patch for l_ldap_result function.
Note that now the function raises exceptions both in case of an LDAP or
system error AND an unsuccessful LDAP operation result (including
LDAP_PARTIAL). It returns Py_None object if there was no result at all
(i.e. timeout has occured or no async requests were issued to the server
before the call).

--
          * *        Konstantin Chuguev - Application Engineer
       *      *              Francis House, 112 Hills Road
     *                       Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E       WWW:    http://www.dante.net

Re: Referrals...

[Michael <mi...@st...>]

Konstantin Chuguev wrote:
> 
>      LDAP_BEGIN_ALLOW_THREADS( self );
>      result_type = ldap_result( self->ldap, msgid, all, tvp, &msg
>      );
>      result = ldap_result2error( self->ldap, msg, 0 );
>      LDAP_END_ALLOW_THREADS( self );

Hmm, my slapd logs the occurence of the referral right after calling
the search() method of the LDAP object. I guess the function
ldap_result2error() should be called in l_ldap_search() either.

Ciao, Michael.

Re: Referrals...

[Michael <mi...@st...>]

Konstantin Chuguev wrote:
> 
> The problem is that python-ldap assumes ldap_result() returns, like
> ldap_search() and many other C LDAP API functions, an LDAP error code,
> which is wrong, according to the API.
> [..]
> To check if there was an LDAP error while
> processing an asynchronous request, one needs to call int
> ldap_result2error(LDAP *ld, LDAPMessage *res, int freeit) after
> ldap_result().

You're right.

>      result_type = ldap_result( self->ldap, msgid, all, tvp, &msg
>      );
>      result = ldap_result2error( self->ldap, msg, 0 );
> 
> ... but the drawback is that in this case the result type variable is
> getting hidden to a python caller.

No drawback since we have exceptions! :-) Look at the lines
following the ldap_result() call:

    if (result == -1)
        return LDAPerror( self->ldap, "ldap_result" );

etc.

I think this should raise an exception. IMHO David planned to do it
right but forgot to call ldap_result2error() function.

Ciao, Michael.

Re: Referrals...

[Konstantin C. <Kon...@da...>]

Hi All,

I seem to have found the bug (Michael, this time I'm quite sure ;-)

The problem is that python-ldap assumes ldap_result() returns, like
ldap_search() and many other C LDAP API functions, an LDAP error code,
which is wrong, according to the API. ldap_result() always returns the
type of the result retrieved, which is a constant like
LDAP_RES_SERARCH_ENTRY, LDAP_RES_SEARCH_RESULT, LDAP_RES_BIND_RESULT,
LDAP_RES_COMPARE_RESULT etc. To check if there was an LDAP error while
processing an asynchronous request, one needs to call int
ldap_result2error(LDAP *ld, LDAPMessage *res, int freeit) after
ldap_result(). python-ldap's static PyObject *l_ldap_result() does not
do it.
A possible solution would be the following change in
python-ldap-*/Modules/LDAPObject.c, function static PyObject
*l_ldap_result( LDAPObject* self, PyObject *args ):

     LDAP_BEGIN_ALLOW_THREADS( self );
     result = ldap_result( self->ldap, msgid, all, tvp, &msg );
     LDAP_END_ALLOW_THREADS( self );

for

     int result_type;
     ...
     LDAP_BEGIN_ALLOW_THREADS( self );
     result_type = ldap_result( self->ldap, msgid, all, tvp, &msg
     );
     result = ldap_result2error( self->ldap, msg, 0 );
     LDAP_END_ALLOW_THREADS( self );

... but the drawback is that in this case the result type variable is
getting hidden to a python caller.

Any ideas?

Michael Ströder wrote:

> HI!
>
> Back to a python-ldap build with OpenLDAP 1.2.11 libs:
>
> It seems that referral exceptions are not raised if doing an
> asynchronous search call. In the example below the entry
> ldap://localhost:1389/c=DE is a referral entry holding the ref
> attribute ldap://ldap.nameflow.net:1389. l is my LDAP connection
> object.
>
> >>> l.options=0
> >>> l.search_s('c=DE',ldap.SCOPE_ONELEVEL,'(objectclass=*)')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ldap.PARTIAL_RESULTS: {'desc': 'Partial results and referral
> received', 'info':
> 'Referral:\012ldap://ldap.nameflow.net:1389/c=DE', 'matched':
> 'c=DE'}
>
> This seems to be ok.
>
> >>> m=l.search('c=DE',ldap.SCOPE_ONELEVEL,'(objectclass=*)')
> >>> l.result(m,0)
> ('RES_SEARCH_RESULT', [])
>
> This seems not ok to me. Shouldn't there be an exception
> ldap.PARTIAL_RESULTS raised? My OpenLDAP 2.0.6 slapd logs that a
> referral occured immediately after invoking the l.search() method.
>
> Ciao, Michael.

--
          * *        Konstantin Chuguev - Application Engineer
       *      *              Francis House, 112 Hills Road
     *                       Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E       WWW:    http://www.dante.net

Referrals...

[Michael <mi...@st...>]

HI!

Back to a python-ldap build with OpenLDAP 1.2.11 libs:

It seems that referral exceptions are not raised if doing an
asynchronous search call. In the example below the entry
ldap://localhost:1389/c=DE is a referral entry holding the ref
attribute ldap://ldap.nameflow.net:1389. l is my LDAP connection
object.

>>> l.options=0
>>> l.search_s('c=DE',ldap.SCOPE_ONELEVEL,'(objectclass=*)')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ldap.PARTIAL_RESULTS: {'desc': 'Partial results and referral
received', 'info':
'Referral:\012ldap://ldap.nameflow.net:1389/c=DE', 'matched':
'c=DE'}

This seems to be ok.

>>> m=l.search('c=DE',ldap.SCOPE_ONELEVEL,'(objectclass=*)')
>>> l.result(m,0)
('RES_SEARCH_RESULT', [])

This seems not ok to me. Shouldn't there be an exception
ldap.PARTIAL_RESULTS raised? My OpenLDAP 2.0.6 slapd logs that a
referral occured immediately after invoking the l.search() method.

Ciao, Michael.

Re: Building python-ldap against Netscape's LDAP-SDK 4.11

[Michael <mi...@st...>]

HI!

Well, I have to admit that I messed up the libs => forget about my
previous pseudo-results. I tried again to build python-ldap against
Netscape's LDAP-SDK 4.11 but it fails.

David, could you have a look at this? Is there any chance that it's
possible to build against 4.11?

Maybe it would make more sense to dig into the OpenLDAP 2.x libs?

Ciao, Michael.

ldap_set_option() and ldap_get_option()

[Michael <mi...@st...>]

HI!

it would be nice if python-ldap exposes the ldap_set_option() and
ldap_get_option() calls and the constants of Netscape's SDK. I'm
fine if it could be done with simple methods of LDAPObject class.

According to the Netscape's C-SDK docs this would solve many of my
problems.

Ciao, Michael.

Re: Building python-ldap against Netscape's LDAP-SDK 4.11

[Michael <mi...@st...>]

David Leonard wrote:
> 
> On Thu, 5 Oct 2000, Michael Ströder typed thusly:
> 
> > > Ok, I edited Modules/LDAPObject.c to use only 2 arguments. The
> 
> really, configure.in should be modified to test for and pick that up...

Uuuh, I removed config.cache. After that configure was able to
determine the right value for LDAP_SET_REBIND_PROC_3ARGS.

> > > ldap.LDAPError: unknown error (C API does not expose error)
> 
> I just looked at netscape's docs and found the function ldap_get_lderrno().
> i've added it in (untested patch at end of message)

This patch seems to work now.

> > It's me again. ;-)
> 
> talking to yourself is a sign of impending madness :)

We're all kinda mad, aren't we. ;-)

> > I managed to connect to a OpenLDAP 2.0.6 server (which is LDAPv3).
> > Connecting to OpenLDAP 1.2.11 server (LDAPv2) does not work.

I was able to connect to both OpenLDAP versions now. Unfortunately
it does "do_bind: v2 anonymous bind" to the OpenLDAP 2 server. But I
would like to have a v3 bind.

> >     ldap_obj.options = 0
> > NameError: cannot set that field
> 
> hmm, perhaps this is a design error. if the C API doesn't support things
> like options, then there will be no .options attribute to set. I had
> originally imagined people writing code like:
> 
>         if hasattr(ldap_obj, 'options'): ldap_obj.options = 0

I'm fine with doing a hasattr(ldap_obj, 'options').

But I want to avoid that the LDAP lib itself chases the referral.
How to do that with Netscape's SDK?

> however at this level (_ldap), I really wanted to get as close to the
> C api as possible, and leave it to "higher-level" abstractions to deal with
> such nitty gritty logic.

That's ok.

> > I would like to actively catch LDAPv3 referrals.
> 
> suggested patches are welcome :)

I'm not a C programmer. :-(

If
1. I can set .options or a similar field with Netscape's SDK to
switch off OPT_REFERRALS and
2. I can do a LDAPv3 bind
I would be quite happy.

Ciao, Michael.

Re: Building python-ldap against Netscape's LDAP-SDK 4.11

[David L. <dav...@cs...>]

On Thu, 5 Oct 2000, Michael Ströder typed thusly:

> > Ok, I edited Modules/LDAPObject.c to use only 2 arguments. The

really, configure.in should be modified to test for and pick that up...
can you send me your diffs to LDAPObject.c?

> > module builds now and import ldap works. But it gives me undefined
> > exceptions.
> > 
> > ldap.LDAPError: unknown error (C API does not expose error)

I just looked at netscape's docs and found the function ldap_get_lderrno().
i've added it in (untested patch at end of message)

i'm also going to upgrade Misc/openldap.sh to grab an OpenLDAP 2 release
but it seems I'll need to bundle libtool into the distribution :(

> It's me again. ;-)

talking to yourself is a sign of impending madness :)

> I managed to connect to a OpenLDAP 2.0.6 server (which is LDAPv3).
> Connecting to OpenLDAP 1.2.11 server (LDAPv2) does not work. It
> seems it has something to do with choosing LDAPv3 during connect and
> falling back to LDAPv2 if v3 fails.
> 
> I can browse my test data on the OpenLDAP 2.0 server. But when I hit
> a LDAPv3 referral entry the exception above is raised. I guess the
> C-LDAP-SDK returns some LDAPv3 specific data not known to
> python-ldap.

no, its probably a simple error, just have to teach the module how to find it.

> BTW: The following code is also rejected (it works with OpenLDAP
> 1.2.11 libs):
> 
> ldap_obj.deref = ldap.DEREF_NEVER
> ldap_obj.options = 0
> 
> Traceback:
> [..]
>     ldap_obj.options = 0
> NameError: cannot set that field
> 
> Why I want this?

hmm, perhaps this is a design error. if the C API doesn't support things
like options, then there will be no .options attribute to set. I had 
originally imagined people writing code like:

	if hasattr(ldap_obj, 'options'): ldap_obj.options = 0

which shows the variability of the C libraries.

however at this level (_ldap), I really wanted to get as close to the
C api as possible, and leave it to "higher-level" abstractions to deal with 
such nitty gritty logic.

> I would like to actively catch LDAPv3 referrals. This works slightly
> well with catching ldap.PARTIAL_RESULTS and pulling the referral
> LDAP URL out of the info field.
> However, if binding via LDAPv2 (OpenLDAP 1.2.x libs) to a LDAPv3
> server
> 1. the server is free to just ignore my request if a referral is hit
> and
> 2. I don't get the search continuations of the referral entry when
> doing a one level search.
> This causes a lot of inconsistent behaviour of my client (besides
> all those broken LDAP servers out there...sigh!).

suggested patches are welcome :)

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Index: errors.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/errors.c,v
retrieving revision 1.3
diff -u -r1.3 errors.c
--- errors.c	2000/08/14 22:37:37	1.3
+++ errors.c	2000/10/05 23:44:05
@@ -30,7 +30,7 @@
 		PyErr_SetFromErrno( LDAPexception_class );
 		return NULL;
 	}
-#ifdef LDAP_TYPE_IS_OPAQUE
+#if !defined(HAVE_LDAP_GET_LDERRNO) && defined(LDAP_TYPE_IS_OPAQUE)
 	else {
 		PyErr_SetString(LDAPexception_class,
 			"unknown error (C API does not expose error)");
@@ -42,8 +42,16 @@
 		PyObject *errobj;
 		PyObject *info;
 		PyObject *str;
+		char *m, *s;
 
+#if defined(HAVE_LDAP_GET_LDERRNO)
+		errnum = ldap_get_lderrno(l, &m, &s);
+#else
 		errnum = l->ld_errno;
+		m = l->ld_matched;
+		s = l->ld_error;
+#endif
+
 		if (errnum<0 || errnum>=NUM_LDAP_ERRORS)
 			errobj = LDAPexception_class;	/* unknown error XXX */
 		else
@@ -60,22 +68,19 @@
 		if (str)
 			PyDict_SetItemString( info, "desc", str );
 		Py_XDECREF(str);
+
+		if (m == NULL && (str = PyString_FromString(m)) != NULL) {
+		   PyDict_SetItemString(info, "matched", str);
+		   Py_DECREF(str);
+		} else
+		   PyDict_SetItemString(info, "matched", Py_None);
+
+		if (s == NULL && (str = PyString_FromString(s)) != NULL) {
+		   PyDict_SetItemString(info, "info", str);
+		   Py_DECREF(str);
+		} else
+		   PyDict_SetItemString(info, "info", Py_None);
 
-		if (l->ld_matched != NULL && *l->ld_matched != '\0') 
-		{
-		   str = PyString_FromString(l->ld_matched);
-		   if (str)
-			   PyDict_SetItemString( info, "matched", str );
-		   Py_XDECREF(str);
-		}
-
-		if (l->ld_error != NULL && *l->ld_error != '\0') 
-		{
-		   str = PyString_FromString(l->ld_error);
-		   if (str)
-			   PyDict_SetItemString( info, "info", str );
-		   Py_XDECREF(str);
-		}
 		PyErr_SetObject( errobj, info );
 		Py_DECREF(info);
 		return NULL;

Re: Building python-ldap against Netscape's LDAP-SDK 4.11

[Michael <mi...@st...>]

Michael Ströder wrote:
> 
> Ok, I edited Modules/LDAPObject.c to use only 2 arguments. The
> module builds now and import ldap works. But it gives me undefined
> exceptions.
> 
> ldap.LDAPError: unknown error (C API does not expose error)

It's me again. ;-)

I managed to connect to a OpenLDAP 2.0.6 server (which is LDAPv3).
Connecting to OpenLDAP 1.2.11 server (LDAPv2) does not work. It
seems it has something to do with choosing LDAPv3 during connect and
falling back to LDAPv2 if v3 fails.

I can browse my test data on the OpenLDAP 2.0 server. But when I hit
a LDAPv3 referral entry the exception above is raised. I guess the
C-LDAP-SDK returns some LDAPv3 specific data not known to
python-ldap.

BTW: The following code is also rejected (it works with OpenLDAP
1.2.11 libs):

ldap_obj.deref = ldap.DEREF_NEVER
ldap_obj.options = 0

Traceback:
[..]
    ldap_obj.options = 0
NameError: cannot set that field

Why I want this?

I would like to actively catch LDAPv3 referrals. This works slightly
well with catching ldap.PARTIAL_RESULTS and pulling the referral
LDAP URL out of the info field.
However, if binding via LDAPv2 (OpenLDAP 1.2.x libs) to a LDAPv3
server
1. the server is free to just ignore my request if a referral is hit
and
2. I don't get the search continuations of the referral entry when
doing a one level search.
This causes a lot of inconsistent behaviour of my client (besides
all those broken LDAP servers out there...sigh!).

LDAPv2 vs. LDAPv3 binding also affects all kind of RootDSE
attributes and schema information...

Ciao, Michael.

Re: Building python-ldap against Netscape's LDAP-SDK 4.11

[Michael <mi...@st...>]

Michael Ströder wrote:
> 
> ./configure --prefix=/usr --with-python=/usr/bin/python1.6
> --with-ldap=~/src/ldapsdk-41
> 
> runs ok but make fails with:
> [..]
> too many arguments to function `ldap_set_rebind_proc'

Ok, I edited Modules/LDAPObject.c to use only 2 arguments. The
module builds now and import ldap works. But it gives me undefined
exceptions.

ldap.LDAPError: unknown error (C API does not expose error) 

Hmm...

Ciao, Michael.

Building python-ldap against Netscape's LDAP-SDK 4.11

[Michael <mi...@st...>]

HI!

I tried to build python-ldap against Netscape's LDAP-C-SDK. I had to
choose version 4.11 because 3.x is not avaiable for Linux-Kernel
2.2.x and glibc2.1.

./configure --prefix=/usr --with-python=/usr/bin/python1.6
--with-ldap=~/src/ldapsdk-41

runs ok but make fails with:

make[1]: Entering directory
`/home/michael/Proj/python/ldap/python-ldap/python-ldap/Modules'
gcc -fpic  -I. -DLDAP_REFERRALS -I~/src/ldapsdk-41/include -g -O2
-I/usr/include/python1.6 -I/usr/include/python1.6 -DHAVE_CONFIG_H -c
/home/michael/Proj/python/ldap/python-ldap/python-ldap/Modules/LDAPObject.c
/home/michael/Proj/python/ldap/python-ldap/python-ldap/Modules/LDAPObject.c:
In function `l_ldap_set_rebind_proc':
/home/michael/Proj/python/ldap/python-ldap/python-ldap/Modules/LDAPObject.c:595:
too many arguments to function `ldap_set_rebind_proc'
/home/michael/Proj/python/ldap/python-ldap/python-ldap/Modules/LDAPObject.c:609:
warning: passing arg 2 of `ldap_set_rebind_proc' from incompatible
pointer type
/home/michael/Proj/python/ldap/python-ldap/python-ldap/Modules/LDAPObject.c:609:
too many arguments to function `ldap_set_rebind_proc'
make[1]: *** [LDAPObject.o] Error 1
make[1]: Leaving directory
`/home/michael/Proj/python/ldap/python-ldap/python-ldap/Modules'
make: *** [_ldapmodule-build] Error 2

I guess Netscape changed the API. Hmm, can this be easily fixed?

I would like to have the possibility to bind with LDAPv3 to a
server. IMHO this could be achieved with building python-ldap
against Netscape's SDK.

Ciao, Michael.