python-ldap-dev — discussion among developers

Re: RedHat 8.0 RPMS -- what they foretell

[Joe L. <jl...@op...>]

Yeah.. I know there is a lot to do. I was just relating what I saw in =
one of my primary tasks (maintain a university's Linux distro). I =
sincerely hope to dig into builds against 2.1.x and libldap_r. I also =
noted the issue with OpenLDAP and the problem report, and will await =
whatever they respond to. I just don't have much code to test OpenLDAP =
2.1 or any version against. I need to get sufficient code that will =
provide bug reports.

As to the mem leaks, I'm at a loss as to how to tackle that one on =
Python.

On Friday, July 5, 2002, at 10:15 AM, Michael Str=F6der wrote:

> Joe Little wrote:
>> I'll downloaded the isos for limbo, the first RedHat 8.0 beta =
release.
>> Its a true .0 release, in that a lot of major changes are in the =
works. Primarily, they have migrated their whole installation system =
from python 1.5.x to 2.2.x. Along with this, they have adopted OpenLDAP =
2.1.2, and their compat libs are only for OpenLDAP 1.2.13. This means =
that at least for this vendor, a CVS release of python-ldap will be the =
bare minimum requirement. My guess is that 8.0 may be an August release, =
or perhaps later. Regardless, the list will get more questions about =
OpenLDAP 2.1.x in the future.
>
> Now how about testing the current CVS instead of counting version =
numbers? Did you read about my problems with OpenLDAP 2.1.x libs? I =
filed two bug reports to OpenLDAP's ITS related to problems I found when =
working on python-ldap during the last days.
>
> So far I had no feedback from list members when requesting tests =
during the last days! :-(
>
> Red Hat is famous for packaging premature software into RPMs such =
causing a 1st-level support nightmare on mailing lists which they simply =
don't have to pay (e.g. the gcc catastrophy).
>
> Sorry, Red Hat nor any other Linux distributors' packaging decisions =
will influence my schedule.
>
> Joe, if you want to push things forward then there are several things =
to dig into:
>
> 1. Solve problems with NON-ASCII chars in DN when using OpenLDAP 2.1.x =
libs.
>
> 2. Find huge memory leaks reported to the list.
>
> 3. Dig into thread-safety issues with libldap_r. Despite your personal =
conversation with Luke I have some doubts that this is really solved.
>
> 4. Test build process with several flavors of OpenLDAP (./configure =
--help to give you an idea).
>
> 5. Clean up the nightmare of DEFINE's used.
>
> 6. At least test the CVS version!
>
> Not to speak of adding new features...
>
> Ciao, Michael.

Re: RedHat 8.0 RPMS -- what they foretell

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

Joe Little wrote:
> I'll downloaded the isos for limbo, the first RedHat 8.0 beta release.
> 
> Its a true .0 release, in that a lot of major changes are in the works. 
> Primarily, they have migrated their whole installation system from 
> python 1.5.x to 2.2.x. Along with this, they have adopted OpenLDAP 
> 2.1.2, and their compat libs are only for OpenLDAP 1.2.13. This means 
> that at least for this vendor, a CVS release of python-ldap will be the 
> bare minimum requirement. My guess is that 8.0 may be an August release, 
> or perhaps later. Regardless, the list will get more questions about 
> OpenLDAP 2.1.x in the future.

Now how about testing the current CVS instead of counting version 
numbers? Did you read about my problems with OpenLDAP 2.1.x libs? 
I filed two bug reports to OpenLDAP's ITS related to problems I 
found when working on python-ldap during the last days.

So far I had no feedback from list members when requesting tests 
during the last days! :-(

Red Hat is famous for packaging premature software into RPMs such 
causing a 1st-level support nightmare on mailing lists which they 
simply don't have to pay (e.g. the gcc catastrophy).

Sorry, Red Hat nor any other Linux distributors' packaging 
decisions will influence my schedule.

Joe, if you want to push things forward then there are several 
things to dig into:

1. Solve problems with NON-ASCII chars in DN when using OpenLDAP 
2.1.x libs.

2. Find huge memory leaks reported to the list.

3. Dig into thread-safety issues with libldap_r. Despite your 
personal conversation with Luke I have some doubts that this is 
really solved.

4. Test build process with several flavors of OpenLDAP 
(./configure --help to give you an idea).

5. Clean up the nightmare of DEFINE's used.

6. At least test the CVS version!

Not to speak of adding new features...

Ciao, Michael.

RedHat 8.0 RPMS -- what they foretell

[Joe L. <jl...@op...>]

I'll downloaded the isos for limbo, the first RedHat 8.0 beta release.

Its a true .0 release, in that a lot of major changes are in the works. Primarily, they have migrated their whole installation system from python 1.5.x to 2.2.x. Along with this, they have adopted OpenLDAP 2.1.2, and their compat libs are only for OpenLDAP 1.2.13. This means that at least for this vendor, a CVS release of python-ldap will be the bare minimum requirement. My guess is that 8.0 may be an August release, or perhaps later. Regardless, the list will get more questions about OpenLDAP 2.1.x in the future. The good news is that Python 1.5.x is going away and so my RPMs won't need to deal with "python == python-1.5.x and python2 == python 2.x.y?" notation..

#ifdef HAVE_SASL

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

HI!

For those who haven't built their local OpenLDAP libs with SASL 
support I have introduced #ifdef HAVE_SASL in setup.py and 
Modules/*.c.

HAVE_SASL is automagically set according to the line libs in 
setup.cfg.

It seems to work but please test!

Ciao, Michael. (I really hate C!)

[Fwd: libldap_r: undefined symbol: ldap_first_reference (ITS#1922)]

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

HI!

I filed a bug report for the problems with libldap_r:

     http://www.OpenLDAP.org/its/index.cgi?findid=1922

Credits go to Johannes Stezenbach for sorting that out.

Now adding references.c and references.lo in 
libraries/libldap_r/Makefile.in makes it possible to build with 
this line in setup.cfg:

libs = ldap_r lber sasl

BTW: Make sure to bring your CVS working tree in sync. There are 
some changes in there related to using libldap_r.

Verify if everything works after installing:

# python -c "import ldap"

Under Linux you can check with ldd:

# ldd /usr/lib/python2.2/site-packages/_ldap.so
         libldap_r.so.2 => /usr/local/openldap2/lib/libldap_r.so.2 
(0x4001f000)
         liblber.so.2 => /usr/local/openldap2/lib/liblber.so.2 
(0x40052000)
         libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4005e000)

libldap.so.2 must not be mentioned there!

Mauro, I'd be happy if you also test that on Win32.

Ciao, Michael.

Re: LDAP_TYPE_IS_OPAQUE?

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

On Tue, 2 Jul 2002, Michael Str=F6der typed thusly:

> I have no clue what define LDAP_TYPE_IS_OPAQUE is for?
>
> Can we get rid of it because we require OpenLDAP 2.x libs for
> python-ldap 2.x?

the type-is-opaque test was introduced when the LDAP type was not defined
in the ldap.h header file (netscape's from memory).

to determine the error number from failed LDAP operations, you either had
to access an errno field of the structure, or use a function such as
ldap_get_error() or something. (its getting foggy in my mind)

so, in the early days, if LDAP_TYPE_IS_OPAQUE was detected by configure,
and if no ldap_get_error() function was provided, then - well errors
were all generic.

if the focus is now on simply supporting the OpenLDAP client library, then
getting rid of LDAP_TYPE_IS_OPAQUE makes sense.

d

Re: timeout on bind() function

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

Olivier Guillossou wrote:
> 
> I've a question: is there any option in the bind() function to make it 
> raising a timeout exception ?

There's no timeout parameter for bind() method.

> I'm testing the python-ldap library, and I wouldn't like the program to 
> hang if the LDAP server is down, for example.

If the server is really down you get a ldap.SERVER_DOWN when 
firing the first LDAP operation (no matter which). The really 
tricky things are servers which do accept the connection but don't 
proceed.

> If there's no embedded timeout function, how can I make my program 
> "timeouting" when the bind() function hangs ?

 >>> import ldap
 >>> l=ldap.open('localhost:1389')
 >>> m=l.bind(ldap.AUTH_SIMPLE,'','')
 >>> m=l.bind('','',ldap.AUTH_SIMPLE)
 >>> r=l.result(m,1,30)

Hmm, is there any interest in setting a LDAPObject.timeout which 
would automagically apply to all *_s() methods?

Ciao, Michael.

LDAP_TYPE_IS_OPAQUE?

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

HI!

I have no clue what define LDAP_TYPE_IS_OPAQUE is for?

Can we get rid of it because we require OpenLDAP 2.x libs for 
python-ldap 2.x?

Ciao, Michael.

timeout on bind() function

[Olivier G. <oli...@c2...>]

Hello everybody,

I've a question: is there any option in the bind() function to make it 
raising a timeout exception ?
I'm testing the python-ldap library, and I wouldn't like the program to 
hang if the LDAP server is down, for example.

If there's no embedded timeout function, how can I make my program 
"timeouting" when the bind() function hangs ?

Yours,

-- 
Olivier Guillossou
Spécialiste Linux / ADELUX
146 Bd Voltaire
92600 Asnières sur Seine - FRANCE
tel: 01 46 88 60 55
fax: 01 47 90 26 32

Re: python-ldap 2.0.0pre04 Installation problem

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

Isabelle Moullet wrote:
>> Isabelle Moullet wrote:
>>
>>> I got the following error message as I tried to install python-ldap 
>>> 2.0.0pre04
>>> release on a 2.8 Solaris machine with the command :python setup.py build
>>
>> Did you install the required OpenLDAP 2 libs before?
> 
> No I didn't ! Maybe that's my problem.. But I remember that with verison 
> 1.10alpha3 it was not useful, right ?

python-ldap 1.x only works with OpenLDAP 1.x, Netscape 3.x(?) and 
old Novell libs.

python-ldap 2.x requires OpenLDAP 2.x libs installed.

>  Do you think it is better to use 1.10alpha3 or the latest release ?

I'd recommend to use python-ldap 2.0.0pre04. There are a couple of 
issues there. But they will be solved. python-ldap 1.x is not 
actively maintained anymore.


Ciao, Michael.

Re: python-ldap 2.0.0pre04 Installation problem

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

Isabelle Moullet wrote:
> 
> I got the following error message as I tried to install python-ldap 2.0.0pre04
> release on a 2.8 Solaris machine with the command :python setup.py build

Did you install the required OpenLDAP 2 libs before? If yes, did 
you make sure that they don't conflict with Netscape/iPlanet LDAP 
libs probably shipped with Solaris? Check which libldap is really 
used.

> [_ldap]
> class = OpenLDAP2
> library_dirs = /usr/local/lib
> include_dirs = /usr/local/include

I'd suggest that you build OpenLDAP 2.0.x with 
--prefix=/usr/local/openldap2 and modify setup.cfg accordingly.

library_dirs = /usr/local/openldap2/lib
include_dirs = /usr/local/openldap2/include

 > cc -O -DLDAP_TYPE_IS_OPAQUE -DHAVE_LDAP_DESTROY_CACHE 
-DHAVE_LDAP_DISABLE_CACHE-DHAVE_LDAP_ENABLE_CACHE 
-DHAVE_LDAP_FLUSH_CACHE -DHAVE_LDAP_MODRDN2 -DHAVE_LDA_MODRDN2_S 
-DHAVE_LDAP_SET_CACHE_OPTIONS -DHAVE_LDAP_START_TLS_S 
-DHAVE_LDAP_UNACHE_ENTRY -DHAVE_LDAP_UNCACHE_REQUEST 
-DLDAPMODULE_VERSION=2.0.0pre04 -IModule -I/usr/local/include 
-I/usr/local/include/python2.0 -c Modules/LDAPObject.c 
-obuild/temp.solaris-2.8-sun4u-2.0/Modules/LDAPObject.o
 > "Modules/LDAPObject.c", line 900: warning: syntax error:  empty 
declaration
 > "Modules/LDAPObject.c", line 918: undefined symbol: 
LDAP_CONTROL_MANAGEDSAIT
 > "Modules/LDAPObject.c", line 918: warning: improper 
pointer/integer combination op "="
 > "Modules/LDAPObject.c", line 936: warning: syntax error:  empty 
declaration
 > cc: acomp failed for Modules/LDAPObject.c
 > error: command 'cc' failed with exit status 2

I guess you're using Sun's C compiler. Right? Hmm, anyone here 
having experience with that?

 > Is it normal he could not find th efile Lib/ldap.py ?

Yes, this message is caused by a limitation of DistUtils.

Ciao, Michael.

Fat memory leaks

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

HI!

I remember that someone reported memory leaks quite a while ago 
and there was no further action. Running some test scripts I can 
observe that the python-ldap using process grows quite fast.

Does anybody have the time to look into this? If yes, please dig 
into Modules/LDAPObject.c, functions l_ldap_result() and 
l_ldap_search().

Ciao, Michael.

python-ldap 2.0.0pre04 Installation problem

[Isabelle M. <Isa...@ci...>]

Bonjour,

I got the following error message as I tried to install python-ldap 2.0.0pre04

release on a 2.8 Solaris machine with the command :python setup.py build

( I use python 2.0)

 super@cisun50$ python setup.py build

running build
running build_py
warning: build_py: file Lib/ldap.py (for module ldap) not found
creating build
creating build/lib.solaris-2.8-sun4u-2.0
creating build/lib.solaris-2.8-sun4u-2.0/ldap
copying Lib/ldap/__init__.py -> build/lib.solaris-2.8-sun4u-2.0/ldap
copying Lib/ldap/async.py -> build/lib.solaris-2.8-sun4u-2.0/ldap
copying Lib/ldap/functions.py -> build/lib.solaris-2.8-sun4u-2.0/ldap
copying Lib/ldap/ldapobject.py -> build/lib.solaris-2.8-sun4u-2.0/ldap
copying Lib/ldap/modlist.py -> build/lib.solaris-2.8-sun4u-2.0/ldap
copying Lib/ldapurl.py -> build/lib.solaris-2.8-sun4u-2.0
copying Lib/ldif.py -> build/lib.solaris-2.8-sun4u-2.0
warning: build_py: file Lib/ldap.py (for module ldap) not found
running build_ext
building '_ldap' extension
creating build/temp.solaris-2.8-sun4u-2.0
creating build/temp.solaris-2.8-sun4u-2.0/Modules
cc -O -DLDAP_TYPE_IS_OPAQUE -DHAVE_LDAP_DESTROY_CACHE -DHAVE_LDAP_DISABLE_CACHE-DHAVE_LDAP_ENABLE_CACHE -DHAVE_LDAP_FLUSH_CACHE -DHAVE_LDAP_MODRDN2 -DHAVE_LDA_MODRDN2_S -DHAVE_LDAP_SET_CACHE_OPTIONS -DHAVE_LDAP_START_TLS_S -DHAVE_LDAP_UNACHE_ENTRY -DHAVE_LDAP_UNCACHE_REQUEST -DLDAPMODULE_VERSION=2.0.0pre04 -IModule -I/usr/local/include -I/usr/local/include/python2.0 -c Modules/LDAPObject.c -obuild/temp.solaris-2.8-sun4u-2.0/Modules/LDAPObject.o
"Modules/LDAPObject.c", line 900: warning: syntax error:  empty declaration
"Modules/LDAPObject.c", line 918: undefined symbol: LDAP_CONTROL_MANAGEDSAIT
"Modules/LDAPObject.c", line 918: warning: improper pointer/integer combination op "="
"Modules/LDAPObject.c", line 936: warning: syntax error:  empty declaration
cc: acomp failed for Modules/LDAPObject.c
error: command 'cc' failed with exit status 2

Is it normal he could not find th efile Lib/ldap.py ?

Here is my setup.cfg file

# Section for compiling the C extension module
# for wrapping OpenLDAP 2 libs

[_ldap]
class = OpenLDAP2
library_dirs = /usr/local/lib
include_dirs = /usr/local/include
libs = lber ldap resolv

# Installation options

[install]

compile = 1
optimize = 1

Thanks a lof for your help..

--
Isabelle Moullet
Centre Informatique
Universite de Lausanne
email: isa...@ci...

Re: Building python-ldap with libldap_r (was: defect)

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

Michael Str=F6der wrote:
>=20
> libs =3D ldap_r ldap lber sasl

libldap_r allows finer-grained locking for each LDAPObject=20
instance. I've checked in a new ldap/__init__.py and=20
ldap/ldapobject.py which allows to use separate Lock instances for=20
global function calls into LDAP lib and for each LDAPObject=20
instance created.

At the moment you have to create a LDAPObject instance directly=20
for using that (not through ldap.open() or ldap.initialize()).

Example:

l =3D ldap.ldapobject.LDAPObject('ldap://www.openldap.org',ldap_r=3D1)

Also there's a more elegant fall-back if the Python installation=20
used has no thread support (translates to import threading failed).

Please read the changed source and comment!
Please try to build a python-ldap with libldap_r and test!
Also test with Python without thread support!

Ciao, Michael.

Re: Building python-ldap with libldap_r (was: defect)

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

Michael Str=F6der wrote:
>=20
> I tried to build python-ldap against libldap_r from OpenLDAP's REL_ENG_=
2=20
> branch by simply modifying setup.cfg:
>=20
> libs =3D ldap_r lber sasl
>=20
> The build went fine. ldd shows output like expected:
> [..]
>=20
> But import does not work.
 > [..]
> ImportError: /usr/lib/python2.2/site-packages/_ldap.so: undefined=20
> symbol: ldap_first_reference

Hmm I saw some postings on using libldap_r with other software=20
packages. They used libldap_r *and* libldap for linking.

I tried this in setup.cfg:

libs =3D ldap_r ldap lber sasl

It seems to work and ldd shows this:

$ ldd /usr/lib/python2.2/site-packages/_ldap.so
         libldap_r.so.2 =3D> /usr/local/openldap2/lib/libldap_r.so.2=20
(0x4001f000)
         libldap.so.2 =3D> /usr/local/openldap2/lib/libldap.so.2=20
(0x40052000)
         liblber.so.2 =3D> /usr/local/openldap2/lib/liblber.so.2=20
(0x40082000)
         libsasl.so.7 =3D> /usr/lib/libsasl.so.7 (0x4008e000)

Can anyone confirm that it's supposed to work that way using both=20
libldap_r and libldap for linking? How can I be sure that the=20
reentrant version of a ldaplib function is used? (Again revealing=20
my lack of C compiling knowledge...)

Ciao, Michael.

Re: Bug in LDAPObject.c, l_ldap_result()

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

Derrick 'dman' Hudson wrote:
 >
> -       pmsg = Py_None;
> +       pmsg = LDAPmessage_to_python( self->ldap, msg );
> 
> It really does help to not ignore the data that's returned :-).

There's still something wrong with that when a search continuation 
is returned. It simply does not return the last empty search 
result which terminates the while loop.

Strange enough it works from web2ldap but not from a simple demo 
using ldap.async. Hmm...

Ciao, Michael.

Re: Bug in LDAPObject.c, l_ldap_result()

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

On Sun, 30 Jun 2002, Michael Str=F6der typed thusly:

> > | >I also think the C function needs
> > | >to be modified to treat Py_None as NULL to allow python code to
> > | >specify a timeout that is indefinitely long.
> > |
> > | IMHO that's done with timeout=3D-1. Looking at l_ldap_result() in
> > | LDAPObject.c it seems to be implemented correctly
> >
> > Ahh, yeah, that is one suitable convention.  Doesn't
> >     timeout=3DNone
> > sound amusingly accurate though?  (in english at least)
>
> Well, I have no clue why David chose -1 instead of None.

that's the C/unix convention.

however, looking at the documentation of select.select() it seems that
using None could be better justified

  select(rlist, wlist, xlist[, timeout]) -> (rlist, wlist, xlist)
  [...]
  The optional 4th argument specifies a timeout in seconds; it may be
  a floating point number to specify fractions of seconds.  If it is absent
  or None, the call will never time out.

d
--=20
David Leonard                           Dav...@it...
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13E=
A0FC8

Issues with NON-ASCII chars and OpenLDAP 2.1 libs

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

HI!

For those of you planning to build python-ldap against OpenLDAP 
2.1.x.:

I get ldap.NO_SUCH_OBJECT when a distinguished name for a search 
operation contains non-ASCII characters (as UTF-8 off course). It 
works smoothly with python-ldap build against OpenLDAP 2 libs. 
AFAIR OpenLDAP 2.1 contains a completely new Unicode normalization...

Ciao, Michael.

FYI: python-ldap with MDS()

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

HI!

Here's what people are doing with recently added SASL support:

   http://www-itg.lbl.gov/gtg/projects/misc/mds_python-ldap.html

Ciao, Michael.

Re: Module ldapurl (was: ldap_url_search ?)

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

Michael Str=F6der wrote:
> Derrick 'dman' Hudson wrote:
>=20
>> On Fri, Jun 28, 2002 at 09:36:26PM +0200, Michael Str=F6der wrote:
>> | | How about practicing with the module ldapurl?
>>
>> How?  The documentation is pretty sparse.

BTW: There's Demo/Lib/ldapurl/urlsearch.py since ages... ;-)

Ciao, Michael.

Re: set_rebind_proc

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

Steffen Ries wrote:
> 
>>I have to admit that I'm scared about adding such functionality into
>>the C part of python-ldap. I'd like to encourage you to find a
>>Python-only solution which is easier to maintain. BTW: That's exactly
>>one of the benefits of class ldap.ldapobject.LDAPObject: It can be
>>sub-classed for extending its functionality.
> 
> Hmm. Implementing a Python-only solution would require to catch the
> ldap.REFERRAL (or ldap.PARTIAL_RESULT) for each of the operations,
> decide how to chase the referral and then retry the operation. I can
> try to come up with a proposal...
 > [..]
>>I'd rather like to see a framework which helps the application
>>developer to implement generic exception handlers for
>>e.g. ldap.SERVER_DOWN or ldap.REFERRAL and decide what to do in
>>his/her specific environment.
> 
> Are you thinking of registering error specific exception handlers or
> pushing the functionality to the application?

LDAPObject._ldap_call could be the point from where registered 
exception handlers are called. E.g. a new method 
LDAPObject.ErrorHandler(e,func,args,kwargs) could check whether a 
generic handler method is registered for a specific LDAPError 
class and call that handler with these parameters.

Now the application would sub-class LDAPObject and implement such 
handlers applying the specific knowledge about the environment.

Note that we have the advantage of having OO-oriented API and 
exceptions. Therefore we aren't limited to such crude mechanisms 
common in C like call-back functions. IMHO we should think in this 
direction.

> I would like to add some functionality to the library (call it a
> framework), rather than burden the application to wrap every
> search/add/modify with an exception handler for chasing referrals. I
> have this kind of code in some places for fail over, which makes it
> pretty hard to maintain.

Well, I'd like to have something in the python-ldap library too. 
But although it sounds pretty easy I guess it's not. There are 
some caveats I'm sure (e.g. some kind of nested error handling in 
exception handlers...).

Ciao, Michael.

Re: set_rebind_proc

[Steffen R. <ste...@sy...>]

Michael Str=F6der <mi...@st...> writes:

[...]

> > After looking into the code I found that the "set_rebind_proc" method
> > has been disabled "until made OpenLDAP2 compatible". Since I need this
> > functionality, I have implemented an openLDAP2 compatible version of
> > set_rebind_proc.
>=20
> AFAIR there was no decision made yet in the OpenLDAP project how to
> implement set_rebind_proc. But I have to check recent status.

I guess I should have done more research and less reverse
engineering... :-)

I looked through the OpenLDAP mailing list archives and found only a
couple of messages relating to this issue. I can't say whether the
mechanism is finalized, but I've seen concerns that it should not be
implemented the way it is.

[...]

> I have to admit that I'm scared about adding such functionality into
> the C part of python-ldap. I'd like to encourage you to find a
> Python-only solution which is easier to maintain. BTW: That's exactly
> one of the benefits of class ldap.ldapobject.LDAPObject: It can be
> sub-classed for extending its functionality.

Hmm. Implementing a Python-only solution would require to catch the
ldap.REFERRAL (or ldap.PARTIAL_RESULT) for each of the operations,
decide how to chase the referral and then retry the operation. I can
try to come up with a proposal...

> > I kept the interface for the callback the same as it was for the old
> > implementation, i.e. the callback has to accept an LDAP object and
> > return a tuple (DN, CRED, METHOD).
>=20
> Please check whether this complies to what's done in OpenLDAP 2 today.

It does not. The new API call passes URL, request type and message-id. I
ignored these values (mostly because I don't have any particular use
for them...).

[...]

> I'd rather like to see a framework which helps the application
> developer to implement generic exception handlers for
> e.g. ldap.SERVER_DOWN or ldap.REFERRAL and decide what to do in
> his/her specific environment.
>=20
> We could store the last operation tried in a class attribute by just
> extending LDAPObject._ldap_call(). Hmm, adding the parameters of the
> LDAP operation which raised a LDAPError exception to the LDAPError
> exception instance itself would be really nice...

Are you thinking of registering error specific exception handlers or
pushing the functionality to the application?

I would like to add some functionality to the library (call it a
framework), rather than burden the application to wrap every
search/add/modify with an exception handler for chasing referrals. I
have this kind of code in some places for fail over, which makes it
pretty hard to maintain.

/steffen
--=20
ste...@sy...	<> Gravity is a myth -- the Earth sucks!

Re: set_rebind_proc

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

Steffen Ries wrote:
> 
> I recently ran into a problem with a replicated iPlanet directory
> server. My client was setup to write to the slave directory, which
> answered with a REFERRAL. The client was trying to follow the
> referral but could not authenticate with the master directory.

Steffen, I can confirm that you already hit many of the issues 
with following referrals.

> After looking into the code I found that the "set_rebind_proc" method
> has been disabled "until made OpenLDAP2 compatible". Since I need this
> functionality, I have implemented an openLDAP2 compatible version of
> set_rebind_proc.

AFAIR there was no decision made yet in the OpenLDAP project how 
to implement set_rebind_proc. But I have to check recent status.

> The old implementation had an IMHO very bad design flaw: only one
> rebind_proc was allowed for the whole module.

Which is not the only design flaw of set_rebind_proc. It's rather 
flawed by design...

> Since I need to support multiple connections to different directories
> as well, I implemented a solution for this problem.

I have to admit that I'm scared about adding such functionality 
into the C part of python-ldap. I'd like to encourage you to find 
a Python-only solution which is easier to maintain. BTW: That's 
exactly one of the benefits of class ldap.ldapobject.LDAPObject: 
It can be sub-classed for extending its functionality.

> I kept the interface for the callback the same as it was for the old
> implementation, i.e. the callback has to accept an LDAP object and
> return a tuple (DN, CRED, METHOD). 

Please check whether this complies to what's done in OpenLDAP 2 today.

> The second part of the patch is for the python wrapper. I added an
> automatic rebind_procedure, which is installed when you call a version
> of "bind()". This way referrals should normally be transparent to the
> client. I am not sure whether this is a good idea or not (?).

My own investigations of this problem lead to not add any generic 
referral mechanism to python-ldap because one can't find a generic 
way without making too many assumptions. Several issues with 
referrals and - a similar problem - LDAP connection failover.

Connection handling:
An application has to decide whether it follows the referral for a 
single operation (e.g. a single write operations) or drop the 
current LDAP connection completely and switch over to the referred 
server for all following operations. An interesting question in 
e.g. a one master, many slaves scenario.
Another issue is whether there are more operations involved to 
properly establish a new LDAP connection, e.g. calling start_tls_s().

Bind sequence:
Currently most implementations solely use simple bind. But e.g. 
SASL BindRequests are rather more complicated (Kerberos via 
GSS-API, SSL with client certificates). Also the target server 
mentioned in the referral might have other SASL capabilities. 
Another issue is setting the right LDAP protocol version 
(negotiated vs. set by a-priori knowledge).

Security issues:
I have no clue how to model all the different bind mechanisms 
securely. Also one would have to store credentials (not only 
passwords)...

I'd rather like to see a framework which helps the application 
developer to implement generic exception handlers for e.g. 
ldap.SERVER_DOWN or ldap.REFERRAL and decide what to do in his/her 
specific environment.

We could store the last operation tried in a class attribute by 
just extending LDAPObject._ldap_call(). Hmm, adding the parameters 
of the LDAP operation which raised a LDAPError exception to the 
LDAPError exception instance itself would be really nice...

Ciao, Michael.

Re: Bug in LDAPObject.c, l_ldap_result()

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

Derrick 'dman' Hudson wrote:
> On Sat, Jun 29, 2002 at 07:54:12PM +0200, Michael Str=F6der wrote:
> | This whole stuff with result() is somewhat=20
> | incomplete anyway since the result type
>=20
> Looks like your sentence was cut off.

The result type is not returned in search results when using=20
search_s() which is somewhat incomplete. Search results may=20
contain real entries and search continuations. One has to=20
distinguish that by looking at the type (tuple vs. string). But=20
that's not nice.

> The CVS version of python-ldap doesn't work for me, though.  I had to
> change some of the sasl stuff in LDAPObject.c for it to compile,

Hmm, which version of OpenLDAP? I usually compile against CVS=20
version checked out from REL_ENG_2 branch. That works smoothly.

Can you post your SASL-related changes?

> and I get a SEGV with web2ldap.

Did you check http://www.web2ldap.de/faq.html ?

-------------------------- snip ---------------------------
web2ldap crashs a lot of with segmentation faults.

This is not a web2ldap issue. Please check how your Python=20
interpreter was compiled. It has to be build with configure=20
--without-pymalloc. You probably have to rebuild all C extension=20
modules involved afterwards.
-------------------------- snip ---------------------------

 > (I also changed a couple other minor
> details that gcc complained about)

Again: Post these changes for open discussion.

> | Yes. But then the application has to handle that.
>=20
> Isn't that the purpose of not blocking in the first place?
>=20
> | The non-blocking version of LDAPObject.result() is the one which
> | needed the time.sleep() hack.
>=20
> The version that was in release 2.0.0pre04 was blocking if all was
> true.  It just did the blocking in python/python-ldap instead of in
> C/libldap2.

Yes. My wording was rather misleading. Blocking yes, but not=20
locking all the time. Therefore other threads calling into the=20
LDAP libs are allowed to run although one thread is blocked.

> | >I also think the C function needs
> | >to be modified to treat Py_None as NULL to allow python code to
> | >specify a timeout that is indefinitely long.
> |=20
> | IMHO that's done with timeout=3D-1. Looking at l_ldap_result() in=20
> | LDAPObject.c it seems to be implemented correctly
>=20
> Ahh, yeah, that is one suitable convention.  Doesn't
>     timeout=3DNone
> sound amusingly accurate though?  (in english at least)

Well, I have no clue why David chose -1 instead of None.

Ciao, Michael.

set_rebind_proc

[Steffen R. <ste...@sy...>]

Hi,

I recently ran into a problem with a replicated iPlanet directory
server. My client was setup to write to the slave directory, which
answered with a REFERRAL. The client was trying to follow the
referral but could not authenticate with the master directory.

After looking into the code I found that the "set_rebind_proc" method
has been disabled "until made OpenLDAP2 compatible". Since I need this
functionality, I have implemented an openLDAP2 compatible version of
set_rebind_proc.

The old implementation had an IMHO very bad design flaw: only one
rebind_proc was allowed for the whole module. In other words, if you
try to open more than one directory connection, the rebind_proc could
only be set to one directory, rebinds to the other directory would
have fatal consequences (either python-fatal error or a segfault).

Since I need to support multiple connections to different directories
as well, I implemented a solution for this problem. My solution is not
ideal, but I think it is a reasonable compromise. Ideally I would
extend the LDAP object and store the rebind callback in the extended
version, but LDAP is an opaque object handled by the OpenLDAP
library. My alternative is to keep track of the allocated LDAPObjects
and map the LDAP object to the corresponding LDAPObject. For this
purpose I'm storing the LDAPObjects in a linked list. I don't expect a
big number of LDAPObjects to be allocated, so the overhead of doing a
linear search should be acceptable.

I kept the interface for the callback the same as it was for the old
implementation, i.e. the callback has to accept an LDAP object and
return a tuple (DN, CRED, METHOD). 

The second part of the patch is for the python wrapper. I added an
automatic rebind_procedure, which is installed when you call a version
of "bind()". This way referrals should normally be transparent to the
client. I am not sure whether this is a good idea or not (?).

/steffen
-- 
ste...@sy...	<> Gravity is a myth -- the Earth sucks!