From jens at dataflake.org Wed Oct 6 21:26:33 2004 From: jens at dataflake.org (Jens Vagelpohl) Date: Wed, 6 Oct 2004 21:26:33 +0200 Subject: ANN: python-ldap-2.0.3 In-Reply-To: <416445A5.3030300@stroeder.com> References: <416445A5.3030300@stroeder.com> Message-ID: > * Added support for LDAP Password Modify Extended Operation > (see RFC 3062) > > Demo/: > * Added passwd_ext_op.py > > Modules/: > * Added l_ldap_passwd() in LDAPObject.c > > Lib/: > * Added methods passwd() and passwd_s() to > ldap.ldapobject.LDAPObject Question: Is the Password Modify Extended Operation a generally supported LDAP operation or is it only on a few server implementations (I know OpenLDAP has it)? I'm trying to gauge whether this should be the default under-the-hood way of changing passwords from my own Zope-related products. jens --------------- Jens Vagelpohl jens at zetwork.com Software Engineer Zope - done medium rare Zetwork GmbH http://www.zetwork.com/ From michael at stroeder.com Wed Oct 6 21:43:36 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 06 Oct 2004 21:43:36 +0200 Subject: LDAP Password Modify Extended Operation (was: ANN: python-ldap-2.0.3) In-Reply-To: References: <416445A5.3030300@stroeder.com> Message-ID: <41644AE8.7040905@stroeder.com> Jens Vagelpohl wrote: >> * Added support for LDAP Password Modify Extended Operation >> (see RFC 3062) > > Question: Is the Password Modify Extended Operation a generally > supported LDAP operation or is it only on a few server implementations > (I know OpenLDAP has it)? You can find out by looking at attribute supportedExtension in the RootDSE. The OID 1.3.6.1.4.1.1466.20037 as attribute value indicates that the LDAP server supports Password Modify Extended Operation. Note that this attribute might be subject to access control. Currently the only LDAP server I know of which supports this is OpenLDAP. > I'm trying to gauge whether this should be the > default under-the-hood way of changing passwords from my own > Zope-related products. Probably not. Ciao, Michael. From jens at dataflake.org Thu Oct 7 07:41:51 2004 From: jens at dataflake.org (Jens Vagelpohl) Date: Thu, 7 Oct 2004 07:41:51 +0200 Subject: LDAP Password Modify Extended Operation (was: ANN: python-ldap-2.0.3) In-Reply-To: <41644AE8.7040905@stroeder.com> References: <416445A5.3030300@stroeder.com> <41644AE8.7040905@stroeder.com> Message-ID: <96F997A2-1823-11D9-AE63-000D9368D272@dataflake.org> >> Question: Is the Password Modify Extended Operation a generally >> supported LDAP operation or is it only on a few server >> implementations (I know OpenLDAP has it)? > > You can find out by looking at attribute supportedExtension in the > RootDSE. The OID 1.3.6.1.4.1.1466.20037 as attribute value indicates > that the LDAP server supports Password Modify Extended Operation. Note > that this attribute might be subject to access control. > > Currently the only LDAP server I know of which supports this is > OpenLDAP. > >> I'm trying to gauge whether this should be the default under-the-hood >> way of changing passwords from my own Zope-related products. > > Probably not. Thanks Michael. Looks like for my code it's still more viable to "hand-encode" passwords than to test for and utilize the extended operation. jens --------------- Jens Vagelpohl jens at zetwork.com Software Engineer Zope - done medium rare Zetwork GmbH http://www.zetwork.com/ From michael at stroeder.com Thu Oct 7 08:12:48 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 07 Oct 2004 08:12:48 +0200 Subject: LDAP Password Modify Extended Operation In-Reply-To: <96F997A2-1823-11D9-AE63-000D9368D272@dataflake.org> References: <416445A5.3030300@stroeder.com> <41644AE8.7040905@stroeder.com> <96F997A2-1823-11D9-AE63-000D9368D272@dataflake.org> Message-ID: <4164DE60.3060800@stroeder.com> Jens Vagelpohl wrote: >> >>> I'm trying to gauge whether this should be the default under-the-hood >>> way of changing passwords from my own Zope-related products. >> >> Probably not. > > Thanks Michael. Looks like for my code it's still more viable to > "hand-encode" passwords than to test for and utilize the extended > operation. Probably yes. LDAP Password Modify Extended Operation is mainly interesting if you're deploying SASL with an external password store and the 'user' name value is not a distinguished name. Ciao, Michael. From cklinger at novareto.de Tue Oct 12 16:27:22 2004 From: cklinger at novareto.de (Christian Klinger) Date: Tue, 12 Oct 2004 16:27:22 +0200 Subject: Batch Input with Python-Ldap Message-ID: <416BE9CA.9030400@novareto.de> Hello List I have a question about adding a large numbers of users to ldap with python_ldap! I think the problem is the second part of the script. I put every member in the group ENMS! If I run the script without part two it runs 5 Minuts with it runs much longer. Is this the right way to make an batch import? Do you have any tips to make it faster? I test it with 50.000 User but in production there should be 500.000 - Is this a problem? thx Christian ----snip---- for x in range(50000) cn=x+basedn try: l.add_s(dn,[("objectclass", ["person",]), ("sn", [cn]), ("cn", [cn]), ("userpassword", [pw]), ]) except ldap.LDAPError, e1: err = "DN: %s, FEHLER: %s, BESCHREIBUNG: %s \n" %(dn,e1[0]['desc'],e1[0]['info']) try: gdn = "cn=ENMS,%s" %(str(orgu)) l.modify_s(gdn, [(ldap.MOD_ADD,'uniqueMember',dn)] ) except ldap.LDAPError, e1: err = "DN: %s, FEHLER: %s, BESCHREIBUNG: %s \n" %(dn,e1[0]['desc'],e1[0]['info']) ----snip---- From michael at stroeder.com Tue Oct 12 17:37:59 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 12 Oct 2004 17:37:59 +0200 Subject: Batch Input with Python-Ldap In-Reply-To: <416BE9CA.9030400@novareto.de> References: <416BE9CA.9030400@novareto.de> Message-ID: <416BFA57.2020604@stroeder.com> Christian Klinger wrote: > > I have a question about adding a large numbers of users to ldap with > python_ldap! This seems not specific to python-ldap. I will try to answer though. > I think the problem is the second part of the script. I put every member > in the group ENMS! > If I run the script without part two it runs 5 Minuts with it runs much > longer. Depending on the machine running the LDAP client you could try to build a list of all users and pass this list to l.modify_s(gdn,..). Then you would only send one big modify request instead of a modify request for each user. > Is this the right way to make an batch import? > Do you have any tips to make it faster? > I test it with 50.000 User but in production there should be 500.000 - > Is this a problem? Generally speaking group entries with more than 1000 member attribute values does not scale very well. The exact limit varies depending on the LDAP server product and configuration. I'd avoid that. You should really think about it. But that's more a question of LDAP directory design in general and hence more suitable to be asked in a general LDAP forum. Ciao, Michael. From wido.depping at gmail.com Sat Oct 30 02:07:55 2004 From: wido.depping at gmail.com (Wido Depping) Date: Sat, 30 Oct 2004 02:07:55 +0200 Subject: SASL/GSSAPI problems Message-ID: <127079e104102917079769474@mail.gmail.com> Hi All, some users of Luma ( http://luma.sf.net ) have problems with binding to a directory using the SASL/GSSAPI method. All these people have a working Kerberos environment and using SASL/MD5 work flawlessly. Here's the output they get from the console: SASL/GSSAPI authentication started Error during LDAP bind request Reason: {'info': 'SASL(0): successful result: ', 'desc': 'Local error'} Unfortunately I'm not able to test this myself since it would take to much time to set up such an environment. And currently I'm busy with my exams. For integrating SASL support into Luma I used the example code from python-ldap. Here is the 'bind()' function from Luma and maybe you have an idea what is going wrong: def bind(self): try: urlschemeVal = "ldap" if self.serverMeta.tls: urlschemeVal = "ldaps" whoVal = None credVal = None if not (self.serverMeta.bindAnon): whoVal = self.serverMeta.bindDN credVal = self.serverMeta.bindPassword url = ldapurl.LDAPUrl(urlscheme=urlschemeVal, hostport = self.serverMeta.host + ":" + str(self.serverMeta.port), dn = self.serverMeta.baseDN, who = whoVal, cred = credVal) self.ldapServerObject = ldap.initialize(url.initializeUrl()) self.ldapServerObject.protocol_version = 3 if self.serverMeta.bindAnon: self.ldapServerObject.simple_bind() elif self.serverMeta.authMethod == u"Simple": self.ldapServerObject.simple_bind(whoVal, credVal) elif u"SASL" in self.serverMeta.authMethod: sasl_cb_value_dict = None if not u"GSSAPI" in self.serverMeta.authMethod: sasl_cb_value_dict = {ldap.sasl.CB_AUTHNAME:whoVal, ldap.sasl.CB_PASS:credVal} sasl_mech = None if self.serverMeta.authMethod == u"SASL Plain": sasl_mech = "PLAIN" elif self.serverMeta.authMethod == u"SASL CRAM-MD5": sasl_mech = "CRAM-MD5" elif self.serverMeta.authMethod == u"SASL DIGEST-MD5": sasl_mech = "DIGEST-MD5" elif self.serverMeta.authMethod == u"SASL Login": sasl_mech = "LOGIN" elif self.serverMeta.authMethod == u"SASL GSSAPI": sasl_mech = "GSSAPI" sasl_auth = ldap.sasl.sasl(sasl_cb_value_dict,sasl_mech) self.ldapServerObject.sasl_interactive_bind_s("", sasl_auth) except ldap.LDAPError, e: print "Error during LDAP bind request" print "Reason: " + str(e) Maybe someone with a Kerberos environment can test Luma. So far I'm pretty lost what is going on. mfg. Wido -- Wido Depping ICQ: 51303067 AIM: wido3379 Jabber: wido at jabber.ccc.de Blog: http://widoww.blogspot.com From Hans.Aschauer at epost.de Wed Nov 3 10:05:34 2004 From: Hans.Aschauer at epost.de (Hans Aschauer) Date: Wed, 3 Nov 2004 10:05:34 +0100 Subject: SASL/GSSAPI problems In-Reply-To: <127079e104102917079769474@mail.gmail.com> References: <127079e104102917079769474@mail.gmail.com> Message-ID: <200411031005.34324.Hans.Aschauer@epost.de> [to list and OP] On Saturday 30 October 2004 02:07, Wido Depping wrote: > Hi All, > some users of Luma ( http://luma.sf.net ) have problems with binding > to a directory using the SASL/GSSAPI method. All these people have a > working Kerberos environment and using SASL/MD5 work flawlessly. > Here's the output they get from the console: > > SASL/GSSAPI authentication started > Error during LDAP bind request > Reason: {'info': 'SASL(0): successful result: ', 'desc': 'Local error'} This error is most likely due to a wrong setup of kerberos <-> LDAP, and has probably nothing to do with python-ldap. The luma users might look at http://www.bayour.com/LDAPv3-HOWTO.html which is a great HOWTO for setting up a working ldap server with GSSAPI authentication. It also explains the reasons for a 'local error'. BTW, it was some time ago that I last looked at python-ldap, but I think that it still is built on top of the openldap-libraries. So SASL/GSSAPI will work only if it also works using ldapsearch (and vice versa(?)). Hans From michael at stroeder.com Wed Nov 3 17:25:11 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 03 Nov 2004 17:25:11 +0100 Subject: SASL/GSSAPI problems In-Reply-To: <200411031005.34324.Hans.Aschauer@epost.de> References: <127079e104102917079769474@mail.gmail.com> <200411031005.34324.Hans.Aschauer@epost.de> Message-ID: <41890667.1050809@stroeder.com> Hans Aschauer wrote: > [to list and OP] > > On Saturday 30 October 2004 02:07, Wido Depping wrote: > >>SASL/GSSAPI authentication started >>Error during LDAP bind request >>Reason: {'info': 'SASL(0): successful result: ', 'desc': 'Local error'} > > This error is most likely due to a wrong setup of kerberos <-> LDAP, and has > probably nothing to do with python-ldap. I agree. One would also need to know which version of heimdal or MIT Kerberos and which kind of KDC this happens with. E.g. I did get such errors when using a earlier version of heimdal with a KDC of W2K3 Active Directory. In my case this was solved by upgrading heimdal. Your mileage may vary. > So SASL/GSSAPI will work only if it > also works using ldapsearch (and vice versa(?)). Yes. Best advice is to test with OpenLDAP's command-line tool ldapsearch. Ciao, Michael. From marc at msys.ch Wed Nov 3 16:58:12 2004 From: marc at msys.ch (Marc Balmer) Date: Wed, 3 Nov 2004 16:58:12 +0100 Subject: start_tls? Message-ID: <2A2B816A-2DB1-11D9-A745-0003938168B2@msys.ch> Hi OpenLDAP support start_tls to switch to TLS while talking to a LDAP server. I found no reference to it in the python-ldap docs. Is it supported after all? - Marc BTW: I am not (yet) subsribed to this list, maybe you answer directly. From michael at stroeder.com Wed Nov 3 17:28:38 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 03 Nov 2004 17:28:38 +0100 Subject: start_tls? In-Reply-To: <2A2B816A-2DB1-11D9-A745-0003938168B2@msys.ch> References: <2A2B816A-2DB1-11D9-A745-0003938168B2@msys.ch> Message-ID: <41890736.4010402@stroeder.com> Marc Balmer wrote: > > OpenLDAP support start_tls to switch to TLS while talking to a LDAP > server. I found no reference to it in the python-ldap docs. Is it > supported after all? Yes, it is supported. Check out Demo/initialize.py in the source distribution. Hmm, it's missing in the docs... > BTW: I am not (yet) subsribed to this list, maybe you answer directly. Please subscribe. It's very low-traffic. Normally I refuse to answer direct e-mails. Ciao, Michael. From kyle at klmhosting.net Wed Oct 27 21:34:48 2004 From: kyle at klmhosting.net (Kyle Mott) Date: Wed, 27 Oct 2004 12:34:48 -0700 Subject: python-ldap on OS X 10.3 Message-ID: <001d01c4bc5c$05dd5160$150ba8c0@kyledesktop> Hi, I'm trying to compile and install python-ldap-2.0.3 and 2.0.4 on Mac OS X 10.3, but I seem to be getting some errors, and nothing ends up getting installed. The weirdest part about this is that I originally had this working just fine not even a week ago with version 2.0.3. If I uncompress the older (2.0.3) version and try to install, I still get the following: root at localhost:~ # python setup.py install extra_compile_args: extra_objects: include_dirs: /usr/local/openldap-REL_ENG_2_1/include /usr/include/sasl /usr/local/sasl/include/sasl library_dirs: /usr/local/openldap-REL_ENG_2_1/lib /usr/lib/sasl /usr/local/sasl/lib libs: ldap_r lber sasl2 ssl crypto running install running build running build_py file Lib/ldap.py (for module ldap) not found file Lib/ldap/schema.py (for module ldap.schema) not found file Lib/ldap.py (for module ldap) not found file Lib/ldap/schema.py (for module ldap.schema) not found running build_ext building '_ldap' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-protoo gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict-protoo Modules/LDAPObject.c:20:18: sasl.h: No such file or directory Modules/LDAPObject.c:492: error: parse error before "sasl_interact_t" Modules/LDAPObject.c:494: warning: function declaration isn't a prototype Modules/LDAPObject.c: In function `interaction': Modules/LDAPObject.c:495: error: `interact' undeclared (first use in this function) Modules/LDAPObject.c:495: error: (Each undeclared identifier is reported only once Modules/LDAPObject.c:495: error: for each function it appears in.) Modules/LDAPObject.c:498: error: `SASLObject' undeclared (first use in this function) Modules/LDAPObject.c:495: warning: unused variable `dflt' Modules/LDAPObject.c: In function `py_ldap_sasl_interaction': Modules/LDAPObject.c:546: error: `sasl_interact_t' undeclared (first use in this function) Modules/LDAPObject.c:546: error: `interact' undeclared (first use in this function) Modules/LDAPObject.c:549: error: `SASL_CB_LIST_END' undeclared (first use in this function) Modules/LDAPObject.c: In function `l_ldap_sasl_interactive_bind_s': Modules/LDAPObject.c:562: warning: unused variable `cred' Modules/LDAPObject.c:569: warning: unused variable `version' Modules/LDAPObject.c:571: warning: unused variable `defaults' error: command 'gcc' failed with exit status 1 -Kyle Mott -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Nov 3 17:58:29 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 03 Nov 2004 17:58:29 +0100 Subject: python-ldap on OS X 10.3 In-Reply-To: <001d01c4bc5c$05dd5160$150ba8c0@kyledesktop> References: <001d01c4bc5c$05dd5160$150ba8c0@kyledesktop> Message-ID: <41890E35.8020803@stroeder.com> Kyle Mott wrote: > > include_dirs: /usr/local/openldap-REL_ENG_2_1/include /usr/include/sasl > /usr/local/sasl/include/sasl > [..] > Modules/LDAPObject.c:20:18: sasl.h: No such file or directory First I don't know Mac OS X. But where's your sasl.h located? You have to set the appropriate include directories in setup.cfg. Or turn off SASL in setup.cfg if you don't need it at all. Ciao, Michael. From jens at dataflake.org Wed Nov 3 22:30:51 2004 From: jens at dataflake.org (Jens Vagelpohl) Date: Wed, 3 Nov 2004 22:30:51 +0100 Subject: python-ldap on OS X 10.3 In-Reply-To: <41890E35.8020803@stroeder.com> References: <001d01c4bc5c$05dd5160$150ba8c0@kyledesktop> <41890E35.8020803@stroeder.com> Message-ID: On Nov 3, 2004, at 17:58, Michael Str?der wrote: > Kyle Mott wrote: > > > > include_dirs: /usr/local/openldap-REL_ENG_2_1/include > /usr/include/sasl > > /usr/local/sasl/include/sasl > > [..] > > Modules/LDAPObject.c:20:18: sasl.h: No such file or directory > > First I don't know Mac OS X. > > But where's your sasl.h located? You have to set the appropriate > include directories in setup.cfg. Or turn off SASL in setup.cfg if you > don't need it at all. By default OS X does not have SASL header files. At least I cannot find them on my 10.3.5, even though it has sasl-libraries in /usr/lib and /usr/lib/sasl2 jens --------------- Jens Vagelpohl jens at zetwork.com Software Engineer +49-(0)441-36 18 14 38 Zetwork GmbH http://www.zetwork.com/ From michael at stroeder.com Wed Nov 3 22:50:51 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 03 Nov 2004 22:50:51 +0100 Subject: python-ldap on OS X 10.3 In-Reply-To: References: <001d01c4bc5c$05dd5160$150ba8c0@kyledesktop> <41890E35.8020803@stroeder.com> Message-ID: <418952BB.8060806@stroeder.com> Jens Vagelpohl wrote: > > By default OS X does not have SASL header files. At least I cannot find > them on my 10.3.5, even though it has sasl-libraries in /usr/lib and > /usr/lib/sasl2 I'd add an example setup.cfg for Mac OS X to the source distribution under Build/ if you provide one. Ciao, Michael. From jens at dataflake.org Wed Nov 3 23:04:48 2004 From: jens at dataflake.org (Jens Vagelpohl) Date: Wed, 3 Nov 2004 23:04:48 +0100 Subject: python-ldap on OS X 10.3 In-Reply-To: <418952BB.8060806@stroeder.com> References: <001d01c4bc5c$05dd5160$150ba8c0@kyledesktop> <41890E35.8020803@stroeder.com> <418952BB.8060806@stroeder.com> Message-ID: <61085D38-2DE4-11D9-B861-000D9368D272@dataflake.org> On Nov 3, 2004, at 22:50, Michael Str?der wrote: > Jens Vagelpohl wrote: > > > > By default OS X does not have SASL header files. At least I cannot > find > > them on my 10.3.5, even though it has sasl-libraries in /usr/lib and > > /usr/lib/sasl2 > > I'd add an example setup.cfg for Mac OS X to the source distribution > under Build/ if you provide one. Hallo Michael, All I do is remove "sasl2" from the "libs" directive in setup.cfg. Then it compiles. Is that enough modification to qualify inclusion as a separate sample setup.cfg? jens --------------- Jens Vagelpohl jens at zetwork.com Software Engineer +49-(0)441-36 18 14 38 Zetwork GmbH http://www.zetwork.com/ From michael at stroeder.com Wed Nov 3 23:15:33 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 03 Nov 2004 23:15:33 +0100 Subject: python-ldap on OS X 10.3 In-Reply-To: <61085D38-2DE4-11D9-B861-000D9368D272@dataflake.org> References: <001d01c4bc5c$05dd5160$150ba8c0@kyledesktop> <41890E35.8020803@stroeder.com> <418952BB.8060806@stroeder.com> <61085D38-2DE4-11D9-B861-000D9368D272@dataflake.org> Message-ID: <41895885.8040804@stroeder.com> Jens Vagelpohl wrote: > > All I do is remove "sasl2" from the "libs" directive in setup.cfg. Then > it compiles. Is that enough modification to qualify inclusion as a > separate sample setup.cfg? Well, some people might wanna get spoon-fed. ;-) Any other platform-specific DistUtils options for e.g. binary packages under Mac OS X? Ciao, Michael. From jens at dataflake.org Wed Nov 3 23:54:40 2004 From: jens at dataflake.org (Jens Vagelpohl) Date: Wed, 3 Nov 2004 23:54:40 +0100 Subject: python-ldap on OS X 10.3 In-Reply-To: <41895885.8040804@stroeder.com> References: <001d01c4bc5c$05dd5160$150ba8c0@kyledesktop> <41890E35.8020803@stroeder.com> <418952BB.8060806@stroeder.com> <61085D38-2DE4-11D9-B861-000D9368D272@dataflake.org> <41895885.8040804@stroeder.com> Message-ID: <5844BA94-2DEB-11D9-B861-000D9368D272@dataflake.org> On Nov 3, 2004, at 23:15, Michael Str?der wrote: > Jens Vagelpohl wrote: >> All I do is remove "sasl2" from the "libs" directive in setup.cfg. >> Then it compiles. Is that enough modification to qualify inclusion as >> a separate sample setup.cfg? > > Well, some people might wanna get spoon-fed. ;-) > > Any other platform-specific DistUtils options for e.g. > binary packages under Mac OS X? Doing python setup.py --help-commands doesn't reveal anything special for OS X. I don't think there are any OS X-related special options. jens From mcicogni at libero.it Mon Nov 8 23:40:24 2004 From: mcicogni at libero.it (Mauro Cicognini) Date: Mon, 08 Nov 2004 23:40:24 +0100 Subject: ANN: 2.0.4 win32 build using mingw32 Message-ID: <418FF5D8.6030409@libero.it> Hi all, I finally got around to updating my win32 binary of Python-LDAP. The reason it took so long was that in between my last attempt and today the core OpenLDAP developers have dropped MSVC support and now Win32 platforms are officially supported through mingw32, so all my previous work of making Python-LDAP compile using the Microsoft toolchain were useless and obsolete :-( The good news is that the original developer of the OpenLDAP win32 port (his name is Lucas Bergman) resumed work on it, as a purely volounteer effort, so now we can count on OpenLDAP living on Windows for a while. So far his most important achievement has been the re-introduction of SSL capabilities (which should be promptly available through Python-LDAP too). On the other hand, the SASL developers seem to be sticking to the MS toolchain, therefore since mingw cannot build it, SASL support is not available instead... oh well. I sure hope we'll have it back sometime, but that isn't currently one of my priorities. After asking the win32 Python developers for reassurance (it turns out mingw-built extensions will work nicely with the ordinary MSVC-built interpreter), I had to learn to use mingw32, which was fun (I got around building OpenLDAP too) and actually easier than I thought. I used the very latest versions of both OpenLDAP (2.2.18) and OpenSSL (0.9.7e) so we should really be cutting edge. Anyway, I have uploaded the new binary to my homepage (the one referred to from http://python-ldap.sourceforge.net/download.shtml) where it should appear sometime tomorrow. I also have a mingw setup.cfg for our build script, which I propose to label the "official" win32 compiler, and therefore to remove all MSVC-related stuff from the HEAD branch of the source tree. I can provide the script on demand, I won't obvisouly attach it here to avoid spam. I'd be glad to hear feedback, although, as always, YMMV. All the best, Mauro From wido.depping at gmail.com Tue Nov 9 00:10:51 2004 From: wido.depping at gmail.com (Wido Depping) Date: Tue, 9 Nov 2004 00:10:51 +0100 Subject: SASL/GSSAPI problems In-Reply-To: <200411031005.34324.Hans.Aschauer@epost.de> References: <127079e104102917079769474@mail.gmail.com> <200411031005.34324.Hans.Aschauer@epost.de> Message-ID: <127079e104110815104e975b8d@mail.gmail.com> On Wed, 3 Nov 2004 10:05:34 +0100, Hans Aschauer wrote: > On Saturday 30 October 2004 02:07, Wido Depping wrote: > > Hi All, > > some users of Luma ( http://luma.sf.net ) have problems with binding > > to a directory using the SASL/GSSAPI method. All these people have a > > working Kerberos environment and using SASL/MD5 work flawlessly. > > Here's the output they get from the console: > > > > SASL/GSSAPI authentication started > > Error during LDAP bind request > > Reason: {'info': 'SASL(0): successful result: ', 'desc': 'Local error'} > > This error is most likely due to a wrong setup of kerberos <-> LDAP, and has > probably nothing to do with python-ldap. The luma users might look at > > http://www.bayour.com/LDAPv3-HOWTO.html > > which is a great HOWTO for setting up a working ldap server with GSSAPI > authentication. It also explains the reasons for a 'local error'. BTW, it was > some time ago that I last looked at python-ldap, but I think that it still is > built on top of the openldap-libraries. So SASL/GSSAPI will work only if it > also works using ldapsearch (and vice versa(?)). Hi All, The solution for my problem was simpler than expected. In my code I had "sasl_cb_value_dict = None" instead of "sasl_cb_value_dict = {}". After correcting this, everything worked. However it would be good if the developer gets a more meaningful error message than 'local error'. Beside that, I just want to say that python-ldap is a really nice library and it has helped me a lot with my Luma development, altough I don't use its full potential :) mfg. Wido Depping -- Wido Depping ICQ: 51303067 AIM: wido3379 Jabber: wido at jabber.ccc.de Blog: http://widoww.blogspot.com From michael at stroeder.com Tue Nov 9 00:46:51 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 09 Nov 2004 00:46:51 +0100 Subject: SASL/GSSAPI problems In-Reply-To: <127079e104110815104e975b8d@mail.gmail.com> References: <127079e104102917079769474@mail.gmail.com> <200411031005.34324.Hans.Aschauer@epost.de> <127079e104110815104e975b8d@mail.gmail.com> Message-ID: <4190056B.5030801@stroeder.com> Wido Depping wrote: > On Wed, 3 Nov 2004 10:05:34 +0100, Hans Aschauer wrote: > >>>SASL/GSSAPI authentication started >>>Error during LDAP bind request >>>Reason: {'info': 'SASL(0): successful result: ', 'desc': 'Local error'} >> >>This error is most likely due to a wrong setup of kerberos <-> LDAP, and has >>probably nothing to do with python-ldap. > > The solution for my problem was simpler than expected. Thanks for letting us know. > In my code I > had "sasl_cb_value_dict = None" instead of "sasl_cb_value_dict = {}". > After correcting this, everything worked. However it would be good if > the developer gets a more meaningful error message than 'local error'. Hmm, would the patch below solve this particular problem? > Beside that, I just want to say that python-ldap is a really nice > library and it has helped me a lot with my Luma development, altough I > don't use its full potential :) I look forward to luma using the full potential of python-ldap... :-) Ciao, Michael. Index: Lib/ldap/sasl.py =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Lib/ldap/sasl.py,v retrieving revision 1.11 diff -u -r1.11 sasl.py --- Lib/ldap/sasl.py 25 Mar 2004 14:57:02 -0000 1.11 +++ Lib/ldap/sasl.py 8 Nov 2004 23:44:36 -0000 @@ -46,7 +46,7 @@ question-answer pairs. Questions are specified by the respective SASL callback id's. The mech argument is a string that specifies the SASL mechaninsm to be uesd.""" - self.cb_value_dict = cb_value_dict + self.cb_value_dict = cb_value_dict or {} self.mech = mech def callback(self,cb_id,challenge,prompt,defresult): From michael at stroeder.com Tue Nov 9 00:51:21 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 09 Nov 2004 00:51:21 +0100 Subject: ANN: 2.0.4 win32 build using mingw32 In-Reply-To: <418FF5D8.6030409@libero.it> References: <418FF5D8.6030409@libero.it> Message-ID: <41900679.9010607@stroeder.com> Mauro Cicognini wrote: > I finally got around to updating my win32 binary of Python-LDAP. Thanks so much for contributing this. I will test it soon. > Anyway, I have uploaded the new binary to my homepage (the one referred > to from http://python-ldap.sourceforge.net/download.shtml) where it > should appear sometime tomorrow. Would you like to see some details explained on this web page about your Win32 build? > I also have a mingw setup.cfg for our build script, which I propose to > label the "official" win32 compiler, and therefore to remove all > MSVC-related stuff from the HEAD branch of the source tree. I can > provide the script on demand, I won't obvisouly attach it here to avoid > spam. Please send this stuff to me personally. Ciao, Michael. From wido.depping at gmail.com Tue Nov 9 01:03:53 2004 From: wido.depping at gmail.com (Wido Depping) Date: Tue, 9 Nov 2004 01:03:53 +0100 Subject: SASL/GSSAPI problems In-Reply-To: <4190056B.5030801@stroeder.com> References: <127079e104102917079769474@mail.gmail.com> <200411031005.34324.Hans.Aschauer@epost.de> <127079e104110815104e975b8d@mail.gmail.com> <4190056B.5030801@stroeder.com> Message-ID: <127079e104110816034ef82d07@mail.gmail.com> On Tue, 09 Nov 2004 00:46:51 +0100, Michael Str?der wrote: > > The solution for my problem was simpler than expected. > Thanks for letting us know. > > In my code I > > had "sasl_cb_value_dict = None" instead of "sasl_cb_value_dict = {}". > > After correcting this, everything worked. However it would be good if > > the developer gets a more meaningful error message than 'local error'. > > Hmm, would the patch below solve this particular problem? The patch looks ok to me. Thanks for the fast response :) bye Wido -- Wido Depping ICQ: 51303067 AIM: wido3379 Jabber: wido at jabber.ccc.de Blog: http://widoww.blogspot.com From mcicogni at libero.it Tue Nov 9 18:26:08 2004 From: mcicogni at libero.it (Mauro Cicognini) Date: Tue, 09 Nov 2004 18:26:08 +0100 Subject: ANN: 2.0.4 win32 build using mingw32 In-Reply-To: <6339A596-31E4-11D9-8FFA-000D9368D272@dataflake.org> References: <418FF5D8.6030409@libero.it> <6339A596-31E4-11D9-8FFA-000D9368D272@dataflake.org> Message-ID: <4190FDB0.9040800@libero.it> Jens Vagelpohl scrive: >> Anyway, I have uploaded the new binary to my homepage (the one >> referred to from http://python-ldap.sourceforge.net/download.shtml) >> where it should appear sometime tomorrow. >> >> I also have a mingw setup.cfg for our build script, which I propose >> to label the "official" win32 compiler, and therefore to remove all >> MSVC-related stuff from the HEAD branch of the source tree. I can >> provide the script on demand, I won't obvisouly attach it here to >> avoid spam. > > > I don't use Windows myself, but as someone whose software relies on > the windows library in those cases where people deploy it on Windows > I'd like to say thanks! I'd say You're welcome ;-) but I think you should rather wait and see some actual successful use cases first :-) Mauro From exogen at gmail.com Thu Nov 11 05:42:40 2004 From: exogen at gmail.com (Brian Beck) Date: Wed, 10 Nov 2004 23:42:40 -0500 Subject: Python-LDAP-dev digest, Vol 1 #876 - 1 msg In-Reply-To: <20041111042104.27F271D1507@sc8-sf-uberspam1.sourceforge.net> References: <20041111042104.27F271D1507@sc8-sf-uberspam1.sourceforge.net> Message-ID: > From: Bertrand Croq > To: python-ldap-dev at lists.sourceforge.net > Subject: escape_dn_chars > > Hi, > I wasn't able to find a function to escape chars in DN strings, so I > wrote this one (based on escape_filter_chars): > > def escape_dn_chars(s): > s =3D s.replace('\\', r'\5C') > s =3D s.replace(',', r'\2C') > s =3D s.replace('=3D', r'\3D') > s =3D s.replace('+', r'\2B') > return s > Alternatively, wouldn't using urllib.quote do nearly the same thing? The only difference I notice is that quote uses a % as an escape character instead of \. That's easily changed... s = urllib.quote(s).replace('%', r'\') Or is there something about LDAP URIs that I'm missing? -- Brian Beck Adventurer of the First Order From exogen at gmail.com Thu Nov 11 05:45:21 2004 From: exogen at gmail.com (Brian Beck) Date: Wed, 10 Nov 2004 23:45:21 -0500 Subject: Python-LDAP-dev digest, Vol 1 #876 - 1 msg In-Reply-To: References: <20041111042104.27F271D1507@sc8-sf-uberspam1.sourceforge.net> Message-ID: > > s = urllib.quote(s).replace('%', r'\') > Whoops, that should be '\\' instead of r'\' at the end there. -- Brian Beck Adventurer of the First Order From michael at stroeder.com Thu Nov 11 09:10:31 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 11 Nov 2004 09:10:31 +0100 Subject: Python-LDAP-dev digest, Vol 1 #876 - 1 msg In-Reply-To: References: <20041111042104.27F271D1507@sc8-sf-uberspam1.sourceforge.net> Message-ID: <41931E77.4010404@stroeder.com> Brian Beck wrote: > Bertrand Croq wrote: >> >> I wasn't able to find a function to escape chars in DN strings, so I >>wrote this one (based on escape_filter_chars): >> >>def escape_dn_chars(s): >>[..] > > Alternatively, wouldn't using urllib.quote do nearly the same thing? > The only difference I notice is that quote uses a % as an escape > character instead of \. That's easily changed... I strongly dislike abusing urllib.quote since RFC2253 clearly defines a certain set of special chars in DNs which surely differs from special chars in URLs. > Or is there something about LDAP URIs that I'm missing? We're talking about LDAP DN string representation here (see RFC2253). Not about LDAP URLs (as described in RFC2255). LDAP URLs are handled through python-ldap's module 'ldapurl'. Ciao, Michael. From michael at stroeder.com Sun Nov 14 16:01:54 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 14 Nov 2004 16:01:54 +0100 Subject: SASL/TLS question In-Reply-To: <41971638.9060306@msys.ch> References: <41971638.9060306@msys.ch> Message-ID: <41977362.40701@stroeder.com> Marc Balmer wrote: > > Why is SASL/TLS support in python-ldap not enabled by default in configure? python-ldap is built with the help of Python DistUtils. autoconf's configure is not used at all. See http://docs.python.org/dist/dist.html > Does it make sense to enable it by default on platforms that always > have tls libs, e.g. on OpenBSD? Feel free to contribute a platform-specific setup.cfg for addition to the source distribution under directory Build/. The text in file INSTALL refers to that directory under "Quick build instructions". Ciao, Michael. From marc at msys.ch Sun Nov 14 09:24:24 2004 From: marc at msys.ch (Marc Balmer) Date: Sun, 14 Nov 2004 09:24:24 +0100 Subject: SASL/TLS question Message-ID: <41971638.9060306@msys.ch> HI Why is SASL/TLS support in python-ldap not enabled by default in configure? Does it make sense to enable it by default on platforms that always have tls libs, e.g. on OpenBSD? - Marc From marc at msys.ch Sun Nov 14 16:18:29 2004 From: marc at msys.ch (Marc Balmer) Date: Sun, 14 Nov 2004 16:18:29 +0100 Subject: SASL/TLS question In-Reply-To: <41977362.40701@stroeder.com> References: <41971638.9060306@msys.ch> <41977362.40701@stroeder.com> Message-ID: <41977745.70405@msys.ch> Michael Str?der wrote: > Feel free to contribute a platform-specific setup.cfg for addition to > the source distribution under directory Build/. The text in file INSTALL > refers to that directory under "Quick build instructions". On OpenBSD databases/py-ldap comes in two flavors: with sasl and without. We can not just provide the one and only OpenBSD setup.cfg because of that. And it would make no sense as python-ldap is included in the OpenBSD ports collection. As the maintainer of said port, questions arrise from time to time ;-) - Marc From d at adaptive-enterprises.com.au Thu Nov 18 02:17:44 2004 From: d at adaptive-enterprises.com.au (David Leonard) Date: Thu, 18 Nov 2004 11:17:44 +1000 (EST) Subject: undefined symbol: ber_pvt_opt_on In-Reply-To: <1100705324.3438.103.camel@PC-8768> References: <1100705324.3438.103.camel@PC-8768> Message-ID: It looks like _ldap.so module was not linked with -lber. ber_pvt_opt_on was introduced early in the openldap-2.2 branch, so OpenLDAP-2.2.17 will certainly that symbol. References: http://www.openldap.org/devel/cvsweb.cgi/libraries/liblber/options.c (1.35) d On Thu, 17 Nov 2004, Gwenaelle Demol typed thusly: > Hello David Leonard, > > I've an error when i import the product Ldap in my python2.3. Do you > recognise this error ?: > >>>> import ldap > Traceback (most recent call last): > File "", line 1, in ? > File > "/home/user/Zopes/m8/Python/lib/python2.3/site-packages/ldap/__init__.py", line 21, in ? > from _ldap import * > ImportError: > /home/user/Zopes/m8/Python/lib/python2.3/site-packages/_ldap.so: > undefined symbol: ber_pvt_opt_on > (i use /home/user/Zopes/m8/Python/lib/python2.3 and not the python > system) > > I work on RedHat 9.0, I've installed OpenLDAP-2.2.17 > Before install your products (python-ldap-2.0.5), i've edited the file > setup.cfg with my librairies directories. > > I have no idea about this error. Can you help me ? I searched on the web > but i don't find any solution to fix it. > > Thanks very much > Gwenaelle Demol > > -- David Leonard d at adaptive-enterprises.com.au Ph:+61 404 844 850 From bertrand.croq at freeskop.com Wed Nov 10 15:22:04 2004 From: bertrand.croq at freeskop.com (Bertrand Croq) Date: Wed, 10 Nov 2004 15:22:04 +0100 Subject: escape_dn_chars Message-ID: <20041110142204.GA11135@freeskop.com> Hi, I wasn't able to find a function to escape chars in DN strings, so I wrote this one (based on escape_filter_chars): def escape_dn_chars(s): s = s.replace('\\', r'\5C') s = s.replace(',', r'\2C') s = s.replace('=', r'\3D') s = s.replace('+', r'\2B') return s Feel free to use/modify it in python-ldap (license: PSFL, as python-ldap) -- Bertrand Croq - FreesKop - Avenue Robert Schuman - 35170 BRUZ (France) http://www.freeskop.com/ - Tel: 02 99 05 04 56 - Fax: 02 99 05 96 40 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From michael at stroeder.com Thu Dec 2 21:38:36 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 02 Dec 2004 21:38:36 +0100 Subject: escape_dn_chars In-Reply-To: <20041110142204.GA11135@freeskop.com> References: <20041110142204.GA11135@freeskop.com> Message-ID: <41AF7D4C.7030407@stroeder.com> Bertrand Croq wrote: > I wasn't able to find a function to escape chars in DN strings, so I > wrote this one (based on escape_filter_chars): > > def escape_dn_chars(s): > s = s.replace('\\', r'\5C') > s = s.replace(',', r'\2C') > s = s.replace('=', r'\3D') > s = s.replace('+', r'\2B') > return s > > Feel free to use/modify it in python-ldap (license: PSFL, as > python-ldap) Thanks for contributing it. I've added a new function ldap.dn.escape_dn_chars() in a new sub-module ldap.dn to CVS. It was taken from web2ldap which also handles two special cases with # as first char and a trailing space. Please test! Ciao, Michael. From tlau-pythonldap at tlau.org Wed Dec 8 23:52:07 2004 From: tlau-pythonldap at tlau.org (Tessa Lau) Date: Wed, 8 Dec 2004 17:52:07 -0500 Subject: LDAP search segfaults on RH FC3 Message-ID: <20041208225207.GA19436@ofb.net> Hi, I'm finding that Python-LDAP on Fedora Core 3 segfaults when doing an LDAP search. The same code works without crashing on a Debian system. The gdb backtrace indicates that the crash happens while processing an error from the LDAP server. I submitted the bug to Python sourceforge, but they told me to post it here instead. Here's the URL: http://sourceforge.net/tracker/index.php?func=detail&aid=1081633&group_id=5470&atid=105470 The RPM versions are listed in the bug report. Since the backtrace also references SASL, here are the versions of Cyrus SASL installed: cyrus-sasl-2.1.19-3 cyrus-sasl-plain-2.1.19-3 cyrus-sasl-md5-2.1.19-3 cyrus-sasl-devel-2.1.19-3 Any ideas? Thanks, --Tessa ================= Tessa Lau, PhD http://tlau.org/ From dmalcolm at redhat.com Thu Dec 9 00:03:53 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 08 Dec 2004 18:03:53 -0500 Subject: LDAP search segfaults on RH FC3 In-Reply-To: <20041208225207.GA19436@ofb.net> References: <20041208225207.GA19436@ofb.net> Message-ID: <1102547033.5125.7.camel@cassandra.boston.redhat.com> On Wed, 2004-12-08 at 17:52 -0500, Tessa Lau wrote: > Hi, > > I'm finding that Python-LDAP on Fedora Core 3 segfaults when doing an > LDAP search. The same code works without crashing on a Debian system. > The gdb backtrace indicates that the crash happens while processing an > error from the LDAP server. I submitted the bug to Python sourceforge, > but they told me to post it here instead. Here's the URL: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1081633&group_id=5470&atid=105470 > > The RPM versions are listed in the bug report. Since the backtrace also > references SASL, here are the versions of Cyrus SASL installed: > > cyrus-sasl-2.1.19-3 > cyrus-sasl-plain-2.1.19-3 > cyrus-sasl-md5-2.1.19-3 > cyrus-sasl-devel-2.1.19-3 > > Any ideas? If the crash seems to be specific to Fedora, please can you file a bug for it in Red Hat's bugzilla please. Thanks Dave Malcolm From michael at stroeder.com Thu Dec 9 03:30:00 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 09 Dec 2004 03:30:00 +0100 Subject: LDAP search segfaults on RH FC3 In-Reply-To: <20041208225207.GA19436@ofb.net> References: <20041208225207.GA19436@ofb.net> Message-ID: <41B7B8A8.3050000@stroeder.com> Tessa Lau wrote: > > I'm finding that Python-LDAP on Fedora Core 3 segfaults when doing an > LDAP search. I'm pasting the RPM list from your bug report here as quotation: > Python and LDAP RPMs installed: > > python-2.3.4-11 > nss_ldap-220-3 > python-ldap-2.0.1-2 > openldap-2.2.13-2 > openldap-devel-2.2.13-2 > openldap-clients-2.2.13-2 > openldap-servers-2.2.13-2 > [..] > cyrus-sasl-2.1.19-3 > cyrus-sasl-plain-2.1.19-3 > cyrus-sasl-md5-2.1.19-3 > cyrus-sasl-devel-2.1.19-3 nss_ldap is not relevant here. Maybe some mix of the used libraries though. What's the output of: ldd /usr/lib/python2.3/site-packages/_ldap.so Do all the RPMs come from Fedora? Does the current version of python-ldap compiled from source also segfault? Ciao, Michael. From tlau-pythonldap at tlau.org Thu Dec 9 16:59:24 2004 From: tlau-pythonldap at tlau.org (Tessa Lau) Date: Thu, 9 Dec 2004 10:59:24 -0500 Subject: LDAP search segfaults on RH FC3 In-Reply-To: <41B7B8A8.3050000@stroeder.com> References: <20041208225207.GA19436@ofb.net> <41B7B8A8.3050000@stroeder.com> Message-ID: <20041209155923.GA5742@ofb.net> On Thu, Dec 09, 2004 at 03:30:00AM +0100, Michael Stroeder wrote: > ldd /usr/lib/python2.3/site-packages/_ldap.so libldap_r-2.2.so.7 => /usr/lib/libldap_r-2.2.so.7 (0xf6f9e000) liblber-2.2.so.7 => /usr/lib/liblber-2.2.so.7 (0xf6f91000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xf6f7d000) libssl.so.4 => /lib/libssl.so.4 (0xf6f49000) libcrypto.so.4 => /lib/libcrypto.so.4 (0xf6e61000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xf6e4f000) libc.so.6 => /lib/tls/libc.so.6 (0xf6d28000) libresolv.so.2 => /lib/libresolv.so.2 (0xf6d13000) libdl.so.2 => /lib/libdl.so.2 (0xf6d0f000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xf6ce1000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf6ccd000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf6c68000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xf6c65000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf6c43000) libz.so.1 => /usr/lib/libz.so.1 (0xf6c33000) /lib/ld-linux.so.2 (0xf6feb000) > Do all the RPMs come from Fedora? Yes. This is a fresh install of FC3 direct from the ISOs. > Does the current version of python-ldap compiled from source also segfault? Yep. I checked out the latest python-ldap from anonymous CVS, compiled, and ran my test against it. Same result. --Tessa From mrroach at okmaybe.com Sat Dec 11 01:24:42 2004 From: mrroach at okmaybe.com (Mark Roach) Date: Fri, 10 Dec 2004 19:24:42 -0500 Subject: Connections established using SASL die after search Message-ID: <1102724682.22873.9.camel@flmrroach.okmaybe.com> 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 michael at stroeder.com Sat Dec 11 09:17:11 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 11 Dec 2004 09:17:11 +0100 Subject: Connections established using SASL die after search In-Reply-To: <1102724682.22873.9.camel@flmrroach.okmaybe.com> References: <1102724682.22873.9.camel@flmrroach.okmaybe.com> Message-ID: <41BAAD07.5040101@stroeder.com> 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 michael at stroeder.com Sat Dec 11 13:36:32 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 11 Dec 2004 13:36:32 +0100 Subject: Connections established using SASL die after search In-Reply-To: <41BAAD07.5040101@stroeder.com> References: <1102724682.22873.9.camel@flmrroach.okmaybe.com> <41BAAD07.5040101@stroeder.com> Message-ID: <41BAE9D0.40306@stroeder.com> Michael Str?der wrote: > 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? It'd be also useful to know which versions of OpenLDAP libs, cyrus-sasl and heimdal are used with python-ldap. Note that this combination is rather fragile. Please use current versions of all these... Ciao, Michael. From michael at stroeder.com Sun Dec 12 01:28:51 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 12 Dec 2004 01:28:51 +0100 Subject: Connections established using SASL die after search In-Reply-To: <1102790614.7130.11.camel@flmrroach.okmaybe.com> References: <1102724682.22873.9.camel@flmrroach.okmaybe.com> <41BAAD07.5040101@stroeder.com> <41BAE9D0.40306@stroeder.com> <1102790614.7130.11.camel@flmrroach.okmaybe.com> Message-ID: <41BB90C3.80608@stroeder.com> 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 mrroach at okmaybe.com Sat Dec 11 19:43:33 2004 From: mrroach at okmaybe.com (Mark Roach) Date: Sat, 11 Dec 2004 13:43:33 -0500 Subject: Connections established using SASL die after search In-Reply-To: <41BAE9D0.40306@stroeder.com> References: <1102724682.22873.9.camel@flmrroach.okmaybe.com> <41BAAD07.5040101@stroeder.com> <41BAE9D0.40306@stroeder.com> Message-ID: <1102790614.7130.11.camel@flmrroach.okmaybe.com> On Sat, 2004-12-11 at 13:36 +0100, Michael Str?der wrote: > > > > Are you sure that the code and python-ldap causes the problem? > > > > Which LDAP server and which version is it? > > It'd be also useful to know which versions of OpenLDAP libs, cyrus-sasl > and heimdal are used with python-ldap. > > Note that this combination is rather fragile. Please use current > 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 michael at stroeder.com Sun Dec 12 02:51:05 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 12 Dec 2004 02:51:05 +0100 Subject: [Fwd: ANN: PSF Licensing FAQ] Message-ID: <41BBA409.60804@stroeder.com> I think it's worth to take note of... Ciao, Michael. -------- Original Message -------- Subject: ANN: PSF Licensing FAQ Date: Sat, 11 Dec 2004 15:53:48 -0500 (EST) From: Stephan Deibel To: python-list at python.org Newsgroups: comp.lang.python Hi, The Python Software Foundation (PSF) board recently wrote up a licensing FAQ that we hope will help to clear up some of the confusion that has surrounded the PSF License. There are quite a few projects out there (on Source Forge and otherwise) that misuse this license in ways potentially detrimental to those projects. If you are the author or maintainer of a project that uses the PSF License, please read this: http://www.python.org/cgi-bin/moinmoin/PythonSoftwareFoundationLicenseFaq In short: The PSF License was originally developed specifically and only for Python itself (and its standard library). It can be reused but not verbatim without modifying the copyright and product name in the license. Also, the entire "license stack" that comes with Python is irrelevant to 3rd party projects and should not be reproduced outside of Python. The above document also covers contribution of code to the PSF, which is only an issue if your code will become part of the Python distribution. The contribution process is still being set up, so this part of the document is subject to change. Please cc me on any replies, as I can't currently keep up with CLP. Thanks! Stephan Deibel Chairman of the Board Python Software Foundation http://python.org/psf From mrroach at okmaybe.com Sun Dec 12 05:51:24 2004 From: mrroach at okmaybe.com (Mark Roach) Date: Sat, 11 Dec 2004 23:51:24 -0500 Subject: Connections established using SASL die after search In-Reply-To: <41BB90C3.80608@stroeder.com> References: <1102724682.22873.9.camel@flmrroach.okmaybe.com> <41BAAD07.5040101@stroeder.com> <41BAE9D0.40306@stroeder.com> <1102790614.7130.11.camel@flmrroach.okmaybe.com> <41BB90C3.80608@stroeder.com> Message-ID: <1102827084.7130.22.camel@flmrroach.okmaybe.com> On Sun, 2004-12-12 at 01:28 +0100, Michael Str?der wrote: > 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. 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: ----------------------------------- => access_allowed: search access granted by read(=rscx) <= test_filter 5 <= test_filter_and 5 <= test_filter 5 bdb_search: 110 does not match filter send_ldap_result: conn=6 op=2 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=3 tag=101 err=0 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=14, written=14 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ conn=6 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= daemon: activity on 1 descriptors daemon: activity on: 10r daemon: read activity on 10 connection_get(10) connection_get(10): got connid=6 connection_read(10): checking for input on id=6 ber_get_next ldap_read: want=8, got=0 ber_get_next on fd 10 failed errno=0 (Success) connection_read(10): input error=-2 id=6, closing. connection_closing: readying conn=6 sd=10 for close connection_close: conn=6 sd=10 daemon: removing 10 conn=6 fd=10 closed daemon: select: listen=6 active_threads=0 tvp=NULL daemon: select: listen=7 active_threads=0 tvp=NULL daemon: activity on 1 descriptors daemon: select: listen=6 active_threads=0 tvp=NULL daemon: select: listen=7 active_threads=0 tvp=NULL From michael at stroeder.com Tue Dec 14 08:59:56 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 14 Dec 2004 08:59:56 +0100 Subject: Connections established using SASL die after search In-Reply-To: <1102724682.22873.9.camel@flmrroach.okmaybe.com> References: <1102724682.22873.9.camel@flmrroach.okmaybe.com> Message-ID: <41BE9D7C.9010707@stroeder.com> 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 Paul.Casteels at ua.ac.be Thu Nov 25 16:21:42 2004 From: Paul.Casteels at ua.ac.be (Paul Casteels) Date: Thu, 25 Nov 2004 16:21:42 +0100 Subject: undefined symbol Message-ID: <41A5F886.10301@ua.ac.be> Hi, I have python-2.2.3-5, cyrus-sasl-2.1.15-10 and openldap-2.0.27-17 installed. Builing and installing python-ldap-2.0.5 went fine but when I try to start I have : Python 2.2.3 (#1, Aug 8 2003, 08:44:02) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ldap Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/ldap/__init__.py", line 21, in ? from _ldap import * ImportError: /usr/lib/python2.2/site-packages/_ldap.so: undefined symbol: ldap_passwd >>> Are there any suggestions to fix this ? Best regards and thanks, Paul Casteels From michael at stroeder.com Wed Dec 15 20:43:04 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 15 Dec 2004 20:43:04 +0100 Subject: undefined symbol In-Reply-To: <41A5F886.10301@ua.ac.be> References: <41A5F886.10301@ua.ac.be> Message-ID: <41C093C8.6020505@stroeder.com> Paul Casteels wrote: > > ImportError: /usr/lib/python2.2/site-packages/_ldap.so: undefined > symbol: ldap_passwd What does ldd /usr/lib/python2.2/site-packages/_ldap.so display? Does it really link the right OpenLDAP libs? I suspect the function ldap_passwd is not available in OpenLDAP 2.0.x libs. But then I wonder how you managed to compile from source. Did you? Hmm, you might have several versions of the OpenLDAP libs hanging around on your system. Ciao, Michael. From mrroach at okmaybe.com Tue Dec 14 16:55:41 2004 From: mrroach at okmaybe.com (Mark Roach) Date: Tue, 14 Dec 2004 10:55:41 -0500 Subject: Connections established using SASL die after search In-Reply-To: <41BE9D7C.9010707@stroeder.com> References: <1102724682.22873.9.camel@flmrroach.okmaybe.com> <41BE9D7C.9010707@stroeder.com> Message-ID: <1103039742.32539.11.camel@flmrroach.okmaybe.com> On Tue, 2004-12-14 at 08:59 +0100, Michael Str?der wrote: > Mark Roach wrote: > > except: > > print "Died on iteration %d" % (i) > > print out > > break > > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: ldapsearch-sasltest.patch Type: text/x-patch Size: 1390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testsasl2.py Type: application/x-python Size: 2415 bytes Desc: not available URL: -------------- next part -------------- mrroach at flmrroach:~/Archives/src/edsadmin/test$ python testsasl2.py Trying gssapi connection SASL/GSSAPI authentication started SASL username: mrroach at OKMAYBE.COM SASL SSF: 56 SASL installing layers 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Trying gssapi + extra search 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 Died on iteration 36 ldap.SERVER_DOWN Error: {'info': '', 'desc': "Can't contact LDAP server"} ['dc=okmaybe,dc=com'] mrroach at flmrroach:~/Archives/src/edsadmin/test$ python testsasl2.py Trying gssapi connection SASL/GSSAPI authentication started SASL username: mrroach at OKMAYBE.COM SASL SSF: 56 SASL installing layers 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Trying gssapi + extra search 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 mrroach at flmrroach:~/Archives/src/edsadmin/test$ python testsasl2.py Trying gssapi connection SASL/GSSAPI authentication started SASL username: mrroach at OKMAYBE.COM SASL SSF: 56 SASL installing layers 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Trying gssapi + extra search 0 1 2 3 4 5 Died on iteration 6 ldap.SERVER_DOWN Error: {'info': '', 'desc': "Can't contact LDAP server"} ['dc=okmaybe,dc=com'] mrroach at flmrroach:~/Archives/src/edsadmin/test$ python testsasl2.py Trying gssapi connection SASL/GSSAPI authentication started SASL username: mrroach at OKMAYBE.COM SASL SSF: 56 SASL installing layers 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Trying gssapi + extra search Died on iteration 0 ldap.SERVER_DOWN Error: {'info': '', 'desc': "Can't contact LDAP server"} ['dc=okmaybe,dc=com'] mrroach at flmrroach:~/Archives/src/edsadmin/test$ python testsasl2.py Trying gssapi connection SASL/GSSAPI authentication started SASL username: mrroach at OKMAYBE.COM SASL SSF: 56 SASL installing layers 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Trying gssapi + extra search Died on iteration 0 ldap.SERVER_DOWN Error: {'info': '', 'desc': "Can't contact LDAP server"} ['dc=okmaybe,dc=com'] mrroach at flmrroach:~/Archives/src/edsadmin/test$ python testsasl2.py Trying gssapi connection SASL/GSSAPI authentication started SASL username: mrroach at OKMAYBE.COM SASL SSF: 56 SASL installing layers 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Trying gssapi + extra search 0 1 Died on iteration 2 ldap.SERVER_DOWN Error: {'info': '', 'desc': "Can't contact LDAP server"} ['dc=okmaybe,dc=com'] mrroach at flmrroach:~/Archives/src/edsadmin/test$ python testsasl2.py Trying gssapi connection SASL/GSSAPI authentication started SASL username: mrroach at OKMAYBE.COM SASL SSF: 56 SASL installing layers 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Trying gssapi + extra search 0 1 2 3 4 5 6 7 8 9 10 11 12 13 Died on iteration 14 ldap.SERVER_DOWN Error: {'info': '', 'desc': "Can't contact LDAP server"} ['dc=okmaybe,dc=com'] mrroach at flmrroach:~/Archives/src/edsadmin/test$ python testsasl2.py Trying gssapi connection SASL/GSSAPI authentication started SASL username: mrroach at OKMAYBE.COM SASL SSF: 56 SASL installing layers 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Trying gssapi + extra search 0 1 2 3 4 5 6 7 8 9 Died on iteration 10 ldap.SERVER_DOWN Error: {'info': '', 'desc': "Can't contact LDAP server"} ['dc=okmaybe,dc=com'] mrroach at flmrroach:~/Archives/src/edsadmin/test$ python testsasl2.py Trying gssapi connection SASL/GSSAPI authentication started SASL username: mrroach at OKMAYBE.COM SASL SSF: 56 SASL installing layers 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Trying gssapi + extra search 0 1 2 3 4 5 6 7 8 9 10 11 12 13 Died on iteration 14 ldap.SERVER_DOWN Error: {'info': '', 'desc': "Can't contact LDAP server"} ['dc=okmaybe,dc=com'] From mrroach at okmaybe.com Thu Dec 16 22:38:49 2004 From: mrroach at okmaybe.com (Mark Roach) Date: Thu, 16 Dec 2004 16:38:49 -0500 Subject: Connections established using SASL die after search In-Reply-To: <1103039742.32539.11.camel@flmrroach.okmaybe.com> References: <1102724682.22873.9.camel@flmrroach.okmaybe.com> <41BE9D7C.9010707@stroeder.com> <1103039742.32539.11.camel@flmrroach.okmaybe.com> Message-ID: <1103233130.10302.18.camel@flmrroach.okmaybe.com> On Tue, 2004-12-14 at 10:55 -0500, Mark Roach wrote: > On Tue, 2004-12-14 at 08:59 +0100, Michael Str?der wrote: > > Mark Roach wrote: > > > except: > > > print "Died on iteration %d" % (i) > > > print out > > > break > > > > 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 = 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): [l.search_s('ou=%s,dc=okmaybe,dc=com' % ou, ldap.SCOPE_ONELEVEL, '(objectClass=*)') \ for ou in ['system','people','groups']] Thanks again. And sorry for all the noise on this list. -Mark From michael at stroeder.com Fri Dec 17 10:22:35 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 17 Dec 2004 10:22:35 +0100 Subject: Connections established using SASL die after search In-Reply-To: <1103233130.10302.18.camel@flmrroach.okmaybe.com> References: <1102724682.22873.9.camel@flmrroach.okmaybe.com> <41BE9D7C.9010707@stroeder.com> <1103039742.32539.11.camel@flmrroach.okmaybe.com> <1103233130.10302.18.camel@flmrroach.okmaybe.com> Message-ID: <41C2A55B.2090801@stroeder.com> 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 michael at stroeder.com Fri Dec 17 10:23:43 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 17 Dec 2004 10:23:43 +0100 Subject: Connections established using SASL die after search In-Reply-To: <1103039742.32539.11.camel@flmrroach.okmaybe.com> References: <1102724682.22873.9.camel@flmrroach.okmaybe.com> <41BE9D7C.9010707@stroeder.com> <1103039742.32539.11.camel@flmrroach.okmaybe.com> Message-ID: <41C2A59F.6070404@stroeder.com> 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. From michael at stroeder.com Mon Dec 20 09:40:41 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 20 Dec 2004 09:40:41 +0100 Subject: undefined symbol In-Reply-To: <41C14601.3000107@ua.ac.be> References: <41A5F886.10301@ua.ac.be> <41C093C8.6020505@stroeder.com> <41C14601.3000107@ua.ac.be> Message-ID: <41C69009.2000804@stroeder.com> Paul Casteels wrote: > Michael Str?der wrote: > >> Hmm, you might have several versions of the OpenLDAP libs hanging >> around on your system. > > Thanks for your reply Michael. I tried python-ldap-2.0.6 with the same > result. Compiling and linking goes without problems. I suppose I could > not have _ldap.so if it failed ? I don't know your system. There are many possibilities how things can go wrong with a library mix. Please compare the time-stamp of the installed file /usr/lib/python2.2/site-packages/_ldap.so with your build time. Ciao, Michael. P.S.: Please stay on python-ldap-dev at lists.sourceforge.net that others can answer as well. From steuwer at univention.de Thu Dec 16 13:36:10 2004 From: steuwer at univention.de (Ingo Steuwer) Date: Thu, 16 Dec 2004 13:36:10 +0100 Subject: Implementation of LDAPControls Message-ID: <1103200570.1037.443.camel@anton.knut.univention.de> Hello we are using python-ldap in some of our main projects and are glad to have this great tool. To fulfill our upcomming goals we need to use LDAPControls, but the latest released version of python-ldap doesn't support them. We did some experimental implementations in the C-backend (for "proof of concept") and would now like to define a general approach. This should be done in coordination with you to see our work in upcoming versions of python-ldap. At the moment we need no "complete" implementation, only support for sending an arbitrary OID and the "iscritcal"-Flag. But the implementation should be prepared for optional values and parsing of client-controls. My attempt would defining a python-class LDAPControl (containing OID, iscritcal and value (dictionary)) and implement a correspondig wrapper to *LDAPControl. I think the most diffcult part will be the representation of berval/berelement in python. So, some questions before going further: - is there somebody else implementing this (I didn't look at the cvs) ? - are there already thoughts, definitions or an approach I should know ? - do you know about wrappers between berval/berelement and python ? I'd be glad to get some hints, opinions and feedback. Regards Ingo Steuwer -- Ingo Steuwer steuwer at univention.de fon: +49 421 22 232- 0 Entwicklung Linux for Your Business Univention GmbH http://www.univention.de/ fax: +49 421 22 232-99 From michael at stroeder.com Mon Dec 20 10:01:10 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 20 Dec 2004 10:01:10 +0100 Subject: Implementation of LDAPControls In-Reply-To: <1103200570.1037.443.camel@anton.knut.univention.de> References: <1103200570.1037.443.camel@anton.knut.univention.de> Message-ID: <41C694D6.2090006@stroeder.com> Ingo Steuwer wrote: > > To fulfill our upcomming goals we need to use LDAPControls, but the > latest released version of python-ldap doesn't support them. Yes, you'll find a hint in file TODO. > We did some experimental implementations in the C-backend (for "proof of > concept") and would now like to define a general approach. This should > be done in coordination with you to see our work in upcoming versions of > python-ldap. Since I'm not a C programmer (David wrote the C code) I'd be really glad if someone would jump on in and contribute code for LDAP controls and extended operations. I already tried to wrap the arguments whereever appropriate. Please review this. > My attempt would defining a python-class LDAPControl (containing OID, > iscritcal and value (dictionary)) and implement a correspondig wrapper > to *LDAPControl. But value can be a complex ASN.1 structure as well. > I think the most diffcult part will be the > representation of berval/berelement in python. Yes. > - is there somebody else implementing this (I didn't look at the cvs) ? No. And I'm currently rather short on time. I'd highly appreciate your contributions. But note that you should give away copyright for your contributed code. Make sure that your legal department agrees on that. > - are there already thoughts, definitions or an approach I should know ? There are several approaches. 1. Python classes for controls with a method berencode(). This method would be called before passing the controls as argument to the functions in _ldap. This would be the most flexible approach and independent of the underlying OpenLDAP API. Drawbacks are that you need a BER module for this and it's much work for complex controls. 1.a Wrap libber. 1.b Implement a pure Python BER module. Maybe we could get one from a SNMP implementation implemented in Python? 2. We could also wrap the helper functions in libldap (see controls.c, vlvctrl.c, sortctrl.c). But this would add another strong dependency on the OpenLDAP libs. > - do you know about wrappers between berval/berelement and python ? No. You could try to wrap OpenLDAP's libber. Ciao, Michael. From Hans.Aschauer at epost.de Mon Dec 20 14:44:58 2004 From: Hans.Aschauer at epost.de (Hans Aschauer) Date: Mon, 20 Dec 2004 14:44:58 +0100 Subject: Implementation of LDAPControls In-Reply-To: <41C694D6.2090006@stroeder.com> References: <1103200570.1037.443.camel@anton.knut.univention.de> <41C694D6.2090006@stroeder.com> Message-ID: <200412201445.00285.Hans.Aschauer@epost.de> On Monday 20 December 2004 10:01, Michael Str?der wrote: > 1.b Implement a pure Python BER module. Maybe we could get one from a > SNMP implementation implemented in Python? I did some research on this topic some time ago. That's the results, as far as I remember: To me, pySNMP looks fine (feature and license-wise). It is a pure-python package, and the ASN.1 package can be used independently from the rest of the pySNMP package, and it has a reasonable size (~100 k). They also implement (as far as I understand it) not only the snmp-parts of ASN.1 (or their BER encodings), but try to be generic. On the other hand, I have never tried this package... The package and docs are located on sourceforge: http://pysnmp.sourceforge.net/docs/3.4.x/asn1/index.html BTW. pysnmp is also used in twisted... Hans From michael at stroeder.com Mon Dec 20 17:03:29 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 20 Dec 2004 17:03:29 +0100 Subject: Implementation of LDAPControls In-Reply-To: <200412201445.00285.Hans.Aschauer@epost.de> References: <1103200570.1037.443.camel@anton.knut.univention.de> <41C694D6.2090006@stroeder.com> <200412201445.00285.Hans.Aschauer@epost.de> Message-ID: <41C6F7D1.50307@stroeder.com> Hans Aschauer wrote: > On Monday 20 December 2004 10:01, Michael Str?der wrote: > >>1.b Implement a pure Python BER module. Maybe we could get one from a >>SNMP implementation implemented in Python? > > To me, pySNMP looks fine (feature and license-wise). I also glanced over it quite a while ago. Do you argue for requiring it as a 3rd-party module? This would be overkill. Hmm, maybe we could convince the author to extract and separately distribute the BER-related stuff? Ciao, Michael. From michael at stroeder.com Tue Dec 21 08:04:05 2004 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 21 Dec 2004 08:04:05 +0100 Subject: Export to LDIF In-Reply-To: <127079e104122017152fa601df@mail.gmail.com> References: <127079e104122017152fa601df@mail.gmail.com> Message-ID: <41C7CAE5.7080707@stroeder.com> Wido Depping wrote: > Is it possible that the LDIFWriter class can be extended to return the > LDIF string and don't write it to a file handler? This is useful if > you want to save the content to a resource which is not accessible > with a file handler. Use StringIO or for that. try: from cStringIO import StringIO except ImportError: from StringIO import StringIO ... Ciao, Michael. From wido.depping at gmail.com Tue Dec 21 02:15:48 2004 From: wido.depping at gmail.com (Wido Depping) Date: Tue, 21 Dec 2004 02:15:48 +0100 Subject: Export to LDIF Message-ID: <127079e104122017152fa601df@mail.gmail.com> Is it possible that the LDIFWriter class can be extended to return the LDIF string and don't write it to a file handler? This is useful if you want to save the content to a resource which is not accessible with a file handler. In my case I have created something like 'smart' LDAP objects for Luma. They are aware of the server schemas and provide functions which go beyond the data structure provided by python-ldap. One function of these objects is the ability to export its own data into LDIF format. An instance has control over all data entries and collects the LDIF strings to export the data into a file. But in the future other resource should be implemented, like access to KDE io-slaves. Somehow I feel uncomfortable doing the LDIF encoding stuff myself and I thought python-ldap is the ideal place to implement this functionality. Thanks in advance, Wido -- Wido Depping ICQ: 51303067 AIM: wido3379 Jabber: wido at jabber.ccc.de Blog: http://widoww.blogspot.com