From: Mike D'E. <mi...@Ne...> - 2004-07-12 19:06:43
|
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 ------------------------------------------------------------------------- |
From: <mi...@st...> - 2004-07-13 07:06:03
|
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 D'E. <mi...@Ne...> - 2004-07-13 14:41:09
|
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 ------------------------------------------------------------------------- |
From: <mi...@st...> - 2004-07-13 16:07:26
|
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: <mi...@st...> - 2004-07-17 16:55:17
|
Mike D'Errico wrote: > On Tue, 13 Jul 2004, Michael Str=F6der wrote: >=20 >>I found in CHANGES of OpenLDAP 2.2.15 Engineering (currently only avail= able >>as branch OPENLDAP_REL_ENG_2_2 in OpenLDAP's CVS): >> >> Fixed libldap sasl_encode 64-bit bug (ITS#3054,3212) >=20 > This is very interesting indeed.. Unfortunatly I've just tried recompil= ing > the module using this cvs version of openldap, but it doesn't see to ha= ve > fixed anything... There's another new line in CHANGES which seems to be interesting for thi= s=20 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= =20 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 <Ku...@Op...> To: ope...@Op... 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 |