From mike at Nexus.concordia.ca  Mon Jul 12 21:05:59 2004
From: mike at Nexus.concordia.ca (Mike D'Errico)
Date: Mon, 12 Jul 2004 15:05:59 -0400 (EDT)
Subject: Possible bug results in 'Encoding Error' on Tru64 5.1A..
Message-ID: <Pine.LNX.4.33.0407121423020.9037-100000@Nexus.concordia.ca>


Hello,

I've currently run into a problem on our Tru64 5.1A machines when I
try to do a simple_bind_s() to any ldap server.

Sample code:

...

try:
    oldap = ldap.initialize("ldap://some_valid_host")
    print "inititalized ok."
    oldap.simple_bind_s("cn=manager,ou=someunit,dc=some_valid_host","secret")
    print "things are good."
except ldap.LDAPError, error:
    print error
    sys.exit(1)
...

this generates the following output:

opened ok.
{'desc': 'Encoding error'}

To debug the problem, I added some debugging code (a few print
statements) to the ldapobject.py code. Then to get even further
information I added some debugging code to the LDAPObject.c code and
suddently the binding works ?

Output:
-------
F:'<built-in method set_option of LDAP object at 0x1400a0080>' A:'(17, 3)'
K:'{}'
opened ok.
F:'<built-in method simple_bind of LDAP object at 0x1400a0080>'
A:'('cn=manager,ou=someunit,dc=some_valid_host', 'secret', None, None)'
K:'{}'
line 425 - C PROG - PRE-BIND Obj:'1075979520'
who:'cn=manager,ou=someunit,dc=some_valid_host' msgid:'0'
line 431 - C PROG - POST-BIND Obj:'1075979520'
who:'cn=manager,ou=someunit,dc=some_valid_host' msgid:'1' ERROR:'Success'
F:'<built-in method result2 of LDAP object at 0x1400a0080>' A:'(1, 1, -1)'
K:'{}'
bound ok.

I've added 3 print statements in all. The odd thing is that when I remove
any one of these print statements or if I make any modifications to these
statements (ie. try not to print out the 'who' param), the operation
fails.

I suspect there is a pointer or array reference that is out of bound and
that is clobbering another variable's space but haven't found where in the
code exactly. Another possibility is that there is a problem somewhere
with the fact that Tru64 is 64bit and that either python / python-ldap /
openldap is not behaving correctly using 64 bit addresses.

Here's further information about my current environment:

- python 2.3.4
- openldap-2.2.14 (tried on 2.1.23 also)
- unix cc compiler (although I tried with gcc 3.0.4 also)
- python-ldap 2.0.1
- OSF1 V5.1 1885 alpha

Here are the diffs of my modifications to the python-ldap modules:

--- python-ldap-2.0.1/Modules/LDAPObject.c.original     2004-07-12
15:01:38.000000000 -0400
+++ python-ldap-2.0.1/Modules/LDAPObject.c      2004-07-12
15:01:38.000000000 -0400
@@ -416,15 +416,18 @@
     PyObject *clientctrls = Py_None;
     struct berval cred;

     if (!PyArg_ParseTuple( args, "ss#|OO", &who, &cred.bv_val,
&cred.bv_len, &serverctrls, &clientctrls )) return NULL;

     if (not_valid(self)) return NULL;

+    printf("line 425 - C PROG - PRE-BIND Obj:'%d' who:'%s'
msgid:'%d'\n",self->ldap,who,msgid);
+
     LDAP_BEGIN_ALLOW_THREADS( self );
     ldaperror = ldap_sasl_bind( self->ldap, who, LDAP_SASL_SIMPLE, &cred,
NULL, NULL, &msgid);
     LDAP_END_ALLOW_THREADS( self );

+    printf("line 431 - C PROG - POST-BIND Obj:'%d' who:'%s' msgid:'%d'
ERROR:'%s'\n",self->ldap,who,msgid,ldap_err2string(ldaperror));
+
     if ( ldaperror!=LDAP_SUCCESS )
        return LDAPerror( self->ldap, "ldap_simple_bind" );


---
python-ldap-2.0.1/build/lib.osf1-V5.1-alpha-2.3/ldap/ldapobject.py.original2004-07-12
15:03:07.000000000 -0400
+++ python-ldap-2.0.1/build/lib.osf1-V5.1-alpha-2.3/ldap/ldapobject.py
2004-07-12 15:04:30.000000000 -0400
@@ -91,6 +91,7 @@
     self._ldap_object_lock.acquire()
     try:
       try:
+        print "F:'%s' A:'%s' K:'%s'"%(func,args,kwargs)
         result = func(*args,**kwargs)
       finally:
         self._ldap_object_lock.release()

Any help in resolving this issue would be greatly appreciated,

Thank you,



From michael at stroeder.com  Tue Jul 13 08:40:03 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 13 Jul 2004 08:40:03 +0200
Subject: Possible bug results in 'Encoding Error' on Tru64 5.1A..
In-Reply-To: <Pine.LNX.4.33.0407121423020.9037-100000@Nexus.concordia.ca>
References: <Pine.LNX.4.33.0407121423020.9037-100000@Nexus.concordia.ca>
Message-ID: <40F383C3.9000107@stroeder.com>

Mike D'Errico wrote:
> 
> I've currently run into a problem on our Tru64 5.1A machines when I
> try to do a simple_bind_s() to any ldap server.
 > [..]
> opened ok.
> {'desc': 'Encoding error'}

Hmm...

> To debug the problem, I added some debugging code (a few print
> statements) to the ldapobject.py code.

You know about argument trace_level?

     oldap = ldap.initialize("ldap://some_valid_host",trace_level=2)

> Then to get even further
> information I added some debugging code to the LDAPObject.c code and
> suddently the binding works ?
 > [..]
> I've added 3 print statements in all. The odd thing is that when I remove
> any one of these print statements or if I make any modifications to these
> statements (ie. try not to print out the 'who' param), the operation
> fails.
> [..]
> I suspect there is a pointer or array reference that is out of bound and
> that is clobbering another variable's space but haven't found where in the
> code exactly. Another possibility is that there is a problem somewhere
> with the fact that Tru64 is 64bit and that either python / python-ldap /
> openldap is not behaving correctly using 64 bit addresses.

Unfortunately I'm not a C programmer at all. Therefore please try to dig 
into this issue.

> - openldap-2.2.14 (tried on 2.1.23 also)

I found in CHANGES of OpenLDAP 2.2.15 Engineering (currently only available 
as branch OPENLDAP_REL_ENG_2_2 in OpenLDAP's CVS):

         Fixed libldap sasl_encode 64-bit bug (ITS#3054,3212)

I don't have a clue whether that's really related to this issue here though. 
It could be since LDAPObject.simple_bind() directly wraps ldap_sasl_bind().

This was changed in python-ldap 2.0.0pre21. Prior versions wrapped 
ldap_simple_bind() which in turn calls ldap_sasl_bind().

Could you please try to submit a LDAP search request right after invoking 
ldap.initialize() to determine if LDAPObject.simple_bind() is the only 
problem or if the issue is a more general one?

try:
   oldap = ldap.initialize("ldap://some_valid_host",trace_level=2)
   print "inititalized ok."
   # Read rootDSE
   r = oldap.search_s("",ldap.SCOPE_BASE,'(objectClass=*)')
except ldap.LDAPError, error:
   print error
else:
   print r

With tracing enabled it looks like this in the Python interpreter.

 >>> import ldap
 >>> oldap = ldap.initialize("ldap://localhost:1390",trace_level=2)
*** ldap://localhost:1390 - SimpleLDAPObject.set_option ((17, 3),{})
 >>> r = oldap.search_s("",ldap.SCOPE_BASE,'(objectClass=*)')
*** ldap://localhost:1390 - SimpleLDAPObject.search_ext (('', 0, 
'(objectClass=*)', None, 0, None, None, -1, 0),{})
=> result: 1
*** ldap://localhost:1390 - SimpleLDAPObject.result2 ((1, 1, -1),{})
=> result: (101, [('', {'objectClass': ['top', 'OpenLDAProotDSE']})], 1)
 >>>

Ciao, Michael.


From mike at Nexus.concordia.ca  Tue Jul 13 16:40:27 2004
From: mike at Nexus.concordia.ca (Mike D'Errico)
Date: Tue, 13 Jul 2004 10:40:27 -0400 (EDT)
Subject: Possible bug results in 'Encoding Error' on Tru64 5.1A..
In-Reply-To: <40F383C3.9000107@stroeder.com>
Message-ID: <Pine.LNX.4.33.0407130722580.13918-100000@Nexus.concordia.ca>


On Tue, 13 Jul 2004, Michael Str?der wrote:

> > - openldap-2.2.14 (tried on 2.1.23 also)
>
> I found in CHANGES of OpenLDAP 2.2.15 Engineering (currently only available
> as branch OPENLDAP_REL_ENG_2_2 in OpenLDAP's CVS):
>
>          Fixed libldap sasl_encode 64-bit bug (ITS#3054,3212)
>
> I don't have a clue whether that's really related to this issue here though.
> It could be since LDAPObject.simple_bind() directly wraps ldap_sasl_bind().
>

This is very interesting indeed.. Unfortunatly I've just tried recompiling
the module using this cvs version of openldap, but it doesn't see to have
fixed anything...

> Could you please try to submit a LDAP search request right after invoking
> ldap.initialize() to determine if LDAPObject.simple_bind() is the only
> problem or if the issue is a more general one?
>

Humm the problem appears to be on simple_bind() only... Here's the output:

*** ldap://some_valid_host - SimpleLDAPObject.set_option ((17, 3),{})
*** ldap://some_valid_host - SimpleLDAPObject.search_ext (('', 0,
'(objectClass=*)', None, 0, None, None, -1, 0),{})
=> result: 1
*** ldap://some_valid_host - SimpleLDAPObject.result2 ((1, 1, -1),{})
=> result: (101, [('', {'objectClass': ['top', 'OpenLDAProotDSE']})], 1)
[('', {'objectClass': ['top', 'OpenLDAProotDSE']})]


I've been debugging the problem all morning and all signs point towards
the openldap itself.. perhaps there's another 64 bit issue that I've
uncovered. I'll keep working on this and let you all know if I trace this
problem back towards the python-ldap module.

Thanks you for the prompt response,

Sincerely,



From michael at stroeder.com  Tue Jul 13 17:50:53 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 13 Jul 2004 17:50:53 +0200
Subject: Possible bug results in 'Encoding Error' on Tru64 5.1A..
In-Reply-To: <Pine.LNX.4.33.0407130722580.13918-100000@Nexus.concordia.ca>
References: <Pine.LNX.4.33.0407130722580.13918-100000@Nexus.concordia.ca>
Message-ID: <40F404DD.1060508@stroeder.com>

Mike D'Errico wrote:
> 
> I've been debugging the problem all morning and all signs point towards
> the openldap itself.. perhaps there's another 64 bit issue that I've
> uncovered. I'll keep working on this and let you all know if I trace this
> problem back towards the python-ldap module.

You can (globally) turn on logging in the OpenLDAP lib itself when using 
python-ldap:

ldap.set_option(ldap.OPT_DEBUG_LEVEL,255)

255 is just a wild guess.

You can also turn on logging at the OpenLDAP server's side. You could even 
choose a log level which dumps the raw BER data received in requests from 
LDAP clients.

Ciao, Michael.


From fdeldegan at libero.it  Wed Jul 14 14:24:48 2004
From: fdeldegan at libero.it (Francesco Del Degan)
Date: Wed, 14 Jul 2004 14:24:48 +0200
Subject: Server and Client Controls
Message-ID: <40F52610.1020500@libero.it>

Hi all...

I'm interested in using extended controls (simplePagedResults and
ServerSort in specific) within a search, but i've notice that this is
notImplemented yet...

What is state of it? Will be a next release feature?

I've read python-ldap source (i have also a mid knowledge of openldap
code) and i'm would to contribute to this part.

Regards...
FrancescoDD







From michael at stroeder.com  Wed Jul 14 21:07:48 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 14 Jul 2004 21:07:48 +0200
Subject: Server and Client Controls
In-Reply-To: <40F52610.1020500@libero.it>
References: <40F52610.1020500@libero.it>
Message-ID: <40F58484.5060305@stroeder.com>

Francesco Del Degan wrote:
> 
> I'm interested in using extended controls (simplePagedResults and
> ServerSort in specific) within a search, but i've notice that this is
> notImplemented yet...

Yes, still on TODO list.

> What is state of it?

There's currently no one working on it.

> Will be a next release feature?

If someone jumps on in...

> I've read python-ldap source (i have also a mid knowledge of openldap
> code) and i'm would to contribute to this part.

