From michael at stroeder.com Tue Jul 5 16:02:39 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 05 Jul 2011 16:02:39 +0200 Subject: [python-ldap] ANN: python-ldap 2.4.1 Message-ID: <4E13197F.8080802@stroeder.com> Find a new release of python-ldap: http://pypi.python.org/pypi/python-ldap/2.4.1 python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). Project's web site: http://www.python-ldap.org/ Ciao, Michael. ---------------------------------------------------------------- Released 2.4.1 2011-07-05 Changes since 2.4.0: Modules: * New LDAP option OPT_X_TLS_PACKAGE available in OpenLDAP 2.4.26+ to determine the name of the SSL/TLS package OpenLDAP was built with Lib/ * ldap.modlist.modifyModlist(): New key-word argument case_ignore_attr_types used to define attribute types for which comparison of old and new values should be case-insensitive * Minor changes to which data is sent to debug output for various trace levels * Now tag [1] is used in ldap.extop.dds.RefreshResponse in compliance with RFC 2589 (fix available for OpenLDAP ITS#6886) * New sub-module ldap.controls.sessiontrack implements request control as described in draft-wahl-ldap-session (needs pyasn1_modules) From cornelius.koelbel at lsexperts.de Wed Jul 6 15:01:41 2011 From: cornelius.koelbel at lsexperts.de (=?ISO-8859-15?Q?Cornelius_K=F6lbel?=) Date: Wed, 06 Jul 2011 15:01:41 +0200 Subject: [python-ldap] sizelimit but no offset? Message-ID: <4E145CB5.2010108@lsexperts.de> Hi List, I got an ldap search that will return me some thousand users. This makes an LDAP search very long lasting. I know there is the OPT_SIZELIMIT. But is there also the possibility to specify some kind of offset? Lets say to do the first search for the objects 1-100. Assume the user hits a button "next" and then the search 101-200 will be triggered? Thanks a lot and kind regards Cornelius -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From vela at debian.org Wed Jul 6 16:19:21 2011 From: vela at debian.org (Matej Vela) Date: Wed, 06 Jul 2011 16:19:21 +0200 Subject: [python-ldap] sizelimit but no offset? In-Reply-To: <4E145CB5.2010108@lsexperts.de> ("Cornelius =?utf-8?Q?K=C3=B6?= =?utf-8?Q?lbel=22's?= message of "Wed\, 06 Jul 2011 15\:01\:41 +0200") References: <4E145CB5.2010108@lsexperts.de> Message-ID: <874o2zebkm.fsf@zelendur.carpriv.carnet.hr> Cornelius K?lbel writes: > I got an ldap search that will return me some thousand users. > This makes an LDAP search very long lasting. > I know there is the OPT_SIZELIMIT. But is there also the possibility to > specify some kind of offset? > > Lets say to do the first search for the objects 1-100. > Assume the user hits a button "next" and then the search 101-200 will be > triggered? Yes, RFC 2696 specifies a control for paged results -- see Demo/page_control.py. Cheers, Matej From bgollmer at tcnetworks.com Wed Jul 6 16:09:51 2011 From: bgollmer at tcnetworks.com (Ben Gollmer) Date: Wed, 6 Jul 2011 10:09:51 -0400 Subject: [python-ldap] sizelimit but no offset? In-Reply-To: <4E145CB5.2010108@lsexperts.de> References: <4E145CB5.2010108@lsexperts.de> Message-ID: <06F66A30-C6B2-4D0E-BED2-C27A8BC85010@tcnetworks.com> On Jul 6, 2011, at 9:01 AM, Cornelius K?lbel wrote: > Hi List, > > I got an ldap search that will return me some thousand users. > This makes an LDAP search very long lasting. > I know there is the OPT_SIZELIMIT. But is there also the possibility to > specify some kind of offset? > > Lets say to do the first search for the objects 1-100. > Assume the user hits a button "next" and then the search 101-200 will be > triggered? Many LDAP servers implement paged results. If yours does, you can use ldap.controls.SimplePagedResults. -- Ben From stefanik at dscon.sk Wed Jul 6 16:47:01 2011 From: stefanik at dscon.sk (Dusan Stefanik) Date: Wed, 6 Jul 2011 16:47:01 +0200 Subject: [python-ldap] ReconnectLDAPObject not working properly? Message-ID: <20110706144654.GB27307@portos> Hi, I tried simple test: >>> l = ldap.ldapobject.ReconnectLDAPObject('ldap://172.16.2.1:389/',trace_level=1,retry_max=3) *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.set_option ((17, 3),{}) >>> l.search_s("o=test",ldap.SCOPE_BASE,"objectclass=*") *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.search_ext (('o=test', 0, 'objectclass=*', None, 0, None, None, -1, 0),{}) *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.unbind_ext ((None, None),{}) *** Try 1. reconnect to ldap://172.16.2.1:389/... *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.set_option ((17, 3),{}) *** 1. reconnect to ldap://172.16.2.1:389/ successful, last operation will be repeated *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.search_ext (('o=test', 0, 'objectclass=*', None, 0, None, None, -1, 0),{}) Traceback (most recent call last): ... ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"} So there is o retry_max = 3 but I don't see 3 attempts to connect from debug and as you can see: reconnect successful... but server is still down. It is like a problem in this call that will not raise exception: self._l = ldap.functions._ldap_function_call(ldap._ldap_module_lock,_ldap.initialize,uri) in this reconnect method: def reconnect(self,uri): # Drop and clean up old connection completely # Reconnect reconnect_counter = self._retry_max while reconnect_counter: if __debug__ and self._trace_level>=1: self._trace_file.write('*** Try %d. reconnect to %s...\n' % ( self._retry_max-reconnect_counter+1,uri )) try: # Do the connect self._l = ldap.functions._ldap_function_call(ldap._ldap_module_lock,_ldap.initialize,uri) self._restore_options() # StartTLS extended operation in case this was called before if self._start_tls: self.start_tls_s() # Repeat last simple or SASL bind self._apply_last_bind() except ldap.SERVER_DOWN as e: SimpleLDAPObject.unbind_s(self) del self._l if __debug__ and self._trace_level>=1: self._trace_file.write('*** %d. reconnect to %s failed\n' % ( self._retry_max-reconnect_counter+1,uri )) reconnect_counter = reconnect_counter-1 if not reconnect_counter: raise if __debug__ and self._trace_level>=1: self._trace_file.write('=> delay %s...\n' % (self._retry_delay)) time.sleep(self._retry_delay) else: if __debug__ and self._trace_level>=1: self._trace_file.write('*** %d. reconnect to %s successful, last operation will be repeated\n' % ( self._retry_max-reconnect_counter+1,uri )) self._reconnects_done = self._reconnects_done + 1 break Dusan From michael at stroeder.com Wed Jul 6 20:03:25 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 06 Jul 2011 20:03:25 +0200 Subject: [python-ldap] ReconnectLDAPObject not working properly? In-Reply-To: <20110706144654.GB27307@portos> References: <20110706144654.GB27307@portos> Message-ID: <4E14A36D.7050904@stroeder.com> Dusan Stefanik wrote: > I tried simple test: >>>> l = ldap.ldapobject.ReconnectLDAPObject('ldap://172.16.2.1:389/',trace_level=1,retry_max=3) > *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.set_option ((17, 3),{}) >>>> l.search_s("o=test",ldap.SCOPE_BASE,"objectclass=*") > *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.search_ext (('o=test', 0, 'objectclass=*', None, 0, None, None, -1, 0),{}) > *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.unbind_ext ((None, None),{}) > *** Try 1. reconnect to ldap://172.16.2.1:389/... > *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.set_option ((17, 3),{}) > *** 1. reconnect to ldap://172.16.2.1:389/ successful, last operation will be repeated > *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.search_ext (('o=test', 0, 'objectclass=*', None, 0, None, None, -1, 0),{}) > Traceback (most recent call last): > ... > ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"} What happened during "..."? > So there is o retry_max = 3 but I don't see 3 attempts to connect from debug and as you can see: reconnect successful... but server is still down. > It is like a problem in this call that will not raise exception: > self._l = ldap.functions._ldap_function_call(ldap._ldap_module_lock,_ldap.initialize,uri) What makes you think _ldap.initialize() will not raise an exception? It's hard to tell what's happening without looking at the calling code. Ciao, Michael. From stefanik at dscon.sk Thu Jul 7 06:52:04 2011 From: stefanik at dscon.sk (Dusan Stefanik) Date: Thu, 7 Jul 2011 06:52:04 +0200 Subject: [python-ldap] ReconnectLDAPObject not working properly? In-Reply-To: <4E14A36D.7050904@stroeder.com> References: <20110706144654.GB27307@portos> <4E14A36D.7050904@stroeder.com> Message-ID: <20110707045204.GB30587@portos> What calling code? My code has 3 lines in python interpreter. import ldap l = ldap.ldapobject.ReconnectLDAPObject('ldap://172.16.2.1:389/',trace_level=1,retry_max=3) l.search_s("o=test",ldap.SCOPE_BASE,"objectclass=*") And all with traceback: >>> l = ldap.ldapobject.ReconnectLDAPObject('ldap://172.16.2.1:389/',trace_level=1,retry_max=3) *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.set_option ((17, 3),{}) >>> l.search_s("o=test",ldap.SCOPE_BASE,"objectclass=*") *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.search_ext (('o=test', 0, 'objectclass=*', None, 0, None, None, -1, 0),{}) *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.unbind_ext ((None, None),{}) *** Try 1. reconnect to ldap://172.16.2.1:389/... *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.set_option ((17, 3),{}) *** 1. reconnect to ldap://172.16.2.1:389/ successful, last operation will be repeated *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.search_ext (('o=test', 0, 'objectclass=*', None, 0, None, None, -1, 0),{}) Traceback (most recent call last): File "", line 1, in File "/home/stefanik/projects/virtualenvs/test/lib/python2.6/site-packages/python_ldap-2.4.1-py2.6-linux-x86_64.egg/ldap/ldapobject.py", line 554, in search_s return self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout=self.timeout) File "/home/stefanik/projects/virtualenvs/test/lib/python2.6/site-packages/python_ldap-2.4.1-py2.6-linux-x86_64.egg/ldap/ldapobject.py", line 858, in search_ext_s return self._apply_method_s(SimpleLDAPObject.search_ext_s,*args,**kwargs) File "/home/stefanik/projects/virtualenvs/test/lib/python2.6/site-packages/python_ldap-2.4.1-py2.6-linux-x86_64.egg/ldap/ldapobject.py", line 814, in _apply_method_s return func(self,*args,**kwargs) File "/home/stefanik/projects/virtualenvs/test/lib/python2.6/site-packages/python_ldap-2.4.1-py2.6-linux-x86_64.egg/ldap/ldapobject.py", line 547, in search_ext_s msgid = self.search_ext(base,scope,filterstr,attrlist,attrsonly,serverctrls,clientctrls,timeout,sizelimit) File "/home/stefanik/projects/virtualenvs/test/lib/python2.6/site-packages/python_ldap-2.4.1-py2.6-linux-x86_64.egg/ldap/ldapobject.py", line 543, in search_ext timeout,sizelimit, File "/home/stefanik/projects/virtualenvs/test/lib/python2.6/site-packages/python_ldap-2.4.1-py2.6-linux-x86_64.egg/ldap/ldapobject.py", line 97, in _ldap_call result = func(*args,**kwargs) ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"} On 06/07/11 at 08:03pm, Michael Str?der wrote: > Dusan Stefanik wrote: > > I tried simple test: > >>>> l = ldap.ldapobject.ReconnectLDAPObject('ldap://172.16.2.1:389/',trace_level=1,retry_max=3) > > *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.set_option ((17, 3),{}) > >>>> l.search_s("o=test",ldap.SCOPE_BASE,"objectclass=*") > > *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.search_ext (('o=test', 0, 'objectclass=*', None, 0, None, None, -1, 0),{}) > > *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.unbind_ext ((None, None),{}) > > *** Try 1. reconnect to ldap://172.16.2.1:389/... > > *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.set_option ((17, 3),{}) > > *** 1. reconnect to ldap://172.16.2.1:389/ successful, last operation will be repeated > > *** ldap://172.16.2.1:389/ - ReconnectLDAPObject.search_ext (('o=test', 0, 'objectclass=*', None, 0, None, None, -1, 0),{}) > > Traceback (most recent call last): > > ... > > ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"} > > What happened during "..."? > > > So there is o retry_max = 3 but I don't see 3 attempts to connect from debug and as you can see: reconnect successful... but server is still down. > > It is like a problem in this call that will not raise exception: > > self._l = ldap.functions._ldap_function_call(ldap._ldap_module_lock,_ldap.initialize,uri) > > What makes you think _ldap.initialize() will not raise an exception? > > It's hard to tell what's happening without looking at the calling code. > > Ciao, Michael. > From michael at stroeder.com Thu Jul 7 09:23:32 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 07 Jul 2011 09:23:32 +0200 Subject: [python-ldap] ReconnectLDAPObject not working properly? In-Reply-To: <20110707045204.GB30587@portos> References: <20110706144654.GB27307@portos> <4E14A36D.7050904@stroeder.com> <20110707045204.GB30587@portos> Message-ID: <4E155EF4.2060001@stroeder.com> Dusan Stefanik wrote: > What calling code? My code has 3 lines in python interpreter. > import ldap > l = ldap.ldapobject.ReconnectLDAPObject('ldap://172.16.2.1:389/',trace_level=1,retry_max=3) > l.search_s("o=test",ldap.SCOPE_BASE,"objectclass=*") Well, with such a short code you cannot reliably test this. The reason is the behaviour of the OpenLDAP C libs which looks strange at first glance. Background: The OpenLDAP function ldap_initialize() and its counterpart _ldap.initialize() in the Python extension module does *nothing* on the wire. It just initializes the LDAP connection struct in the C API. The first call to an operation method (bind, search etc.) really opens the connection. ReconnectLDAPObject relys on the information of an already *successfully* opened connection and bound LDAP association. It was never intended to be a convenience wrapper for your application loop. The main goal was to let *synchronous* methods retry to get through in case of short-time server failure. If the connection wasn't ever really openend it does not *reconnect* since there was never a connection and bind before and therefore IMHO there's no meaningful behaviour (think of connect and bind and already the bind fails with ldap.SERVER_DOWN). But in any case your application has to handle ldap.SERVER_DOWN in a reasonable way which can get very tricky depending on your application. So your test code should look like this: import ldap l = ldap.ldapobject.ReconnectLDAPObject( 'ldap://172.16.2.1:389', trace_level=1, retry_max=6 ) # really open the connection by sending BindRequest l.simple_bind_s('','') # now enough time to stop the LDAP server sleep(10.0) # send the SearchRequest l.search_s("o=test",ldap.SCOPE_BASE,"objectclass=*") But I have to think about your corner-case above where you use an implicit anonymous bind. Personally I never do this so it's not tested though it's allowed in LDAPv3. Feel free to test that inspired by the information above and please give feedback on that. Ciao, Michael. From jblaine at kickflop.net Thu Jul 7 22:38:44 2011 From: jblaine at kickflop.net (Jeff Blaine) Date: Thu, 07 Jul 2011 16:38:44 -0400 Subject: [python-ldap] ldap.SUCCESS sometimes, the results other times Message-ID: <4E161954.40607@kickflop.net> I'm clearly doing something wrong :) I don't see this addressed in the documentation or the FAQ. I'm developing something. When I run it, the majority of the time I get traceback ending in ldap.SUCCESS instead of the expected output. Eventually, if I run it enough times, it spits out my data instead of ldap.SUCCESS What gives? Any pointers? From michael at stroeder.com Fri Jul 8 09:07:12 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 08 Jul 2011 09:07:12 +0200 Subject: [python-ldap] ldap.SUCCESS sometimes, the results other times In-Reply-To: <4E161954.40607@kickflop.net> References: <4E161954.40607@kickflop.net> Message-ID: <4E16ACA0.9090703@stroeder.com> Jeff Blaine wrote: > I'm clearly doing something wrong :) > > I don't see this addressed in the documentation or the > FAQ. > > I'm developing something. When I run it, the majority > of the time I get traceback ending in ldap.SUCCESS > instead of the expected output. Eventually, if I run > it enough times, it spits out my data instead of > ldap.SUCCESS Well, my crystal ball is blurry... ;-) It would certainly help if you provide a terse example script which implements the "something" and showing the behaviour you described above. It's also interesting which versions of python-ldap and OpenLDAP you're running and whether you compiled from source or using a pre-compiled package. Ciao, Michael. From jblaine at kickflop.net Fri Jul 8 15:03:01 2011 From: jblaine at kickflop.net (Jeff Blaine) Date: Fri, 08 Jul 2011 09:03:01 -0400 Subject: [python-ldap] ldap.SUCCESS sometimes, the results other times In-Reply-To: <4E16ACA0.9090703@stroeder.com> References: <4E161954.40607@kickflop.net> <4E16ACA0.9090703@stroeder.com> Message-ID: <4E170005.7090004@kickflop.net> On 7/8/2011 3:07 AM, Michael Str?der wrote: > Jeff Blaine wrote: >> I'm clearly doing something wrong :) >> >> I don't see this addressed in the documentation or the >> FAQ. >> >> I'm developing something. When I run it, the majority >> of the time I get traceback ending in ldap.SUCCESS >> instead of the expected output. Eventually, if I run >> it enough times, it spits out my data instead of >> ldap.SUCCESS > > Well, my crystal ball is blurry... ;-) Sorry, I just figured maybe it was an obvious thing that was easy to detect by a list member. I ended up figuring it out a few hours after posting. I was using search instead of search_s, so was seeing the asynchrony mostly instead of results every time. From michael at stroeder.com Fri Jul 8 15:30:20 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 08 Jul 2011 15:30:20 +0200 Subject: [python-ldap] ldap.SUCCESS sometimes, the results other times In-Reply-To: <4E170005.7090004@kickflop.net> References: <4E161954.40607@kickflop.net> <4E16ACA0.9090703@stroeder.com> <4E170005.7090004@kickflop.net> Message-ID: <4E17066C.8090700@stroeder.com> Jeff Blaine wrote: > On 7/8/2011 3:07 AM, Michael Str?der wrote: >> Jeff Blaine wrote: >>> I'm clearly doing something wrong :) >>> >>> I don't see this addressed in the documentation or the >>> FAQ. >>> >>> I'm developing something. When I run it, the majority >>> of the time I get traceback ending in ldap.SUCCESS >>> instead of the expected output. Eventually, if I run >>> it enough times, it spits out my data instead of >>> ldap.SUCCESS >> >> Well, my crystal ball is blurry... ;-) > > Sorry, I just figured maybe it was an obvious thing > that was easy to detect by a list member. > > I ended up figuring it out a few hours after posting. > > I was using search instead of search_s, so was seeing > the asynchrony mostly instead of results every time. Ah, yes. Feel free to submit text for the FAQ... ;-) Ciao, Michael. From stefanik at dscon.sk Tue Jul 12 12:36:49 2011 From: stefanik at dscon.sk (Dusan Stefanik) Date: Tue, 12 Jul 2011 12:36:49 +0200 Subject: [python-ldap] ReconnectLDAPObject not working properly? In-Reply-To: <4E155EF4.2060001@stroeder.com> References: <20110706144654.GB27307@portos> <4E14A36D.7050904@stroeder.com> <20110707045204.GB30587@portos> <4E155EF4.2060001@stroeder.com> Message-ID: <20110712103649.GD4598@portos> Thanks for explain. You have right. ReconnectObject not working without binding. I change my code to accept this behaviour and it works. Dusan On 07/07/11 at 09:23am, Michael Str?der wrote: > Dusan Stefanik wrote: > > What calling code? My code has 3 lines in python interpreter. > > import ldap > > l = ldap.ldapobject.ReconnectLDAPObject('ldap://172.16.2.1:389/',trace_level=1,retry_max=3) > > l.search_s("o=test",ldap.SCOPE_BASE,"objectclass=*") > > Well, with such a short code you cannot reliably test this. The reason is the > behaviour of the OpenLDAP C libs which looks strange at first glance. > > Background: > The OpenLDAP function ldap_initialize() and its counterpart _ldap.initialize() > in the Python extension module does *nothing* on the wire. It just initializes > the LDAP connection struct in the C API. The first call to an operation method > (bind, search etc.) really opens the connection. > > ReconnectLDAPObject relys on the information of an already *successfully* > opened connection and bound LDAP association. It was never intended to be a > convenience wrapper for your application loop. The main goal was to let > *synchronous* methods retry to get through in case of short-time server > failure. If the connection wasn't ever really openend it does not *reconnect* > since there was never a connection and bind before and therefore IMHO there's > no meaningful behaviour (think of connect and bind and already the bind fails > with ldap.SERVER_DOWN). > > But in any case your application has to handle ldap.SERVER_DOWN in a > reasonable way which can get very tricky depending on your application. > > So your test code should look like this: > > import ldap > l = ldap.ldapobject.ReconnectLDAPObject( > 'ldap://172.16.2.1:389', > trace_level=1, > retry_max=6 > ) > # really open the connection by sending BindRequest > l.simple_bind_s('','') > # now enough time to stop the LDAP server > sleep(10.0) > # send the SearchRequest > l.search_s("o=test",ldap.SCOPE_BASE,"objectclass=*") > > But I have to think about your corner-case above where you use an implicit > anonymous bind. Personally I never do this so it's not tested though it's > allowed in LDAPv3. Feel free to test that inspired by the information above > and please give feedback on that. > > Ciao, Michael. > From raj at csub.edu Tue Jul 12 21:49:50 2011 From: raj at csub.edu (Russell Jackson) Date: Tue, 12 Jul 2011 12:49:50 -0700 Subject: [python-ldap] ldap.SUCCESS sometimes, the results other times In-Reply-To: <4E170005.7090004@kickflop.net> References: <4E161954.40607@kickflop.net> <4E16ACA0.9090703@stroeder.com> <4E170005.7090004@kickflop.net> Message-ID: <4E1CA55E.2000602@csub.edu> On 07/08/2011 06:03 AM, Jeff Blaine wrote: > On 7/8/2011 3:07 AM, Michael Str?der wrote: >> Jeff Blaine wrote: >>> I'm clearly doing something wrong :) >>> >>> I don't see this addressed in the documentation or the >>> FAQ. >>> >>> I'm developing something. When I run it, the majority >>> of the time I get traceback ending in ldap.SUCCESS >>> instead of the expected output. Eventually, if I run >>> it enough times, it spits out my data instead of >>> ldap.SUCCESS >> >> Well, my crystal ball is blurry... ;-) > > Sorry, I just figured maybe it was an obvious thing > that was easy to detect by a list member. > > I ended up figuring it out a few hours after posting. > > I was using search instead of search_s, so was seeing > the asynchrony mostly instead of results every time. I see this only very sporadically from a batch job that runs from cron every 5 minutes. Because it's so sporadic, I've never tried very hard to figure it out. In this case, I can't find anywhere that I've mistakenly called the non-synchronous variant of the search method. Is there any other reason why this exception would be thrown? -- Russell A Jackson Network Analyst California State University, Bakersfield From michael at stroeder.com Wed Jul 13 08:32:12 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 13 Jul 2011 08:32:12 +0200 Subject: [python-ldap] ldap.SUCCESS sometimes, the results other times In-Reply-To: <4E1CA55E.2000602@csub.edu> References: <4E161954.40607@kickflop.net> <4E16ACA0.9090703@stroeder.com> <4E170005.7090004@kickflop.net> <4E1CA55E.2000602@csub.edu> Message-ID: <4E1D3BEC.2080706@stroeder.com> Russell Jackson wrote: > On 07/08/2011 06:03 AM, Jeff Blaine wrote: >> On 7/8/2011 3:07 AM, Michael Str?der wrote: >>> Jeff Blaine wrote: >>>> I'm clearly doing something wrong :) >>>> >>>> I don't see this addressed in the documentation or the >>>> FAQ. >>>> >>>> I'm developing something. When I run it, the majority >>>> of the time I get traceback ending in ldap.SUCCESS >>>> instead of the expected output. Eventually, if I run >>>> it enough times, it spits out my data instead of >>>> ldap.SUCCESS >>> >>> Well, my crystal ball is blurry... ;-) >> >> Sorry, I just figured maybe it was an obvious thing >> that was easy to detect by a list member. >> >> I ended up figuring it out a few hours after posting. >> >> I was using search instead of search_s, so was seeing >> the asynchrony mostly instead of results every time. > > I see this only very sporadically from a batch job that runs from cron every 5 > minutes. Because it's so sporadic, I've never tried very hard to figure it out. > > In this case, I can't find anywhere that I've mistakenly called the > non-synchronous variant of the search method. Is there any other reason why > this exception would be thrown? I'd use trace_level>=1 to find out more. Ciao, Michael. From fabrante at yahoo.com Mon Jul 18 10:22:45 2011 From: fabrante at yahoo.com (Francis Abrante) Date: Mon, 18 Jul 2011 01:22:45 -0700 (PDT) Subject: [python-ldap] problems using import ldap In-Reply-To: <1310569125.6317.YahooMailClassic@web39602.mail.mud.yahoo.com> Message-ID: <1310977365.72787.YahooMailClassic@web39608.mail.mud.yahoo.com> Hi I already install the openldap and the python-ldap but I can't use the library, I don't know where is or how to add it in my pycharm. I am working locally and I have ubuntu, also I did the python-ldap installation with apt-get (but I don't know where are the files) Thanks in advance Francis -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Mon Jul 18 20:31:17 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 18 Jul 2011 20:31:17 +0200 Subject: [python-ldap] problems using import ldap In-Reply-To: <1310977365.72787.YahooMailClassic@web39608.mail.mud.yahoo.com> References: <1310977365.72787.YahooMailClassic@web39608.mail.mud.yahoo.com> Message-ID: <4E247BF5.7050307@stroeder.com> Francis Abrante wrote: > I already install the openldap and the python-ldap but I can't use the > library, I don't know where is or how to add it in my pycharm. I am > working locally and I have ubuntu, also I did the python-ldap installation > with apt-get (but I don't know where are the files) What does python -c "import ldap;print ldap.__version__" say? Ciao, Michael. From michael at stroeder.com Tue Jul 19 10:42:20 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 19 Jul 2011 10:42:20 +0200 Subject: [python-ldap] problems using import ldap In-Reply-To: <1311063088.35420.YahooMailClassic@web39605.mail.mud.yahoo.com> References: <1311063088.35420.YahooMailClassic@web39605.mail.mud.yahoo.com> Message-ID: <4E25436C.3080807@stroeder.com> Francis, please always follow-up on the mailing list (cc:-ed). Unfortunately you also do not provide any information needed to help you. Francis Abrante wrote: > this is the output > > Thanks > > orbac at orbac-desktop:~$ python -c "import ldap;print ldap.__version__" > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named ldap So how did you install python-ldap? If you're using a pre-packaged version of python-ldap found in Ubuntu the command above should simply work - provided you're using the right Python interpreter. If you decide to build and install python-ldap yourself then you should follow the instructions here: http://www.python-ldap.org/doc/html/installing.html Ciao, Michael. From esiotrot at gmail.com Tue Jul 19 10:53:02 2011 From: esiotrot at gmail.com (Michael Wood) Date: Tue, 19 Jul 2011 10:53:02 +0200 Subject: [python-ldap] problems using import ldap In-Reply-To: <4E25436C.3080807@stroeder.com> References: <1311063088.35420.YahooMailClassic@web39605.mail.mud.yahoo.com> <4E25436C.3080807@stroeder.com> Message-ID: Hi 2011/7/19 Michael Str?der : > Francis, > > please always follow-up on the mailing list (cc:-ed). > > Unfortunately you also do not provide any information needed to help you. > > Francis Abrante wrote: >> this is the output >> >> Thanks >> >> orbac at orbac-desktop:~$ python -c "import ldap;print ldap.__version__" >> Traceback (most recent call last): >> ? File "", line 1, in >> ImportError: No module named ldap > > So how did you install python-ldap? If you're using a pre-packaged version of > python-ldap found in Ubuntu the command above should simply work - provided > you're using the right Python interpreter. In his initial post he said: "I did the python-ldap installation with apt-get" so I agree that should "just work". > If you decide to build and install python-ldap yourself then you should follow > the instructions here: > > http://www.python-ldap.org/doc/html/installing.html I think it would be better to get the version installed via apt-get to work than to install it manually. Francis, what do the following commands give you? $ dpkg -l python-ldap $ dpkg -l 'python[23]*' | grep ^i $ which python $ ls -l $(which python) $ ls -l /usr/bin/python $ lsb_release -a -- Michael Wood From michael at stroeder.com Tue Jul 19 10:56:01 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 19 Jul 2011 10:56:01 +0200 Subject: [python-ldap] problems using import ldap In-Reply-To: <4E25436C.3080807@stroeder.com> References: <1311063088.35420.YahooMailClassic@web39605.mail.mud.yahoo.com> <4E25436C.3080807@stroeder.com> Message-ID: <4E2546A1.7080102@stroeder.com> And if anyone is curious *where* Python modules get installed by DistUtils: http://docs.python.org/install/index.html#how-installation-works Ciao, Michael. From fabrante at yahoo.com Tue Jul 19 13:34:16 2011 From: fabrante at yahoo.com (Francis Abrante) Date: Tue, 19 Jul 2011 04:34:16 -0700 (PDT) Subject: [python-ldap] problems using import ldap In-Reply-To: Message-ID: <1311075256.39011.YahooMailClassic@web39606.mail.mud.yahoo.com> Hi I executed the commands: orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ dpkg -l python-ldap Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name?????????? Version??????? Description +++-==============-==============-============================================ ii? python-ldap??? 2.3.10-1ubuntu LDAP interface module for Python orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ dpkg -l 'python[23]*' | grep ^i ii? python2.6??????????????????????????? 2.6.5-1ubuntu6????????????????????????????????? An interactive high-level object-oriented la ii? python2.6-dbg??????????????????????? 2.6.5-1ubuntu6????????????????????????????????? Debug Build of the Python Interpreter (versi ii? python2.6-minimal??????????????????? 2.6.5-1ubuntu6????????????????????????????????? A minimal subset of the Python language (ver orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ which python /usr/local/bin/python orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ ls -l $(which python) -rwxr-xr-x 2 root root 4362121 2011-07-04 16:43 /usr/local/bin/python orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ ls -l /usr/bin/python lrwxrwxrwx 1 root root 9 2011-05-25 11:04 /usr/bin/python -> python2.6 orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ lsb_release -a No LSB modules are available. Distributor ID:??? Ubuntu Description:??? Ubuntu 10.04.2 LTS Release:??? 10.04 Codename:??? lucid Thanks for your help --- El mar, 7/19/11, Michael Wood escribi?: De: Michael Wood Asunto: Re: [python-ldap] problems using import ldap A: "Michael Str?der" Cc: "Francis Abrante" , python-ldap at python.org Fecha: martes, 19 de julio de 2011, 05:53 am Hi 2011/7/19 Michael Str?der : > Francis, > > please always follow-up on the mailing list (cc:-ed). > > Unfortunately you also do not provide any information needed to help you. > > Francis Abrante wrote: >> this is the output >> >> Thanks >> >> orbac at orbac-desktop:~$ python -c "import ldap;print ldap.__version__" >> Traceback (most recent call last): >> ? File "", line 1, in >> ImportError: No module named ldap > > So how did you install python-ldap? If you're using a pre-packaged version of > python-ldap found in Ubuntu the command above should simply work - provided > you're using the right Python interpreter. In his initial post he said: "I did the python-ldap installation with apt-get" so I agree that should "just work". > If you decide to build and install python-ldap yourself then you should follow > the instructions here: > > http://www.python-ldap.org/doc/html/installing.html I think it would be better to get the version installed via apt-get to work than to install it manually. Francis, what do the following commands give you? $ dpkg -l python-ldap $ dpkg -l 'python[23]*' | grep ^i $ which python $ ls -l $(which python) $ ls -l /usr/bin/python $ lsb_release -a -- Michael Wood -------------- next part -------------- An HTML attachment was scrubbed... URL: From esiotrot at gmail.com Tue Jul 19 13:55:43 2011 From: esiotrot at gmail.com (Michael Wood) Date: Tue, 19 Jul 2011 13:55:43 +0200 Subject: [python-ldap] problems using import ldap In-Reply-To: <1311075256.39011.YahooMailClassic@web39606.mail.mud.yahoo.com> References: <1311075256.39011.YahooMailClassic@web39606.mail.mud.yahoo.com> Message-ID: On 19 July 2011 13:34, Francis Abrante wrote: > > Hi > > I executed the commands: > > orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ dpkg -l python-ldap OK, so it looks like you might have been trying to install python-ldap 2.4 manually as well. It might confuse the issue if you have two different versions installed. > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name?????????? Version??????? Description > +++-==============-==============-============================================ > ii? python-ldap??? 2.3.10-1ubuntu LDAP interface module for Python OK, so python-ldap 2.3.10 is installed via apt-get. > orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ dpkg -l 'python[23]*' | grep ^i > ii? python2.6??????????????????????????? 2.6.5-1ubuntu6????????????????????????????????? An interactive high-level object-oriented la and you have Python 2.6 installed via apt-get too (well, it came pre-installed). > ii? python2.6-dbg??????????????????????? 2.6.5-1ubuntu6????????????????????????????????? Debug Build of the Python Interpreter (versi > ii? python2.6-minimal??????????????????? 2.6.5-1ubuntu6????????????????????????????????? A minimal subset of the Python language (ver > > > orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ which python > /usr/local/bin/python Aha! So you have another installation of Python on your system and it's not the one that runs when you type: $ python I suspect this has something to do with "pycharm" which you mentioned in your first message. I am not familiar with pycharm, though. If this rogue installation of python is because of pycharm, you might want to ask the pycharm developers about your problem with getting python-ldap to work. What does this say: $ /usr/bin/python -c "import ldap;print ldap.__version__" Also: $ python --version > orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ ls -l $(which python) > -rwxr-xr-x 2 root root 4362121 2011-07-04 16:43 /usr/local/bin/python > > > orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ ls -l /usr/bin/python > lrwxrwxrwx 1 root root 9 2011-05-25 11:04 /usr/bin/python -> python2.6 OK, so the "proper" installation of python is version 2.6 and it hasn't been symlinked to somewhere else. > orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ lsb_release -a > No LSB modules are available. > Distributor ID:??? Ubuntu > Description:??? Ubuntu 10.04.2 LTS > Release:??? 10.04 > Codename:??? lucid > > > Thanks for your help No problem. But I think the pycharm developers/mailing list/forum/whatever might be a better place to ask your question. -- Michael Wood From esiotrot at gmail.com Tue Jul 19 13:58:21 2011 From: esiotrot at gmail.com (Michael Wood) Date: Tue, 19 Jul 2011 13:58:21 +0200 Subject: [python-ldap] problems using import ldap In-Reply-To: References: <1311075256.39011.YahooMailClassic@web39606.mail.mud.yahoo.com> Message-ID: On 19 July 2011 13:55, Michael Wood wrote: > On 19 July 2011 13:34, Francis Abrante wrote: [...] >> orbac at orbac-desktop:~/python-ldap/python-ldap-2.4.0$ which python >> /usr/local/bin/python > > Aha! ?So you have another installation of Python on your system and > it's not the one that runs when you type: > > $ python I mean that it *is* the one that runs when you type "python". This is why the command Michael Stroeder asked you to type did not work. -- Michael Wood From fabrante at yahoo.com Tue Jul 19 14:07:09 2011 From: fabrante at yahoo.com (Francis Abrante) Date: Tue, 19 Jul 2011 05:07:09 -0700 (PDT) Subject: [python-ldap] problems using import ldap In-Reply-To: Message-ID: <1311077229.76236.YahooMailClassic@web39603.mail.mud.yahoo.com> Hi again I tried to uninstall and install the package and doesn't work either. root at orbac-desktop:~/python-ldap/python-ldap-2.4.0# apt-get install python-ldap Reading package lists... Done Building dependency tree?????? Reading state information... Done python-ldap is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. root at orbac-desktop:~/python-ldap/python-ldap-2.4.0# apt-get remove python-ldap Reading package lists... Done Building dependency tree?????? Reading state information... Done The following packages will be REMOVED: ? python-ldap 0 upgraded, 0 newly installed, 1 to remove and 2 not upgraded. After this operation, 352kB disk space will be freed. Do you want to continue [Y/n]? y (Reading database ... 150730 files and directories currently installed.) Removing python-ldap ... root at orbac-desktop:~/python-ldap/python-ldap-2.4.0# apt-get install python-ldapReading package lists... Done Building dependency tree?????? Reading state information... Done Suggested packages: ? python-ldap-doc The following NEW packages will be installed: ? python-ldap 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded. Need to get 0B/75.2kB of archives. After this operation, 352kB of additional disk space will be used. Selecting previously deselected package python-ldap. (Reading database ... 150683 files and directories currently installed.) Unpacking python-ldap (from .../python-ldap_2.3.10-1ubuntu1_i386.deb) ... Setting up python-ldap (2.3.10-1ubuntu1) ... Processing triggers for python-central ... root at orbac-desktop:~/python-ldap/python-ldap-2.4.0# python -c "import ldap;print ldap.__version__" Traceback (most recent call last): ? File "", line 1, in ImportError: No module named ldap --- El mar, 7/19/11, Michael Wood escribi?: De: Michael Wood Asunto: Re: [python-ldap] problems using import ldap A: "Michael Str?der" Cc: "Francis Abrante" , python-ldap at python.org Fecha: martes, 19 de julio de 2011, 05:53 am Hi 2011/7/19 Michael Str?der : > Francis, > > please always follow-up on the mailing list (cc:-ed). > > Unfortunately you also do not provide any information needed to help you. > > Francis Abrante wrote: >> this is the output >> >> Thanks >> >> orbac at orbac-desktop:~$ python -c "import ldap;print ldap.__version__" >> Traceback (most recent call last): >> ? File "", line 1, in >> ImportError: No module named ldap > > So how did you install python-ldap? If you're using a pre-packaged version of > python-ldap found in Ubuntu the command above should simply work - provided > you're using the right Python interpreter. In his initial post he said: "I did the python-ldap installation with apt-get" so I agree that should "just work". > If you decide to build and install python-ldap yourself then you should follow > the instructions here: > > http://www.python-ldap.org/doc/html/installing.html I think it would be better to get the version installed via apt-get to work than to install it manually. Francis, what do the following commands give you? $ dpkg -l python-ldap $ dpkg -l 'python[23]*' | grep ^i $ which python $ ls -l $(which python) $ ls -l /usr/bin/python $ lsb_release -a -- Michael Wood -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Tue Jul 19 14:16:34 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 19 Jul 2011 14:16:34 +0200 Subject: [python-ldap] problems using import ldap In-Reply-To: <1311077229.76236.YahooMailClassic@web39603.mail.mud.yahoo.com> References: <1311077229.76236.YahooMailClassic@web39603.mail.mud.yahoo.com> Message-ID: <4E2575A2.50708@stroeder.com> Francis Abrante wrote: > root at orbac-desktop:~/python-ldap/python-ldap-2.4.0# python -c "import > ldap;print ldap.__version__" > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named ldap Please read the Python docs at the link I've already posted: http://www.python-ldap.org/doc/html/installing.html Especially find out which Python interpreter you're environment is really using. Then type ? /path/to/python -c "import sys;print sys.prefix;print sys.exec_prefix" /usr /usr where /path/to is the full path to the Python interpreter executable you're trying to use. See the docs above how that helps to find out where modules get installed. Similar when building/installing from source /path/to/python setup.py install has to be invoked to install python-ldap (like all other DistUtils-based Python modules). Ciao, Michael. From esiotrot at gmail.com Tue Jul 19 14:35:16 2011 From: esiotrot at gmail.com (Michael Wood) Date: Tue, 19 Jul 2011 14:35:16 +0200 Subject: [python-ldap] problems using import ldap In-Reply-To: <1311077229.76236.YahooMailClassic@web39603.mail.mud.yahoo.com> References: <1311077229.76236.YahooMailClassic@web39603.mail.mud.yahoo.com> Message-ID: On 19 July 2011 14:07, Francis Abrante wrote: > > Hi again > > I tried to uninstall and install the package and doesn't work either. > > root at orbac-desktop:~/python-ldap/python-ldap-2.4.0# apt-get install python-ldap > Reading package lists... Done > Building dependency tree > Reading state information... Done > python-ldap is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. That's because it is already correctly installed. The problem is not with the python-ldap package, but rather with your non-standard installation of Python (/usr/local/bin/python), which as I said I suspect has something to do with "pycharm", with which I am unfamiliar. [...] > root at orbac-desktop:~/python-ldap/python-ldap-2.4.0# python -c "import ldap;print ldap.__version__" > Traceback (most recent call last): > ? File "", line 1, in > ImportError: No module named ldap You did not correctly follow my instructions. I said you should try: $ /usr/bin/python -c "import ldap;print ldap.__version__" and not just: $ python -c "import ldap;print ldap.__version__" And I still think pycharm is what's causing this to not just work out of the box. So you might want to contact them rather. -- Michael Wood From michael at stroeder.com Fri Jul 22 10:35:23 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 22 Jul 2011 10:35:23 +0200 Subject: [python-ldap] Plans for 2.4.3: documentation! Message-ID: <4E29364B.6020500@stroeder.com> HI! There are various small modules in python-ldap which are not documented and the rst-markup was a historically grown/converted mess in various parts. So I've started cleaning up Doc/ a little bit. My plan is to focus on documentation for release 2.4.3. Why not just writing the docs for 2.4.2? It turned out that some classes for which .. autoclass:: is used in the .rst file do not have proper doc strings. As usual your input is welcome. Stay tuned to CVS HEAD, contribute doc-related patches or at least review. Ciao, Michael. From michael at stroeder.com Fri Jul 22 16:26:37 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 22 Jul 2011 16:26:37 +0200 Subject: [python-ldap] Plans for 2.4.3: documentation! In-Reply-To: <4E29364B.6020500@stroeder.com> References: <4E29364B.6020500@stroeder.com> Message-ID: <4E29889D.3040903@stroeder.com> Michael Str?der wrote: > There are various small modules in python-ldap which are not documented and > the rst-markup was a historically grown/converted mess in various parts. So > I've started cleaning up Doc/ a little bit. > My plan is to focus on documentation for release 2.4.3. > > Why not just writing the docs for 2.4.2? > It turned out that some classes for which > .. autoclass:: > is used in the .rst file do not have proper doc strings. > > As usual your input is welcome. Stay tuned to CVS HEAD, contribute doc-related > patches or at least review. First draft is online because otherwise nobody takes note of it: http://www.python-ldap.org/doc/html/index.html Ideally you could provide doc patches... ;-) Ciao, Michael. From michael at stroeder.com Sat Jul 23 15:23:38 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 23 Jul 2011 15:23:38 +0200 Subject: [python-ldap] ANN: python-ldap 2.4.3 Message-ID: <4E2ACB5A.2010303@stroeder.com> Find a new release of python-ldap: http://pypi.python.org/pypi/python-ldap/2.4.3 python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). Project's web site: http://www.python-ldap.org/ Ciao, Michael. ---------------------------------------------------------------- Released 2.4.3 2011-07-23 Changes since 2.4.2: Lib/ * Mostly corrected/updated __doc__ strings Doc: * Corrected rst files * Added missing modules, functions, classes, methods, parameters etc. at least as auto-generated doc ---------------------------------------------------------------- Released 2.4.2 2011-07-21 Changes since 2.4.1: Lib/ Logging: * pprint.pformat() is now used when writing method/function arguments to the trace log ldap.schema.subentry: * SubSchema.__init__() now has new key-word argument check_uniqueness which enables checking whether OIDs are unique in the subschema subentry * Code-cleaning: consequent use of method SubSchema.getoid() instead of accessing SubSchema.name2oid directly. * SubSchema.getoid() and SubSchema.getoid() now have key-word argument raise_keyerror=0 and raise KeyError with appropriate description. From mailinglist0 at skurfer.com Mon Jul 25 17:04:30 2011 From: mailinglist0 at skurfer.com (Rob McBroom) Date: Mon, 25 Jul 2011 11:04:30 -0400 Subject: [python-ldap] Mac OS X 10.7 (Lion) Message-ID: Has anyone gotten python-ldap working under Lion? It seems to install, but I'm not able to use it. Here's a transcript of the installation (using `easy_install`): % sudo easy_install python-ldap Searching for python-ldap Reading http://pypi.python.org/simple/python-ldap/ Reading http://www.python-ldap.org/ Best match: python-ldap 2.4.3 Downloading http://pypi.python.org/packages/source/p/python-ldap/python-ldap-2.4.3.tar.gz#md5=772cba8e066cd1404ffb90d16efd5dde Processing python-ldap-2.4.3.tar.gz Running python-ldap-2.4.3/setup.py -q bdist_egg --dist-dir /tmp/easy_install-oEHkiA/python-ldap-2.4.3/egg-dist-tmp-Mn7xZF extra_compile_args: -g extra_objects: include_dirs: /opt/openldap-RE24/include /usr/include/sasl library_dirs: /opt/openldap-RE24/lib libs: ldap_r lber sasl2 ssl crypto file Lib/ldap.py (for module ldap) not found file Lib/ldap/controls.py (for module ldap.controls) not found file Lib/ldap/extop.py (for module ldap.extop) not found file Lib/ldap/schema.py (for module ldap.schema) not found warning: no files found matching 'Makefile' warning: no files found matching 'Modules/LICENSE' file Lib/ldap.py (for module ldap) not found file Lib/ldap/controls.py (for module ldap.controls) not found file Lib/ldap/extop.py (for module ldap.extop) 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/controls.py (for module ldap.controls) not found file Lib/ldap/extop.py (for module ldap.extop) not found file Lib/ldap/schema.py (for module ldap.schema) not found In file included from Modules/LDAPObject.c:18: /usr/include/sasl/sasl.h:347: warning: function declaration isn?t a prototype In file included from Modules/LDAPObject.c:18: /usr/include/sasl/sasl.h:347: warning: function declaration isn?t a prototype Modules/LDAPObject.c: In function ?interaction?: Modules/LDAPObject.c:581: warning: implicit conversion shortens 64-bit value into a 32-bit value Modules/options.c: In function ?set_timeval_from_double?: Modules/options.c:12: warning: implicit conversion shortens 64-bit value into a 32-bit value ld: warning: directory not found for option '-L/opt/openldap-RE24/lib' ld: warning: directory not found for option '-L/opt/openldap-RE24/lib' ld: warning: directory not found for option '-L/opt/openldap-RE24/lib' ld: warning: directory not found for option '-L/opt/openldap-RE24/lib' Adding python-ldap 2.4.3 to easy-install.pth file Installed /Library/Python/2.7/site-packages/python_ldap-2.4.3-py2.7-macosx-10.7-intel.egg Processing dependencies for python-ldap Finished processing dependencies for python-ldap If I try to import it, I get: % python -c "import ldap" Traceback (most recent call last): File "", line 1, in File "/Library/Python/2.7/site-packages/python_ldap-2.4.3-py2.7-macosx-10.7-intel.egg/ldap/__init__.py", line 22, in from _ldap import * ImportError: dlopen(/Library/Python/2.7/site-packages/python_ldap-2.4.3-py2.7-macosx-10.7-intel.egg/_ldap.so, 2): Symbol not found: _ldap_create_assertion_control_value Referenced from: /Library/Python/2.7/site-packages/python_ldap-2.4.3-py2.7-macosx-10.7-intel.egg/_ldap.so Expected in: flat namespace in /Library/Python/2.7/site-packages/python_ldap-2.4.3-py2.7-macosx-10.7-intel.egg/_ldap.so The errors referencing `/opt/openldap-RE24/lib` seemed odd, so I tried getting the source and changing library_dirs and include_dirs in setup.cfg, then running python setup.py build sudo python setup.py install but the error is the same. Any ideas? Thanks. -- Rob McBroom From cmikk at qwest.net Wed Jul 27 23:50:25 2011 From: cmikk at qwest.net (Chris Mikkelson) Date: Wed, 27 Jul 2011 16:50:25 -0500 Subject: [python-ldap] LDAP Sync (RFC 4533) support Message-ID: <20110727215025.GA11995@uerige.oss.uswest.net> The attached patch against python-ldap 2.4.3 adds a new sub-module 'ldap.syncrepl' which implements an RFC 4533 replication client. It also requires the patch to Modules/message.c Michael just committed. Since the sync replication protocol is moderately complicated, the primary API exposed by this module is a base class which inherits from LDAPObject and adds a few syncrepl-specific methods: syncrepl_search - wrapper around search_ext which creates and adds the SyncRequest control syncrepl_poll - processes the responses to the syncrepl_search operation, and calls various handler methods. A subclass my provide handler methods for: * storing and retrieving the sync cookie (syncrepl_set_cookie and syncrepl_get_cookie) * adding or modifying entries (syncrepl_entry) * deleting entries (syncrepl_delete) * handling presentation operations (syncrepl_present) The API works well enough for my purposes, but I'd appreciate feedback and comments on it. -- Chris Mikkelson | Disclaimer: the plural of "anecdote" is not "data." cmikk at qwest.net | -- spencer at engin.umich.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: ldap.syncrepl.patch Type: text/x-diff Size: 18090 bytes Desc: not available URL: From raj at csub.edu Thu Jul 28 01:16:18 2011 From: raj at csub.edu (Russell Jackson) Date: Wed, 27 Jul 2011 16:16:18 -0700 Subject: [python-ldap] LDAP Sync (RFC 4533) support In-Reply-To: <20110727215025.GA11995@uerige.oss.uswest.net> References: <20110727215025.GA11995@uerige.oss.uswest.net> Message-ID: <4E309C42.2050700@csub.edu> On Wed 27 Jul 2011 02:50:25 PM PDT, Chris Mikkelson wrote: > The attached patch against python-ldap 2.4.3 adds a new > sub-module 'ldap.syncrepl' which implements an RFC 4533 > replication client. It also requires the patch to > Modules/message.c Michael just committed. > > Since the sync replication protocol is moderately > complicated, the primary API exposed by this module is a > base class which inherits from LDAPObject and adds a few > syncrepl-specific methods: > > syncrepl_search - wrapper around search_ext which > creates and adds the SyncRequest control > > syncrepl_poll - processes the responses to the syncrepl_search > operation, and calls various handler methods. > > A subclass my provide handler methods for: > > * storing and retrieving the sync cookie (syncrepl_set_cookie > and syncrepl_get_cookie) > > * adding or modifying entries (syncrepl_entry) > > * deleting entries (syncrepl_delete) > > * handling presentation operations (syncrepl_present) > > The API works well enough for my purposes, but I'd > appreciate feedback and comments on it. > Awesome. Now I can get rid of my auditlog trigger contraption -- Russell A Jackson Network Analyst California State University, Bakersfield From michael at stroeder.com Thu Jul 28 09:01:55 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 28 Jul 2011 09:01:55 +0200 Subject: [python-ldap] LDAP Sync (RFC 4533) support In-Reply-To: <20110727215025.GA11995@uerige.oss.uswest.net> References: <20110727215025.GA11995@uerige.oss.uswest.net> Message-ID: <4E310963.7000903@stroeder.com> Chris Mikkelson wrote: > replication client. It also requires the patch to > Modules/message.c Michael just committed. I have to review that again. Maybe the 3-tuple vs. 4-tuple thing should be fixed in LDAPObject.result4(). I will do that during the day... > Since the sync replication protocol is moderately > complicated, the primary API exposed by this module is a > base class which inherits from LDAPObject How about implementing it as a mix-in class like ldap.resiter.ResultProcessor? Then one can use it together with ReconnectLDAPObject or any other class derived from LDAPObject. http://www.python-ldap.org/doc/html/ldap-resiter.html If you don't mind I will change your patch. Especially it would be nice if one could use ldap.resiter.ResultProcessor (result processing generator class) together with syncrepl. Ciao, Michael. From fabrante at yahoo.com Thu Jul 28 10:25:02 2011 From: fabrante at yahoo.com (Francis Abrante) Date: Thu, 28 Jul 2011 01:25:02 -0700 (PDT) Subject: [python-ldap] problems using import ldap In-Reply-To: References: <1311077229.76236.YahooMailClassic@web39603.mail.mud.yahoo.com> Message-ID: <1311841502.20742.YahooMailNeo@web39601.mail.mud.yahoo.com> Hi I still have problems, but I think that my problem come from the library version. I don't know from where I can get the egg version for python 2.7. From??? http://svn.kmrc.de/download/distribution/contrib/? only allow me until 2.6? /usr/local/bin/python2.7 /home/orbac/TSP-CloudStack/src/it/tsp/cloudstack/orbac/LDAP Agent/get_info.py Traceback (most recent call last): ? File "/home/orbac/TSP-CloudStack/src/it/tsp/cloudstack/orbac/LDAP Agent/get_info.py", line 1, in ??? import ldap ? File "/usr/local/lib/python2.7/site-packages/python_ldap-2.3.9-py2.6-linux-x86_64.egg/ldap/__init__.py", line 22, in ??? from _ldap import * ImportError: /usr/local/lib/python2.7/site-packages/python_ldap-2.3.9-py2.6-linux-x86_64.egg/_ldap.so: wrong ELF class: ELFCLASS64 Process finished with exit code 1 By the way: orbac at orbac-desktop:~/python-ldap$ /usr/bin/python -c "import ldap;print ldap.__version__" 2.3.10 Thanks. ________________________________ De: Michael Wood Para: Francis Abrante CC: Michael Str?der ; python-ldap at python.org Enviado: Martes, julio 19, 2011 2:35 P.M. Asunto: Re: [python-ldap] problems using import ldap On 19 July 2011 14:07, Francis Abrante wrote: > > Hi again > > I tried to uninstall and install the package and doesn't work either. > > root at orbac-desktop:~/python-ldap/python-ldap-2.4.0# apt-get install python-ldap > Reading package lists... Done > Building dependency tree > Reading state information... Done > python-ldap is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. That's because it is already correctly installed.? The problem is not with the python-ldap package, but rather with your non-standard installation of Python (/usr/local/bin/python), which as I said I suspect has something to do with "pycharm", with which I am unfamiliar. [...] > root at orbac-desktop:~/python-ldap/python-ldap-2.4.0# python -c "import ldap;print ldap.__version__" > Traceback (most recent call last): > ? File "", line 1, in > ImportError: No module named ldap You did not correctly follow my instructions. I said you should try: $ /usr/bin/python -c "import ldap;print ldap.__version__" and not just: $ python -c "import ldap;print ldap.__version__" And I still think pycharm is what's causing this to not just work out of the box.? So you might want to contact them rather. -- Michael Wood -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabrante at yahoo.com Thu Jul 28 10:36:35 2011 From: fabrante at yahoo.com (Francis Abrante) Date: Thu, 28 Jul 2011 01:36:35 -0700 (PDT) Subject: [python-ldap] problems using import ldap---library In-Reply-To: <1311841502.20742.YahooMailNeo@web39601.mail.mud.yahoo.com> References: <1311077229.76236.YahooMailClassic@web39603.mail.mud.yahoo.com> <1311841502.20742.YahooMailNeo@web39601.mail.mud.yahoo.com> Message-ID: <1311842195.11810.YahooMailNeo@web39607.mail.mud.yahoo.com> Hi I think that this is the version that I need, but I cannot found it. python_ldap-2.4.0-py2.7-linux-x86_64.egg ________________________________ De: Francis Abrante Para: Michael Wood CC: Michael Str?der ; "python-ldap at python.org" Enviado: Jueves, julio 28, 2011 10:25 A.M. Asunto: Re: [python-ldap] problems using import ldap Hi I still have problems, but I think that my problem come from the library version. I don't know from where I can get the egg version for python 2.7. From??? http://svn.kmrc.de/download/distribution/contrib/? only allow me until 2.6? /usr/local/bin/python2.7 /home/orbac/TSP-CloudStack/src/it/tsp/cloudstack/orbac/LDAP Agent/get_info.py Traceback (most recent call last): ? File "/home/orbac/TSP-CloudStack/src/it/tsp/cloudstack/orbac/LDAP Agent/get_info.py", line 1, in ??? import ldap ? File "/usr/local/lib/python2.7/site-packages/python_ldap-2.3.9-py2.6-linux-x86_64.egg/ldap/__init__.py", line 22, in ??? from _ldap import * ImportError: /usr/local/lib/python2.7/site-packages/python_ldap-2.3.9-py2.6-linux-x86_64.egg/_ldap.so: wrong ELF class: ELFCLASS64 Process finished with exit code 1 By the way: orbac at orbac-desktop:~/python-ldap$ /usr/bin/python -c "import ldap;print ldap.__version__" 2.3.10 Thanks. ________________________________ De: Michael Wood Para: Francis Abrante CC: Michael Str?der ; python-ldap at python.org Enviado: Martes, julio 19, 2011 2:35 P.M. Asunto: Re: [python-ldap] problems using import ldap On 19 July 2011 14:07, Francis Abrante wrote: > > Hi again > > I tried to uninstall and install the package and doesn't work either. > > root at orbac-desktop:~/python-ldap/python-ldap-2.4.0# apt-get install python-ldap > Reading package lists... Done > Building dependency tree > Reading state information... Done > python-ldap is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. That's because it is already correctly installed.? The problem is not with the python-ldap package, but rather with your non-standard installation of Python (/usr/local/bin/python), which as I said I suspect has something to do with "pycharm", with which I am unfamiliar. [...] > root at orbac-desktop:~/python-ldap/python-ldap-2.4.0# python -c "import ldap;print ldap.__version__" > Traceback (most recent call last): > ? File "", line 1, in > ImportError: No module named ldap You did not correctly follow my instructions. I said you should try: $ /usr/bin/python -c "import ldap;print ldap.__version__" and not just: $ python -c "import ldap;print ldap.__version__" And I still think pycharm is what's causing this to not just work out of the box.? So you might want to contact them rather. -- Michael Wood -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu Jul 28 10:39:44 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 28 Jul 2011 10:39:44 +0200 Subject: [python-ldap] problems using import ldap In-Reply-To: <1311841502.20742.YahooMailNeo@web39601.mail.mud.yahoo.com> References: <1311077229.76236.YahooMailClassic@web39603.mail.mud.yahoo.com> <1311841502.20742.YahooMailNeo@web39601.mail.mud.yahoo.com> Message-ID: <4E312050.1080402@stroeder.com> Francis Abrante wrote: > I still have problems, but I think that my problem come from the library > version. I don't know from where I can get the egg version for python 2.7. > From http://svn.kmrc.de/download/distribution/contrib/ only allow me until > 2.6 > > /usr/local/bin/python2.7 > /home/orbac/TSP-CloudStack/src/it/tsp/cloudstack/orbac/LDAP Agent/get_info.py > Traceback (most recent call last): > File "/home/orbac/TSP-CloudStack/src/it/tsp/cloudstack/orbac/LDAP > Agent/get_info.py", line 1, in > import ldap > File > "/usr/local/lib/python2.7/site-packages/python_ldap-2.3.9-py2.6-linux-x86_64.egg/ldap/__init__.py", > line 22, in > from _ldap import * > ImportError: > /usr/local/lib/python2.7/site-packages/python_ldap-2.3.9-py2.6-linux-x86_64.egg/_ldap.so: > wrong ELF class: ELFCLASS64 This rather sounds to me that you've compiled python-ldap for 64-bit platform but the Python interpreter you're using is a 32-bit build. It seems that to that you should really clean up your system. You're mixing build platforms, Python versions, python-ldap etc. That's a big mess. Especially you should read and understand about how DistUtils are working (the link I've posted before). Ciao, Michael. From fabrante at yahoo.com Thu Jul 28 13:24:23 2011 From: fabrante at yahoo.com (Francis Abrante) Date: Thu, 28 Jul 2011 04:24:23 -0700 (PDT) Subject: [python-ldap] problems using import ldap In-Reply-To: <4E312050.1080402@stroeder.com> References: <1311077229.76236.YahooMailClassic@web39603.mail.mud.yahoo.com> <1311841502.20742.YahooMailNeo@web39601.mail.mud.yahoo.com> <4E312050.1080402@stroeder.com> Message-ID: <1311852263.17111.YahooMailNeo@web39604.mail.mud.yahoo.com> Hi I already uninstall the other versions, but where can I get the library for 32 bits? python_ldap-2.4.0-py2.7 Thanks ________________________________ De: Michael Str?der Para: Francis Abrante CC: "python-ldap at python.org" Enviado: Jueves, julio 28, 2011 10:39 A.M. Asunto: Re: [python-ldap] problems using import ldap Francis Abrante wrote: > I still have problems, but I think that my problem come from the library > version. I don't know from where I can get the egg version for python 2.7. > From? ? http://svn.kmrc.de/download/distribution/contrib/? only allow me until > 2.6 > > /usr/local/bin/python2.7 > /home/orbac/TSP-CloudStack/src/it/tsp/cloudstack/orbac/LDAP Agent/get_info.py > Traceback (most recent call last): >? File "/home/orbac/TSP-CloudStack/src/it/tsp/cloudstack/orbac/LDAP > Agent/get_info.py", line 1, in >? ? import ldap >? File > "/usr/local/lib/python2.7/site-packages/python_ldap-2.3.9-py2.6-linux-x86_64.egg/ldap/__init__.py", > line 22, in >? ? from _ldap import * > ImportError: > /usr/local/lib/python2.7/site-packages/python_ldap-2.3.9-py2.6-linux-x86_64.egg/_ldap.so: > wrong ELF class: ELFCLASS64 This rather sounds to me that you've compiled python-ldap for 64-bit platform but the Python interpreter you're using is a 32-bit build. It seems that to that you should really clean up your system. You're mixing build platforms, Python versions, python-ldap etc. That's a big mess. Especially you should read and understand about how DistUtils are working (the link I've posted before). Ciao, Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu Jul 28 13:31:08 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 28 Jul 2011 13:31:08 +0200 Subject: [python-ldap] problems using import ldap In-Reply-To: <1311852263.17111.YahooMailNeo@web39604.mail.mud.yahoo.com> References: <1311077229.76236.YahooMailClassic@web39603.mail.mud.yahoo.com> <1311841502.20742.YahooMailNeo@web39601.mail.mud.yahoo.com> <4E312050.1080402@stroeder.com> <1311852263.17111.YahooMailNeo@web39604.mail.mud.yahoo.com> Message-ID: <4E31487C.3070904@stroeder.com> Francis Abrante wrote: > I already uninstall the other versions, but where can I get the library for 32 > bits? > > python_ldap-2.4.0-py2.7 Simply build and install python-ldap with the *very same* Python interpreter you're planning to use it with. (As you have been told in this thread several times...) Ciao, Michael. From mailinglist0 at skurfer.com Thu Jul 28 14:51:07 2011 From: mailinglist0 at skurfer.com (Rob McBroom) Date: Thu, 28 Jul 2011 08:51:07 -0400 Subject: [python-ldap] Mac OS X 10.7 (Lion) In-Reply-To: References: Message-ID: <36AAA4B9-80FE-4782-93ED-386C554BB19C@skurfer.com> On Jul 25, 2011, at 11:04 AM, Rob McBroom wrote: > Has anyone gotten python-ldap working under Lion? For the archives? The answer for now seems to be ?Use 2.3.13?. See http://stackoverflow.com/questions/6475118/python-ldap-os-x-10-6-and-python-2-6/ -- Rob McBroom From michael at stroeder.com Thu Jul 28 15:14:11 2011 From: michael at stroeder.com (=?windows-1252?Q?Michael_Str=F6der?=) Date: Thu, 28 Jul 2011 15:14:11 +0200 Subject: [python-ldap] Mac OS X 10.7 (Lion) In-Reply-To: <36AAA4B9-80FE-4782-93ED-386C554BB19C@skurfer.com> References: <36AAA4B9-80FE-4782-93ED-386C554BB19C@skurfer.com> Message-ID: <4E3160A3.4090508@stroeder.com> Rob McBroom wrote: > On Jul 25, 2011, at 11:04 AM, Rob McBroom wrote: > >> Has anyone gotten python-ldap working under Lion? > > For the archives? The answer for now seems to be ?Use 2.3.13?. > > See http://stackoverflow.com/questions/6475118/python-ldap-os-x-10-6-and-python-2-6/ As documented OpenLDAP libs 2.4.11 or newer are required to build and install python-ldap 2.4.x: http://www.python-ldap.org/doc/html/installing.html#prerequisites OpenLDAP 2.4.11 was released three years ago now (2008/07/16). Note that I won't maintain python-ldap 2.3.x anymore except important security updates. Ciao, Michael. From michael at stroeder.com Thu Jul 28 16:20:55 2011 From: michael at stroeder.com (=?windows-1252?Q?Michael_Str=F6der?=) Date: Thu, 28 Jul 2011 16:20:55 +0200 Subject: [python-ldap] Mac OS X 10.7 (Lion) In-Reply-To: <0962C88F-2FA4-4DA3-8090-C56688F0A9F8@skurfer.com> References: <36AAA4B9-80FE-4782-93ED-386C554BB19C@skurfer.com> <4E3160A3.4090508@stroeder.com> <0962C88F-2FA4-4DA3-8090-C56688F0A9F8@skurfer.com> Message-ID: <4E317047.2000802@stroeder.com> Please always follow-up on the mailing lists so others can comment and/or learn as well. Rob McBroom wrote: > On Jul 28, 2011, at 9:14 AM, Michael Str?der wrote: > >> As documented OpenLDAP libs 2.4.11 or newer are required to build and install >> python-ldap 2.4.x: >> >> http://www.python-ldap.org/doc/html/installing.html#prerequisites >> >> OpenLDAP 2.4.11 was released three years ago now (2008/07/16). > > Requiring something that?s been out for 3 years seems pretty safe to me. > > For what it?s worth, the OpenLDAP server and client tools bundled with Lion are 2.4.23, but if I?m interpreting this correctly, the library is nowhere near that: > > % otool -L /usr/lib/libldap_r.dylib > /usr/lib/libldap_r.dylib: > /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP (compatibility version 1.0.0, current version 2.2.0) I'm not familiar with MAC OS X and the file system used for the libs. Maybe you have to install additional development files like on Linux boxes? Is ldap.h around at all? Ciao, Michael. From mailinglist0 at skurfer.com Thu Jul 28 16:56:35 2011 From: mailinglist0 at skurfer.com (Rob McBroom) Date: Thu, 28 Jul 2011 10:56:35 -0400 Subject: [python-ldap] Mac OS X 10.7 (Lion) In-Reply-To: <4E317047.2000802@stroeder.com> References: <36AAA4B9-80FE-4782-93ED-386C554BB19C@skurfer.com> <4E3160A3.4090508@stroeder.com> <0962C88F-2FA4-4DA3-8090-C56688F0A9F8@skurfer.com> <4E317047.2000802@stroeder.com> Message-ID: <2B184CC9-37B0-44F9-805C-58368601F9DD@skurfer.com> On Jul 28, 2011, at 10:20 AM, Michael Str?der wrote: > Please always follow-up on the mailing lists so others can comment and/or > learn as well. I thought I was. Didn?t realize you had sent that to me directly. (No need, as I?m on the list.) > I'm not familiar with MAC OS X and the file system used for the libs. > Maybe you have to install additional development files like on Linux boxes? Is > ldap.h around at all? Yes it is, and while it doesn?t explicitly specify a version, the date is 2010/06/10. A mere 20 days earlier than the date in the man pages for 2.4.23. It also contains a reference to `ldap_create_assertion_control_value`. Looks to me like the header doesn?t match the library. I don?t know a lot about C, but this seems broken to me. Maybe I should just put my own copy in `/usr/local` to build against. -- Rob McBroom From yancey at unt.edu Thu Jul 28 17:19:22 2011 From: yancey at unt.edu (Yeargan, Yancey) Date: Thu, 28 Jul 2011 15:19:22 +0000 Subject: [python-ldap] Mac OS X 10.7 (Lion) In-Reply-To: <2B184CC9-37B0-44F9-805C-58368601F9DD@skurfer.com> References: <36AAA4B9-80FE-4782-93ED-386C554BB19C@skurfer.com> <4E3160A3.4090508@stroeder.com> <0962C88F-2FA4-4DA3-8090-C56688F0A9F8@skurfer.com> <4E317047.2000802@stroeder.com> <2B184CC9-37B0-44F9-805C-58368601F9DD@skurfer.com> Message-ID: You might consider MacPorts. http://www.macports.org/ports.php?by=name&substr=ldap On Jul 28, 2011, at 9:56 AM, Rob McBroom wrote: >> I'm not familiar with MAC OS X and the file system used for the libs. >> Maybe you have to install additional development files like on Linux boxes? Is >> ldap.h around at all? > > Yes it is, and while it doesn?t explicitly specify a version, the date is 2010/06/10. A mere 20 days earlier than the date in the man pages for 2.4.23. It also contains a reference to `ldap_create_assertion_control_value`. > > Looks to me like the header doesn?t match the library. I don?t know a lot about C, but this seems broken to me. Maybe I should just put my own copy in `/usr/local` to build against. > From cmikk at qwest.net Thu Jul 28 17:29:16 2011 From: cmikk at qwest.net (Chris Mikkelson) Date: Thu, 28 Jul 2011 10:29:16 -0500 Subject: [python-ldap] LDAP Sync (RFC 4533) support In-Reply-To: <4E310963.7000903@stroeder.com> References: <20110727215025.GA11995@uerige.oss.uswest.net> <4E310963.7000903@stroeder.com> Message-ID: <20110728152916.GA14802@uerige.oss.uswest.net> On Thu, Jul 28, 2011 at 09:01:55AM +0200, Michael Str?der wrote: > Chris Mikkelson wrote: > > replication client. It also requires the patch to > > Modules/message.c Michael just committed. > > I have to review that again. Maybe the 3-tuple vs. 4-tuple thing should be > fixed in LDAPObject.result4(). I will do that during the day... I think the C fix is the right one. The field removed from the decoded response data is a duplicate of information in the overall response. That is, before the C code change, the structure of an intermediate response was: [ 121, [ (121, oid, value, controls) ], ...] and after it is: [ 121, [ (oid, value, controls) ], ...] a search response was (and still is): [ 100, [ (dn, attrs, controls) ], ... ] > > Since the sync replication protocol is moderately > > complicated, the primary API exposed by this module is a > > base class which inherits from LDAPObject > > How about implementing it as a mix-in class like ldap.resiter.ResultProcessor? > Then one can use it together with ReconnectLDAPObject or any other class > derived from LDAPObject. > > http://www.python-ldap.org/doc/html/ldap-resiter.html > > If you don't mind I will change your patch. Especially it would be nice if one > could use ldap.resiter.ResultProcessor (result processing generator class) > together with syncrepl. I don't mind at all, go ahead. -- Chris Mikkelson | For example, I could be a sentient PERL script. That cmikk at qwest.net | pretty much assumes that someone brilliant enough to | write me was also stupid enough to program in PERL. | Not a likely explanation. -- Terry Lambert From michael at stroeder.com Thu Jul 28 20:36:49 2011 From: michael at stroeder.com (=?windows-1252?Q?Michael_Str=F6der?=) Date: Thu, 28 Jul 2011 20:36:49 +0200 Subject: [python-ldap] Mac OS X 10.7 (Lion) In-Reply-To: <2B184CC9-37B0-44F9-805C-58368601F9DD@skurfer.com> References: <36AAA4B9-80FE-4782-93ED-386C554BB19C@skurfer.com> <4E3160A3.4090508@stroeder.com> <0962C88F-2FA4-4DA3-8090-C56688F0A9F8@skurfer.com> <4E317047.2000802@stroeder.com> <2B184CC9-37B0-44F9-805C-58368601F9DD@skurfer.com> Message-ID: <4E31AC41.6060505@stroeder.com> Rob McBroom wrote: > On Jul 28, 2011, at 10:20 AM, Michael Str?der wrote: >> I'm not familiar with MAC OS X and the file system used for the libs. >> Maybe you have to install additional development files like on Linux boxes? Is >> ldap.h around at all? > > Yes it is, and while it doesn?t explicitly specify a version, the date is > 2010/06/10. A mere 20 days earlier than the date in the man pages for > 2.4.23. It also contains a reference to > `ldap_create_assertion_control_value`. > > Looks to me like the header doesn?t match the library. I don?t know a lot > about C, but this seems broken to me. Maybe I should just put my own copy > in `/usr/local` to build against. I don't know anything about Mac OS X and its package management. On a Linux distribution I'd try to find out which file belongs to which distribution package and remove any file which does not belong to a package. Ciao, Michael. From bgollmer at tcnetworks.com Thu Jul 28 21:06:31 2011 From: bgollmer at tcnetworks.com (Ben Gollmer) Date: Thu, 28 Jul 2011 19:06:31 +0000 Subject: [python-ldap] Mac OS X 10.7 (Lion) In-Reply-To: <2B184CC9-37B0-44F9-805C-58368601F9DD@skurfer.com> Message-ID: <20110728190631.334378cc@rs1.tcnetworks.com> On Jul 28, 2011, at 10:56 AM, Rob McBroom wrote: > Looks to me like the header doesn?t match the library. I don?t know a > lot about C, but this seems broken to me. Maybe I should just put my own > copy in `/usr/local` to build against. If you have a look at `nm -g /usr/lib/libldap_r.dylib`, you'll see that _ldap_create_assertion_control_value is not exported, which breaks building against the system copy of OpenLDAP. This is (unfortunately) why I have not created any binary Mac OS X packages for Python-LDAP 2.4.x on PyPI. -- Ben From stefanik at dscon.sk Fri Jul 29 11:20:52 2011 From: stefanik at dscon.sk (Dusan Stefanik) Date: Fri, 29 Jul 2011 11:20:52 +0200 Subject: [python-ldap] what's next with python-ldap and py3 Message-ID: <20110729092052.GC4420@portos> Hi, is there somebody who tested/testing python-ldap on py3? What's next with python-ldap and py3? Dusan From michael at stroeder.com Fri Jul 29 12:22:05 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 29 Jul 2011 12:22:05 +0200 Subject: [python-ldap] what's next with python-ldap and py3 In-Reply-To: <20110729092052.GC4420@portos> References: <20110729092052.GC4420@portos> Message-ID: <4E3289CD.6090705@stroeder.com> HI! I'll take this as an opportunity to think about the development of python-ldap package in general. Dusan Stefanik wrote: > is there somebody who tested/testing python-ldap on py3? Not yet. > What's next with python-ldap and py3? Frankly I don't have a use-case for Python3 myself. So for me personally this has a rather low priority. As background information my work on python-ldap is driven by two factors: 1. Things I need to improve web2ldap which only runs under Python 2.x anyway. 2. Stuff needed for implementing more sophisticated LDAP connectors for my customers. For both I don't need Python 3 yet. Besides that I spent a lot of time during last week improving the docs just to bring the project itself in a better shape. Still more work is needed also for the long missing test-suite. And I'm a bit scared that there will be a lot of #ifdef-statements in the C module part...especially since there is no test suite yet. I understand that this might seem frustrating to you since you already submitted a patch. But crossing the gap between an experimental _ldap patch and a releaseable, well-documented python-ldap package still requires a lot of effort. The new more complete docs show quite well how much code has to be touched. So without more people willing to spend time on it this will not really take off soon... Ciao, Michael. From mail at timgolden.me.uk Fri Jul 29 14:41:18 2011 From: mail at timgolden.me.uk (Tim Golden) Date: Fri, 29 Jul 2011 13:41:18 +0100 Subject: [python-ldap] what's next with python-ldap and py3 In-Reply-To: <4E3289CD.6090705@stroeder.com> References: <20110729092052.GC4420@portos> <4E3289CD.6090705@stroeder.com> Message-ID: <4E32AA6E.90603@timgolden.me.uk> On 29/07/2011 11:22, Michael Str?der wrote: > Frankly I don't have a use-case for Python3 myself. So for me personally this > has a rather low priority. I just wanted to say that I sympathise with this point of view, as well as the other you expressed later where there's a difference between a working prototype and a fully documented, release-packaged version (or versions, depending on how you play things). I follow python-ldap principally because I'm the author of a module aimed specifically at Active Directory and I just want to pick up the kind of issues people are facing when accessing via LDAP proper. (I occasionally point people your way, too, when that seems to make sense). But I have the same issue: how hard do I try to support Py3 if I don't need it myself? Like all active Python developers, I recognise the need for pushing Python 3 forward, but my drivers are similar to yours: whatever my immedaite customers need and which I can support. FWIW I have the luxury of a pure-python package, supported by pywin32 (which is already py2 and py3 ready) and I'm refactoring with a view to py3 support, but my main market is still py2 and unless I get time and/or money to do otherwise it'll likely stay that way for the moment. TJG From stefanik at dscon.sk Sat Jul 30 00:45:49 2011 From: stefanik at dscon.sk (Dusan Stefanik) Date: Sat, 30 Jul 2011 00:45:49 +0200 Subject: [python-ldap] what's next with python-ldap and py3 In-Reply-To: <4E3289CD.6090705@stroeder.com> References: <20110729092052.GC4420@portos> <4E3289CD.6090705@stroeder.com> Message-ID: <20110729224547.GA13202@dscon.dscon.sk> On 29/07/11 at 12:22pm, Michael Str?der wrote: > HI! > > I'll take this as an opportunity to think about the development of python-ldap > package in general. It's working peace of code :-). Well it's your baby, you know best what neededs to be done. Please send your proposals/todo. I hope someone can help. Please let me know which next steps is needed to get py3 version at least to CVS. I can spend some time working on it. > > Dusan Stefanik wrote: > > is there somebody who tested/testing python-ldap on py3? > > Not yet. > > > What's next with python-ldap and py3? > > Frankly I don't have a use-case for Python3 myself. So for me personally this > has a rather low priority. > > As background information my work on python-ldap is driven by two factors: > 1. Things I need to improve web2ldap which only runs under Python 2.x anyway. > 2. Stuff needed for implementing more sophisticated LDAP connectors for my > customers. > > For both I don't need Python 3 yet. I understand your point of view. You're right. > > Besides that I spent a lot of time during last week improving the docs just to > bring the project itself in a better shape. Still more work is needed also for > the long missing test-suite. > > And I'm a bit scared that there will be a lot of #ifdef-statements in the C > module part...especially since there is no test suite yet. > > I understand that this might seem frustrating to you since you already > submitted a patch. But crossing the gap between an experimental _ldap patch > and a releaseable, well-documented python-ldap package still requires a lot of > effort. The new more complete docs show quite well how much code has to be > touched. > > So without more people willing to spend time on it this will not really take > off soon... > > Ciao, Michael. > Dusan From fabrante at yahoo.com Mon Aug 1 16:16:48 2011 From: fabrante at yahoo.com (Francis Abrante) Date: Mon, 1 Aug 2011 07:16:48 -0700 (PDT) Subject: [python-ldap] multiples values in roleOccupant Message-ID: <1312208208.1094.YahooMailNeo@web39603.mail.mud.yahoo.com> how do I for add multiples values in roleOccupant attribute? If the attribute is empty ok, but if I need add other accounts? Can I concatenate the accounts? This is part of my code: def role_user(dn,user): ??? old = {'roleOccupant':''} ??? new = {'roleOccupant':user} ??? ldif = modlist.modifyModlist(old,new) ??? l.modify_s(dn,ldif) Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Mon Aug 1 18:42:54 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 01 Aug 2011 18:42:54 +0200 Subject: [python-ldap] multiples values in roleOccupant In-Reply-To: <1312208208.1094.YahooMailNeo@web39603.mail.mud.yahoo.com> References: <1312208208.1094.YahooMailNeo@web39603.mail.mud.yahoo.com> Message-ID: <4E36D78E.4010500@stroeder.com> Francis Abrante wrote: > > how do I for add multiples values in roleOccupant attribute? In general it's an attribute value list. > old = {'roleOccupant':''} > new = {'roleOccupant':user} > ldif = modlist.modifyModlist(old,new) > l.modify_s(dn,ldif) This won't work. Should be: new = {'roleOccupant':[user]} If you have large group entries you should build the modify list by hand. Add two distinct users to the group entry: user1 = 'uid=user1,dc=example,dc=com' user2 = 'uid=user2,dc=example,dc=com' modlist = [ (ldap.MOD_ADD,'roleOccupant',[user1,user2]), ] Ciao, Michael. From michael at stroeder.com Tue Aug 2 09:22:07 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 02 Aug 2011 09:22:07 +0200 Subject: [python-ldap] Minimum Python version supported by python-ldap? Message-ID: <4E37A59F.5060705@stroeder.com> HI! Somebody else already raised this question some time ago: Which old version of Python should still be supported by python-ldap 2.4.x? Python 2.4 introduced built-in function set() which is quite handy for various LDAP stuff. I don't see any reason supporting anything older than that. Python 2.5 was released on September 19th 2006 which is already five years ago. For several months my web2ldap at least requires Python 2.6 which was released October 1st, 2008. Therefore that's the minimum version I'm testing python-ldap with. This would almost match the requirement for OpenLDAP 2.4.11 (released 2008-07-16). So everybody maintaining older systems *and* who needs newer features found in python-ldap 2.4 should speak up *now* including a statement about he/she is willing to do thorough testing on this older Python version. Otherwise I will choose a minimum required version and some code might get refactored strictly requiring newer versions. Ciao, Michael. From michael at stroeder.com Tue Aug 2 09:29:02 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 02 Aug 2011 09:29:02 +0200 Subject: [python-ldap] LDAP Sync (RFC 4533) support In-Reply-To: <20110727215025.GA11995@uerige.oss.uswest.net> References: <20110727215025.GA11995@uerige.oss.uswest.net> Message-ID: <4E37A73E.3040604@stroeder.com> Chris Mikkelson wrote: > The attached patch against python-ldap 2.4.3 adds a new > sub-module 'ldap.syncrepl' which implements an RFC 4533 > replication client. I'm currently reviewing this. Well done. I have some questions/remarks though: 1. Do you have a sample script demonstrating usage of ldap.syncrepl? I'd like to add one under Demo/ in the source distribution. 2. I will add a comment that this implements a syncrepl-consumer not a provider. That's right? 3. Which minimum Python version does your code need? Currently there's no minimum Python version specified for python-ldap (see my other posting). This affects use of sets etc. 4. {} is an empty dictionary not an empty set as you might have intended. 5. Using mutable types as defaults for key-word arguments causes unpredictable side-effects (uuids={} sets empty dict). I'd also argue that the various methods should not have key-word arguments if the arguments aren't truly optional. 6. As said I will turn the LDAPSyncObject into a mix-in class used with LDAPObject classes. Ciao, Michael. From fabrante at yahoo.com Tue Aug 2 11:23:06 2011 From: fabrante at yahoo.com (Francis Abrante) Date: Tue, 2 Aug 2011 02:23:06 -0700 (PDT) Subject: [python-ldap] multiples values in roleOccupant In-Reply-To: <4E36D78E.4010500@stroeder.com> References: <1312208208.1094.YahooMailNeo@web39603.mail.mud.yahoo.com> <4E36D78E.4010500@stroeder.com> Message-ID: <1312276986.62699.YahooMailNeo@web39607.mail.mud.yahoo.com> Hi Thanks for your help :) But, if I have already values in the field? they are overwrite?? Thanks again ________________________________ De: Michael Str?der Para: Francis Abrante CC: Python Forum Enviado: Lunes, agosto 1, 2011 6:42 P.M. Asunto: Re: [python-ldap] multiples values in roleOccupant Francis Abrante wrote: > > how do I for add multiples values in roleOccupant attribute? In general it's an attribute value list. >? ? old = {'roleOccupant':''} >? ? new = {'roleOccupant':user} >? ? ldif = modlist.modifyModlist(old,new) >? ? l.modify_s(dn,ldif) This won't work. Should be: new = {'roleOccupant':[user]} If you have large group entries you should build the modify list by hand. Add two distinct users to the group entry: user1 = 'uid=user1,dc=example,dc=com' user2 = 'uid=user2,dc=example,dc=com' modlist = [ ? (ldap.MOD_ADD,'roleOccupant',[user1,user2]), ] Ciao, Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Tue Aug 2 12:03:57 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 02 Aug 2011 12:03:57 +0200 Subject: [python-ldap] multiples values in roleOccupant In-Reply-To: <1312276986.62699.YahooMailNeo@web39607.mail.mud.yahoo.com> References: <1312208208.1094.YahooMailNeo@web39603.mail.mud.yahoo.com> <4E36D78E.4010500@stroeder.com> <1312276986.62699.YahooMailNeo@web39607.mail.mud.yahoo.com> Message-ID: <4E37CB8D.9000009@stroeder.com> Francis Abrante wrote: > Thanks for your help :) > But, if I have already values in the field? they are overwrite? The modlist with ldap.MOD_ADD adds another value to an already existing attribute. Note that if the particular value already exists you get an error by most LDAP servers. Ciao, Michael. From cmikk at qwest.net Tue Aug 2 16:24:04 2011 From: cmikk at qwest.net (Chris Mikkelson) Date: Tue, 2 Aug 2011 09:24:04 -0500 Subject: [python-ldap] LDAP Sync (RFC 4533) support In-Reply-To: <4E37A73E.3040604@stroeder.com> References: <20110727215025.GA11995@uerige.oss.uswest.net> <4E37A73E.3040604@stroeder.com> Message-ID: <20110802142404.GA33550@uerige.oss.uswest.net> On Tue, Aug 02, 2011 at 09:29:02AM +0200, Michael Str?der wrote: > Chris Mikkelson wrote: > > The attached patch against python-ldap 2.4.3 adds a new > > sub-module 'ldap.syncrepl' which implements an RFC 4533 > > replication client. > > I'm currently reviewing this. Well done. > > I have some questions/remarks though: > > 1. Do you have a sample script demonstrating usage of ldap.syncrepl? I'd like > to add one under Demo/ in the source distribution. I'll throw one together, hopefully in the next few days. > 2. I will add a comment that this implements a syncrepl-consumer not a > provider. That's right? That is correct. > 3. Which minimum Python version does your code need? Currently there's no > minimum Python version specified for python-ldap (see my other posting). This > affects use of sets etc. I'm new to python (as evidenced by your next few comments :-). I'm personally using 2.7, but I didn't intentionally use any 2.7-specific features. > 4. {} is an empty dictionary not an empty set as you might have intended. > > 5. Using mutable types as defaults for key-word arguments causes unpredictable > side-effects (uuids={} sets empty dict). I'd also argue that the various > methods should not have key-word arguments if the arguments aren't truly optional. OK. I've made the following API changes to my local copy. The methods are now: syncrepl_present(self, uuids, refreshDeletes=False) syncrepl_delete(self, uuids) and the uuids parameters are either a list of uuid strings or None. I'll test my changes while writing a demo script, and send out the patch along with the demo script. -- Chris Mikkelson | It has been said that man is a rational animal. cmikk at qwest.net | All my life I have been searching for evidence | which could support this. -- Bertrand Russell From cmikk at qwest.net Wed Aug 3 17:24:52 2011 From: cmikk at qwest.net (Chris Mikkelson) Date: Wed, 3 Aug 2011 10:24:52 -0500 Subject: [python-ldap] LDAP Sync (RFC 4533) support In-Reply-To: <20110802142404.GA33550@uerige.oss.uswest.net> References: <20110727215025.GA11995@uerige.oss.uswest.net> <4E37A73E.3040604@stroeder.com> <20110802142404.GA33550@uerige.oss.uswest.net> Message-ID: <20110803152452.GA37837@uerige.oss.uswest.net> On Tue, Aug 02, 2011 at 09:24:04AM -0500, Chris Mikkelson wrote: > OK. I've made the following API changes to my local copy. The > methods are now: > > syncrepl_present(self, uuids, refreshDeletes=False) > syncrepl_delete(self, uuids) > > and the uuids parameters are either a list of uuid strings > or None. I'll test my changes while writing a demo script, > and send out the patch along with the demo script. One more API change: * syncrepl_search() now returns a msgid which can be passed to syncrepl_poll(msgid=...). This makes it possible to interleave ldapsync and non-ldapsync operations on the same connection. Patch attached. Demo script also attached. It "mirrors" the DNs of entries matching a search into a dbm, and prints out its updates. -- Chris Mikkelson | For example, I could be a sentient PERL script. That cmikk at qwest.net | pretty much assumes that someone brilliant enough to | write me was also stupid enough to program in PERL. | Not a likely explanation. -- Terry Lambert -------------- next part -------------- diff --git a/Lib/ldap/syncrepl.py b/Lib/ldap/syncrepl.py index cc92c7d..6c3960d 100644 --- a/Lib/ldap/syncrepl.py +++ b/Lib/ldap/syncrepl.py @@ -264,15 +264,15 @@ class SyncInfoMessage: if attr.startswith('refresh'): val['refreshDone'] = bool(comp.getComponentByName('refreshDone')) elif attr == 'syncIdSet': - uuids = set() + uuids = [] ids = comp.getComponentByName('syncUUIDs') for i in range(len(ids)): uuid = UUID(bytes=str(ids.getComponentByPosition(i))) - uuids |= { str(uuid) } + uuids.append(str(uuid)) val['syncUUIDs'] = uuids val['refreshDeletes'] = bool(comp.getComponentByName('refreshDeletes')) - self.__dict__[attr] = val + setattr(self,attr,val) return @@ -312,11 +312,11 @@ class LDAPSyncObject(ldap.ldapobject.LDAPObject): else: search_args['serverctrls'] = [syncreq] - self.__msgid = self.search_ext(base, scope, **search_args) self.__refreshDone = False + return self.search_ext(base, scope, **search_args) - def syncrepl_poll(self, timeout=None, all=0): + def syncrepl_poll(self, msgid=-1, timeout=None, all=0): """ polls for and processes responses to the syncrepl_search() operation. Returns False when operation finishes, True if it is in progress, or @@ -330,7 +330,7 @@ class LDAPSyncObject(ldap.ldapobject.LDAPObject): """ while True: type, msg, mid, ctrls, n, v = self.result4( - msgid=self.__msgid, timeout=timeout, + msgid=msgid, timeout=timeout, add_intermediates=1, add_ctrls=1, all = 0 ) @@ -341,7 +341,7 @@ class LDAPSyncObject(ldap.ldapobject.LDAPObject): for c in ctrls: if c.__class__.__name__ != 'SyncDoneControl': continue - self.syncrepl_present(refreshDeletes=c.refreshDeletes) + self.syncrepl_present(None,refreshDeletes=c.refreshDeletes) if c.cookie is not None: self.syncrepl_set_cookie(c.cookie) @@ -355,13 +355,13 @@ class LDAPSyncObject(ldap.ldapobject.LDAPObject): if c.__class__.__name__ != 'SyncStateControl': continue if c.state == 'present': - self.syncrepl_present(uuids={c.entryUUID}) + self.syncrepl_present([c.entryUUID]) elif c.state == 'delete': - self.syncrepl_delete(uuids={c.entryUUID}) + self.syncrepl_delete([c.entryUUID]) else: self.syncrepl_entry(dn, attrs, c.entryUUID) if self.__refreshDone is False: - self.syncrepl_present(uuids={c.entryUUID}) + self.syncrepl_present([c.entryUUID]) if c.cookie is not None: self.syncrepl_set_cookie(c.cookie) break @@ -376,20 +376,20 @@ class LDAPSyncObject(ldap.ldapobject.LDAPObject): if sim.newcookie is not None: self.syncrepl_set_cookie(sim.newcookie) elif sim.refreshPresent is not None: - self.syncrepl_present(refreshDeletes=False) + self.syncrepl_present(None, refreshDeletes=False) if 'cookie' in sim.refreshPresent: self.syncrepl_set_cookie(sim.refreshPresent['cookie']) self.__refreshDone=sim.refreshPresent['refreshDone'] elif sim.refreshDelete is not None: - self.syncrepl_present(refreshDeletes=True) + self.syncrepl_present(None, refreshDeletes=True) if 'cookie' in sim.refreshDelete: self.syncrepl_set_cookie(sim.refreshDelete['cookie']) self.__refreshDone=sim.refreshDelete['refreshDone'] elif sim.syncIdSet is not None: if sim.syncIdSet['refreshDeletes'] is True: - self.syncrepl_delete(uuids=sim.syncIdSet['syncUUIDs']) + self.syncrepl_delete(sim.syncIdSet['syncUUIDs']) else: - self.syncrepl_present(uuids=sim.syncIdSet['syncUUIDs']) + self.syncrepl_present(sim.syncIdSet['syncUUIDs']) if 'cookie' in sim.syncIdSet: self.syncrepl_set_cookie(sim.syncIdSet['cookie']) pass @@ -412,31 +412,32 @@ class LDAPSyncObject(ldap.ldapobject.LDAPObject): """ pass - def syncrepl_present(self, uuids={}, refreshDeletes=False): + def syncrepl_present(self, uuids, refreshDeletes=False): """ Called by syncrepl_poll() whenever entry UUIDs are presented to the client. syncrepl_present() is given a list of entry UUIDs (uuids) and a flag (refreshDeletes) which indicates whether the server explicitly deleted non-present entries during the refresh operation. - If called with a nonempty set of uuids, the syncrepl_present() implementation + If called with a list of uuids, the syncrepl_present() implementation should record those uuids as present in the directory. - If called with an empty set of uuids and refreshDeletes set to False, + If called with uuids set to None and refreshDeletes set to False, syncrepl_present() should delete all non-present entries from the local mirror, and reset the list of recorded uuids. - If called with an empty set of uuids and refreshDeletes set to True, + If called with uuids set to None and refreshDeletes set to True, syncrepl_present() should reset the list of recorded uuids, without deleting any entries. """ pass - def syncrepl_delete(self, uuids={}): + def syncrepl_delete(self, uuids): """ - Called by syncrepl_poll() to delete entries. It is given a list - of UUIDs (uuids) of the entries to be deleted. + Called by syncrepl_poll() to delete entries. A list + of UUIDs of the entries to be deleted is given in the + uuids parameter. """ pass -------------- next part -------------- A non-text attachment was scrubbed... Name: syncrepl-demo.py Type: text/x-python Size: 2114 bytes Desc: not available URL: From scott.batchelor at capstonetech.com Thu Aug 11 19:24:44 2011 From: scott.batchelor at capstonetech.com (Scott Batchelor) Date: Thu, 11 Aug 2011 13:24:44 -0400 Subject: [python-ldap] Error trying to test python-ldap install. Message-ID: Admittedly, I am new to both python and python-ldap so I may be missing something simple. I am trying to run the following script from the doc example. I have verified that I can connect to the LDAP server and return the desired result via a simple ldapsearch command line. Here is the result of checking the module install. $ python ?c "import ldap;print ldap._version_" 2.4.4 I have checked to make sure that the module is being called from the correct python install with: $ python ?c "import ldap;print ldap._file_" And that checks out ok. Upon trying to run the following script: **Note dummy values have replaced real values to protect the innocent. import ldap, sys l = ldap.initialize('ldap//localhost:389') l.simple_bind_s() l.search_s('base',ldap.SCOPE_SUBTREE,'filter') I receive this error: raceback (most recent call last): File "simple.py", line 3, in ld = ldap.initialize('ldap//localhost:389') File "/vol09/eng/python/python27/lib/python2.7/site-packages/ldap/functions.py", line 91, in initialize return LDAPObject(uri,trace_level,trace_file,trace_stack_limit) File "/vol09/eng/python/python27/lib/python2.7/site-packages/ldap/ldapobject.py", line 70, in __init__ self._l = ldap.functions._ldap_function_call(ldap._ldap_module_lock,_ldap.initialize,u ri) File "/vol09/eng/python/python27/lib/python2.7/site-packages/ldap/functions.py", line 63, in _ldap_function_call result = func(*args,**kwargs) ldap.LDAPError: (2, 'No such file or directory') Any help to point me in the right direction would greatly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Sat Aug 13 20:04:50 2011 From: michael at stroeder.com (=?windows-1252?Q?Michael_Str=F6der?=) Date: Sat, 13 Aug 2011 20:04:50 +0200 Subject: [python-ldap] Error trying to test python-ldap install. In-Reply-To: <4E46BB30.1080605@stroeder.com> References: <4E46BB30.1080605@stroeder.com> Message-ID: <4E46BCC2.8070609@stroeder.com> Michael Str?der wrote: >> l.search_s('base',ldap.SCOPE_SUBTREE,'filter') >> [..] >> ldap.LDAPError: (2, 'No such file or directory') > > I'd set trace_level=2 to observe which argument values are really passed to > python-ldap. I've overlooked this. You probably want to write l.search_s(base,ldap.SCOPE_SUBTREE,filter) if base and filter are variable names. Also note that filter() is a built-in Python function. So I rather would use filterstr as variable name. Ciao, Michael. From michael at stroeder.com Sat Aug 13 19:58:08 2011 From: michael at stroeder.com (=?windows-1252?Q?Michael_Str=F6der?=) Date: Sat, 13 Aug 2011 19:58:08 +0200 Subject: [python-ldap] Error trying to test python-ldap install. In-Reply-To: References: Message-ID: <4E46BB30.1080605@stroeder.com> Scott Batchelor wrote: > I have verified that I can connect to the LDAP server and return the desired > result via a simple ldapsearch command line. Ok. > Here is the result of checking the module install. > $ python ?c "import ldap;print ldap._version_" > 2.4.4 You problaby meant __version__. Note the doube underscores. Note that 2.4.4 is from CVS HEAD and this code was not officially released yet. Expect changes... Why are you using CVS HEAD? > Upon trying to run the following script: **Note dummy values have replaced > real values to protect the innocent. Hmm, it's right to replace real values. But I suspect that therein lies the problem. > l = ldap.initialize('ldap//localhost:389') > l.simple_bind_s() > l.search_s('base',ldap.SCOPE_SUBTREE,'filter') > > I receive this error: > [..] > ldap.LDAPError: (2, 'No such file or directory') I'd set trace_level=2 to observe which argument values are really passed to python-ldap. See http://www.python-ldap.org/doc/html/ldap.html#ldapobject-classes If that does not provide any clue it might be worth looking at OpenLDAP logs. See Demo/initialize.py how to set option ldap.OPT_DEBUG_LEVEL. Note that the OpenLDAP libs use parameter defaults from ldap.conf(5) unless you explicitly turn that off by adding os.environ['LDAPNOINIT']='1' to your code. Ciao, Michael. From mailinglist0 at skurfer.com Thu Aug 18 17:18:59 2011 From: mailinglist0 at skurfer.com (Rob McBroom) Date: Thu, 18 Aug 2011 11:18:59 -0400 Subject: [python-ldap] Mac OS X 10.7 (Lion) In-Reply-To: <36AAA4B9-80FE-4782-93ED-386C554BB19C@skurfer.com> References: <36AAA4B9-80FE-4782-93ED-386C554BB19C@skurfer.com> Message-ID: <0237DD4F-AE05-447A-BCAF-231714150101@skurfer.com> For anyone that wants to use 2.4.3, I?ve got it working. http://projects.skurfer.com/posts/2011/python_ldap_lion/ -- Rob McBroom From patrickf at signaller.net Sun Aug 28 15:43:18 2011 From: patrickf at signaller.net (Patrick Fitzgerald) Date: Sun, 28 Aug 2011 14:43:18 +0100 Subject: [python-ldap] Adding members to a group in AD Message-ID: <4E5A45F6.2010900@signaller.net> Hi Everyone, I am using python-ldap with Active Directory (2003) to populate an OU called "people" with client contacts. This works well. Now I need to add these contacts to a (distribution) group called 'clients'. Problem is - I can add one member and one only before i get the error: /UNWILLING_TO_PERFORM at /company/contact/34480/ {'info': '00000057: LdapErr: DSID-0C090A85, comment: Error in attribute conversion operation, data 0, vece', 'desc': 'Server is unwilling to perform'} /I am trying to append the new contact to the members list of the group. My relevant code is: ContactDN = member to add to group SearchDN ='OU=Global Distribution Groups,OU=department,DC=example,dc=com' DN = 'cn=myClients,ou=Global Distribution Groups,OU=department,dc=example,dc=com' result_id = l.search(SearchDN,ldap.SCOPE_SUBTREE,'(cn=myClients)',['member']) # get members if the group result_data=l.result(result_id,0) old = result_data[1][0][1] # extract the relevant attribute if len(old)>0: # group has members attrs = old attrs['member'].append(ContactDN) else: # group has no members attrs={} attrs['member']=[ContactDN] ldif = modlist.modifyModlist(old,attrs) l.modify_s(DN,ldif) I am puzzled as to how I am allowed to add the first but not subsequent members to the group. As bit of a newbie to ldap, all and any advice is welcome! Thanks in advance, Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From raj at csub.edu Sun Aug 28 21:52:35 2011 From: raj at csub.edu (Russell Jackson) Date: Sun, 28 Aug 2011 12:52:35 -0700 Subject: [python-ldap] Adding members to a group in AD In-Reply-To: <4E5A45F6.2010900@signaller.net> References: <4E5A45F6.2010900@signaller.net> Message-ID: <4E5A9C83.80802@csub.edu> On 08/28/2011 06:43 AM, Patrick Fitzgerald wrote: > Hi Everyone, > > I am using python-ldap with Active Directory (2003) to populate an OU called "people" with > client contacts. This works well. Now I need to add these contacts to a (distribution) > group called 'clients'. > > Problem is - I can add one member and one only before i get the error: > > /UNWILLING_TO_PERFORM at /company/contact/34480/ > {'info': '00000057: LdapErr: DSID-0C090A85, comment: Error in attribute conversion > operation, data 0, vece', 'desc': 'Server is unwilling to perform'} > > /I am trying to append the new contact to the members list of the group. My relevant code is: > > ContactDN = member to add to group > SearchDN ='OU=Global Distribution Groups,OU=department,DC=example,dc=com' > > DN = 'cn=myClients,ou=Global Distribution Groups,OU=department,dc=example,dc=com' > > result_id = l.search(SearchDN,ldap.SCOPE_SUBTREE,'(cn=myClients)',['member']) # get > members if the group > result_data=l.result(result_id,0) > > old = result_data[1][0][1] # extract the relevant attribute > > if len(old)>0: # group has members > attrs = old > attrs['member'].append(ContactDN) > else: # group has no members > attrs={} > attrs['member']=[ContactDN] > ldif = modlist.modifyModlist(old,attrs) > l.modify_s(DN,ldif) > > I am puzzled as to how I am allowed to add the first but not subsequent members to the > group. As bit of a newbie to ldap, all and any advice is welcome! modifyModList() is a bit ham fisted in that it just does a replace rather than figure out what to add and delete. I'm not sure if this is the problem or not, but try building your modlist by hand. dn, entry = dir.search_s('dc=domain', ldap.SCOPE_SUBTREE, ''' (& (objectClass=group) (cn=some_group) ) '''.strip())[0] member_dn_list = [ 'cn=foo,ou=people,dc=domain', 'cn=bar,ou=people,dc=domain', 'cn=baz,ou=people,dc=domain', ] modlist = [ (ldap.MOD_ADD, 'member', [ dn for dn in member_dn_list if dn not in entry.get('member', []) ]) ] ldif.LDIFWriter(sys.stderr).unparse(dn, modlist) dir.modify_s(dn, modlist) -- Russell A. Jackson Network Analyst California State University, Bakersfield From michael at stroeder.com Mon Aug 29 13:32:39 2011 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Mon, 29 Aug 2011 13:32:39 +0200 Subject: [python-ldap] Adding members to a group in AD In-Reply-To: <4E5A9C83.80802@csub.edu> References: <4E5A45F6.2010900@signaller.net> <4E5A9C83.80802@csub.edu> Message-ID: <4E5B78D7.10405@stroeder.com> Russell Jackson wrote: > modifyModList() is a bit ham fisted in that it just does a replace rather than > figure out what to add and delete. More precise: modifyModList() will result in MOD_DEL all values, MOD_ADD complete new value list. The reason for this is that not all attributes have an EQUALITY matching rule assigned to it (e.g. binary attributes) which is required for doing something smarter. This turned out to be successful with most LDAP servers. But some LDAP server seem to do schema-checking not on the overall result of the modify operation. It seems that MOD_DEL all values leads to a schema violation one these servers. My web2ldap has a smarter variant of this function which looks in the subschema for determining whether an EQUALITY matching rule is usable. Anyway one would not want to use that for large group entries. > dn, entry = dir.search_s('dc=domain', ldap.SCOPE_SUBTREE, ''' > (& > (objectClass=group) > (cn=some_group) > ) > '''.strip())[0] > > member_dn_list = [ > 'cn=foo,ou=people,dc=domain', > 'cn=bar,ou=people,dc=domain', > 'cn=baz,ou=people,dc=domain', > ] > modlist = [ > (ldap.MOD_ADD, 'member', [ > dn > for dn in member_dn_list > if dn not in entry.get('member', []) > ]) > ] > > ldif.LDIFWriter(sys.stderr).unparse(dn, modlist) > dir.modify_s(dn, modlist) Hmm, in principle this is ok but one should make it a bit faster by pre-initializing a set. Also one might to make this case-insensitive. I'd usually do: member_list = set([av.lower() for av in entry.get('member', [])]) and then: if not dn.lower() in member_list: If one already knows which DN to add it's more easy anyway. Note that DNs are not case-insensitive in general. E.g. OpenLDAP looks applys the exact matching rules for the attributes used in a DN. Ciao, Michael. From patrickf at signaller.net Wed Aug 31 13:19:46 2011 From: patrickf at signaller.net (Patrick Fitzgerald) Date: Wed, 31 Aug 2011 12:19:46 +0100 Subject: [python-ldap] Adding members to a group in AD In-Reply-To: <4E5B78D7.10405@stroeder.com> References: <4E5A45F6.2010900@signaller.net> <4E5A9C83.80802@csub.edu> <4E5B78D7.10405@stroeder.com> Message-ID: <4E5E18D2.6060001@signaller.net> Thanks - just the clues I needed to get it working. Building the modify list by hand worked as it exposed an error in my code. Thanks again- Patrick On 29/08/2011 12:32, Michael Str?der wrote: > Russell Jackson wrote: >> modifyModList() is a bit ham fisted in that it just does a replace rather than >> figure out what to add and delete. > More precise: modifyModList() will result in MOD_DEL all values, MOD_ADD > complete new value list. The reason for this is that not all attributes have > an EQUALITY matching rule assigned to it (e.g. binary attributes) which is > required for doing something smarter. This turned out to be successful with > most LDAP servers. But some LDAP server seem to do schema-checking not on the > overall result of the modify operation. It seems that MOD_DEL all values leads > to a schema violation one these servers. > > My web2ldap has a smarter variant of this function which looks in the > subschema for determining whether an EQUALITY matching rule is usable. > > Anyway one would not want to use that for large group entries. > >> dn, entry = dir.search_s('dc=domain', ldap.SCOPE_SUBTREE, ''' >> (& >> (objectClass=group) >> (cn=some_group) >> ) >> '''.strip())[0] >> >> member_dn_list = [ >> 'cn=foo,ou=people,dc=domain', >> 'cn=bar,ou=people,dc=domain', >> 'cn=baz,ou=people,dc=domain', >> ] >> modlist = [ >> (ldap.MOD_ADD, 'member', [ >> dn >> for dn in member_dn_list >> if dn not in entry.get('member', []) >> ]) >> ] >> >> ldif.LDIFWriter(sys.stderr).unparse(dn, modlist) >> dir.modify_s(dn, modlist) > Hmm, in principle this is ok but one should make it a bit faster by > pre-initializing a set. Also one might to make this case-insensitive. > > I'd usually do: > > member_list = set([av.lower() for av in entry.get('member', [])]) > > and then: > > if not dn.lower() in member_list: > > If one already knows which DN to add it's more easy anyway. > > Note that DNs are not case-insensitive in general. E.g. OpenLDAP looks applys > the exact matching rules for the attributes used in a DN. > > Ciao, Michael. From mailinglist0 at skurfer.com Thu Sep 1 16:30:01 2011 From: mailinglist0 at skurfer.com (Rob McBroom) Date: Thu, 1 Sep 2011 10:30:01 -0400 Subject: [python-ldap] GSSAPI and Active Directory Message-ID: I'm unable to search Active Directory with GSSAPI for some reason. The behavior described below doesn't seem to be version dependent. It's exactly the same on a RHEL5 box (Python 2.4.3, python-ldap 2.2.0, OpenLDAP 2.3.43) or an up-to-date Mac OS X box (Python 2.7.1, python-ldap 2.4.3, OpenLDAP 2.4.23). Here's a small test script I've been using. import ldap import ldap.sasl adconn = ldap.initialize('ldap://employer.com') auth_tokens = ldap.sasl.gssapi() adconn.sasl_interactive_bind_s('', auth_tokens) ad_search = adconn.search_s( 'dc=employer,dc=com', ldap.SCOPE_SUBTREE, '(&(objectClass=user)(sn=McBroom))', ['sAMAccountName', 'userPrincipalName'] ) It fails every time with ldap.OPERATIONS_ERROR: {'info': '000004DC: LdapErr: DSID-0C0906DC, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db0', 'desc': 'Operations error'} The same script works if I point it at one of our OpenLDAP servers. The command-line tools like `ldapwhoami` and `ldapsearch` work with both AD and OpenLDAP. Based on some digging with WireShark, the bind to the AD server is successful. The AD and OpenLDAP connections look about the same up to that point. But when `search_s` gets called, against OpenLDAP everything is encrypted in "SASL GSS-API Privacy" packets from then on. Against AD, the search is sent in the clear. Any ideas? Is it not using the existing (authenticated) connection or something? On a related note, the contents of `auth_tokens` appears to be identical whether a Kerberos ticket is available or not. I'd like to be able to test this *before* a bind (to fall back on simple authentication, SASL external, etc). Is there a way to tell (besides something clunky like calling `klist -s`)? Thanks. -- Rob McBroom From michael at stroeder.com Thu Sep 1 23:10:19 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 01 Sep 2011 23:10:19 +0200 Subject: [python-ldap] GSSAPI and Active Directory In-Reply-To: References: Message-ID: <4E5FF4BB.3050206@stroeder.com> Rob McBroom wrote: > I'm unable to search Active Directory with GSSAPI for some reason. Hard to tell. It works for me. Are you sure that ldapsearch -Y GSSAPI works from the very same system and using the very same OpenLDAP libs like your Python code? Did kinit work? Does your Python code have access to the TGT cache? Ciao, Michael. From mailinglist0 at skurfer.com Fri Sep 2 04:27:14 2011 From: mailinglist0 at skurfer.com (Rob McBroom) Date: Thu, 1 Sep 2011 22:27:14 -0400 Subject: [python-ldap] GSSAPI and Active Directory In-Reply-To: <4E5FF4BB.3050206@stroeder.com> References: <4E5FF4BB.3050206@stroeder.com> Message-ID: <7F1133A8-5ED1-4883-9BD0-9F8035BE4267@skurfer.com> On Sep 1, 2011, at 5:10 PM, Michael Str?der wrote: > Hard to tell. It works for me. Well, good to know it?s possible in theory. > Are you sure that ldapsearch -Y GSSAPI works from the very same system and > using the very same OpenLDAP libs like your Python code? I don?t usually explicitly give the -Y option, but there?s no place my identity could be coming from other than GSSAPI so, yes. The ?same? LDAP libs? Technically, no on the Mac. Same version, but not the same files. Perhaps you remember an [earlier discussion][1] on that. But that?s clearly not the problem. The error was the same on 10.6, where the libraries were literally the same and on a RHEL5 system where everything is coming from ?official? packages. > Did kinit work? Of course. > Does your Python code have access to the TGT cache? I don?t know how to test that directly, but like I said, it works when searching OpenLDAP so I have to assume it does. And the bind succeeds with the AD server. It?s only when searching that it complains. It seems to act as if the bind never took place. In fact, I just tested the script with the bind statement commented out and the error is the same. [1]: http://projects.skurfer.com/posts/2011/python_ldap_lion/ -- Rob McBroom From michael at stroeder.com Fri Sep 2 20:26:19 2011 From: michael at stroeder.com (=?windows-1252?Q?Michael_Str=F6der?=) Date: Fri, 02 Sep 2011 20:26:19 +0200 Subject: [python-ldap] GSSAPI and Active Directory In-Reply-To: <7F1133A8-5ED1-4883-9BD0-9F8035BE4267@skurfer.com> References: <4E5FF4BB.3050206@stroeder.com> <7F1133A8-5ED1-4883-9BD0-9F8035BE4267@skurfer.com> Message-ID: <4E611FCB.2050400@stroeder.com> Rob McBroom wrote: >> Does your Python code have access to the TGT cache? > > I don?t know how to test that directly, but like I said, it works when > searching OpenLDAP so I have to assume it does. And the bind succeeds with > the AD server. It?s only when searching that it complains. It seems to act > as if the bind never took place. In fact, I just tested the script with the > bind statement commented out and the error is the same. I'd first set trace_level to 2 to check whether the bind method is called at all. http://www.python-ldap.org/doc/html/ldap.html#ldap.initialize Ciao, Michael. From mailinglist0 at skurfer.com Sat Sep 3 04:28:01 2011 From: mailinglist0 at skurfer.com (Rob McBroom) Date: Fri, 2 Sep 2011 22:28:01 -0400 Subject: [python-ldap] GSSAPI and Active Directory In-Reply-To: <4E611FCB.2050400@stroeder.com> References: <4E5FF4BB.3050206@stroeder.com> <7F1133A8-5ED1-4883-9BD0-9F8035BE4267@skurfer.com> <4E611FCB.2050400@stroeder.com> Message-ID: <65CB1767-8C44-4902-9F2F-2D80CBB722B1@skurfer.com> On Sep 2, 2011, at 2:26 PM, Michael Str?der wrote: > I'd first set trace_level to 2 to check whether the bind method is called at all. > > http://www.python-ldap.org/doc/html/ldap.html#ldap.initialize I?ll try it next time I?m at work. I know the bind is happening (and succeeding) because I?m using WireShark to watch the whole thing, but maybe the increased trace level will provide other clues. -- Rob McBroom From michael at stroeder.com Sat Sep 3 14:33:14 2011 From: michael at stroeder.com (=?windows-1252?Q?Michael_Str=F6der?=) Date: Sat, 03 Sep 2011 14:33:14 +0200 Subject: [python-ldap] GSSAPI and Active Directory In-Reply-To: <65CB1767-8C44-4902-9F2F-2D80CBB722B1@skurfer.com> References: <4E5FF4BB.3050206@stroeder.com> <7F1133A8-5ED1-4883-9BD0-9F8035BE4267@skurfer.com> <4E611FCB.2050400@stroeder.com> <65CB1767-8C44-4902-9F2F-2D80CBB722B1@skurfer.com> Message-ID: <4E621E8A.30807@stroeder.com> Rob McBroom wrote: > On Sep 2, 2011, at 2:26 PM, Michael Str?der wrote: > >> I'd first set trace_level to 2 to check whether the bind method is called at all. >> >> http://www.python-ldap.org/doc/html/ldap.html#ldap.initialize > > I?ll try it next time I?m at work. I know the bind is happening (and > succeeding) because I?m using WireShark to watch the whole thing, but maybe > the increased trace level will provide other clues. wireshark tells you what happens on the wire but the trace_level tells you what happens within your application at python-ldap API level. So it's quite different. Ciao, Michael. From mailinglist0 at skurfer.com Tue Sep 6 22:01:42 2011 From: mailinglist0 at skurfer.com (Rob McBroom) Date: Tue, 6 Sep 2011 16:01:42 -0400 Subject: [python-ldap] GSSAPI and Active Directory In-Reply-To: <4E611FCB.2050400@stroeder.com> References: <4E5FF4BB.3050206@stroeder.com> <7F1133A8-5ED1-4883-9BD0-9F8035BE4267@skurfer.com> <4E611FCB.2050400@stroeder.com> Message-ID: <27176BA0-08FB-4CC0-A949-2851DB0A9EC2@skurfer.com> On Sep 2, 2011, at 2:26 PM, Michael Str?der wrote: > I'd first set trace_level to 2 to check whether the bind method is called at all. It is called, and I now I *know* it?s working because I?ve added a call to whoami_s before the search which correctly identifies me. *** ldap://employer.com - SimpleLDAPObject.set_option ((17, 3), {}) => result: None *** ldap://employer.com - SimpleLDAPObject.sasl_interactive_bind_s (('', , None, None, 2), {}) => result: 0 *** ldap://employer.com - SimpleLDAPObject.whoami_s ((None, None), {}) => result: 'u:EMPLOYER\\Username' *** ldap://employer.com - SimpleLDAPObject.search_ext (('dc=employer,dc=com', 2, '(sn=McBroom)', ['sAMAccountName', 'userPrincipalName'], 0, None, None, -1, 0), {}) => result: 4 *** ldap://employer.com - SimpleLDAPObject.result4 ((4, 1, -1, 0, 0, 0), {}) => LDAPError - OPERATIONS_ERROR: {'info': '000004DC: LdapErr: DSID-0C0906DC, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db0', 'desc': 'Operations error?} -- Rob McBroom From michael at stroeder.com Wed Sep 7 08:58:18 2011 From: michael at stroeder.com (=?windows-1252?Q?Michael_Str=F6der?=) Date: Wed, 07 Sep 2011 08:58:18 +0200 Subject: [python-ldap] GSSAPI and Active Directory In-Reply-To: <27176BA0-08FB-4CC0-A949-2851DB0A9EC2@skurfer.com> References: <4E5FF4BB.3050206@stroeder.com> <7F1133A8-5ED1-4883-9BD0-9F8035BE4267@skurfer.com> <4E611FCB.2050400@stroeder.com> <27176BA0-08FB-4CC0-A949-2851DB0A9EC2@skurfer.com> Message-ID: <4E67160A.8050407@stroeder.com> Rob McBroom wrote: > On Sep 2, 2011, at 2:26 PM, Michael Str?der wrote: > >> I'd first set trace_level to 2 to check whether the bind method is called at all. > > It is called, and I now I *know* it?s working because I?ve added a call to > whoami_s before the search which correctly identifies me. So this is W2K8 since the Who Am I extended operation is not supported in W2K3. I don't have a test machine of W2K8 at hand. > *** ldap://employer.com - SimpleLDAPObject.set_option > ((17, 3), {}) > => result: > None > *** ldap://employer.com - SimpleLDAPObject.sasl_interactive_bind_s > (('', , None, None, 2), {}) > => result: > 0 > *** ldap://employer.com - SimpleLDAPObject.whoami_s > ((None, None), {}) > => result: > 'u:EMPLOYER\\Username' > *** ldap://employer.com - SimpleLDAPObject.search_ext > (('dc=employer,dc=com', > 2, > '(sn=McBroom)', > ['sAMAccountName', 'userPrincipalName'], > 0, > None, > None, > -1, > 0), > {}) > => result: > 4 > *** ldap://employer.com - SimpleLDAPObject.result4 > ((4, 1, -1, 0, 0, 0), {}) > => LDAPError - OPERATIONS_ERROR: {'info': '000004DC: LdapErr: DSID-0C0906DC, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db0', 'desc': 'Operations error?} Are you 100% sure that the very same LDAPObject instance is used when doing the search? I note a deficiency of the trace logging since it does not print the object id. Ciao, Michael. From mailinglist0 at skurfer.com Wed Sep 7 15:07:47 2011 From: mailinglist0 at skurfer.com (Rob McBroom) Date: Wed, 7 Sep 2011 09:07:47 -0400 Subject: [python-ldap] GSSAPI and Active Directory In-Reply-To: <4E67160A.8050407@stroeder.com> References: <4E5FF4BB.3050206@stroeder.com> <7F1133A8-5ED1-4883-9BD0-9F8035BE4267@skurfer.com> <4E611FCB.2050400@stroeder.com> <27176BA0-08FB-4CC0-A949-2851DB0A9EC2@skurfer.com> <4E67160A.8050407@stroeder.com> Message-ID: On Sep 7, 2011, at 2:58 AM, Michael Str?der wrote: > So this is W2K8 since the Who Am I extended operation is not supported in > W2K3. I don't have a test machine of W2K8 at hand. Yes, it?s 2008. I didn?t try this when we were still on 2003, so I can?t say what the result would have been. > Are you 100% sure that the very same LDAPObject instance is used when doing > the search? I note a deficiency of the trace logging since it does not print > the object id. I?m only creating one, so it has to be. It's just a bare-bones test script at this point. import ldap import ldap.sasl adconn = ldap.initialize('ldap://employer.com', trace_level=2) auth_tokens = ldap.sasl.gssapi() adconn.sasl_interactive_bind_s('', auth_tokens) adconn.whoami_s() ad_search = adconn.search_s( 'dc=employer,dc=com', ldap.SCOPE_SUBTREE, '(sn=McBroom)', ['sAMAccountName', 'userPrincipalName'] ) for (dn, attrs) in ad_search: print attrs['sAMAccountName'][0] -- Rob McBroom From ziade.tarek at gmail.com Thu Sep 8 11:48:58 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Thu, 8 Sep 2011 11:48:58 +0200 Subject: [python-ldap] Ldap connectors pool Message-ID: Hey I've been working on a pool class for ldap connectors, we're using for the Firefox Sync server. It's a very simple class that provides a context manager to create connectors, and offers features like: - recycling existing connectors to avoid reconnections - handles several connection binds - retry a few times when the server is down or times out - provides a max lifetime for connectors -- this is useful when you have several ldap servers load balanced and you add a new one in the pool: fresh connectors will use this new server ** It's been running in production for a few months now, except ** which is to be introduced soon, All those features are pretty generic and it seems to me that it would be a good addition to the python-ldap project, since I haven't seen such thing there when I started this. If there's interest, I can isolate the pool, document it, and turn it into a patch for Python-ldap the code: https://hg.mozilla.org/services/server-core/file/tip/services/ldappool.py Example of usage: cm = ConnectionManager('ldap://localhost') with cm.connection('bind', 'password') as conn: ... do something with conn... Cheers Tarek -- Tarek Ziad? | http://ziade.org From jens at dataflake.org Mon Sep 12 16:37:57 2011 From: jens at dataflake.org (Jens Vagelpohl) Date: Mon, 12 Sep 2011 16:37:57 +0200 Subject: [python-ldap] Ldap connectors pool In-Reply-To: References: Message-ID: On Sep 8, 2011, at 11:48 , Tarek Ziad? wrote: > All those features are pretty generic and it seems to me that it would > be a good addition to the python-ldap project, since I haven't seen > such thing there when I started this. > > If there's interest, I can isolate the pool, document it, and turn it > into a patch for Python-ldap +1 jens From michael at stroeder.com Wed Sep 14 21:26:39 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 14 Sep 2011 21:26:39 +0200 Subject: [python-ldap] Ldap connectors pool In-Reply-To: References: Message-ID: <4E70FFEF.2020609@stroeder.com> Tarek Ziad? wrote: > I've been working on a pool class for ldap connectors, we're using for > the Firefox Sync server. > [..] > Example of usage: > > cm = ConnectionManager('ldap://localhost') > > with cm.connection('bind', 'password') as conn: > ... do something with conn... Hmm, so it provides a slighty different API? I'd really prefer something which is a drop-in replacement for an LDAPObject class not limiting what can be done with the current API. Ciao, Michael. From ziade.tarek at gmail.com Wed Sep 14 23:27:02 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Wed, 14 Sep 2011 23:27:02 +0200 Subject: [python-ldap] Ldap connectors pool In-Reply-To: <4E70FFEF.2020609@stroeder.com> References: <4E70FFEF.2020609@stroeder.com> Message-ID: 2011/9/14 Michael Str?der : > Tarek Ziad? wrote: >> I've been working on a pool class for ldap connectors, we're using for >> the Firefox Sync server. >> [..] >> Example of usage: >> >> ? cm = ConnectionManager('ldap://localhost') >> >> ? with cm.connection('bind', 'password') as conn: >> ? ? ? ... do something with conn... > > Hmm, so it provides a slighty different API? The connection manager returns ldap objects actually, The addition is that you get a context manager to get that ldap object and it takes care of recycling it when you get out if the with block. > > I'd really prefer something which is a drop-in replacement for an LDAPObject > class not limiting what can be done with the current API. So right now we have: 1/ a connection pool (ConnectionManager in our case) 2/ ldap objects returned by the connection pool #1 is a new thing, #2 does not introduce any change to the existing api of the LDAP object, but adds the get_lifetime() API. Another ldap object could be used there (you can provide your own, it's an option) and the lifetime feature could be deactivated in that case Cheers > Ciao, Michael. > -- Tarek Ziad? | http://ziade.org From michael at stroeder.com Tue Sep 20 10:38:23 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 20 Sep 2011 10:38:23 +0200 Subject: [python-ldap] Ldap connectors pool In-Reply-To: References: <4E70FFEF.2020609@stroeder.com> Message-ID: <4E7850FF.7040208@stroeder.com> Tarek Ziad? wrote: > 2011/9/14 Michael Str?der : >> Tarek Ziad? wrote: >>> I've been working on a pool class for ldap connectors, we're using for >>> the Firefox Sync server. >>> [..] >>> Example of usage: >>> >>> cm = ConnectionManager('ldap://localhost') >>> >>> with cm.connection('bind', 'password') as conn: >>> ... do something with conn... >> >> Hmm, so it provides a slighty different API? > > The connection manager returns ldap objects actually, > > The addition is that you get a context manager to get that ldap object > and it takes care of recycling it when you get out if the with block. Hmm, being rather old-fashioned I'm not familiar with the context manager paradigm which was introduced in Python 2.5. It seems to be elegant but I'm not sure how common this is for developers using python-ldap. So far my posting "Minimum Python version supported by python-ldap?" sent 2nd August 2011 did not receive any answers...but this is relevant for that. Ciao, Michael. From raj at csub.edu Thu Sep 22 04:00:22 2011 From: raj at csub.edu (Russell Jackson) Date: Wed, 21 Sep 2011 19:00:22 -0700 Subject: [python-ldap] Ldap connectors pool In-Reply-To: <4E7850FF.7040208@stroeder.com> References: <4E70FFEF.2020609@stroeder.com> <4E7850FF.7040208@stroeder.com> Message-ID: <4E7A96B6.7090207@csub.edu> On 09/20/2011 01:38 AM, Michael Str?der wrote: > Tarek Ziad? wrote: >> 2011/9/14 Michael Str?der: >>> Tarek Ziad? wrote: >>>> I've been working on a pool class for ldap connectors, we're using for >>>> the Firefox Sync server. >>>> [..] >>>> Example of usage: >>>> >>>> cm = ConnectionManager('ldap://localhost') >>>> >>>> with cm.connection('bind', 'password') as conn: >>>> ... do something with conn... >>> >>> Hmm, so it provides a slighty different API? >> >> The connection manager returns ldap objects actually, >> >> The addition is that you get a context manager to get that ldap object >> and it takes care of recycling it when you get out if the with block. > > Hmm, being rather old-fashioned I'm not familiar with the context manager > paradigm which was introduced in Python 2.5. It seems to be elegant but I'm > not sure how common this is for developers using python-ldap. > > So far my posting "Minimum Python version supported by python-ldap?" sent 2nd > August 2011 did not receive any answers...but this is relevant for that. I'd personally like to see that at least old-style classes went away. Trying to write mixin classes that chain __init__ require using a derived LDAPObject that also inherits object and then overriding MRO (move the old-style classes to the end) in a meta-class so that the old-style class doesn't short-circuit super(). So whatever version of Python introduced unified types should be the minimal version. As to the connection manager... couldn't you hijack __new__ in LDAPObject to return existing instances so that you could just use it the normal way without having the factory class? From ziade.tarek at gmail.com Thu Sep 22 09:59:54 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Thu, 22 Sep 2011 09:59:54 +0200 Subject: [python-ldap] Ldap connectors pool In-Reply-To: <4E7A96B6.7090207@csub.edu> References: <4E70FFEF.2020609@stroeder.com> <4E7850FF.7040208@stroeder.com> <4E7A96B6.7090207@csub.edu> Message-ID: On Thu, Sep 22, 2011 at 4:00 AM, Russell Jackson wrote: ... > > As to the connection manager... couldn't you hijack __new__ in LDAPObject to > return existing instances so that you could just use it the normal way > without having the factory class? I'd rather change the connection manager class itself, so it can be used with any existing LDAPObject class, IOW have two methods in it, something like: .create(bind=None, passwd=None, klass=LDAPObject) .recycle(instance) The patter would then become: cm = ConnectionManager(default_bind, default_password) connection = cn.create() try: ... do something finally: cm.recycle(connection) Cheers Tarek > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap > -- Tarek Ziad? | http://ziade.org From ziade.tarek at gmail.com Thu Sep 22 10:03:52 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Thu, 22 Sep 2011 10:03:52 +0200 Subject: [python-ldap] Ldap connectors pool In-Reply-To: <4E7850FF.7040208@stroeder.com> References: <4E70FFEF.2020609@stroeder.com> <4E7850FF.7040208@stroeder.com> Message-ID: 2011/9/20 Michael Str?der : ... > Hmm, being rather old-fashioned I'm not familiar with the context manager > paradigm which was introduced in Python 2.5. It seems to be elegant but I'm > not sure how common this is for developers using python-ldap. Context manager just makes the code simpler, thanks to 'with' But if it's just two method (see my previous post) It's good enough, I can add a context manager in my code. > So far my posting "Minimum Python version supported by python-ldap?" sent 2nd > August 2011 did not receive any answers...but this is relevant for that. I'd keep Python 2.4 and onward. I rarely see 2.3 and less these days, even in old RHEL flavors environments. Older softwares are probably not evolving anymore. Cheers Tarek -- Tarek Ziad? | http://ziade.org