python-ldap-dev — discussion among developers

Re: Possible bug results in 'Encoding Error' on Tru64 5.1A..

[Mike D'E. <mi...@Ne...>]

On Tue, 13 Jul 2004, Michael Str=F6der wrote:

> > - openldap-2.2.14 (tried on 2.1.23 also)
>
> I found in CHANGES of OpenLDAP 2.2.15 Engineering (currently only availab=
le
> 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 thou=
gh.
> 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=3D*)', None, 0, None, None, -1, 0),{})
=3D> result: 1
*** ldap://some_valid_host - SimpleLDAPObject.result2 ((1, 1, -1),{})
=3D> 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,

-------------------------------------------------------------------------
Michel D'Errico
System Programmer / Analyst
IITS, System Software Unix Group,
Concordia University
-------------------------------------------------------------------------

Re: Possible bug results in 'Encoding Error' on Tru64 5.1A..

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

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.

Possible bug results in 'Encoding Error' on Tru64 5.1A..

[Mike D'E. <mi...@Ne...>]

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,

-------------------------------------------------------------------------
Michel D'Errico
System Programmer / Analyst
IITS, System Software Unix Group,
Concordia University
-------------------------------------------------------------------------

Re: Notes on ActivePython and IIS

[Greg F. <gfo...@ma...>]

I'm on the list so no need to cc: me with your reply...

On Wednesday 30 June 2004 09:29 am, you wrote:
> Greg Fortune wrote:
> > I fought with the python-ldap module last night, but couldn't get it to
> > behave properly.  It would import when working on the command line or
> > through PythonWin, but refused to import through ASP/IIS.  I would get a
> > module not found error message.
>
> Please post a complete traceback.

##############
Without any ldap module installed on the ASP page.
=2D----------------------------------------------------
Traceback: File "", line 7, in ?=20
exceptions.ImportError: No module named ldap
=2D----------------------------------------------------

=46rom the command line, import ldap gives
>>> import ldap
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named ldap

###############

After copying the contents of the zip file into the site-packages directory.
=2D----------------------------------------------------
Traceback: File "", line 7, in ?=20
exceptions.ImportError: No module named ldap
=2D----------------------------------------------------

=46rom the command line, it imports successfully.

################
After deleting the necessary files and installing via the .exe, the import =
is=20
successful from both the command line and ASP.

Python version:
2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)]

I wrapped the traceback to make sure we were getting a full traceback as it=
=20
didn't look terribly helpful.  The code on that page is as follows:

<%@ LANGUAGE=3D"Python" %>
<html>
<head></head>
<body>
<%

import sys
if(Server.MapPath('/admin/libs') not in sys.path):
	sys.path.append(Server.MapPath('/admin/libs'))
=09
Response.write(str(sys.version) + '<br>')

try:
	import ldap
except ImportError, err:
	(t, val, tb) =3D sys.exc_info()
	import traceback
	msg =3D  '-----------------------------------------------------<br>'
	msg +=3D 'Traceback:\n'
	msg +=3D '<br>'.join(traceback.format_tb(tb)) + '<br>'
	msg +=3D '%s: %s<br>' % (t, val)
	msg +=3D '-----------------------------------------------------<br>'
	Response.write(msg)
=09

>
> > This morning, I tried the .exe installer from Mauro
> > (python-ldap-2.0.0pre14.win32-py2.3.exe) and it worked like a charm.
>
> Very often I had seg faults when using it with standard Python 2.3.3.