Well, the question is how to do it. I'd like to model controls (and extended 
operations) as Python classes and pass them into the LDAP operation methods. 
Note that controls can be passed with any LDAP operation like add, modify 
etc. That's what the _ext methods are for.

BTW: The OpenLDAP lib itself provides helper functions for creating these 
controle. But I'm not sure whether that's a clean design to use them. Maybe 
with a Python wrapper class above them...

Ciao, Michael.


From yoel at emet.co.il  Fri Jul 16 06:53:36 2004
From: yoel at emet.co.il (yoel at emet.co.il)
Date: Fri, 16 Jul 2004 07:53:36 +0300
Subject: ldap_explode_dn is broken
Message-ID: <9bda2295d12.40f78980@emet.co.il>

Hello, 

Please note that ldap_explode_dn is broken in recent minor versions of OpenLdap (it worked properly with 2.2.6 bot not with 2.2.13/14). For DN parts with multipe EQUALS ('=') the C library returns NULL regardless of the content of the DN. Python-ldap raises an exception.

Exaples of such DNs: cn=uid=yoel_o=org,o=org

Yoel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yoel.vcf
Type: text/x-vcard
Size: 225 bytes
Desc: Card for <yoel at emet.co.il>
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20040716/5fa0f0f3/attachment.vcf>

