From: Mark R. <mr...@ok...> - 2004-12-11 00:24:50
|
Hello, all. I've been trying to figure out the cause of a strange bug and have traced it down to a small example. It seems that searching with wildcards or using the ! operator cause the ldap connection to die, but only when using gssapi (possibly other sasl mechanisms, that's the only one I've tried). Here is the code that causes the problem, you should be able to cut n' paste into an interactive interpreter. Thanks for any suggestions. Mark Roach #---------------------------- import ldap import ldap.sasl URI = 'ldap://cujo.okmaybe.com' BASEDN = 'dc=okmaybe,dc=com' BINDDN = 'cn=admin,dc=okmaybe,dc=com' PASS = 'mypassword' def printTree(conn, dn, out, indent=0, run_extra_search=False): "recursively prints ou objects to a list" # This is the extra bit of searching that kills the ldap connection if (run_extra_search): resid = conn.search(dn, ldap.SCOPE_ONELEVEL, \ '(objectClass=*)') rescode, res = conn.result(resid, timeout=10) # Search for organizationalUnits recursively resid = conn.search(dn, ldap.SCOPE_ONELEVEL, \ '(objectClass=organizationalUnit)', ['ou']) rescode, res = conn.result(resid, timeout=10) out.append( " " * indent + dn) for c in res: if c[1].has_key('ou'): printTree(conn, c[0], out, indent + 1, run_extra_search) ### Try a connection with simple bind (This works fine) l = ldap.initialize(URI) l.bind_s(BINDDN, PASS) for i in xrange(50): out = [] printTree(l, BASEDN, out) for i in xrange(50): out = [] printTree(l, BASEDN, out, run_extra_search = True) ### Now try a gssapi connection g = ldap.sasl.gssapi() l = ldap.initialize(URI) l.sasl_interactive_bind_s('', g) # This one works for i in xrange(50): out = [] try: printTree(l, BASEDN, out) except: print "Died on iteration %d" % (i) print out break # Maybe dies, maybe succeeds (mostly dies) for i in xrange(50): out = [] try: printTree(l, BASEDN, out, run_extra_search = True) except: print "Died on iteration %d" % (i) print out break |
From: <mi...@st...> - 2004-12-11 09:32:12
|
Mark Roach wrote: > Hello, all. I've been trying to figure out the cause of a strange bug > and have traced it down to a small example. It seems that searching with > wildcards or using the ! operator cause the ldap connection to die, but > only when using gssapi (possibly other sasl mechanisms, that's the only > one I've tried). > > Here is the code that causes the problem, you should be able to cut n' > paste into an interactive interpreter. Are you sure that the code and python-ldap causes the problem? Which LDAP server and which version is it? Ciao, Michael. |
From: <mi...@st...> - 2004-12-11 13:11:08
|
Michael Str=F6der wrote: > Mark Roach wrote: >=20 >> Hello, all. I've been trying to figure out the cause of a strange bug >> and have traced it down to a small example. It seems that searching wi= th >> wildcards or using the ! operator cause the ldap connection to die, bu= t >> only when using gssapi (possibly other sasl mechanisms, that's the onl= y >> one I've tried). >> >> Here is the code that causes the problem, you should be able to cut n'= >> paste into an interactive interpreter. >=20 > Are you sure that the code and python-ldap causes the problem? >=20 > Which LDAP server and which version is it? It'd be also useful to know which versions of OpenLDAP libs, cyrus-sasl=20 and heimdal are used with python-ldap. Note that this combination is rather fragile. Please use current=20 versions of all these... Ciao, Michael. |
From: Mark R. <mr...@ok...> - 2004-12-11 18:43:47
|
On Sat, 2004-12-11 at 13:36 +0100, Michael Str=F6der wrote: > >=20 > > Are you sure that the code and python-ldap causes the problem? > >=20 > > Which LDAP server and which version is it? >=20 > It'd be also useful to know which versions of OpenLDAP libs, cyrus-sasl=20 > and heimdal are used with python-ldap. >=20 > Note that this combination is rather fragile. Please use current=20 > versions of all these... Hi, Michael. I'm not sure how to test outside of python-ldap. I guess I could try duplicating the code in C, but that would take me some time as I'm not much of a C hacker. I'm on Ubuntu. Relevant versions of software are: SERVER: slapd: 2.1.30 libkrb53: 1.3.4 libsasl2: 2.1.19 libsasl2-gssapi-mit: 2.1.18 CLIENT: libsasl2: 2.1.19 libsasl2-gssapi-mit: 2.1.18 python-ldap: 2.0.4 I guess I'll have to try upgrading my openldap stuff, but I am hoping to be able to deploy this app on debian systems where this is the latest version (due to their patch to use gnutls instead of openssl not having been ported yet). Can anyone else maybe try to run the example code I provided and see if it causes problems for them? Thanks, Mark Roach |
From: <mi...@st...> - 2004-12-12 00:47:13
|
Mark Roach wrote: > > I'm on Ubuntu. Relevant versions of software are: > > SERVER: > slapd: 2.1.30 > libkrb53: 1.3.4 > libsasl2: 2.1.19 > libsasl2-gssapi-mit: 2.1.18 > > CLIENT: > libsasl2: 2.1.19 > libsasl2-gssapi-mit: 2.1.18 > python-ldap: 2.0.4 > > I guess I'll have to try upgrading my openldap stuff, Upgrading would be good. AFAIK the MIT Kerberos implementation is not thread-safe. This can lead to very weird effects depending how OpenLDAP's slapd is built. Use a recent heimdal release instead. Ciao, Michael. |
From: Mark R. <mr...@ok...> - 2004-12-12 04:51:36
|
On Sun, 2004-12-12 at 01:28 +0100, Michael Str=F6der wrote: > Upgrading would be good. AFAIK the MIT Kerberos implementation is not=20 > thread-safe. This can lead to very weird effects depending how=20 > OpenLDAP's slapd is built. Use a recent heimdal release instead. Hi, Michael. Thanks for your assistance with this. I have upgraded my openldap server to 2.2.19 and replaced the mit kerberos sasl module with the heimdal one and the problem seems to be the same. I have no idea if it's useful, but I am including the tail of the debug output of slapd process while causing a failure. Any additional suggestions are much appreciated. Thanks, Mark Roach Slapd debug info: ----------------------------------- =3D> access_allowed: search access granted by read(=3Drscx) <=3D test_filter 5 <=3D test_filter_and 5 <=3D test_filter 5 bdb_search: 110 does not match filter send_ldap_result: conn=3D6 op=3D2 p=3D3 send_ldap_result: err=3D0 matched=3D"" text=3D"" send_ldap_response: msgid=3D3 tag=3D101 err=3D0 ber_flush: 14 bytes to sd 10 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ ldap_write: want=3D14, written=3D14 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ conn=3D6 op=3D2 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D daemon: activity on 1 descriptors daemon: activity on: 10r daemon: read activity on 10 connection_get(10) connection_get(10): got connid=3D6 connection_read(10): checking for input on id=3D6 ber_get_next ldap_read: want=3D8, got=3D0 ber_get_next on fd 10 failed errno=3D0 (Success) connection_read(10): input error=3D-2 id=3D6, closing. connection_closing: readying conn=3D6 sd=3D10 for close connection_close: conn=3D6 sd=3D10 daemon: removing 10 conn=3D6 fd=3D10 closed daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptors daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL |
From: <mi...@st...> - 2004-12-14 08:04:56
|
Mark Roach wrote: > except: > print "Died on iteration %d" % (i) > print out > break You're catching all LDAP error exceptions here without printing them. To avoid information loss either solely catch with except ldap.SERVER_DOWN: print "Died on iteration %d" % (i) print out break or explicitly print out the LDAPError exception: except ldap.LDAPError,e: print "LDAPError on iteration %d: %s" % (i,e) print out break Ciao, Michael. |
From: Mark R. <mr...@ok...> - 2004-12-14 15:55:57
|
On Tue, 2004-12-14 at 08:59 +0100, Michael Str=F6der wrote: > Mark Roach wrote: > > except: > > print "Died on iteration %d" % (i) > > print out > > break >=20 > You're catching all LDAP error exceptions here without printing them. Good point. I made some modifications (attached). I have attached the output from a few iterations. In order to test where in the ldap/sasl/python stack the problem is coming from, I also patched ldapsearch.c to run the same queries. It seems to work just fine. The patch is attached. Thanks again, Mark |
From: Mark R. <mr...@ok...> - 2004-12-16 21:39:00
|
On Tue, 2004-12-14 at 10:55 -0500, Mark Roach wrote: > On Tue, 2004-12-14 at 08:59 +0100, Michael Str=F6der wrote: > > Mark Roach wrote: > > > except: > > > print "Died on iteration %d" % (i) > > > print out > > > break > >=20 > > You're catching all LDAP error exceptions here without printing them. > In order to test where in the ldap/sasl/python stack the problem is > coming from, I also patched ldapsearch.c to run the same queries. It > seems to work just fine. The patch is attached. OK, I promise this will be my last message on the subject. I am currently using ReconnectLDAPObject as a workaround, and it seems fine (if not the purist's approach). I just wanted to post one last test case. It doesn't get much smaller than this :-) import ldap, ldap.sasl l =3D initialize('ldap://my.ldap.server') l.sasl_interactive_bind_s('', ldap.sasl.gssapi()) # Here's the real work. The use of multiple search bases is key for i in range(20):=20 [l.search_s('ou=3D%s,dc=3Dokmaybe,dc=3Dcom' % ou, ldap.SCOPE_ONELEVEL, = '(objectClass=3D*)') \ for ou in ['system','people','groups']] Thanks again. And sorry for all the noise on this list. -Mark |
From: <mi...@st...> - 2004-12-17 09:26:25
|
Mark Roach wrote: > > OK, I promise this will be my last message on the subject. > [..] > Thanks again. And sorry for all the noise on this list. Let me clearly state that you're welcome to mention your problems here. I do not consider this noise. I'm currently a little short on time. That's why I didn't answer to your recent posts yet. And although I did some tests myself I can't reproduce your problem on my system. > I am currently using ReconnectLDAPObject as a workaround, and it seems fine That's what I'd have suggested although it is just a work-around. > I just wanted to post one last test > case. It doesn't get much smaller than this :-) I ran your script with little modifications against a W2K3 Active Directory using SASL/GSSAPI with no problems at all. Maybe I should run the test with OpenLDAP slapd and heimdal KDC. But this will take me a while because I have to setup my KDC again. import ldap, ldap.sasl l = ldap.initialize('ldap://xxxxxx.vmtestnetz.xxx.xx') l.sasl_interactive_bind_s('', ldap.sasl.gssapi()) # Here's the real work. The use of multiple search bases is key for i in range(2000): try: for ou in ['Users','Computers','System']: dn = 'CN=%s,DC=VMTESTNETZ,DC=XXX,DC=XX' % ou res = l.search_s(dn, ldap.SCOPE_ONELEVEL, '(objectClass=*)') except ldap.SERVER_DOWN: print 'Aborted after %d searches' % i break Ciao, Michael. |
From: <mi...@st...> - 2004-12-17 09:26:27
|
Mark Roach wrote: > > In order to test where in the ldap/sasl/python stack the problem is > coming from, I also patched ldapsearch.c to run the same queries. It > seems to work just fine. The patch is attached. Because I don't experience any problems at all I still suspect your local installation has a library mix. Ciao, Michael. |