This is with ActivePython, but it might have the same problem :(  I've used=
=20
ldap with=20
Python 2.3.3 (#1, May 25 2004, 08:52:15)
[GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2
and it seems to work fine.  I'll watch for the segfaults...

Greg Fortune

Re: Notes on ActivePython and IIS

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

Greg Fortune wrote:
> I fought with the python-ldap module last night, but couldn't get it to behave 
> properly.  It would import when working on the command line or through 
> PythonWin, but refused to import through ASP/IIS.  I would get a module not 
> found error message.

Please post a complete traceback.

> This morning, I tried the .exe installer from Mauro 
> (python-ldap-2.0.0pre14.win32-py2.3.exe) and it worked like a charm.

Very often I had seg faults when using it with standard Python 2.3.3.

Ciao, Michael.

Notes on ActivePython and IIS

[Greg F. <gfo...@ma...>]

I fought with the python-ldap module last night, but couldn't get it to behave 
properly.  It would import when working on the command line or through 
PythonWin, but refused to import through ASP/IIS.  I would get a module not 
found error message.

This morning, I tried the .exe installer from Mauro 
(python-ldap-2.0.0pre14.win32-py2.3.exe) and it worked like a charm.  It 
appears that the package from volker doesn't function properly with 
ActivePython through ASP (python-2.3-ldap-2.0.0pre11.win32.zip) although it 
might simply be the difference in version numbers.  btw, I installed the .zip 
file by copying the ldap directory and files into 
c:\Python23\Lib\site-packages so I believe I got it installed correctly.

Greg Fortune

ANN: python-ldap-2.0.1

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

Find a new pre-release of python-ldap:

   http://python-ldap.sourceforge.net/

python-ldap provides an object-oriented API to access LDAP directory
servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for
that purpose. Additionally it contains modules for other LDAP-related
stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema).

----------------------------------------------------------------
Released 2.0.1 2004-06-29

Changes since 2.0.0:

dsml:
* Fixed wrong exception message format string

ldap.schema.models:
* Fixed Entry.__delitem__() to delete really everything
   when deleting an attribute dictionary item.

Re: Certificate Confusion:hostname does not match CN

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

Becky Hepper wrote:
> 
> I got the following error:  "SSL3_GET_SERVER_CERTIFICATE: certificate 
> verify failed".  So I asked the people that control the LDAP server for 
> a key.  They sent me the Netscape certificate: cert7.db & key3.db.  If I 
> put those two files in my home directory and add this line to my code:   
> ldap.set_option(ldap.OPT_X_TLS_CACERTDIR, "/home/jack")  I get an 
> error:  "TLS: hostname does not match CN in peer certificate".

???

How did you build python-ldap? I really wonder why this does anything useful.

>  Can I use the cert7.db or does it 
> have to be converted to a PEM file?

python-ldap uses the OpenLDAP libs which in turn use the OpenSSL libs which 
cannot handle Netscape certificate database files
=> you have to use PEM files.

>  I get the same error if I use the 
> following line in my code: ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, 
> "/usr/share/ssl/cert.pem")  What is this cert.pem file that 
> automatically gets installed?

There's nothing automatically installed. cert.pem should contain the CA 
certificate against which the server certificate is validated.

Recommended reading:

http://www.openldap.org/faq/index.cgi?_highlightWords=ssl&file=185

Ciao, Michael.

Re: Certificate Confusion:hostname does not match CN

[Derrick 'd. H. <dm...@dm...>]

On Wed, Jun 09, 2004 at 02:58:43PM +0000, Becky Hepper wrote:
[...]
=20
| I got the following error:  "SSL3_GET_SERVER_CERTIFICATE: certificate=20
| verify failed".

The cert could be self-signed.  Unless the CA (Certificate Authority)
certificate is known (and trusted) by the client, the verification
will fail because the client has no way to automatically trust the
certificate.

| So I asked the people that control the LDAP server for a=20
| key.  They sent me the Netscape certificate: cert7.db & key3.db.  If I pu=
t=20
| those two files in my home directory and add this line to my code:  =20
| ldap.set_option(ldap.OPT_X_TLS_CACERTDIR, "/home/jack")

This solves that problem.

| I get an error:  "TLS: hostname does not match CN in peer
| certificate".  Does anyone know what that error means?

This means that you tried to connect to a machine using the name
'foo'.  However the CN (Common Name) in the SSL certificate is 'bar'.
The CN in the certificate needs to match the hostname used to connect
in order for automatic verification to work.

One cause for this problem is a machine with multiple host names.
In this scenario, make sure you are using the name in the CN of the
cert and not some other name that resolves to that host.

Another cause is a poorly made cert.  If this is the case, have the
server administrators recreate the cert and instruct them to specify
the correct hostname as the CN for the cert.


BTW, you can demonstrate both of these "error" conditions with a web
browser.  The only difference is the browser then prompts the user and
allows the user to manually choose to trust the cert when automatic
verification fails.

HTH,
-D

--=20
"Open Source Software - Sometimes you get more than you paid for..."
=20
www: http://dman13.dyndns.org/~dman/            jabber: dman@dman13.dyndns.=
org

Certificate Confusion:hostname does not match CN

[Becky H. <br...@ho...>]

Hi,

I am working on a RH 9 Linux system.  Below is the code I'm using:

l = ldap.initialize('ldaps://x.x.x:636')
l.protocol_version=ldap.VERSION3
l.simple_bind_s("username", "password")
l.unbind_s()

I got the following error:  "SSL3_GET_SERVER_CERTIFICATE: certificate verify 
failed".  So I asked the people that control the LDAP server for a key.  
They sent me the Netscape certificate: cert7.db & key3.db.  If I put those 
two files in my home directory and add this line to my code:   
ldap.set_option(ldap.OPT_X_TLS_CACERTDIR, "/home/jack")  I get an error:  
"TLS: hostname does not match CN in peer certificate".  Does anyone know 
what that error means?  Can I use the cert7.db or does it have to be 
converted to a PEM file?  I get the same error if I use the following line 
in my code: ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, 
"/usr/share/ssl/cert.pem")  What is this cert.pem file that automatically 
gets installed?  Is it just an example or did RH convert the cert7.db?

Thanks!

_________________________________________________________________
Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com

Re: Which sha to use?

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

S. Alan Ezust wrote:
> 
> Which SHA to use? slappasswd claims to use SHA digests, but it's not the same 
> as what the python sha built-in uses.

It is the same SHA-1 hash algorithm.

> $ slappasswd
> New password: foobar
> {SSHA}ssib43Zm62dDYjKVLYg/IMXJMBJPMYDG

This is a salted SHA-1 hash.

http://www.openldap.org/faq/data/cache/347.html

Ciao, Michael.

Which sha to use?

[S. A. E. <ez...@us...>]

Hi, I'm new here.

Which SHA to use? slappasswd claims to use SHA digests, but it's not the same 
as what the python sha built-in uses. Does the LDAP python library have its 
own sha interface that's compatible with slappasswd?
:
>>> import sha
>>> x = sha.new("foobar")
>>> x.digest()
'\x88C\xd7\xf9$\x16!\x1d\xe9\xeb\xb9c\xffL\xe2\x81%\x93(x'
>>> x.hexdigest()
'8843d7f92416211de9ebb963ff4ce28125932878'

$ slappasswd
New password: foobar
{SSHA}ssib43Zm62dDYjKVLYg/IMXJMBJPMYDG

Why are these different anyway? Should I be using the sha built-in 
differently? 

question #2: Is there a simple example of how to add the first 
user/sha-password/e-mail into a brand-new LDAP repository and then query it 
to get the user back?



-- 
S. Alan Ezust
Ottawa, Ontario, Canada
http://cartan.cas.suffolk.edu/~sae

Re: Please update Win32 builds

[Mauro C. <mci...@li...>]

Michael Str=F6der wrote:

> I'd like to kindly ask maintainers of Win32 builds to update their=20
> binary distributions.=20

I'll try. This will mean updating the win32 build of the OpenLDAP lib...=20
which is currently  evolving quite a bit (at long last!), so this will=20
all be more complicated... but I'll try.
Don't hold your breath though, before the end of next week nothing will=20
happen on my part :-(

Mauro

Re: Leave Sourceforge?

[Mauro C. <mci...@li...>]

Michael Str=F6der wrote:

> - Since quite some time I'm the only developer who is really applying=20
> patches to the python-ldap code =3D> there's no need for CVS access.

Too right :-(
I'm sad I can't contribute, I wish I could but I really am at a loss for=20
time just to do what I must do.
This said, kudos to Michael, you're doing such a great job.

> Therefore I'd like to ask the community here if there are any=20
> objections against moving the python-ldap stuff away from SF.net into=20
> my own private web space (probably under=20
> http://www.stroeder.com/pylib/). In my private environment I can=20
> implement scripts for doing many things automagically which would save=20
> me lot of time.

Well, I'd normally be against moving out of a shared space to a private=20
one, but if it can make your life easier I am totally in favor. +1.

Mauro

Re: Leave Sourceforge?

[Jens V. <je...@da...>]

> Therefore I'd like to ask the community here if there are any 
> objections
> against moving the python-ldap stuff away from SF.net into my own 
> private
> web space (probably under http://www.stroeder.com/pylib/). In my 
> private
> environment I can implement scripts for doing many things automagically
> which would save me lot of time.

+1

I'd do the same thing for any project where I would be the "last man 
standing" like you are.

jens

FYI: python-ldap at OpenLDAP booth, Linuxtag 2004

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

HI!

There will be an OpenLDAP booth at Linuxtag 2004, Karlsruhe, Germany (see 
http://www.linuxtag.org/2004/, currently Java-buggy) where I also 
participate and will present web2ldap. Off course I'm available to answer 
questions about python-ldap either.

Ciao, Michael.

Please update Win32 builds

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

HI!

I'd like to kindly ask maintainers of Win32 builds to update
their binary distributions.

Please....

Ciao, Michael.

Re: Leave Sourceforge?

[Joao S. O. B. <gw...@mp...>]

Hi,

I would have no problem with that at all.

If there is no problem with it, I think it would be important to redirect=20
anyone who hits current sourceforge develelopment area to be sent to the ne=
w=20
space.

Thank you for consulting the list at all.

	JS
	-><-=20

On Tuesday 18 May 2004 16:43, Michael Str=F6der wrote:
> HI!
>
> SF is a nice service for distributed development and the infrastructure is
> helpful for many projects. And we don't have to pay for it. So it was
> natural for David to move the python-ldap stuff to SF when he did not have
> much time to work on it himself anymore.
>
> But sometimes using SF really drives me crazy!
>

Leave Sourceforge?

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

HI!

SF is a nice service for distributed development and the infrastructure is
helpful for many projects. And we don't have to pay for it. So it was
natural for David to move the python-ldap stuff to SF when he did not have
much time to work on it himself anymore.

But sometimes using SF really drives me crazy!

- Some things, e.g. the file-release system, have such a messy user
interface with ad banners that it's really waste of time to use it.

- Access is often damn slow

- Systems are quite often not available (e.g. can't login/CVS with ssh)

- SSL setup for web interface screwed up => security pop-ups

Furthermore:

- Since quite some time I'm the only developer who is really applying
patches to the python-ldap code => there's no need for CVS access.

- Additionally the python-ldap project does not make use of many of the SF
features (trackers are rarely used, the documentation is just on the normal
web page, etc.).

Therefore I'd like to ask the community here if there are any objections
against moving the python-ldap stuff away from SF.net into my own private
web space (probably under http://www.stroeder.com/pylib/). In my private
environment I can implement scripts for doing many things automagically
which would save me lot of time.

Ciao, Michael.

ANN: python-ldap-2.0.0

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

Find a new pre-release of python-ldap:

   http://python-ldap.sourceforge.net/

python-ldap provides an object-oriented API to access LDAP directory
servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for
that purpose. Additionally it contains modules for other LDAP-related
stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema).

----------------------------------------------------------------
Released 2.0.0 2004-05-18

Changes since 2.0.0pre21:

ldif:
* Empty records are simply ignored in ldif.LDIFWriter.unparse()

Modules/:
* New method result2() returns 3-tuple containing the msgid
   of the outstanding operation.

ldap.ldapobject:
* New _ldap wrapper method LDAPObject.result2() (see above)
   which is now used by LDAPObject.result().

Re: Where's the RES_BIND?

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

Jerry Lee wrote:
> 
> Any idea where it might be documented what result is returning??
> These docs:
> http://python-ldap.sourceforge.net/doc/python-ldap/ldap-objects.html
> seem a bit off.

Docs are already fixed in CVS version.
I will release these updated docs ASAP.

Ciao, Michael.

Re: Where's the RES_BIND?

[Derrick 'd. H. <dm...@dm...>]

On Tue, May 11, 2004 at 09:06:40PM +0000, Jerry Lee wrote:
| Hello All,
|=20
| I just dusted off a QT LDAP browser I had been working on and noticed it=
=20
| didn't work.
| A bit of investigation revealed that after:
| import ldap
| >>>c =3D ldap.open(host=3D'localhost', port=3D389)
| >>>msg =3D c.bind("cn=3Droot,o=3DUniversity of Michigan,=20
| >>>c=3DUS","secret",ldap.AUTH_SIMPLE)
| >>>msg
| 1
| >>>status,res =3Dc.result(msg,1,5)
| >>>status
| 97
|=20
| 97?  It used to be 'RES_BIND'.....
| Guess things have changed a bit :-)

Use the symbolic names provided by the module.  Don't use string
literals.

| Any idea where it might be documented what result is returning??

http://sourceforge.net/mailarchive/forum.php?forum_id=3D4346&max_rows=3D25&=
style=3Dflat&viewmonth=3D200403&viewday=3D11

| These docs:
| http://python-ldap.sourceforge.net/doc/python-ldap/ldap-objects.html
| seem a bit off.

The docs are missing the module constants.  One way to see what is
available :
    $ python
    Python 2.3.3 (#2, Feb 24 2004, 09:29:20)=20
    [GCC 3.3.3 (Debian)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ldap
    >>> dir(ldap)

For the code shown above, use :
    import ldap
    [...]
    status,res =3Dc.result(msg,1,5)
    if status =3D=3D ldap.RES_BIND :
        print "result is BIND"

-D

--=20
\begin{humor}
Disclaimer:
If I receive a message from you, you are agreeing that:
   1. I am by definition, "the intended recipient"
   2. All information in the email is mine to do with as I see fit and make
        such financial profit, political mileage, or good joke as it lends
        itself to. In particular, I may quote it on USENET or the WWW.
   3. I may take the contents as representing the views of your company.
   4. This overrides any disclaimer or statement of confidentiality that may
        be included on your message
\end{humor}
=20
www: http://dman13.dyndns.org/~dman/            jabber: dman@dman13.dyndns.=
org

Where's the RES_BIND?

[Jerry L. <te...@ho...>]

Hello All,

I just dusted off a QT LDAP browser I had been working on and noticed it 
didn't work.
A bit of investigation revealed that after:
import ldap
>>>c = ldap.open(host='localhost', port=389)
>>>msg = c.bind("cn=root,o=University of Michigan, 
>>>c=US","secret",ldap.AUTH_SIMPLE)
>>>msg
1
>>>status,res =c.result(msg,1,5)
>>>status
97

97?  It used to be 'RES_BIND'.....
Guess things have changed a bit :-)

Any idea where it might be documented what result is returning??
These docs:
http://python-ldap.sourceforge.net/doc/python-ldap/ldap-objects.html
seem a bit off.

Thanks in advance,

Jerry.

_________________________________________________________________
Express yourself with the new version of MSN Messenger! Download today - 
it's FREE! http://messenger.msn.com/go/onm00200471ave/direct/01/

Re: Why LDAPObject.._ldap_object_lock around library calls?

[Ken K. <key...@KS...>]

> Don't do this! The OpenLDAP libs are not re-entrant within one connection
> context. See OpenLDAP mailings list archives for details.
>

Ahh.  This is the crux of my problem!  I was working on the mistaken
assumption that the ldap_r library verion was fully (operational)
thread-safe. As you can tell, I'm a newbie to LDAP as well as Python.

Thanks for saving me from myself!
K^2

Re: Why LDAPObject.._ldap_object_lock around library calls?

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

Ken Key wrote:
> Ah, I found the answer to my question.  Since we store the thread
> state in the LDAPObject instance, the object cannot be shared between
> my two threads.

It can be shared. That's what the locks are for. But not in a completely 
async manner like you're trying. Maybe your problem is that you are using 
result2() in a blocking manner. You can let it somewhat poll the results. 
But this is CPU intensive.

(History: I had a non-blocking version of result() in former versions of 
python-ldap to avoid locking over long time spans. But some people 
experienced serious problems with it.)

> I tossed together a prototype of the two-thread model I was thinking of.
> With the LDAPObject._ldap_lock in place, I got the deadlock I was
> afraid of.  When I removed the _ldap_lock.acquire/release in
> _ldap_call() I got the "saving thread twice?" fatal error from the
> LDAP_BEGIN_ALLOW_THREADS() when the second thread makes the second
> function call.

Don't mess around with the locks! They are needed because of the OpenLDAP libs.

Ciao, Michael.