From jens at dataflake.org  Fri Jul 16 08:01:56 2004
From: jens at dataflake.org (Jens Vagelpohl)
Date: Fri, 16 Jul 2004 02:01:56 -0400
Subject: ldap_explode_dn is broken
In-Reply-To: <9bda2295d12.40f78980@emet.co.il>
References: <9bda2295d12.40f78980@emet.co.il>
Message-ID: <A48933CA-D6ED-11D8-B678-000D9368D272@dataflake.org>


On Jul 16, 2004, at 12:53 AM, yoel at emet.co.il wrote:

> Hello,
>
> Please note that ldap_explode_dn is broken in recent minor versions of 
> OpenLdap (it worked properly with 2.2.6 bot not with 2.2.13/14). For 
> DN parts with multipe EQUALS ('=') the C library returns NULL 
> regardless of the content of the DN. Python-ldap raises an exception.
>
> Exaples of such DNs: cn=uid=yoel_o=org,o=org

IMHO a DN where one element has an extra "=" in it, for whatever 
reason, is just plain broken. Don't do it.

jens






From michael at stroeder.com  Fri Jul 16 09:49:39 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 16 Jul 2004 09:49:39 +0200
Subject: ldap_explode_dn is broken
In-Reply-To: <9bda2295d12.40f78980@emet.co.il>
References: <9bda2295d12.40f78980@emet.co.il>
Message-ID: <40F78893.8060207@stroeder.com>

yoel at emet.co.il wrote:
> 
> Please note that ldap_explode_dn is broken in recent minor versions of
> OpenLdap (it worked properly with 2.2.6 bot not with 2.2.13/14). For DN
> parts with multipe EQUALS ('=') the C library returns NULL regardless of
> the content of the DN. Python-ldap raises an exception.

Testing...

 >>> from ldap import explode_dn
 >>> explode_dn('cn=Michael Stroeder,dc=stroeder,dc=de')
['cn=Michael Stroeder', 'dc=stroeder', 'dc=de']
 >>> explode_dn('cn=Michael = Stroeder')
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/lib/python2.3/site-packages/ldap/functions.py", line 117, in 
explode_dn
     return _ldap_function_call(_ldap.explode_dn,dn,notypes)
   File "/usr/lib/python2.3/site-packages/ldap/functions.py", line 57, in 
_ldap_function_call
     result = func(*args,**kwargs)
ldap.LDAPError: (11, 'Resource temporarily unavailable')
 >>> explode_dn('cn=Michael \= Stroeder')
['cn=Michael \\3D Stroeder']
 >>>

All cases look good to me...

> Exaples of such DNs: cn=uid=yoel_o=org,o=org

This is not a valid DN anyway. It looks like produced by an erronous 
application.

 >>> explode_dn('cn=uid=yoel_o=org,o=org')
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/lib/python2.3/site-packages/ldap/functions.py", line 117, in 
explode_dn
     return _ldap_function_call(_ldap.explode_dn,dn,notypes)
   File "/usr/lib/python2.3/site-packages/ldap/functions.py", line 57, in 
_ldap_function_call
     result = func(*args,**kwargs)
ldap.LDAPError: (2, 'No such file or directory')

Well, the error message is misleading I have to admit. But that 
ldap.explode_dn() fails here is correct.

The equal sign '=' has to be escaped with a back-slash '\'. See RFC2253 or 
draft-ietf-ldapbis-dn.

 >>> explode_dn('cn=uid\=yoel_o\=org,o=org')
['cn=uid\\3Dyoel_o\\3Dorg', 'o=org']
 >>>

Ciao, Michael.


From yoel at emet.co.il  Sat Jul 17 20:28:23 2004
From: yoel at emet.co.il (yoel at emet.co.il)
Date: Sat, 17 Jul 2004 21:28:23 +0300
Subject: ldap_explode_dn is broken
Message-ID: <f5e4c055034.40f999f7@emet.co.il>

Actually it is not that clear from the RFC. It seems that future versions of OpenLdap will accept such a DN like that but will return then (in searches) with the EQUALs escaped.

Thank you for the replies.

----- Original Message -----
From: Michael Str?der <michael at stroeder.com>
Date: Friday, July 16, 2004 10:49 am
Subject: Re: ldap_explode_dn is broken

> yoel at emet.co.il wrote:
> > 
> > Please note that ldap_explode_dn is broken in recent minor 
> versions of
> > OpenLdap (it worked properly with 2.2.6 bot not with 2.2.13/14). 
> For DN
> > parts with multipe EQUALS ('=') the C library returns NULL 
> regardless of
> > the content of the DN. Python-ldap raises an exception.
> 
> Testing...
> 
> >>> from ldap import explode_dn
> >>> explode_dn('cn=Michael Stroeder,dc=stroeder,dc=de')
> ['cn=Michael Stroeder', 'dc=stroeder', 'dc=de']
> >>> explode_dn('cn=Michael = Stroeder')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python2.3/site-packages/ldap/functions.py", line 
> 117, in 
> explode_dn
>     return _ldap_function_call(_ldap.explode_dn,dn,notypes)
>   File "/usr/lib/python2.3/site-packages/ldap/functions.py", line 
> 57, in 
> _ldap_function_call
>     result = func(*args,**kwargs)
> ldap.LDAPError: (11, 'Resource temporarily unavailable')
> >>> explode_dn('cn=Michael \= Stroeder')
> ['cn=Michael \\3D Stroeder']
> >>>
> 
> All cases look good to me...
> 
> > Exaples of such DNs: cn=uid=yoel_o=org,o=org
> 
> This is not a valid DN anyway. It looks like produced by an 
> erronous 
> application.
> 
> >>> explode_dn('cn=uid=yoel_o=org,o=org')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python2.3/site-packages/ldap/functions.py", line 
> 117, in 
> explode_dn
>     return _ldap_function_call(_ldap.explode_dn,dn,notypes)
>   File "/usr/lib/python2.3/site-packages/ldap/functions.py", line 
> 57, in 
> _ldap_function_call
>     result = func(*args,**kwargs)
> ldap.LDAPError: (2, 'No such file or directory')
> 
> Well, the error message is misleading I have to admit. But that 
> ldap.explode_dn() fails here is correct.
> 
> The equal sign '=' has to be escaped with a back-slash '\'. See 
> RFC2253 or 
> draft-ietf-ldapbis-dn.
> 
> >>> explode_dn('cn=uid\=yoel_o\=org,o=org')
> ['cn=uid\\3Dyoel_o\\3Dorg', 'o=org']
> >>>
> 
> Ciao, Michael.
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yoel.vcf
Type: text/x-vcard
Size: 225 bytes
Desc: Card for <yoel at emet.co.il>
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20040717/e4453ac6/attachment.vcf>

From michael at stroeder.com  Sat Jul 17 18:50:57 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Sat, 17 Jul 2004 18:50:57 +0200
Subject: Possible bug results in 'Encoding Error' on Tru64 5.1A..
In-Reply-To: <Pine.LNX.4.33.0407130722580.13918-100000@Nexus.concordia.ca>
References: <Pine.LNX.4.33.0407130722580.13918-100000@Nexus.concordia.ca>
Message-ID: <40F958F1.3010702@stroeder.com>

Mike D'Errico wrote:
> On Tue, 13 Jul 2004, Michael Str?der wrote:
> 
>>I found in CHANGES of OpenLDAP 2.2.15 Engineering (currently only available
>>as branch OPENLDAP_REL_ENG_2_2 in OpenLDAP's CVS):
>>
>>         Fixed libldap sasl_encode 64-bit bug (ITS#3054,3212)
> 
> This is very interesting indeed.. Unfortunatly I've just tried recompiling
> the module using this cvs version of openldap, but it doesn't see to have
> fixed anything...

There's another new line in CHANGES which seems to be interesting for this 
issue. Please check if it's already in your CVS working dir:

         Fixed libldap SASL re-encode bug

If it's new please recompile and test again. There also have been added a 
bunch of other fixes (see Kurt's message below).

Ciao, Michael.

-------- Original Message --------
Subject: OPENLDAP_REL_ENG_2_2, please test
Date: Fri, 16 Jul 2004 13:00:21 -0700
From: Kurt D. Zeilenga <Kurt at OpenLDAP.org>
To: openldap-devel at OpenLDAP.org

I've incorporated many significant changes from HEAD
into 2.2, including those to back-bdb to address
various database/locking issues.  Please test.

Also, please check if I've incorporated everything
needing to get released and nothing which shouldn't
be released.

Thanks, Kurt



From bernard at geekHaus.net.au  Mon Jul 19 08:02:13 2004
From: bernard at geekHaus.net.au (Bernard Gardner)
Date: Mon, 19 Jul 2004 16:02:13 +1000
Subject: ldap_whoami_s availability in OpenLDAP libs
In-Reply-To: <406853F1.7010804@stroeder.com>
References: <406853F1.7010804@stroeder.com>
Message-ID: <2DD88066-D949-11D8-AA93-000A95DA9CB4@geekHaus.net.au>


On 30 Mar 2004, at 2:50 AM, Michael Str?der wrote:

> * Function l_ldap_whoami_s() only added if built against
>   OpenLDAP 2.1.x+ libs (should preserve compability with 2.0 libs)

Hi Michael,

I just tried to build python-ldap-2.0.1 against OpenLDAP 2.1.11 and 
found
out that this isn't quite right. The patch below seems to fix it. I 
think
the function was introduced in OpenLDAP 2.1.13 based on:

http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/whoami.c

Obviously this is only a problem for a tiny minority of users (quite
possibly only me :)

Thanks,
Bernard.

*** LDAPObject.c.orig   Mon Jul 19 15:47:03 2004
--- LDAPObject.c        Mon Jul 19 15:47:31 2004
***************
*** 852,859 ****
   }


! #if LDAP_VENDOR_VERSION>=20100
! /* ldap_whoami_s (available since OpenLDAP 2.1.x) */

   static PyObject*
   l_ldap_whoami_s( LDAPObject* self, PyObject* args )
--- 852,859 ----
   }


! #if LDAP_VENDOR_VERSION>=20113
! /* ldap_whoami_s (available since OpenLDAP 2.1.13) */

   static PyObject*
   l_ldap_whoami_s( LDAPObject* self, PyObject* args )
***************
*** 987,993 ****
   #ifdef HAVE_TLS
       {"start_tls_s",   (PyCFunction)l_ldap_start_tls_s,        
METH_VARARGS },
   #endif
! #if LDAP_VENDOR_VERSION>=20100
       {"whoami_s",      (PyCFunction)l_ldap_whoami_s,           
METH_VARARGS },
   #endif
       {"manage_dsa_it", (PyCFunction)l_ldap_manage_dsa_it,      
METH_VARARGS },
--- 987,993 ----
   #ifdef HAVE_TLS
       {"start_tls_s",   (PyCFunction)l_ldap_start_tls_s,        
METH_VARARGS },
   #endif
! #if LDAP_VENDOR_VERSION>=20113
       {"whoami_s",      (PyCFunction)l_ldap_whoami_s,           
METH_VARARGS },
   #endif
       {"manage_dsa_it", (PyCFunction)l_ldap_manage_dsa_it,      
METH_VARARGS },




From michael at stroeder.com  Tue Jul 20 13:29:49 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 20 Jul 2004 13:29:49 +0200
Subject: ldap_whoami_s availability in OpenLDAP libs
In-Reply-To: <2DD88066-D949-11D8-AA93-000A95DA9CB4@geekHaus.net.au>
References: <406853F1.7010804@stroeder.com> <2DD88066-D949-11D8-AA93-000A95DA9CB4@geekHaus.net.au>
Message-ID: <40FD022D.10905@stroeder.com>

Bernard Gardner wrote:
> 
> I just tried to build python-ldap-2.0.1 against OpenLDAP 2.1.11 and found
> out that this isn't quite right. The patch below seems to fix it.

Added your patch to CVS. Thanks a lot for submitting it.

Ciao, Michael.


From michael at stroeder.com  Wed Aug  4 16:15:58 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 04 Aug 2004 16:15:58 +0200
Subject: segmentation fault on redhat enterprise linux
In-Reply-To: <E4729215-E5F9-11D8-8FAA-000A95D1301E@amaxa.com>
References: <E4729215-E5F9-11D8-8FAA-000A95D1301E@amaxa.com>
Message-ID: <4110EF9E.9040606@stroeder.com>

Christian Guenther wrote:
> 
> I have a bunch of python and shell scripts that manage my 150+ users  
> and groups in ldap and
> generate necessary links and aliases for them. The scripts used to work  
> perfectly on RedHat 9
> and also on Debian 3 - they even workm on my Apple Powerbook under Mac  
> OS X Panther.

Well, which versions of OpenLDAP and cyrus-sasl do you have on these systems?

>     RedHat Enterprise Linux ES 3
>     Python 2.0.2
>     Openldap 2.0.27
>     OpenSSL 0.9.7a
>     cyrus sasl 2.1.15

RedHat's support for OpenLDAP is bad.
I'd recommend to upgrade cyrus-sasl and OpenLDAP libs.

Note that libldap_r is not available for OpenLDAP 2.0.x. Please make sure 
your setup.cfg reflects this.

>     kernel 2.0.23 with XFS support - self compiled

2.0? Why such an old kernel?

>     python-ldap 2.0.2 compiled from tarball

What's the output of

# ldd /usr/lib/python2.0/site-packages/_ldap.so

Ciao, Michael.


From christian.guenther at amaxa.com  Wed Aug  4 11:37:24 2004
From: christian.guenther at amaxa.com (Christian Guenther)
Date: Wed, 4 Aug 2004 11:37:24 +0200
Subject: segmentation fault on redhat enterprise linux
Message-ID: <E4729215-E5F9-11D8-8FAA-000A95D1301E@amaxa.com>

Hi List,

I have a bunch of python and shell scripts that manage my 150+ users  
and groups in ldap and
generate necessary links and aliases for them. The scripts used to work  
perfectly on RedHat 9
and also on Debian 3 - they even workm on my Apple Powerbook under Mac  
OS X Panther.
However since we switched over to RedHat Enterprise Linux 3, I'm having  
diffculties.
Whenever I try to use one of my scripts they just die with a signal 11.  
The error is reproducable
in the python shell as well. I do a

	import ldap
	l = ldap.initialize("ldap://my.ldap.server")
	l.simple_bind_s()

and receive a segmentation fault.

My environment looks like:

	RedHat Enterprise Linux ES 3
	Python 2.0.2
	Openldap 2.0.27
	OpenSSL 0.9.7a
	cyrus sasl 2.1.15

	kernel 2.0.23 with XFS support - self compiled

	python-ldap 2.0.2 compiled from tarball

If anyone could pleeeeease help me,

	chris



From steverding at gws.ms  Tue Sep  7 14:12:03 2004
From: steverding at gws.ms (Steverding, Kai)
Date: Tue, 7 Sep 2004 14:12:03 +0200
Subject: Global Bind Timeout
Message-ID: <C43D74B62BA19A45ADD74C1AB7AEE54242CD35@NT-GWS2>

I want to write a monitor for a ldap server in python. Now  i have the
problem, that the client hangs for about 3 minutes if the servers istn't
available. (eg the server reboots,so there is no connection refused or
something like that). I'd like to throw an error if the server-bind doesn't
work after 20 seconds or so. I found the timeout for result, but nothing
about a "bind-timeout". What can i do ?

Kai





From michael at stroeder.com  Tue Sep 14 14:26:35 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 14 Sep 2004 14:26:35 +0200
Subject: Global Bind Timeout
In-Reply-To: <C43D74B62BA19A45ADD74C1AB7AEE54242CD35@NT-GWS2>
References: <C43D74B62BA19A45ADD74C1AB7AEE54242CD35@NT-GWS2>
Message-ID: <4146E37B.80007@stroeder.com>

Kai,

sorry for answering late.

Steverding, Kai wrote:
> Now  i have the
> problem, that the client hangs for about 3 minutes if the servers istn't
> available. (eg the server reboots,so there is no connection refused or
> something like that).

I simulated this by using a firewall rule dropping IP packets.

> I'd like to throw an error if the server-bind doesn't
> work after 20 seconds or so. I found the timeout for result, but nothing
> about a "bind-timeout". What can i do ?

Use something like this for setting the network timeout before the simple bind:

     l = LDAPObject(ldap_url.initializeUrl())
     l.protocol_version = 3
     l.network_timeout = 2.5 # connect timeout 2500 msec
     l.simple_bind_s()

Note that the l.simple_bind_s() raises the LDAPError exception 
ldap.SERVER_DOWN, not ldap_url.initializeUrl().

The behaviour might only work with recent python-ldap (2.0.0pre14+ according 
to CHANGES) and OpenLDAP libs (tested on my system with python-ldap 2.0.2 
and OpenLDAP 2.2.17 libs).

Ciao, Michael.