From michael at stroeder.com Fri Apr 1 08:45:04 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 01 Apr 2011 08:45:04 +0200 Subject: Load Balance and Redundant LDAP config In-Reply-To: References: Message-ID: <4D957470.6060904@stroeder.com> Bob Brandt wrote: > I apologize if this is not the right place to ask this question... You're welcome to discuss this here. > I am looking to modify my LDAP scripts to be both Redundant and Load > Balancing! Although both things are mixed all the time these are two different goals. > Right now, I have a script that has a list of LDAP servers and uses the > first one that responses, but the problem is all later requests, use > that single LDAP server. If that server were to fail, the script fails. A simple solution would be to try to connect to a random LDAP server within the list and catch ldap.SERVER_DOWN to reconnect. You could have a look at ldap.ldapobject.ReconnectLDAPObject.reconnect() to get an idea how to do that automatically when serving sychronous calls. Feel free to provide an extension for ReconnectLDAPObject which deals with more than one server. If you're using the async methods your application has to deal with it. Ciao, Michael. From michael at stroeder.com Fri Apr 1 10:51:02 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 01 Apr 2011 10:51:02 +0200 Subject: [python-ldap] test posting Message-ID: <4D9591F6.8040902@stroeder.com> It works! From pakraticus at gmail.com Fri Apr 1 20:05:25 2011 From: pakraticus at gmail.com (Chris Dukes) Date: Fri, 01 Apr 2011 14:05:25 -0400 Subject: [python-ldap] Are there still enough python 2.1 users for python-ldap classes to be old style? Message-ID: <1301681125.13196.29.camel@pakrat-6223> I know per the FAQ python-ldap is tested with python 2.0 and up and should work with python 1.5. But given that python-ldap 2.4 requires openldap 2.4, is there any point in the classes remaining old style? At first glance only ldap/schema/models.py:class SchemaElement: ldap/schema/subentry.py:class SubSchema: ldap/__init__.py:class DummyLock: ldap/async.py:class AsyncSearchHandler: ldap/controls.py:class LDAPControl: ldap/ldapobject.py:class SimpleLDAPObject: ldap/resiter.py:class ResultProcessor: ldap/sasl.py:class sasl: dsml.py:class DSMLWriter: ldapurl.py:class LDAPUrlExtension: ldapurl.py:class LDAPUrl: ldif.py:class LDIFWriter: ldif.py:class LDIFParser: would need to be updated to new style objects. Chris Dukes From pakraticus at gmail.com Fri Apr 1 21:17:47 2011 From: pakraticus at gmail.com (Chris Dukes) Date: Fri, 01 Apr 2011 15:17:47 -0400 Subject: [python-ldap] Load Balance and Redundant LDAP config In-Reply-To: References: Message-ID: <1301685467.13196.91.camel@pakrat-6223> On Thu, 2011-03-31 at 11:51 +0100, Bob Brandt wrote: > I apologize if this is not the right place to ask this question... > > I am looking to modify my LDAP scripts to be both Redundant and Load > Balancing! > > For example I have a RADIUS server which runs a python script to > retrieve user's attributes from LDAP once they are authenticated. > > Right now, I have a script that has a list of LDAP servers and uses > the first one that responses, but the problem is all later requests, > use that single LDAP server. If that server were to fail, the script > fails. > > I guess my main question is: Is there a preferred method of supplying > Redundancy and/or Load Balancing? (I don't really want to reinvent the > wheel) Yes, and you're at the wrong end of the stack for load balancing. You use a TCP load balancer[1] or something like OpenLDAP's pcache/proxy overlay to provide load balancing and, in theory, high availability or DNS russian roulette (Sorry, round robin). You could write a TCP load balancer in python, but it'll be lower in the stack than python-ldap provides. The next problem is your script lacks robustness. Let's go for a simpler scenario. LAN monkey unplugs the ethernet cable to your single LDAP server for longer than the TCP Timeout period and plugs it back in again. Do you want your long running script to 1) Die a horrible death, hey you're good for this. 2) Die but be restarted immediately, supervisord or any number of other tools. 3) Setup the state required for the last operation and try it again. Well, you have some trying rewrites to accomplish. Now there is one failure scenario you might want to test. If you have DNS round robin setup and the first N-1 records point to servers that are up, but not running ldap, what does openldap do and what gets returned back to python-ldap. > > However, if I must reinvent the wheel, I am thinking along the lines > of opening multiple connections the each server and programmically > switching between thed different connections as they come up. > > Does this sound right? Any suggestions? > Thanks > Bob > > > > -- > What's the point of having a rapier wit if I can't use it to stab > people? - Jeph Jacques > ------------------------------------------------------------------------------ > Create and publish websites with WebMatrix > Use the most popular FREE web apps or write code yourself; > WebMatrix provides all the features you need to develop and > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf > _______________________________________________ > Python-LDAP-dev mailing list > Python-LDAP-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev From michael at stroeder.com Fri Apr 1 22:03:11 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 01 Apr 2011 22:03:11 +0200 Subject: [python-ldap] Are there still enough python 2.1 users for python-ldap classes to be old style? In-Reply-To: <1301681125.13196.29.camel@pakrat-6223> References: <1301681125.13196.29.camel@pakrat-6223> Message-ID: <4D962F7F.4040502@stroeder.com> Chris Dukes wrote: > I know per the FAQ python-ldap is tested with python 2.0 and up and > should work with python 1.5. But given that python-ldap 2.4 requires > openldap 2.4, is there any point in the classes remaining old style? Funny, for various reasons (e.g. sets) I thought about the minimum required Python version and I've also re-read the FAQ today. > At first glance only > ldap/schema/models.py:class SchemaElement: > ldap/schema/subentry.py:class SubSchema: > ldap/__init__.py:class DummyLock: > ldap/async.py:class AsyncSearchHandler: > ldap/controls.py:class LDAPControl: > ldap/ldapobject.py:class SimpleLDAPObject: > ldap/resiter.py:class ResultProcessor: > ldap/sasl.py:class sasl: > dsml.py:class DSMLWriter: > ldapurl.py:class LDAPUrlExtension: > ldapurl.py:class LDAPUrl: > ldif.py:class LDIFWriter: > ldif.py:class LDIFParser: > > would need to be updated to new style objects. What would be the benefits especially in python-ldap? I'm rather old-fashioned but willing to learn. Ciao, Michael. From pakraticus+python-ldap at gmail.com Fri Apr 1 22:33:26 2011 From: pakraticus+python-ldap at gmail.com (Chris Dukes) Date: Fri, 1 Apr 2011 21:33:26 +0100 Subject: [python-ldap] Are there still enough python 2.1 users for python-ldap classes to be old style? In-Reply-To: <4D962F7F.4040502@stroeder.com> References: <1301681125.13196.29.camel@pakrat-6223> <4D962F7F.4040502@stroeder.com> Message-ID: <20110401203326.GJ7226@ZenIV.linux.org.uk> On Fri, Apr 01, 2011 at 10:03:11PM +0200, Michael Str?der wrote: > Chris Dukes wrote: > > I know per the FAQ python-ldap is tested with python 2.0 and up and > > should work with python 1.5. But given that python-ldap 2.4 requires > > openldap 2.4, is there any point in the classes remaining old style? > > Funny, for various reasons (e.g. sets) I thought about the minimum required > Python version and I've also re-read the FAQ today. > > > At first glance only > > ldap/schema/models.py:class SchemaElement: > > ldap/schema/subentry.py:class SubSchema: > > ldap/__init__.py:class DummyLock: > > ldap/async.py:class AsyncSearchHandler: > > ldap/controls.py:class LDAPControl: > > ldap/ldapobject.py:class SimpleLDAPObject: > > ldap/resiter.py:class ResultProcessor: > > ldap/sasl.py:class sasl: > > dsml.py:class DSMLWriter: > > ldapurl.py:class LDAPUrlExtension: > > ldapurl.py:class LDAPUrl: > > ldif.py:class LDIFWriter: > > ldif.py:class LDIFParser: > > > > would need to be updated to new style objects. > > What would be the benefits especially in python-ldap? > I'm rather old-fashioned but willing to learn. The benefits. Refactoring. If i start with a class that inherits from ldap.async.LDAPWriter and decide ldap.async.AsyncSearchHandler works better, and LDAPWriter and AsyncSearchHandler are old style classes, I'll have to change ever mention of LDAPWriter in my class to AsyncSearchHandler. But if they are new style classes, I only have to change class MyClass(LDAPWriter): to class MyClass(AsyncSearchHandler): because i can use super(MyClass,self) instead of having to explicitly specifying the superclass throughout. And i apologize about the subtly different email address. I've moved most of my mail handling from mutt to evolution. Mutt will let me edit the From: line on the fly and automatically set the From: line on replies based on who I'm replying to. Evolution it appears I have to setup an account for each of them. > > Ciao, Michael. -- Chris Dukes Don't look a gift lion in the mouth. From netcrusher88 at gmail.com Tue Apr 5 04:17:44 2011 From: netcrusher88 at gmail.com (Joe Harrison) Date: Mon, 4 Apr 2011 19:17:44 -0700 Subject: [python-ldap] parsing raw LDAP protocol Message-ID: I'm working on a project to parse LDAP out of pcap files. Is there a way to (using python-ldap) hand the ldap library a raw LDAP packet to parse? From esiotrot at gmail.com Wed Apr 6 08:15:27 2011 From: esiotrot at gmail.com (Michael Wood) Date: Wed, 6 Apr 2011 08:15:27 +0200 Subject: [python-ldap] parsing raw LDAP protocol In-Reply-To: References: Message-ID: On 5 April 2011 04:17, Joe Harrison wrote: > I'm working on a project to parse LDAP out of pcap files. Is there a > way to (using python-ldap) hand the ldap library a raw LDAP packet to > parse? I don't know the answer to your question, but I doubt it. But have you looked at the Wireshark LDAP dissector? -- Michael Wood From michael at stroeder.com Wed Apr 6 22:18:04 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 06 Apr 2011 22:18:04 +0200 Subject: [python-ldap] parsing raw LDAP protocol In-Reply-To: References: Message-ID: <4D9CCA7C.4050706@stroeder.com> Joe Harrison wrote: > I'm working on a project to parse LDAP out of pcap files. Is there a > way to (using python-ldap) hand the ldap library a raw LDAP packet to > parse? No, python-ldap is not capable of doing that. Maybe you could look at the dissectors in Wireshark and wrap something from there in a Python module. Or http://www.secdev.org/projects/scapy/ might be worth a look in your case too. Ciao, Michael. From pakraticus+python-ldap at gmail.com Thu Apr 7 21:04:50 2011 From: pakraticus+python-ldap at gmail.com (Chris Dukes) Date: Thu, 7 Apr 2011 20:04:50 +0100 Subject: [python-ldap] Python LDAP In-Reply-To: <4D9DFB9B.3080709@bubblenet.be> References: <4D9DFB9B.3080709@bubblenet.be> Message-ID: <20110407190449.GN7226@ZenIV.linux.org.uk> On Thu, Apr 07, 2011 at 07:59:55PM +0200, Godefroid Chapelle wrote: > Hi, > > I am trying to access a Lotus Notes LDAP server. > > I got the information from the Notes admin that I should use a Base DN > that consists of a single space. That feels very strange to me. The problem you are having is not specific to python-ldap, nor Lotus LDAP. Be the DN '' (an empty string) or ' ' (A space) or ' ' (Lots of spaces) it's the DN of the root of the tree on that LDAP server. > > Has one of the subscribers already succeeded to connect to Lotus Notes ? I suggest attempting the following against the Lotus Domino LDAP. ldapsearch -h LDAPServer -x -b '' -s base 'objectclass=*' This will return the LDAP entry for the root of the tree, which may or may not contain anything interesting. Now look one level further down. ldapsearch -h LDAPServer -x -b '' -s one 'objectclass=*' Which will probably show all of groups. > > Thanks > -- > Godefroid Chapelle (aka __gotcha) http://bubblenet.be > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Python-LDAP-dev mailing list > Python-LDAP-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev -- Chris Dukes Don't look a gift lion in the mouth. From gotcha at bubblenet.be Fri Apr 8 09:05:39 2011 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Fri, 08 Apr 2011 09:05:39 +0200 Subject: [python-ldap] Python LDAP In-Reply-To: <20110407190449.GN7226@ZenIV.linux.org.uk> References: <4D9DFB9B.3080709@bubblenet.be> <20110407190449.GN7226@ZenIV.linux.org.uk> Message-ID: <4D9EB3C3.8070805@bubblenet.be> Le 07/04/11 21:04, Chris Dukes a ?crit : > On Thu, Apr 07, 2011 at 07:59:55PM +0200, Godefroid Chapelle wrote: >> Hi, >> >> I am trying to access a Lotus Notes LDAP server. >> >> I got the information from the Notes admin that I should use a Base DN >> that consists of a single space. That feels very strange to me. > > The problem you are having is not specific to python-ldap, nor Lotus LDAP. > > Be the DN '' (an empty string) or ' ' (A space) or ' ' (Lots of spaces) > it's the DN of the root of the tree on that LDAP server. > >> >> Has one of the subscribers already succeeded to connect to Lotus Notes ? > > > I suggest attempting the following against the Lotus Domino LDAP. > ldapsearch -h LDAPServer -x -b '' -s base 'objectclass=*' > This will return the LDAP entry for the root of the tree, which may or may not > contain anything interesting. > > Now look one level further down. > ldapsearch -h LDAPServer -x -b '' -s one 'objectclass=*' > Which will probably show all of groups. > >> >> Thanks >> -- >> Godefroid Chapelle (aka __gotcha) http://bubblenet.be The hints you gave about the use of ldapsearch enabled me to understand better the setup of the Notes server I was trying to search. I have now a working setup : thanks for this ! -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be From michael at stroeder.com Fri Apr 8 13:53:40 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 08 Apr 2011 13:53:40 +0200 Subject: [python-ldap] More on ldap.controls in python-ldap 2.4 Message-ID: <4D9EF744.9050502@stroeder.com> HI! Please review what has been done in module ldap.controls and related stuff in LDAPObject.result4(): 1. ldap.controls resides in in Lib/ldap/controls/ and has new sub-modules. 2. The API is not backwards compatible to python-ldap 2.3: Implementations of ResponseControl.decodeControlValue() do not return a result anymore. Instead implementations are expected to set appropriately named class attributes for the decoded control value fields. 3. check out argument knownLDAPControls for function ldap.controls.DecodeControlTuples() and accompanying argument resp_ctrl_classes for LDAPObject.result4() and the global response control class registry in ldap.controls.KNOWN_CONTROLS. 4. The following demo scripts have been updated to make use of the new API: Demo/page_control.py Demo/pyasn1/readentrycontrol.py 5. New sub-modules which make use of pyasn1 were added. These have to be explicitly imported to avoid requiring pyasn1 as mandantory installed module. Check out: Lib/ldap/controls/psearch.py Lib/ldap/controls/pyasn1ctrls.py Lib/ldap/controls/readentry.py Further issues: 1. Response controls are not returned by _s methods in general. This can be easily changed within LDAPObject class methods but makes results incompatible. But I guess no-one used the results anyway. 2. Especially there's no async variant of sasl_interactive_bind_s() so bind response controls are not accessible for LDAP SASL binds (e.g. ldap.controls.pyasn1ctrls.AuthorizationIdentityControl). 3. Response controls are not returned in case of a LDAPError exception being raised. Personally I'd prefer to let the C API return only error codes but together with all other result data including response controls and let LDAPObject.result4() raise the appropriate exception with response controls objects attached as exception class attribute. Your feedback and contributions (code and docs) are appreciated. Ciao, Michael. From michael at stroeder.com Sat Apr 9 11:44:08 2011 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Sat, 09 Apr 2011 11:44:08 +0200 Subject: [python-ldap] Fwd: [ldap] LDAPCon 2011 Call for Papers Message-ID: <4DA02A68.30402@stroeder.com> Hi together, there will be a 3rd LDAPcon this year organized by DAASI in Heidelberg, Germany. Maybe you're interested in presenting some of your work there. See official CfP below. Ciao, Michael. -------- Original Message -------- Subject: [ldap] LDAPCon 2011 Call for Papers Date: Fri, 08 Apr 2011 14:46:47 +0200 From: Peter Gietz To: ldap at umich.edu With the usual apologies. The 3rd Edition of the International Conference on LDAP (LDAPCon 2011[1]) will be held on October, 10-11, 2011 in Heidelberg, Germany. A Call For Papers[2] has been raised and the Program Committee asks you to submit abstracts by July 8th. The International Conference on LDAP is a technical forum for IT professionals interested in LDAP and related topics like directory servers, directory management applications, directory integration, identity and access management, and meta directories. It focuses on implementation and integration of LDAP servers and LDAP-enabled client applications. The event will bring together vendors, developers, active and prospective LDAP practitioners to share their experiences about deployment strategies, service operations, interoperability, discuss LDAP usage in new projects and learn about upcoming trends and developments. The 1st LDAPCon[3] was held in September 2007 in Germany, the 2nd LDAPCon[4] was held in September 2009 in Portland, Oregon, USA (Some pictures from LDAPCon 2007 [5] and a nice summary of LDAPCon 2009 [6]) So if you're involved with LDAP in interesting projects and you want to share your experiences, please check the Call For Papers and submit a proposal. Best, Peter [1]: http://www.ldapcon.org [2]: http://www.daasi.de/ldapcon2011/index.php?site=cfp [3]: http://www.guug.de/veranstaltungen/ldapcon2007/index.html [4]: http://www.symas.com/ldapcon2009 [5]: http://www.flickr.com/photos/ludovic_p/sets/72157601937159198/detail/ [6]: http://blogs.sun.com/Ludo/entry/ldapcon_2009_summary -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 407109-0 Europaplatz 3 Fax: +49 7071 407109-9 D-72074 T?bingen mail: peter.gietz at daasi.de Germany Web: www.daasi.de DAASI International GmbH, T?bingen Gesch?ftsf?hrer Peter Gietz, Amtsgericht Stuttgart HRB 382175 Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From vanmeeuwen at kolabsys.com Mon Apr 11 12:21:29 2011 From: vanmeeuwen at kolabsys.com (Jeroen van Meeuwen (Kolab Systems)) Date: Mon, 11 Apr 2011 11:21:29 +0100 Subject: [python-ldap] [PATCH] Include modules in build / dist Message-ID: <201104111121.32843.vanmeeuwen@kolabsys.com> Hi Michael, please find attached a patch I needed to apply in order to get all 2.4 goodness packaged up. Hope this helps! Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: python-ldap-2.4.0-modules.patch Type: text/x-patch Size: 620 bytes Desc: not available URL: From michael at stroeder.com Mon Apr 11 12:37:11 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 11 Apr 2011 12:37:11 +0200 Subject: [python-ldap] [PATCH] Include modules in build / dist In-Reply-To: <201104111121.32843.vanmeeuwen@kolabsys.com> References: <201104111121.32843.vanmeeuwen@kolabsys.com> Message-ID: <4DA2D9D7.2040609@stroeder.com> Jeroen van Meeuwen (Kolab Systems) wrote: > please find attached a patch I needed to apply in order to get all 2.4 > goodness packaged up. Thanks for reminding me. I always forget to add new stuff to setup.py. Committed your patch slightly updates. Ciao, Michael. From vanmeeuwen at kolabsys.com Mon Apr 11 15:16:36 2011 From: vanmeeuwen at kolabsys.com (Jeroen van Meeuwen (Kolab Systems)) Date: Mon, 11 Apr 2011 14:16:36 +0100 Subject: [python-ldap] Imports from pyasn1 fail? Message-ID: <201104111416.37674.vanmeeuwen@kolabsys.com> Hi Michael, somehow imports from pyasn1 fail all over the place. I'm running pyasn1-0.0.13b and pyasn1-modules-0.0.1a, but the following snippet bails out: # Imports from pyasn1 from pyasn1.type import namedtype,namedval,univ,constraint from pyasn1.codec.ber import encoder,decoder from pyasn1_modules.rfc2251 import LDAPDN Stating: Traceback (most recent call last): File "persistent_search.py", line 7, in from ldap.controls import psearch File "/usr/lib64/python2.7/site-packages/ldap/controls/psearch.py", line 23, in from pyasn1.type import namedtype,namedval,univ,constraint ImportError: No module named type based on this morning's CVS head. I recon the dual use of 'pyasn1' on both ends is creating a namespace conflict. I worked around another occurence of this problem in ldap.controls.pyasn1 where the pyasn1.codec.ber could not be found, by making importing pyasn1 and making the calls to pyasn1.codec.ber.encoder/decoder.encode/decode fully qualified. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ville at torhonen.fi Mon Apr 11 15:14:59 2011 From: ville at torhonen.fi (Ville =?iso-8859-1?Q?T=F6rh=F6nen?=) Date: Mon, 11 Apr 2011 16:14:59 +0300 Subject: [python-ldap] GECOS and UTF-8 Message-ID: <20110411131458.GC10870@reformiklubi.fi> Hi. I've created a user management script with python-ldap and I'm having difficulties with accented characters such as "?" or "?", specifically in the GECOS field. This appears to work with cn. >>> a = "?" >>> b = "?" >>> gecos = a + b >>> gecos '\xc3\xa4\xc3\xb6' Now 'gecos' is a UTF-8 encoded string. If I then use it in a modlist and try to add the modlist into OpenLDAP, I get a traceback saying: ldap.INVALID_SYNTAX: {'info': 'gecos: value #0 invalid per syntax', 'desc': 'Invalid syntax'} If I try to add it as Unicode (gecos = gecos.decode('utf-8')), I get a traceback saying: TypeError: ('expected a string in the list', u'\xe4\xf6') Is there a solution for this? At the moment I have to modify the GECOS field manually by using Apache Directory Studio. -- Ville T?rh?nen From michael at stroeder.com Mon Apr 11 15:24:51 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 11 Apr 2011 15:24:51 +0200 Subject: [python-ldap] Imports from pyasn1 fail? In-Reply-To: <201104111416.37674.vanmeeuwen@kolabsys.com> References: <201104111416.37674.vanmeeuwen@kolabsys.com> Message-ID: <4DA30123.7090100@stroeder.com> Jeroen van Meeuwen (Kolab Systems) wrote: > from pyasn1.type import namedtype,namedval,univ,constraint > > ImportError: No module named type > > based on this morning's CVS head. I recon the dual use of 'pyasn1' on > both ends is creating a namespace conflict. Yes, that was a namespace conflict. Sorry, file Lib/ldap/controls/pyasn1 was junk accidently left in CVS. I had already removed it from your patch to setup.py. Please do a cvs up again. Thanks for testing. Ciao, Michael. From michael at stroeder.com Mon Apr 11 15:27:23 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 11 Apr 2011 15:27:23 +0200 Subject: [python-ldap] GECOS and UTF-8 In-Reply-To: <20110411131458.GC10870@reformiklubi.fi> References: <20110411131458.GC10870@reformiklubi.fi> Message-ID: <4DA301BB.4030901@stroeder.com> Ville T?rh?nen wrote: > I've created a user management script with python-ldap and I'm having > difficulties with accented characters such as "?" or "?", specifically > in the GECOS field. > > ldap.INVALID_SYNTAX: {'info': 'gecos: value #0 invalid per syntax', > 'desc': 'Invalid syntax'} That's because 'gecos' is declared with LDAP syntax IA5String. I doubt that you want to populate that anyway. > Is there a solution for this? At the moment I have to modify the GECOS field > manually by using Apache Directory Studio. And does it NON-ASCII chars with Apache Directory Studio? CIao, Michael. From vanmeeuwen at kolabsys.com Tue Apr 12 23:56:56 2011 From: vanmeeuwen at kolabsys.com (Jeroen van Meeuwen (Kolab Systems)) Date: Tue, 12 Apr 2011 22:56:56 +0100 Subject: [python-ldap] Struggling to implement persistent search Message-ID: <201104122256.57933.vanmeeuwen@kolabsys.com> Hi, I'm trying to implement the PersistentSearchControl with EntryChangeNotificationControl, but the latter does not seem to have a encodeControlValue method. The results I'm getting from a stand-alone PersistentSearchControl (using returnECs=True) however do not seem to represent the changeType in any way. Has somebody successfully implemented PersistentSearchControl with EntryChangeNotificationControl / changeType, or can somebody help me in trying to figure this one out? Thanks in advance, Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Apr 13 08:34:31 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 13 Apr 2011 08:34:31 +0200 Subject: [python-ldap] Struggling to implement persistent search In-Reply-To: <201104122256.57933.vanmeeuwen@kolabsys.com> References: <201104122256.57933.vanmeeuwen@kolabsys.com> Message-ID: <4DA543F7.9060408@stroeder.com> Jeroen van Meeuwen (Kolab Systems) wrote: > I'm trying to implement the PersistentSearchControl with > EntryChangeNotificationControl, but the latter does not seem to have a > encodeControlValue method. First of all: The API for LDAP controls changed. EntryChangeNotificationControl is only an instance of ResponseControl. > The results I'm getting from a stand-alone PersistentSearchControl > (using returnECs=True) however do not seem to represent the changeType > in any way. Please show your code. Note that ResponseControl.decodeControlValue() is supposed to set class attributes as side effect, not to return the decoded value anymore. Have a look at Demo/page_control.py to get the idea. In case of EntryChangeNotificationControl the relevant class attributes are changeType, changeNumber and previousDN. I've only tested this with Novell eDirectory which only returns changeType and previousDN in case of modRDN. > Has somebody successfully implemented PersistentSearchControl with > EntryChangeNotificationControl / changeType, Yes. The code in ldap.controls.psearch is result of a customer project. I want to add also some demo code in Demo/pyasn1/. Not sure when I have time to do that. Which LDAP server are you working with? Ciao, Michael. From vanmeeuwen at kolabsys.com Wed Apr 13 11:38:55 2011 From: vanmeeuwen at kolabsys.com (Jeroen van Meeuwen (Kolab Systems)) Date: Wed, 13 Apr 2011 10:38:55 +0100 Subject: [python-ldap] Struggling to implement persistent search In-Reply-To: <4DA543F7.9060408@stroeder.com> References: <201104122256.57933.vanmeeuwen@kolabsys.com> <4DA543F7.9060408@stroeder.com> Message-ID: <201104131038.56036.vanmeeuwen@kolabsys.com> Michael Str?der wrote: > Jeroen van Meeuwen (Kolab Systems) wrote: > > I'm trying to implement the PersistentSearchControl with > > EntryChangeNotificationControl, but the latter does not seem to have a > > encodeControlValue method. > > First of all: The API for LDAP controls changed. > > EntryChangeNotificationControl is only an instance of ResponseControl. > Yes, I should have noted I'm continuously working against CVS HEAD. > > The results I'm getting from a stand-alone PersistentSearchControl > > (using returnECs=True) however do not seem to represent the changeType > > in any way. > > Please show your code. Sure: http://hosted.kolabsys.com/~vanmeeuwen/persistent_search.py > Note that ResponseControl.decodeControlValue() is > supposed to set class attributes as side effect, not to return the decoded > value anymore. Have a look at Demo/page_control.py to get the idea. > I have page control implemented[1], with a routine that did not seem to work well for the persistent searching... not sure why but any suggestions are welcome! ;-) > In case of EntryChangeNotificationControl the relevant class attributes are > changeType, changeNumber and previousDN. > These are what I'm after. I'm just failing to implement it correctly. > > Has somebody successfully implemented PersistentSearchControl with > > EntryChangeNotificationControl / changeType, > > Yes. Cool, that's what I needed to hear after running in trial and error circles for much too long ;-) > The code in ldap.controls.psearch is result of a customer project. I > want to add also some demo code in Demo/pyasn1/. Not sure when I have time > to do that. > > Which LDAP server are you working with? > 389 Directory Server -so Netscape based as well. Kind regards, Jeroen van Meeuwen [1] http://git.kolab.org/pykolab/tree/pykolab/auth/ldap/__init__.py#n250 -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 77 340 9500 w: http://www.kolabsys.com pgp: 9342 BF08 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Apr 13 20:20:14 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 13 Apr 2011 20:20:14 +0200 Subject: [python-ldap] Struggling to implement persistent search In-Reply-To: <201104131038.56036.vanmeeuwen@kolabsys.com> References: <201104122256.57933.vanmeeuwen@kolabsys.com> <4DA543F7.9060408@stroeder.com> <201104131038.56036.vanmeeuwen@kolabsys.com> Message-ID: <4DA5E95E.6040308@stroeder.com> Jeroen van Meeuwen (Kolab Systems) wrote: > > Sure: http://hosted.kolabsys.com/~vanmeeuwen/persistent_search.py I see two problems in there: 1. You pass a list to argument resp_ctrl_classes of LDAPObject.result4(). This is supposed to be a dictionary. You can leave it as None and then the default registry ldap.controls.KNOWN_RESPONSE_CONTROLS of all imported response control class will be used. 2. You make an object with psearch.EntryChangeNotificationControl(). But resp_ctrl_classes only expects classes (as dictionary values). Ciao, Michael. From michael at stroeder.com Fri Apr 15 10:41:40 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 15 Apr 2011 10:41:40 +0200 Subject: [python-ldap] Struggling to implement persistent search In-Reply-To: <4DA543F7.9060408@stroeder.com> References: <201104122256.57933.vanmeeuwen@kolabsys.com> <4DA543F7.9060408@stroeder.com> Message-ID: <4DA804C4.3060808@stroeder.com> Michael Str?der wrote: > Jeroen van Meeuwen (Kolab Systems) wrote: >> Has somebody successfully implemented PersistentSearchControl with >> EntryChangeNotificationControl / changeType, > > I want to add also some demo code in Demo/pyasn1/. Not sure when I have > time to do that. Check this out: Demo/pyasn1/psearch.py (tested with OpenDJ) Ciao, Michael. From flo at chaoflow.net Thu Apr 21 22:58:21 2011 From: flo at chaoflow.net (Florian Friesdorf) Date: Thu, 21 Apr 2011 22:58:21 +0200 Subject: [python-ldap] python-ldap improvements: attribute conversion Message-ID: <87zknjuxsi.fsf@eve.chaoflow.net> Dear Vitaliy, dear Michael, @Vitaliy: just found your mail on python-ldap "LDAP attribute syntaxes to python data types conversion" from November [1], which sadly received no answer, but triggered my memory. @Michael: you write in the todo to check the mailing list archives with respect to unicode and attribute values - I was unable to find something, it would be great if you could provide pointers. I imported python-ldap to github [2] because I prefer it and intend to work (maybe with Vitaliy?) on patches. I do not intend to create a fork of python-ldap on pypi, highly value your work on python-ldap and want to help. Apart from attribute conversion, I am interest in more sophisticated reconnect management, which was also mentioned recently on the mailing list. I also work on bda.ldap/node.ext.ldap and would rather see corresponding functionality implemented properly in python-ldap or some dedicated addon, instead of every higher level ldap library reinventing the same cornered wheel. For me it looks like the attribute conversions could be handled by subclassing and overwriting _ldap_call [3], in pseudo-code: def _ldap_call(self, func, *args, **kwargs): args = deep_utf8_copy(args) kwargs = deep_utf8_copy(kwargs) res = super(...)... if not self.convmap: return res return check_for_things_to_convert(res, self.convmap) or more selectively in the affected methods. Attribute conversion maps could be generated from automatically parsing an ldap's schemas (if supported) or be provided by the user. There are more details to be taken care of, Vitaliy gave this already some thought in code contributed to higher level libraries. But before putting more effort in here, I'd like to know whether we are fully of track, or whether the general approach would be suitable for inclusion into python-ldap. [1] http://mail.python.org/pipermail/python-ldap/2010q4/002791.html [2] https://github.com/chaoflow/python-ldap [3] https://github.com/chaoflow/python-ldap/blob/master/Lib/ldap/ldapobject.py#L80 best regards -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From michael at stroeder.com Fri Apr 22 16:54:04 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 22 Apr 2011 16:54:04 +0200 Subject: [python-ldap] github etc. In-Reply-To: <87zknjuxsi.fsf@eve.chaoflow.net> References: <87zknjuxsi.fsf@eve.chaoflow.net> Message-ID: <4DB1968C.2070308@stroeder.com> Florian Friesdorf wrote: > I imported python-ldap to github [2] because I prefer it and intend to > work (maybe with Vitaliy?) on patches. I strongly dislike having python-ldap code on public services like github also for legal reasons. You should really check with python-ldap community before doing something like this. So please remove it from there! Note that for various similar reasons I will completely move away from SourceForge. I really appreciate when people contribute code. But please do so using the existing infrastructure! You can always sync a local git repo with CVS HEAD if that helps your work. BTW: Indeed I have some plans improving the infrastructure and using git or mercurial is on the roadmap. So the community's input on this is also very welcome. Ciao, Michael. From michael at stroeder.com Fri Apr 22 17:00:12 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 22 Apr 2011 17:00:12 +0200 Subject: [python-ldap] reconnect management In-Reply-To: <87zknjuxsi.fsf@eve.chaoflow.net> References: <87zknjuxsi.fsf@eve.chaoflow.net> Message-ID: <4DB197FC.4070909@stroeder.com> (I split your posting to several postings with distinct mail subjects) Florian Friesdorf wrote: > I am interest in more > sophisticated reconnect management, which was also mentioned recently on > the mailing list. Can you please point me to your former posting. I may have missed it. What exactly do you want to improve beyond ReconnectLDAPObject? Ciao, Michael. From michael at stroeder.com Fri Apr 22 17:15:25 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 22 Apr 2011 17:15:25 +0200 Subject: [python-ldap] O/R mapper In-Reply-To: <87zknjuxsi.fsf@eve.chaoflow.net> References: <87zknjuxsi.fsf@eve.chaoflow.net> Message-ID: <4DB19B8D.3080609@stroeder.com> Florian Friesdorf wrote: > For me it looks like the attribute conversions could be handled by > subclassing and overwriting _ldap_call [3], in pseudo-code: > > def _ldap_call(self, func, *args, **kwargs): > args = deep_utf8_copy(args) > kwargs = deep_utf8_copy(kwargs) > res = super(...)... > if not self.convmap: > return res > return check_for_things_to_convert(res, self.convmap) http://www.freeipa.org is doing something like this AFAICT with decorators. Check their code. But as repeated on this mailing list several times: In general this won't work without having knowledge of the subschema. E.g. your automatic conversion won't work for attributes like jpegPhoto, userCertificate, userPKCS12 etc. So you could have a look how web2ldap deals with all that based on schema-aware classes. Basically there are classes for each LDAP syntax registered by syntax OID with several possibilities to override that for certain attribute types. web2ldap itself is only interested in (Unicode) strings. One could extend the concept to convert to native Python data types. Ciao, Michael. From raj at csub.edu Fri Apr 22 21:37:08 2011 From: raj at csub.edu (Russell Jackson) Date: Fri, 22 Apr 2011 12:37:08 -0700 Subject: [python-ldap] github etc. In-Reply-To: <4DB1968C.2070308@stroeder.com> References: <87zknjuxsi.fsf@eve.chaoflow.net> <4DB1968C.2070308@stroeder.com> Message-ID: <4DB1D8E4.1060608@csub.edu> On 04/22/2011 07:54 AM, Michael Str?der wrote: > Florian Friesdorf wrote: >> I imported python-ldap to github [2] because I prefer it and intend to >> work (maybe with Vitaliy?) on patches. > > I strongly dislike having python-ldap code on public services like github also > for legal reasons. Curious. What is the reason for this concern? Using github makes it easy to share changes without email diff chaos. Is it because of github's business model? If so, would gitorious.org be acceptable? -- Russell A Jackson Network Analyst California State University, Bakersfield From michael at stroeder.com Sat Apr 23 01:23:00 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 23 Apr 2011 01:23:00 +0200 Subject: [python-ldap] github etc. In-Reply-To: <4DB1D8E4.1060608@csub.edu> References: <87zknjuxsi.fsf@eve.chaoflow.net> <4DB1968C.2070308@stroeder.com> <4DB1D8E4.1060608@csub.edu> Message-ID: <4DB20DD4.30306@stroeder.com> Russell Jackson wrote: > On 04/22/2011 07:54 AM, Michael Str?der wrote: >> Florian Friesdorf wrote: >>> I imported python-ldap to github [2] because I prefer it and intend to >>> work (maybe with Vitaliy?) on patches. >> >> I strongly dislike having python-ldap code on public services like github also >> for legal reasons. > > Curious. What is the reason for this concern? > > Using github makes it easy to share changes without email diff chaos. Is > it because of github's business model? If so, would gitorious.org be > acceptable? I understand quite well why one wants to use git. But I'm very cautious not to run into suspectible terms of use by any such public services. I'm not a lawyer and I won't pay lawyers to check the terms of use jungle of such a service. So please do yourself a favour and use the existing infrastructure. Up to now I was able to handle the small amount of patches submitted without problem. The only patch I requested the submitter to renew was against 2.3.13 for Python 3.x support while CVS HEAD already contained larger changes for upcoming python-ldap 2.4. Also please understand that if you plan larger changes discuss them on the mailing list first. I will give an indication whether I see a possibility to incorporate changes into python-ldap or not. Ciao, Michael. From flo at chaoflow.net Wed Apr 27 05:25:06 2011 From: flo at chaoflow.net (Florian Friesdorf) Date: Wed, 27 Apr 2011 05:25:06 +0200 Subject: [python-ldap] github etc. In-Reply-To: <4DB20DD4.30306@stroeder.com> References: <87zknjuxsi.fsf@eve.chaoflow.net> <4DB1968C.2070308@stroeder.com> <4DB1D8E4.1060608@csub.edu> <4DB20DD4.30306@stroeder.com> Message-ID: <871v0o2x65.fsf@eve.chaoflow.net> On Sat, 23 Apr 2011 01:23:00 +0200, Michael Str?der wrote: > Russell Jackson wrote: > > On 04/22/2011 07:54 AM, Michael Str?der wrote: > >> Florian Friesdorf wrote: > >>> I imported python-ldap to github [2] because I prefer it and intend to > >>> work (maybe with Vitaliy?) on patches. > >> > >> I strongly dislike having python-ldap code on public services like github also > >> for legal reasons. > > > > Curious. What is the reason for this concern? > > > > Using github makes it easy to share changes without email diff chaos. Is > > it because of github's business model? If so, would gitorious.org be > > acceptable? > > I understand quite well why one wants to use git. But I'm very cautious not to > run into suspectible terms of use by any such public services. I'm not a > lawyer and I won't pay lawyers to check the terms of use jungle of such a > service. So please do yourself a favour and use the existing infrastructure. I removed python-ldap from my github account for now. But, I do not understand why it is a problem, if I put its code there. Is it python-ldap's license that does not permit it? Shall I put it there under a different name? github explicitly states "We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours." [1] > Up to now I was able to handle the small amount of patches submitted without > problem. The only patch I requested the submitter to renew was against 2.3.13 > for Python 3.x support while CVS HEAD already contained larger changes for > upcoming python-ldap 2.4. > > Also please understand that if you plan larger changes discuss them on the > mailing list first. I will give an indication whether I see a possibility to > incorporate changes into python-ldap or not. My intention is not that you need to use github, but that I can use it with my colleges to cooperatively work on patches before submitting them to you for inclusion. Of course, I will discuss changes on the mailing list. You have your workflow for discussion and inclusion of patches, which I fully respect and will stick to. I would highly appreciate an explanation, why I shall not stick to my workflow for creation of patches. [1] http://help.github.com/terms/ -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From flo at chaoflow.net Wed Apr 27 05:31:55 2011 From: flo at chaoflow.net (Florian Friesdorf) Date: Wed, 27 Apr 2011 05:31:55 +0200 Subject: [python-ldap] github etc. In-Reply-To: <4DB1968C.2070308@stroeder.com> References: <87zknjuxsi.fsf@eve.chaoflow.net> <4DB1968C.2070308@stroeder.com> Message-ID: <87y62w1iac.fsf@eve.chaoflow.net> On Fri, 22 Apr 2011 16:54:04 +0200, Michael Str?der wrote: > I really appreciate when people contribute code. But please do so using the > existing infrastructure! Is there existing infrastructure, that enables me to publish patches without the need of exporting and emailing them for every minor change? > You can always sync a local git repo with CVS HEAD if > that helps your work. That's exactly what I did. But it is only of limited use, if other people cannot see what patches I am working on. > BTW: Indeed I have some plans improving the infrastructure and using > git or mercurial is on the roadmap. So the community's input on this > is also very welcome. As far as I know (I never used the combination myself), mercurial and bzr are able to use git as a backend and git is not able to use mercurial or bzr as a backend. Not to exclude git as a frontend, I recommend git as a backend. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From flo at chaoflow.net Wed Apr 27 05:37:05 2011 From: flo at chaoflow.net (Florian Friesdorf) Date: Wed, 27 Apr 2011 05:37:05 +0200 Subject: [python-ldap] reconnect management In-Reply-To: <4DB197FC.4070909@stroeder.com> References: <87zknjuxsi.fsf@eve.chaoflow.net> <4DB197FC.4070909@stroeder.com> Message-ID: <87vcy01i1q.fsf@eve.chaoflow.net> On Fri, 22 Apr 2011 17:00:12 +0200, Michael Str?der wrote: > (I split your posting to several postings with distinct mail subjects) > > Florian Friesdorf wrote: > > I am interest in more > > sophisticated reconnect management, which was also mentioned recently on > > the mailing list. > > Can you please point me to your former posting. I may have missed it. > > What exactly do you want to improve beyond ReconnectLDAPObject? It was a post by Bob Brandt, you answered here: http://mail.python.org/pipermail/python-ldap/2011q2/002850.html I am interested in reconnect + fail over. -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From flo at chaoflow.net Wed Apr 27 05:49:13 2011 From: flo at chaoflow.net (Florian Friesdorf) Date: Wed, 27 Apr 2011 05:49:13 +0200 Subject: [python-ldap] O/R mapper In-Reply-To: <4DB19B8D.3080609@stroeder.com> References: <87zknjuxsi.fsf@eve.chaoflow.net> <4DB19B8D.3080609@stroeder.com> Message-ID: <87r58o1hhi.fsf@eve.chaoflow.net> On Fri, 22 Apr 2011 17:15:25 +0200, Michael Str?der wrote: > Florian Friesdorf wrote: > > For me it looks like the attribute conversions could be handled by > > subclassing and overwriting _ldap_call [3], in pseudo-code: > > > > def _ldap_call(self, func, *args, **kwargs): > > args = deep_utf8_copy(args) > > kwargs = deep_utf8_copy(kwargs) > > res = super(...)... > > if not self.convmap: > > return res > > return check_for_things_to_convert(res, self.convmap) > > http://www.freeipa.org is doing something like this AFAICT with decorators. > Check their code. > > But as repeated on this mailing list several times: In general this won't work > without having knowledge of the subschema. E.g. your automatic conversion > won't work for attributes like jpegPhoto, userCertificate, userPKCS12 etc. > > Attribute conversion maps could be generated from automatically parsing > > an ldap's schemas (if supported) or be provided by the user. For fields were automatic conversion does not work, a conversion needs to be specified by the user of the library. Nevertheless, I think the place were the conversion is supposed to happen, is inside of python-ldap, because otherwise people will keep reinventing that functionality. > So you could have a look how web2ldap deals with all that based on > schema-aware classes. Basically there are classes for each LDAP syntax > registered by syntax OID with several possibilities to override that for > certain attribute types. web2ldap itself is only interested in (Unicode) > strings. One could extend the concept to convert to native Python data types. Thank you for the pointer, will definitely have a look at it. Why do you keep this functionality in web2ldap and not in python-ldap? -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: flo at chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From michael at stroeder.com Wed Apr 27 20:15:29 2011 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Wed, 27 Apr 2011 20:15:29 +0200 Subject: [python-ldap] reconnect management In-Reply-To: <87vcy01i1q.fsf@eve.chaoflow.net> References: <87zknjuxsi.fsf@eve.chaoflow.net> <4DB197FC.4070909@stroeder.com> <87vcy01i1q.fsf@eve.chaoflow.net> Message-ID: <4DB85D41.2050709@stroeder.com> Florian Friesdorf wrote: > On Fri, 22 Apr 2011 17:00:12 +0200, Michael Str?der wrote: >> (I split your posting to several postings with distinct mail subjects) >> >> Florian Friesdorf wrote: >>> I am interest in more >>> sophisticated reconnect management, which was also mentioned recently on >>> the mailing list. >> >> Can you please point me to your former posting. I may have missed it. >> >> What exactly do you want to improve beyond ReconnectLDAPObject? > > It was a post by Bob Brandt, you answered here: > http://mail.python.org/pipermail/python-ldap/2011q2/002850.html > > I am interested in reconnect + fail over. You have to carefully think about what you want to achieve and the obstacles for doing a fail-over. Things to think about: Support fail-over of write operations? What happens if applications do read-after-write or vice versa and there's a fail-over in the middle? You have to maintain a list of functional servers. You have to implement a strategy when to re-add a formerly failing server to the list of functional servers. etc. Ciao, Michael. From michael at stroeder.com Wed Apr 27 20:18:25 2011 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Wed, 27 Apr 2011 20:18:25 +0200 Subject: [python-ldap] O/R mapper In-Reply-To: <87r58o1hhi.fsf@eve.chaoflow.net> References: <87zknjuxsi.fsf@eve.chaoflow.net> <4DB19B8D.3080609@stroeder.com> <87r58o1hhi.fsf@eve.chaoflow.net> Message-ID: <4DB85DF1.5060400@stroeder.com> Florian Friesdorf wrote: > On Fri, 22 Apr 2011 17:15:25 +0200, Michael Str?der wrote: >> Florian Friesdorf wrote: >>> For me it looks like the attribute conversions could be handled by >>> subclassing and overwriting _ldap_call [3], in pseudo-code: >>> >>> def _ldap_call(self, func, *args, **kwargs): >>> args = deep_utf8_copy(args) >>> kwargs = deep_utf8_copy(kwargs) >>> res = super(...)... >>> if not self.convmap: >>> return res >>> return check_for_things_to_convert(res, self.convmap) >> >> http://www.freeipa.org is doing something like this AFAICT with decorators. >> Check their code. >> >> But as repeated on this mailing list several times: In general this won't work >> without having knowledge of the subschema. E.g. your automatic conversion >> won't work for attributes like jpegPhoto, userCertificate, userPKCS12 etc. > >>> Attribute conversion maps could be generated from automatically parsing >>> an ldap's schemas (if supported) or be provided by the user. > > For fields were automatic conversion does not work, a conversion needs > to be specified by the user of the library. Yes. So converting attribute values in LDAPObject._ldap_call() is the wrong place. >> So you could have a look how web2ldap deals with all that based on >> schema-aware classes. Basically there are classes for each LDAP syntax >> registered by syntax OID with several possibilities to override that for >> certain attribute types. web2ldap itself is only interested in (Unicode) >> strings. One could extend the concept to convert to native Python data types. > > Thank you for the pointer, will definitely have a look at it. > > Why do you keep this functionality in web2ldap and not in python-ldap? The schema-ware classes are tightly coupled to web2ldap's HTML generating needs and e.g. depend on pyweblib. You can use them as inspiration but not more. Ciao, Michael. From michael at stroeder.com Wed Apr 27 20:10:02 2011 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Wed, 27 Apr 2011 20:10:02 +0200 Subject: [python-ldap] github etc. In-Reply-To: <871v0o2x65.fsf@eve.chaoflow.net> References: <87zknjuxsi.fsf@eve.chaoflow.net> <4DB1968C.2070308@stroeder.com> <4DB1D8E4.1060608@csub.edu> <4DB20DD4.30306@stroeder.com> <871v0o2x65.fsf@eve.chaoflow.net> Message-ID: <4DB85BFA.4020301@stroeder.com> Florian Friesdorf wrote: >> I understand quite well why one wants to use git. But I'm very cautious not to >> run into suspectible terms of use by any such public services. I'm not a >> lawyer and I won't pay lawyers to check the terms of use jungle of such a >> service. So please do yourself a favour and use the existing infrastructure. > > I removed python-ldap from my github account for now. Thanks. > But, I do not > understand why it is a problem, if I put its code there. > > Is it python-ldap's license that does not permit it? > > Shall I put it there under a different name? > > github explicitly states "We claim no intellectual property rights over > the material you provide to the Service. Your profile and materials > uploaded remain yours." [1] Please re-read "I'm not a lawyer and I won't pay lawyers" and terms of use can change over time, e.g. when a service is bought by another company. I want to get rid of this all in mid-term. > My intention is not that you need to use github, but that I can use it > with my colleges to cooperatively work on patches before submitting them > to you for inclusion. I'm quite willing set up up a git repo if somebody proves there's a need for it. So please start working on specific items and the infrastructure will grow along with you submitting patches. Please understand that after over ten years of maintaining python-ldap my experience is that the few patches coming in do not justify spending my spare time to switch things. I will definitely change my mind if contributors send in more patches. > Of course, I will discuss changes on the mailing list. Thanks in advance for contributing. > You have your workflow for discussion and inclusion of patches, which I > fully respect and will stick to. I would highly appreciate an > explanation, why I shall not stick to my workflow for creation of > patches. Please, let's start working on concrete things and workflows will establish as needed. Ciao, Michael. From raj at csub.edu Wed Apr 27 20:32:27 2011 From: raj at csub.edu (Russell Jackson) Date: Wed, 27 Apr 2011 11:32:27 -0700 Subject: [python-ldap] github etc. In-Reply-To: <4DB85BFA.4020301@stroeder.com> References: <87zknjuxsi.fsf@eve.chaoflow.net> <4DB1968C.2070308@stroeder.com> <4DB1D8E4.1060608@csub.edu> <4DB20DD4.30306@stroeder.com> <871v0o2x65.fsf@eve.chaoflow.net> <4DB85BFA.4020301@stroeder.com> Message-ID: <4DB8613B.9080009@csub.edu> On 04/27/2011 11:10 AM, Michael Str?der wrote: > Please understand that after over ten years of maintaining python-ldap my > experience is that the few patches coming in do not justify spending my spare > time to switch things. I will definitely change my mind if contributors send > in more patches. > First. I think you my be causing a self-fulfilling prophecy. Ease of access to source code, tracking local changes (as well as upstream changes) and eventual reintegration might help to seed interest in the project. I know that I personally feel a certain level of repulsion when I have to deal with CVS. I'm probably not alone. Second. I think many of us are probably maintaining internal patch sets that are either not appropriate to be (e.g. specific to institution) or cannot be (e.g. due to legal issues) merged back upstream. An upstream git repository would make it damn near trivial to track upstream along with our local changes. With CVS, I have to periodically check CVS and sync it manually[1]. It works, but it's not ideal. 1. It's actually possible to mirror CVS to git (history and all) with `cvsto`, but you also have to also mirror the entire raw CVS respository locally as well. So it's a fair amount of infrastructure to setup. -- Russell A Jackson Network Analyst California State University, Bakersfield From michael at stroeder.com Wed Apr 27 20:48:00 2011 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Wed, 27 Apr 2011 20:48:00 +0200 Subject: [python-ldap] github etc. In-Reply-To: <4DB8613B.9080009@csub.edu> References: <87zknjuxsi.fsf@eve.chaoflow.net> <4DB1968C.2070308@stroeder.com> <4DB1D8E4.1060608@csub.edu> <4DB20DD4.30306@stroeder.com> <871v0o2x65.fsf@eve.chaoflow.net> <4DB85BFA.4020301@stroeder.com> <4DB8613B.9080009@csub.edu> Message-ID: <4DB864E0.5080301@stroeder.com> Russell Jackson wrote: > On 04/27/2011 11:10 AM, Michael Str?der wrote: >> Please understand that after over ten years of maintaining python-ldap my >> experience is that the few patches coming in do not justify spending my spare >> time to switch things. I will definitely change my mind if contributors send >> in more patches. > > First. I think you my be causing a self-fulfilling prophecy. Maybe. But instead of wasting time discussing workflows and infrastructure I'd like to get concrete issues solved. If somebody is seriously willing to help I'm glad pointing to the urgent issues. > Ease of > access to source code, tracking local changes (as well as upstream > changes) and eventual reintegration might help to seed interest in the > project. I know that I personally feel a certain level of repulsion when > I have to deal with CVS. I'm probably not alone. While I agree that CVS somewhat sucks and git/mercurial etc. are far better, please understand that my spare time is also limited. And you should appreciate that I'm cautious to ensure that the code stays free all the time. > Second. I think many of us are probably maintaining internal patch sets > that are either not appropriate to be (e.g. specific to institution) or > cannot be (e.g. due to legal issues) merged back upstream. An upstream > git repository would make it damn near trivial to track upstream along > with our local changes. With CVS, I have to periodically check CVS and > sync it manually[1]. It works, but it's not ideal. Again: My spare time is also limited. So if anybody out there feels having to maintain a private fork for whatever valid reason the necessary work is also private effort. I find it very strange that there are so many responses in this thread but no responses when I post concrete to-do lists. So for now I won't discuss this any further. Ciao, Michael. From raj at csub.edu Wed Apr 27 22:14:41 2011 From: raj at csub.edu (Russell Jackson) Date: Wed, 27 Apr 2011 13:14:41 -0700 Subject: [python-ldap] github etc. In-Reply-To: <4DB864E0.5080301@stroeder.com> References: <87zknjuxsi.fsf@eve.chaoflow.net> <4DB1968C.2070308@stroeder.com> <4DB1D8E4.1060608@csub.edu> <4DB20DD4.30306@stroeder.com> <871v0o2x65.fsf@eve.chaoflow.net> <4DB85BFA.4020301@stroeder.com> <4DB8613B.9080009@csub.edu> <4DB864E0.5080301@stroeder.com> Message-ID: <4DB87931.4030602@csub.edu> On 04/27/2011 11:48 AM, Michael Str?der wrote: > I find it very strange that there are so many responses in this thread but no > responses when I post concrete to-do lists. Because library design is hard, but everyone has their favorite VCS ;-). -- Russell A Jackson Network Analyst California State University, Bakersfield From michael at stroeder.com Fri Apr 29 18:03:47 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 29 Apr 2011 18:03:47 +0200 Subject: [python-ldap] C programmers needed (was: More on ldap.controls in python-ldap 2.4) In-Reply-To: <4D9EF744.9050502@stroeder.com> References: <4D9EF744.9050502@stroeder.com> Message-ID: <4DBAE163.7040104@stroeder.com> HI! Michael Str?der wrote: > Further issues: > > 2. Especially there's no async variant of sasl_interactive_bind_s() so bind > response controls are not accessible for LDAP SASL binds (e.g. > ldap.controls.pyasn1ctrls.AuthorizationIdentityControl). > > 3. Response controls are not returned in case of a LDAPError exception being > raised. Personally I'd prefer to let the C API return only error codes but > together with all other result data including response controls and let > LDAPObject.result4() raise the appropriate exception with response controls > objects attached as exception class attribute. Any contributors familiar with C programming for issues 2. and 3.? Also there's still an open issue with intermediate responses which are no search results. E.g. for full syncrepl support returning those would be needed. At least the whole BER data to be parsed outside python-ldap. Ciao, Michael. From vanmeeuwen at kolabsys.com Sat May 7 23:14:23 2011 From: vanmeeuwen at kolabsys.com (Jeroen van Meeuwen (Kolab Systems)) Date: Sat, 7 May 2011 17:14:23 -0400 Subject: [python-ldap] Struggling to implement persistent search In-Reply-To: <4DA804C4.3060808@stroeder.com> References: <201104122256.57933.vanmeeuwen@kolabsys.com> <4DA543F7.9060408@stroeder.com> <4DA804C4.3060808@stroeder.com> Message-ID: <201105071714.23737.vanmeeuwen@kolabsys.com> Michael Str?der wrote: > Michael Str?der wrote: > > Jeroen van Meeuwen (Kolab Systems) wrote: > >> Has somebody successfully implemented PersistentSearchControl with > >> EntryChangeNotificationControl / changeType, > > > > I want to add also some demo code in Demo/pyasn1/. Not sure when I have > > time to do that. > > Check this out: Demo/pyasn1/psearch.py (tested with OpenDJ) > You rock! This sort of example is exactly what I needed ;-) Tested and confirmed to work with 389 DS, Red Hat DS 8.x ;-) I'll let you know whether it works with Sun DS 5.x as well, later this week. Apologies for the delay! Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thorsten at thorstenkampe.de Tue May 17 14:02:35 2011 From: thorsten at thorstenkampe.de (Thorsten Kampe) Date: Tue, 17 May 2011 14:02:35 +0200 Subject: [python-ldap] Querying Active Directory excessively slower than querying eDirectory Message-ID: <1305633755.28094.1452812281@webmail.messagingengine.com> Hi, I have a little scripts that queries LDAP servers. Querying Active Directory is ridiculously slower than querying eDirectory on the same host. This is not a connection issue - a Wireshark trace shows that both LDAP services return the data within one second. The data returned by eDirectory is about 560 objects (37 Kb) and by Active Directory 222 objects (19 Kb). The query is... # "1.1" means "no attributes" result = connection.search_s(base, ldap.SCOPE_SUBTREE, attrlist = ['1.1'], attrsonly = True) Is there anything to explain the results below?? Python 2.7.1 on Windows 7 SP1 (thumb drive): eDirectory 8.8.6: 2 seconds Active Directory: 44 seconds Python 2.7.1 on Gentoo Linux: eDirectory 8.8.6: 0.3 seconds Active Directory: 440 seconds LDAP host: Windows 2008 R2 SP1 Python LDAP 2.3.13 Thorsten From michael at stroeder.com Tue May 17 14:14:01 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 17 May 2011 14:14:01 +0200 Subject: [python-ldap] Querying Active Directory excessively slower than querying eDirectory In-Reply-To: <1305633755.28094.1452812281@webmail.messagingengine.com> References: <1305633755.28094.1452812281@webmail.messagingengine.com> Message-ID: <4DD26689.2050604@stroeder.com> Thorsten, without knowing more details one cannot really comment on this. Just wild guesses: Something related to DNS? Or referral chasing? (MS AD returns referrals) Did you try to turn off automatic referral chasing? Is the time measured only the call to connection.search_s() or does it include connecting to the server? Which is the search base? The search filter? Ciao, Michael. Thorsten Kampe wrote: > Hi, > > I have a little scripts that queries LDAP servers. Querying Active > Directory is ridiculously slower than querying eDirectory on the same > host. > > This is not a connection issue - a Wireshark trace shows that both LDAP > services return the data within one second. The data returned by > eDirectory is about 560 objects (37 Kb) and by Active Directory 222 > objects (19 Kb). > > The query is... > > # "1.1" means "no attributes" > result = connection.search_s(base, ldap.SCOPE_SUBTREE, attrlist = > ['1.1'], attrsonly = True) > > Is there anything to explain the results below?? > > Python 2.7.1 on Windows 7 SP1 (thumb drive): > eDirectory 8.8.6: 2 seconds > Active Directory: 44 seconds > > Python 2.7.1 on Gentoo Linux: > eDirectory 8.8.6: 0.3 seconds > Active Directory: 440 seconds > > LDAP host: Windows 2008 R2 SP1 > Python LDAP 2.3.13 > > Thorsten From thorsten at thorstenkampe.de Tue May 17 14:34:46 2011 From: thorsten at thorstenkampe.de (Thorsten Kampe) Date: Tue, 17 May 2011 14:34:46 +0200 Subject: [python-ldap] Querying Active Directory excessively slower than querying eDirectory In-Reply-To: <4DD26689.2050604@stroeder.com> References: <1305633755.28094.1452812281@webmail.messagingengine.com> <4DD26689.2050604@stroeder.com> Message-ID: <1305635686.5820.1452837041@webmail.messagingengine.com> * Michael Str?der (2011-05-17 14:14 +0200) > without knowing more details one cannot really comment on this. Just wild > guesses: > > Something related to DNS? > > Or referral chasing? (MS AD returns referrals) > Did you try to turn off automatic referral chasing? It's not a connection issue. As I wrote, the data is returned from both DAs within the same second (actually 60 milliseconds). > Is the time measured only the call to connection.search_s() or does it > include connecting to the server? It includes connecting but that is less than one second. > Which is the search base? The search filter? In the Active Directory case it is the root of the domain partition (/dc=conto so,dc=com) in the eDirectory case it is the root of the tree. But that shouldn't matter since the response with the query data comes within sixty milliseconds. The filter is the default ((objectClass=*)). Thorsten From michael at stroeder.com Tue May 17 14:40:22 2011 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Tue, 17 May 2011 14:40:22 +0200 Subject: [python-ldap] Querying Active Directory excessively slower than querying eDirectory In-Reply-To: <1305635686.5820.1452837041@webmail.messagingengine.com> References: <1305633755.28094.1452812281@webmail.messagingengine.com> <4DD26689.2050604@stroeder.com> <1305635686.5820.1452837041@webmail.messagingengine.com> Message-ID: <4DD26CB6.1060705@stroeder.com> Thorsten Kampe wrote: > * Michael Str?der (2011-05-17 14:14 +0200) >> without knowing more details one cannot really comment on this. Just wild >> guesses: >> >> Something related to DNS? >> >> Or referral chasing? (MS AD returns referrals) >> Did you try to turn off automatic referral chasing? > > It's not a connection issue. As I wrote, the data is returned from both > DAs within the same second (actually 60 milliseconds). > >> Is the time measured only the call to connection.search_s() or does it >> include connecting to the server? > > It includes connecting but that is less than one second. > >> Which is the search base? The search filter? > > In the Active Directory case it is the root of the domain partition > (/dc=conto > so,dc=com) in the eDirectory case it is the root of the tree. But that > shouldn't matter since the response with the query data comes within > sixty milliseconds. The filter is the default ((objectClass=*)). So in which part of the code can the time difference be observed? How about running with trace_level=2 and use module logging for a file-like object. This also writes time-stamps for each logged line. Example: -------------------------------- snip -------------------------------- import logging class logging_file_class: def __init__(self,logging_level): self._logging_level = logging_level def write(self,msg): logging.log(self._logging_level,msg[:-1]) ldap.initialize(uri,trace_level=2,trace_file=logging_file_class(logging.DEBUG)) -------------------------------- snip -------------------------------- Ciao, Michael. From cornelius.koelbel at lsexperts.de Tue May 17 14:55:42 2011 From: cornelius.koelbel at lsexperts.de (=?UTF-8?B?Q29ybmVsaXVzIEvDtmxiZWw=?=) Date: Tue, 17 May 2011 14:55:42 +0200 Subject: [python-ldap] Querying Active Directory excessively slower than querying eDirectory In-Reply-To: <1305635686.5820.1452837041@webmail.messagingengine.com> References: <1305633755.28094.1452812281@webmail.messagingengine.com> <4DD26689.2050604@stroeder.com> <1305635686.5820.1452837041@webmail.messagingengine.com> Message-ID: <4DD2704E.6070100@lsexperts.de> Am 17.05.2011 14:34, schrieb Thorsten Kampe: > * Michael Str?der (2011-05-17 14:14 +0200) >> without knowing more details one cannot really comment on this. Just wild >> guesses: >> >> Something related to DNS? >> >> Or referral chasing? (MS AD returns referrals) >> Did you try to turn off automatic referral chasing? > It's not a connection issue. As I wrote, the data is returned from both > DAs within the same second (actually 60 milliseconds). > >> Is the time measured only the call to connection.search_s() or does it >> include connecting to the server? > It includes connecting but that is less than one second. > >> Which is the search base? The search filter? > In the Active Directory case it is the root of the domain partition > (/dc=conto > so,dc=com) in the eDirectory case it is the root of the tree. But that > shouldn't matter since the response with the query data comes within > sixty milliseconds. The filter is the default ((objectClass=*)). > > Thorsten Hi Thorsten, I do not know eDirectory that good. But in Active Directory you will also find the configuration partition underneath dc=contoso,dc=com, where you might habe no read access! Maybe this slows some things down? Do you also get slow results when using another search base like ou=myOrga,dc=contoso,dc=com ? Kind regards Cornelius > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From thorsten at thorstenkampe.de Tue May 17 15:28:47 2011 From: thorsten at thorstenkampe.de (Thorsten Kampe) Date: Tue, 17 May 2011 15:28:47 +0200 Subject: [python-ldap] Querying Active Directory excessively slower than querying eDirectory In-Reply-To: <4DD2704E.6070100@lsexperts.de> References: <1305633755.28094.1452812281@webmail.messagingengine.com> <4DD26689.2050604@stroeder.com><1305635686.5820.1452837041@webmail.messagingengine.com> <4DD2704E.6070100@lsexperts.de> Message-ID: <1305638927.25181.1452856489@webmail.messagingengine.com> * Cornelius K?lbel (2011-05-17 14:55 +0200) > Am 17.05.2011 14:34, schrieb Thorsten Kampe: > > In the Active Directory case it is the root of the domain partition > > (/dc=conto > > so,dc=com) in the eDirectory case it is the root of the tree. But that > > shouldn't matter since the response with the query data comes within > > sixty milliseconds. The filter is the default ((objectClass=*)). > I do not know eDirectory that good. > But in Active Directory you will also find the configuration partition > underneath dc=contoso,dc=com, where you might habe no read access! > Maybe this slows some things down? > Do you also get slow results when using another search base like > ou=myOrga,dc=contoso,dc=com ? As I wrote, this is not a connectivity issue. AD and eDir return the result over the network within less than a tenth of a second. Thorsten From thorsten at thorstenkampe.de Tue May 17 15:50:47 2011 From: thorsten at thorstenkampe.de (Thorsten Kampe) Date: Tue, 17 May 2011 15:50:47 +0200 Subject: [python-ldap] Querying Active Directory excessively slower than querying eDirectory In-Reply-To: <4DD26CB6.1060705@stroeder.com> References: <1305633755.28094.1452812281@webmail.messagingengine.com> <4DD26689.2050604@stroeder.com> <1305635686.5820.1452837041@webmail.messagingengine.com> <4DD26CB6.1060705@stroeder.com> Message-ID: <1305640247.1824.1452866165@webmail.messagingengine.com> * Michael Str?der (2011-05-17 14:40 +0200) > Thorsten Kampe wrote: > So in which part of the code can the time difference be observed? # "1.1" means "no attributes" result = connection.search_s(base, ldap.SCOPE_SUBTREE, attrlist = ['1.1'], attrsonly = True) (as already mentioned) > How about running with trace_level=2 and use module logging for a > file-like > object. This also writes time-stamps for each logged line. > > Example: > > -------------------------------- snip -------------------------------- > import logging > > class logging_file_class: > > def __init__(self,logging_level): > self._logging_level = logging_level > > def write(self,msg): > logging.log(self._logging_level,msg[:-1]) > > ldap.initialize(uri,trace_level=2,trace_file=logging_file_class(logging.DEBUG)) > -------------------------------- snip -------------------------------- That did not output anything, but when setting just trace_level 2, I get: # eDirectory case *** ldap://windows2008r2:390 - SimpleLDAPObject.set_option ((17, 3),{}) *** ldap://windows2008r2:390 - SimpleLDAPObject.simple_bind (('', '', None, None),{}) => result: 1 *** ldap://windows2008r2:390 - SimpleLDAPObject.result3 ((1, 1, -1),{}) => result: (97, [], 1, []) *** ldap://windows2008r2:390 - SimpleLDAPObject.search_ext (('', 2, '(objectClass=*)', ['1.1'], 0, None, None, -1, 0),{}) => result: 2 *** ldap://windows2008r2:390 - SimpleLDAPObject.result3 ((2, 1, -1),{}) !! actual output; no delay *** ldap://windows2008r2:50385 - SimpleLDAPObject.unbind_ext ((None, None),{}) # Active Directory case *** ldap://windows2008r2:50385 - SimpleLDAPObject.set_option ((17, 3),{}) *** ldap://windows2008r2:50385 - SimpleLDAPObject.simple_bind (('CONTOSO\\admin', 'password', None, None),{}) => result: 1 *** ldap://windows2008r2:50385 - SimpleLDAPObject.result3 ((1, 1, -1),{}) => result: (97, [], 1, []) *** ldap://windows2008r2:50385 - SimpleLDAPObject.search_ext (('dc=contoso,dc=com', 2, '(objectClass=*)', ['1.1'], 0, None, None, -1, 0),{}) => result: 2 *** ldap://windows2008r2:50385 - SimpleLDAPObject.result3 ((2, 1, -1),{}) !! 40 seconds later: !! actual output *** ldap://windows2008r2:50385 - SimpleLDAPObject.unbind_ext ((None, None),{}) Thorsten From thorsten at thorstenkampe.de Tue May 17 16:35:00 2011 From: thorsten at thorstenkampe.de (Thorsten Kampe) Date: Tue, 17 May 2011 16:35:00 +0200 Subject: [python-ldap] Querying Active Directory excessively slower than querying eDirectory In-Reply-To: <4DD26CB6.1060705@stroeder.com> References: <1305633755.28094.1452812281@webmail.messagingengine.com> <4DD26689.2050604@stroeder.com> <1305635686.5820.1452837041@webmail.messagingengine.com> <4DD26CB6.1060705@stroeder.com> Message-ID: <1305642900.17351.1452873777@webmail.messagingengine.com> * Michael Str?der (2011-05-17 14:40 +0200) I've also got some ASCII and binary pickled objects of the query results. I am not able to find anything in there that would explain the difference in time but maybe you are... Thorsten From michael at stroeder.com Tue May 17 16:54:00 2011 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Tue, 17 May 2011 16:54:00 +0200 Subject: [python-ldap] Querying Active Directory excessively slower than querying eDirectory In-Reply-To: <1305638927.25181.1452856489@webmail.messagingengine.com> References: <1305633755.28094.1452812281@webmail.messagingengine.com> <4DD26689.2050604@stroeder.com><1305635686.5820.1452837041@webmail.messagingengine.com> <4DD2704E.6070100@lsexperts.de> <1305638927.25181.1452856489@webmail.messagingengine.com> Message-ID: <4DD28C08.6040105@stroeder.com> Thorsten Kampe wrote: > * Cornelius K?lbel (2011-05-17 14:55 +0200) >> Am 17.05.2011 14:34, schrieb Thorsten Kampe: >>> In the Active Directory case it is the root of the domain partition >>> (/dc=conto >>> so,dc=com) in the eDirectory case it is the root of the tree. But that >>> shouldn't matter since the response with the query data comes within >>> sixty milliseconds. The filter is the default ((objectClass=*)). > >> I do not know eDirectory that good. >> But in Active Directory you will also find the configuration partition >> underneath dc=contoso,dc=com, where you might habe no read access! >> Maybe this slows some things down? >> Do you also get slow results when using another search base like >> ou=myOrga,dc=contoso,dc=com ? > > As I wrote, this is not a connectivity issue. AD and eDir return the > result over the network within less than a tenth of a second. Cornelius gives a valuable hint (as I did before) because of the referrals returned by MS AD (e.g. for the configuration partition). Please re-read my message and try turning off automatic referral chasing. connection.set_option(ldap.OPT_REFERRALS,0) Ciao, Michael. From thorsten at thorstenkampe.de Tue May 17 17:10:11 2011 From: thorsten at thorstenkampe.de (Thorsten Kampe) Date: Tue, 17 May 2011 17:10:11 +0200 Subject: [python-ldap] Querying Active Directory excessively slower than querying eDirectory In-Reply-To: <4DD28C08.6040105@stroeder.com> References: <1305633755.28094.1452812281@webmail.messagingengine.com> <4DD26689.2050604@stroeder.com><1305635686.5820.1452837041@webmail.messagingengine.com> <4DD2704E.6070100@lsexperts.de> <1305638927.25181.1452856489@webmail.messagingengine.com> <4DD28C08.6040105@stroeder.com> Message-ID: <1305645011.31430.1452894661@webmail.messagingengine.com> * Michael Str?der (2011-05-17 16:54 +0200) > Thorsten Kampe wrote: > > * Cornelius K?lbel (2011-05-17 14:55 +0200) > >> Am 17.05.2011 14:34, schrieb Thorsten Kampe: > >>> In the Active Directory case it is the root of the domain partition > >>> (/dc=conto > >>> so,dc=com) in the eDirectory case it is the root of the tree. But that > >>> shouldn't matter since the response with the query data comes within > >>> sixty milliseconds. The filter is the default ((objectClass=*)). > > > >> I do not know eDirectory that good. > >> But in Active Directory you will also find the configuration partition > >> underneath dc=contoso,dc=com, where you might habe no read access! > >> Maybe this slows some things down? > >> Do you also get slow results when using another search base like > >> ou=myOrga,dc=contoso,dc=com ? > > > > As I wrote, this is not a connectivity issue. AD and eDir return the > > result over the network within less than a tenth of a second. > > Cornelius gives a valuable hint (as I did before) because of the > referrals > returned by MS AD (e.g. for the configuration partition). Please re-read > my > message and try turning off automatic referral chasing. > > connection.set_option(ldap.OPT_REFERRALS,0) That solves the issue, thanks. Please note that "hints" are only useful if the "hinted one" is on the same level knowledgewise as the one who gives the hint. I did not know that python-ldap actively tries to follow the referrals and I did not know how to turn it off. I wasn't even aware of the connection attempts since I filtered on port 50385 and not on 389. Thorsten From michael at stroeder.com Wed May 18 10:20:13 2011 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Wed, 18 May 2011 10:20:13 +0200 Subject: [python-ldap] Querying Active Directory excessively slower than querying eDirectory In-Reply-To: <1305645011.31430.1452894661@webmail.messagingengine.com> References: <1305633755.28094.1452812281@webmail.messagingengine.com> <4DD26689.2050604@stroeder.com><1305635686.5820.1452837041@webmail.messagingengine.com> <4DD2704E.6070100@lsexperts.de> <1305638927.25181.1452856489@webmail.messagingengine.com> <4DD28C08.6040105@stroeder.com> <1305645011.31430.1452894661@webmail.messagingengine.com> Message-ID: <4DD3813D.3070109@stroeder.com> Thorsten Kampe wrote: > Please note that "hints" are only useful if the "hinted one" is on the > same level knowledgewise as the one who gives the hint. The "hinted one" could also assume that a "hint" is given for good reasons and ask back if he/she does not understand the hint. > I did not know > that python-ldap actively tries to follow the referrals and I did not > know how to turn it off. It's the default behaviour of the OpenLDAP libs. MS AD makes use of LDAPv3 referrals. But it assumes that the clients chase the referrals binding with the standard Windows identity (with GSSAPI/Kerberos). But this behaviour is not standardized in LDAPv3 RFCs. So basically switch off automatic referral chasing is always a good idea. Ciao, Michael. From esiotrot at gmail.com Wed May 18 14:03:19 2011 From: esiotrot at gmail.com (Michael Wood) Date: Wed, 18 May 2011 14:03:19 +0200 Subject: [python-ldap] Querying Active Directory excessively slower than querying eDirectory In-Reply-To: <4DD3813D.3070109@stroeder.com> References: <1305633755.28094.1452812281@webmail.messagingengine.com> <4DD26689.2050604@stroeder.com> <1305635686.5820.1452837041@webmail.messagingengine.com> <4DD2704E.6070100@lsexperts.de> <1305638927.25181.1452856489@webmail.messagingengine.com> <4DD28C08.6040105@stroeder.com> <1305645011.31430.1452894661@webmail.messagingengine.com> <4DD3813D.3070109@stroeder.com> Message-ID: 2011/5/18 Michael Str?der : > Thorsten Kampe wrote: >> Please note that "hints" are only useful if the "hinted one" is on the >> same level knowledgewise as the one who gives the hint. > > The "hinted one" could also assume that a "hint" is given for good reasons and > ask back if he/she does not understand the hint. > >> I did not know >> that python-ldap actively tries to follow the referrals and I did not >> know how to turn it off. > > It's the default behaviour of the OpenLDAP libs. > > MS AD makes use of LDAPv3 referrals. But it assumes that the clients chase the > referrals binding with the standard Windows identity (with GSSAPI/Kerberos). > But this behaviour is not standardized in LDAPv3 RFCs. So basically switch off > automatic referral chasing is always a good idea. FAQ 13 says basically the same thing, although it's about a different issue: http://www.python-ldap.org/faq.shtml -- Michael Wood From s at 0x65.net Sat May 28 00:57:44 2011 From: s at 0x65.net (Salman Aljammaz) Date: Fri, 27 May 2011 22:57:44 +0000 Subject: [python-ldap] connect via a socket object Message-ID: Hi Is it possible to get a LDAPObject by passing it a python socket or file-like object instead of a uri sting? I've got a ldap server behind a vpn, and I would like to use a tunneled connection to get to it. Thanks, s From michael at stroeder.com Sun May 29 17:57:29 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 29 May 2011 17:57:29 +0200 Subject: [python-ldap] connect via a socket object In-Reply-To: References: Message-ID: <4DE26CE9.1070009@stroeder.com> Salman Aljammaz wrote: > Is it possible to get a LDAPObject by passing it a python socket or > file-like object instead of a uri sting? Not yet. One could wrap OpenLDAP's function ldap_init_fd() for that purpose. Feel free to submit a patch. But not sure whether ldap_init_fd() is already present in the OpenLDAP libs you're using. > I've got a ldap server behind a vpn, and I would like to use a > tunneled connection to get to it. Maybe I don't get the point. Normally VPNs are invisible to LDAP connections since they route IP packets. What's so special with your VPN? Ciao, Michael. From s at 0x65.net Sun May 29 18:24:09 2011 From: s at 0x65.net (Salman Aljammaz) Date: Sun, 29 May 2011 16:24:09 +0000 Subject: [python-ldap] connect via a socket object In-Reply-To: <4DE26CE9.1070009@stroeder.com> References: <4DE26CE9.1070009@stroeder.com> Message-ID: 2011/5/29 Michael Str?der : > Not yet. One could wrap OpenLDAP's function ldap_init_fd() for that purpose. > Feel free to submit a patch. But not sure whether ldap_init_fd() is already > present in the OpenLDAP libs you're using. thanks, i'll have a look at that. i'm not sure i have the time to promise anything now but i'll send a patch if i ever get around to it :-) > Maybe I don't get the point. Normally VPNs are invisible to LDAP connections > since they route IP packets. What's so special with your VPN? heh, maybe vpn wasn't the correct word here. it's behind a firewall, and i'm currently just setting up a (transparent) vpn connection. but that's a privileged operation and is not an option where this application will eventually be deployed. the alternative would be to set up an ssh tunnel. i was thinking of using paramiko and passing its connection to python-ldap. the uglier approach is to run /bin/ssh with port forwarding (-L) whenever the connection is needed, which seems to be what i'll be doing :-) cheers, s From michael at stroeder.com Mon May 30 19:23:20 2011 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Mon, 30 May 2011 19:23:20 +0200 Subject: [python-ldap] connect via a socket object In-Reply-To: References: <4DE26CE9.1070009@stroeder.com> Message-ID: <4DE3D288.8020205@stroeder.com> Salman Aljammaz wrote: > 2011/5/29 Michael Str?der: >> Not yet. One could wrap OpenLDAP's function ldap_init_fd() for that purpose. >> Feel free to submit a patch. But not sure whether ldap_init_fd() is already >> present in the OpenLDAP libs you're using. > > thanks, i'll have a look at that. i'm not sure i have the time to > promise anything now but i'll send a patch if i ever get around to it > :-) > >> Maybe I don't get the point. Normally VPNs are invisible to LDAP connections >> since they route IP packets. What's so special with your VPN? > > heh, maybe vpn wasn't the correct word here. it's behind a firewall, > and i'm currently just setting up a (transparent) vpn connection. but > that's a privileged operation and is not an option where this > application will eventually be deployed. Could you please be more clear how you want to pass your firewall? SOCKS? HTTP with CONNECT method? You probably have to clarify this with your security department. > the alternative would be to set up an ssh tunnel. i was thinking of > using paramiko and passing its connection to python-ldap. the uglier > approach is to run /bin/ssh with port forwarding (-L) whenever the > connection is needed, which seems to be what i'll be doing :-) Using SSH tunneling (poor man's VPN) is a "privileged operation" too. Ciao, Michael. From esiotrot at gmail.com Tue May 31 08:19:07 2011 From: esiotrot at gmail.com (Michael Wood) Date: Tue, 31 May 2011 08:19:07 +0200 Subject: [python-ldap] connect via a socket object In-Reply-To: <4DE3D288.8020205@stroeder.com> References: <4DE26CE9.1070009@stroeder.com> <4DE3D288.8020205@stroeder.com> Message-ID: 2011/5/30 Michael Str?der : > Salman Aljammaz wrote: [...] >> the alternative would be to set up an ssh tunnel. ?i was thinking of >> using paramiko and passing its connection to python-ldap. ?the uglier >> approach is to run /bin/ssh with port forwarding (-L) whenever the >> connection is needed, which seems to be what i'll be doing :-) > > Using SSH tunneling (poor man's VPN) is a "privileged operation" too. A normal user can set up an SSH tunnel. -- Michael Wood From michael at stroeder.com Thu Jun 2 20:11:37 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 02 Jun 2011 20:11:37 +0200 Subject: [python-ldap] ANN: python-ldap 2.4.0 Message-ID: <4DE7D259.30608@stroeder.com> Find a new release of python-ldap: http://pypi.python.org/pypi/python-ldap/2.4.0 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.0 2011-06-02 Changes since 2.3.13: * OpenLDAP 2.4.11+ required to build * Support for extracting LDAPv3 extended controls in LDAP_RES_SEARCH_ENTRY responses (see SF#2829057, thanks to Rich) * Generic support for LDAPv3 extended operations (thanks to Rich) Lib/ * new class API in ldap.controls, not backwards-compatible! * new sub-modules for ldap.controls, some require pyasn1 and pyasn1_modules * New methods LDAPObject.result4() and LDAPObject.extop_result() * New (optional) class ldap.controls.AssertionControl * New helper module ldap.logger contains file-like object which sends trace messages to logging.log() * Removed non-functional method LDAPObject.set_cache_options() * Removed unused dictionary ldap.controls.knownLDAPControls Modules/ * ldapcontrol.c: Fixed encode_assertion_control() and function is no longer hidden behind ifdef-statement From michael at stroeder.com Sun Jun 5 18:03:16 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 05 Jun 2011 18:03:16 +0200 Subject: [python-ldap] ANNOUNCE: web2ldap release 1.1.0a30 Message-ID: <4DEBA8C4.8040709@stroeder.com> HI! Find a new pre-release of web2ldap for public testing on http://www.web2ldap.de/download/web2ldap-1.1.0a30.tar.gz I'd recommend to install this release since it's much more mature than the previous releases. See more details on http://www.web2ldap.de Ciao, Michael. Changes since 1.1.0a27: - Python 2.6 or newer required! - python-ldap 2.4.0 which was just released required! - pyasn1 and pyasn1-modules required! - Support for more extended controls (assertion control etc.) - Many fixes especially for better form handling and XSS attack vectors. - When adding an entry configurable parts of the superior entry are displayed above the input form - Extended some sample HTML templates - Optional import of module crypt when running on Windows - many more small improvements and fixes - code-cleaning From michael at stroeder.com Mon Jun 6 08:30:16 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 06 Jun 2011 08:30:16 +0200 Subject: [python-ldap] Packages of python-ldap for RHEL 6 Message-ID: <4DEC73F8.4000804@stroeder.com> HI! Anyone maintaining packages of python-ldap 2.4.0 for RHEL 6 in a publicly accessible repository? Ciao, Michael. From Peter.Jacobs at icts.kuleuven.be Tue Jun 7 18:45:33 2011 From: Peter.Jacobs at icts.kuleuven.be (Peter Jacobs) Date: Tue, 7 Jun 2011 18:45:33 +0200 Subject: [python-ldap] older python versions not available anymore Message-ID: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> Hello, We use the python-ldap library in our Plone installations. Recently when running a buildout installation script, it broke when downloading python-ldap version 2.3.11. It turns out that this version has been removed from pypi: http://pypi.python.org/packages/source/p/python-ldap/ This seems to me very inconvenient for a lot of people, as we depend on specific versions of packages. E.g. on our RedHat 5.5 server we cannot use 2.3.12 because it gives an error (dependency on some version of some other system library?) We will try to solve this issue for ourselves by implementing our own local egg cache, but I think it would be a plus for many people to keep older versions online? Kind regards, Peter Jacobs Katholieke Universiteit Leuven, Dienst ICTS http://www.kuleuven.be -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Tue Jun 7 19:28:23 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 07 Jun 2011 19:28:23 +0200 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> Message-ID: <4DEE5FB7.3000309@stroeder.com> Peter, (I manually approved your posting to the python-ldap mailing list. Please subscribe to the mailing list.) Peter Jacobs wrote: > We use the python-ldap library in our Plone installations. > > Recently when running a buildout installation script, it broke when > downloading python-ldap version 2.3.11. Can you please give more details? > It turns out that this version has been removed from pypi: > http://pypi.python.org/packages/source/p/python-ldap/ > > This seems to me very inconvenient for a lot of people, as we depend on > specific versions of packages. > > E.g. on our RedHat 5.5 server we cannot use 2.3.12 because it gives an error > (dependency on some version of some other system library?) Which error? Note that in 2.3.13 there was a build error fixed for older OpenLDAP libs which affected older RHEL versions etc. > We will try to solve this issue for ourselves by implementing our own local > egg cache, but I think it would be a plus for many people to keep older > versions online? Hmm, I'm not convinced... Ciao, Michael. From peter.jacobs at icts.kuleuven.be Tue Jun 7 21:13:39 2011 From: peter.jacobs at icts.kuleuven.be (Peter Jacobs) Date: Tue, 07 Jun 2011 21:13:39 +0200 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <4DEE5FB7.3000309@stroeder.com> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> <4DEE5FB7.3000309@stroeder.com> Message-ID: <4DEE7863.6030809@icts.kuleuven.be> Op 7/06/2011 19:28, Michael Str?der schreef: > Peter Jacobs wrote: >> We use the python-ldap library in our Plone installations. >> >> Recently when running a buildout installation script, it broke when >> downloading python-ldap version 2.3.11. > Can you please give more details? We use the zc.buildout tool to install our Plone/Zope app. It has a nice feature that allows you to easily download and install packages with a specific version, so you can have repeatable installations and go back to a situation in the past. (http://pypi.python.org/pypi/zc.buildout/1.5.2#id109) in my installation script I use the following line: python-ldap=2.3.11 The error when I run the installation script: ------ Getting required 'python-ldap==2.3.11' We have no distributions for python-ldap that satisfies 'python-ldap==2.3.11'. Getting distribution for 'python-ldap==2.3.11'. While: Installing instance. Getting distribution for 'python-ldap==2.3.11'. Error: Couldn't find a distribution for 'python-ldap==2.3.11'. ------ which is logical because it is not available on pypi anymore when i replace it with: python-ldap=2.3.13 , buildout finds python-ldap-2.3.13.tar.gz and the installation succeeds. You could argue that it is best practice not to stick with old versions. That may work fine for python developers who follow up very closely on the packages used, but is much harder for integrators who use complex applications like plone. See for example : http://dist.plone.org/release/3.3.5/versions.cfg . It does not include python-ldap, but other python packages. There are many interdependent packages that are tested in combination, isn't it a bit harsh to force people who depend on a version of a package to fix their installation scripts sito presto, by removing those versions from the pypi repository? >> It turns out that this version has been removed from pypi: >> http://pypi.python.org/packages/source/p/python-ldap/ >> >> This seems to me very inconvenient for a lot of people, as we depend on >> specific versions of packages. >> >> E.g. on our RedHat 5.5 server we cannot use 2.3.12 because it gives an error >> (dependency on some version of some other system library?) > Which error? Note that in 2.3.13 there was a build error fixed for older > OpenLDAP libs which affected older RHEL versions etc. Ah indeed, with 2.3.13 the installation on RHEL5.5 works again. Thank you, that way I can fix the installation scripts. Still, I was happy we had pinned our package versions to 2.3.11 so we could keep our installation working when 2.3.12 was released... >> We will try to solve this issue for ourselves by implementing our own local >> egg cache, but I think it would be a plus for many people to keep older >> versions online? > Hmm, I'm not convinced... If I am the only one complaining and others do update their package versions timely, you can safely ignore this request :-) Thanks for your time and advice, Peter From pakrat at ftp.linux.org.uk Tue Jun 7 22:12:47 2011 From: pakrat at ftp.linux.org.uk (Chris Dukes) Date: Tue, 7 Jun 2011 21:12:47 +0100 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <4DEE7863.6030809@icts.kuleuven.be> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> <4DEE5FB7.3000309@stroeder.com> <4DEE7863.6030809@icts.kuleuven.be> Message-ID: <20110607201247.GU21958@ZenIV.linux.org.uk> On Tue, Jun 07, 2011 at 09:13:39PM +0200, Peter Jacobs wrote: > Op 7/06/2011 19:28, Michael Str?der schreef: [SNEEP] Micheal, It really would not destroy the world to keep all, or most versions of python-ldap available on pypi. It's only ~120KB/version. With buildouts, the scripted build process could take recipes from several source control repositories and even an admin/developer may not have commit access to all of them to update the version of a python package referenced in a recipe. I personally think buildouts are now a snarled mess of spaghetti. Unfortunately they are now the only way to deploy some apps and those apps depend on python-ldap and other packages, and frequently versions that their developers would prefer to have as unavailable. -- Chris Dukes Don't look a gift lion in the mouth. From michael at stroeder.com Wed Jun 8 20:54:15 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 08 Jun 2011 20:54:15 +0200 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> Message-ID: <4DEFC557.30708@stroeder.com> Peter Jacobs wrote: > Hello, > > We use the python-ldap library in our Plone installations. > > Recently when running a buildout installation script, it broke when > downloading python-ldap version 2.3.11. > > It turns out that this version has been removed from pypi: > http://pypi.python.org/packages/source/p/python-ldap/ I've re-enabled 2.3.13 in pypi for those stuck with OpenLDAP 2.3 libs. But I won't fix things in this old release. Ciao, Michael. From pakraticus+python-ldap at gmail.com Wed Jun 8 21:04:15 2011 From: pakraticus+python-ldap at gmail.com (Chris Dukes) Date: Wed, 8 Jun 2011 20:04:15 +0100 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <4DEFC557.30708@stroeder.com> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> <4DEFC557.30708@stroeder.com> Message-ID: <20110608190415.GB21958@ZenIV.linux.org.uk> On Wed, Jun 08, 2011 at 08:54:15PM +0200, Michael Str?der wrote: > Peter Jacobs wrote: > I've re-enabled 2.3.13 in pypi for those stuck with OpenLDAP 2.3 libs. > But I won't fix things in this old release. Thank you! -- Chris Dukes Don't look a gift lion in the mouth. From walbridge at nceas.ucsb.edu Thu Jun 9 01:17:05 2011 From: walbridge at nceas.ucsb.edu (Shaun Walbridge) Date: Wed, 08 Jun 2011 16:17:05 -0700 Subject: [python-ldap] thanks for putting 2.3.13 back on PyPI Message-ID: <4DF002F1.4090604@nceas.ucsb.edu> Hi, Thanks for putting 2.3.13 back on PyPI -- my production Plone site is running Ubuntu 8.04 LTS which doesn't have packaged versions of OpenLDAP 2.4. I know its important to always be moving forward, but thanks for allowing our other use-cases to persist. cheers, Shaun From peter.jacobs at icts.kuleuven.be Thu Jun 9 19:41:24 2011 From: peter.jacobs at icts.kuleuven.be (Peter Jacobs) Date: Thu, 09 Jun 2011 19:41:24 +0200 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <4DEFC557.30708@stroeder.com> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> <4DEFC557.30708@stroeder.com> Message-ID: <4DF105C4.9000300@icts.kuleuven.be> Op 8/06/2011 20:54, Michael Str?der schreef: > Peter Jacobs wrote: >> We use the python-ldap library in our Plone installations. >> >> Recently when running a buildout installation script, it broke when >> downloading python-ldap version 2.3.11. >> >> It turns out that this version has been removed from pypi: >> http://pypi.python.org/packages/source/p/python-ldap/ > I've re-enabled 2.3.13 in pypi for those stuck with OpenLDAP 2.3 libs. > But I won't fix things in this old release. > There is some confusion about the issue at hand: The packages themselves work fine, but I have a lot of installation scripts that basically say: - fetch python-ldap-2.3.11.tar.gz from the pypi website - install it locally These scripts used to work fine, but now when somebody runs them they give a download error, as that file has been removed from pypi. The exact version number is included on purpose, to be able to have a tested and reproducable installation with a Known Good Set of packages. Of course, by changing the script to python-ldap-2.3.13.tar.gz , it finds the package again, but: - it is not always immediately clear which version to take without testing, sometimes you need to install a new application quickly. - if somebody who has no internal knowledge about the installation runs the script, they will be stuck So the proposal is to just keep the older versions online, so people can upgrade at their own pace? kind regards, Peter (I avoided any reference to buildout, the same issue would have happened with custom bash-scripts that dowload files with exact version numbers from pypi.) From michael at stroeder.com Thu Jun 9 20:05:44 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 09 Jun 2011 20:05:44 +0200 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <4DF105C4.9000300@icts.kuleuven.be> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> <4DEFC557.30708@stroeder.com> <4DF105C4.9000300@icts.kuleuven.be> Message-ID: <4DF10B78.5020503@stroeder.com> Peter Jacobs wrote: > Op 8/06/2011 20:54, Michael Str?der schreef: >> I've re-enabled 2.3.13 in pypi for those stuck with OpenLDAP 2.3 libs. >> But I won't fix things in this old release. >> > There is some confusion about the issue at hand: > The packages themselves work fine, but I have a lot of installation scripts > that basically say: > - fetch python-ldap-2.3.11.tar.gz from the pypi website > - install it locally > These scripts used to work fine, but now when somebody runs them they give a > download error, as that file has been removed from pypi. The exact version > number is included on purpose, to be able to have a tested and reproducable > installation with a Known Good Set of packages. > > Of course, by changing the script to python-ldap-2.3.13.tar.gz , it finds the > package again, but: > - it is not always immediately clear which version to take without testing, > sometimes you need to install a new application quickly. > - if somebody who has no internal knowledge about the installation runs the > script, they will be stuck I'd say if your software runs with 2.3.11 it also will work with 2.3.13 without problems. Please look at file CHANGES. There was an important fix in 2.3.12 for python -tt. Also unnecessary thread locking was relaxed. > So the proposal is to just keep the older versions online, so people can > upgrade at their own pace? Yes, but people using an older version might run into problems already fixed (see python -tt above) and people ask for support. Could we agree on that in this case you update to 2.3.13 which is mainly a bug fix release compared to 2.3.11? It can still be built with OpenLDAP 2.3 libs. Ciao, Michael. From peter.jacobs at icts.kuleuven.be Fri Jun 10 10:50:44 2011 From: peter.jacobs at icts.kuleuven.be (Peter Jacobs) Date: Fri, 10 Jun 2011 10:50:44 +0200 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <4DF10B78.5020503@stroeder.com> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> <4DEFC557.30708@stroeder.com> <4DF105C4.9000300@icts.kuleuven.be> <4DF10B78.5020503@stroeder.com> Message-ID: <4DF1DAE4.5050600@icts.kuleuven.be> >> So the proposal is to just keep the older versions online, so people can >> upgrade at their own pace? > Yes, but people using an older version might run into problems already fixed > (see python -tt above) and people ask for support. > > Could we agree on that in this case you update to 2.3.13 > which is mainly a bug > fix release compared to 2.3.11? It can still be built with OpenLDAP 2.3 libs. > Of course, that is a good solution for now, and I will also upgrade to 2.4.0 when all our systems are upgraded. Still, this issue will come up again in the future. It seems there are some fundamental differences in the ways people work with versions and use the packages on pypi, so I give up for now :-) What I am going to do: * I will put the 2.3.13 and the 2.4.0 files on a local webserver and point the installation scripts to that server instead of pypi for python-ldap * in the near future I'll update the scripts to 2.4.0 * When somebody else then needs to run my script on their machine, I give the 2.4.0 file, or point them to my local mirror. That way I can be sure that they can run the installation and all packages are found, because at anytime that file on pypi may have been removed and replaced by a 2.4.1 version... bye, Peter From jens at dataflake.org Fri Jun 10 12:55:00 2011 From: jens at dataflake.org (Jens Vagelpohl) Date: Fri, 10 Jun 2011 12:55:00 +0200 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <4DF1EE69.3090607@dataflake.org> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> <4DEFC557.30708@stroeder.com> <4DF105C4.9000300@icts.kuleuven.be> <4DF10B78.5020503@stroeder.com> <4DF1DAE4.5050600@icts.kuleuven.be> <4DF1EE69.3090607@dataflake.org> Message-ID: <4DF1F804.7020505@dataflake.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/10/11 10:50 , Peter Jacobs wrote: > That way I can be sure that they can run the installation and all > packages are found, because at anytime that file on pypi may have been > removed and replaced by a 2.4.1 version... Yes, this is a real problem. I fear Michael is not conviced yet. Nowadays large applications are developed by combining many separate eggs, like Python-LDAP, with custom code. In order to manage such an application buildout systems have emerged, such as zc.buildout, used by default in the Zope/Plone-universe and many others. zc.buildout allows the developer not only to name the specific packages and automate retrieval, but (and this is the BIG issue) it enables so-called version pinning. The developer can "pin" specific package versions to make sure the resulting application is the same whenever and wherever it is deployed. Version pinning is the only way to guarantee that what has been tested by the developer and QA people is what's running e.g. on the customer site. On the other hand package maintainers would like you to upgrade to the latest version so they don't get repeated support requests for issues that have already been fixed in later versions. Michael goes one step further and removes/disables the older versions on PyPI, which is quite unusual. I don't know of *any* other package maintainer who does this. Of course this breaks buildouts that expect to find the old versions on PyPI. While - as a package maintainer myself - I really appreciate Michael's concern about unwarranted support requests I strongly believe the choice of package version *must* be left to the developer/integrator who put together the larger application. *Everything* that is uploaded to PyPI should be treated as an immutable and un-deletable entity, otherwise build systems that try to guarantee repeatability will never work. This hurts application developers, integrators, and their customers. As a package maintainer I don't believe in the ideal case where people will always upgrade to the latest version, and invalid support requests will ever cease. Matter of fact, the strategy of disabling older versions will generate their own stream of support requests. Where's the gain when instead of saying "upgrade to the latest version and come back" you now need to explain where the old packages went? @Michael: Like everyone else on this thread I am asking you: Please do not remove packages from PyPI. Simply uploading later versions will put everyone who has not made the conscious decision to stick with a specific version on your latest release. Those who have made the conscious decision will know to either not bother you, or they simply cannot complain when you tell them to, well, "sod off". jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk3x+AMACgkQRAx5nvEhZLJE6gCgrbMcFlG7vtMhPh4JTKX7OPP7 mxIAniXPH8iKw3mfw0TC6y1GaAqILZn1 =IlcQ -----END PGP SIGNATURE----- From faassen at startifact.com Fri Jun 10 13:29:21 2011 From: faassen at startifact.com (Martijn Faassen) Date: Fri, 10 Jun 2011 13:29:21 +0200 Subject: [python-ldap] removing old packages Message-ID: Hi there, I was asked to leave a note on this mailing list about the removal of old packages from PyPI. I've been developing and deploying using python-ldap 2.3.12. I deployed to a customer, yesterday they told met hey can't install as python-ldap 2.3.12 isn't available (I think I can find from the google cache that pypi used to have it; no more). I thought I'd report this mistake to the developers, but I found this instead: > > We will try to solve this issue for ourselves by implementing our own local > > egg cache, but I think it would be a plus for many people to keep older > > versions online? > Hmm, I'm not convinced... So I think this removal was deliberate? Please let this help you convince you to keep older versions online? If people lock down versions during development and especially deployment (something I consider good practice), it's now breaking their repetitive deployments. Now I need to go dig around the net to find a python-ldap 2.3.12 to give to my customer as that's what we tested with... (I ended up upgrading my customer to 2.3.13) If you are still interested in throwing away old versions in the future, please let me know, and I'll take this into account and adjust my buildouts to rely on a fixed version locally. I myself consider throwing away old versions in general a bad practice, however. Regards, Martijn From michael at stroeder.com Fri Jun 10 21:09:33 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 10 Jun 2011 21:09:33 +0200 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <4DF1F804.7020505@dataflake.org> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> <4DEFC557.30708@stroeder.com> <4DF105C4.9000300@icts.kuleuven.be> <4DF10B78.5020503@stroeder.com> <4DF1DAE4.5050600@icts.kuleuven.be> <4DF1EE69.3090607@dataflake.org> <4DF1F804.7020505@dataflake.org> Message-ID: <4DF26BED.9040503@stroeder.com> Jens Vagelpohl wrote: > @Michael: Like everyone else on this thread I am asking you: Please do > not remove packages from PyPI. Simply uploading later versions will put > everyone who has not made the conscious decision to stick with a > specific version on your latest release. Those who have made the > conscious decision will know to either not bother you, or they simply > cannot complain when you tell them to, well, "sod off". I can see the pros and cons but everybody should also note that all software is sometimes end-of-life. In case of OpenLDAP version 2.3 is not supported anymore by its developers. That's a very strong reason not to use it anymore since we as python-ldap developers also won't receive security fixes from OpenLDAP anymore. Also when using buildout systems which pin down module versions the developer is also responsible to rebuild all the stuff when a security update of one of the modules is needed. Upgrades of python-ldap provided by e.g. Linux distributions or the OS admins do not have any effect. Practice with such buildout systems (my customers use Maven etc.) shows that most developers are not aware of that fact or most systems are not maintained in a responsable fashion leading to insecure systems. This all is not new. The same problems applys to packaging policies of Linux distros as well. But for the peace in the Python world here's my suggestion for now: 1. Everybody who MUST support old OpenLDAP libs 2.3 MUST upgrade to 2.3.13. But I won't apply fixes therein, won't release more 2.3.x versions and I won't re-enable releases prior 2.3.13. 2. Everybody else SHOULD upgrade to 2.4.0. For most applications it behaves exactly like version 2.3.13 except in very rare cases where an application uses more complex LDAPv3 ext. controls. In the latter case the developers will definitely appreciate/need the improvements and upgrade anyway. 3. I will rethink my PyPI release strategy for future releases. Ok? Ciao, Michael. From jens at dataflake.org Sat Jun 11 16:15:50 2011 From: jens at dataflake.org (Jens Vagelpohl) Date: Sat, 11 Jun 2011 16:15:50 +0200 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <4DF26BED.9040503@stroeder.com> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> <4DEFC557.30708@stroeder.com> <4DF105C4.9000300@icts.kuleuven.be> <4DF10B78.5020503@stroeder.com> <4DF1DAE4.5050600@icts.kuleuven.be> <4DF1EE69.3090607@dataflake.org> <4DF1F804.7020505@dataflake.org> <4DF26BED.9040503@stroeder.com> Message-ID: <4DF37896.8070701@dataflake.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, > I can see the pros and cons but everybody should also note that all > software is sometimes end-of-life. In case of OpenLDAP version 2.3 is > not supported anymore by its developers. That's a very strong reason not > to use it anymore since we as python-ldap developers also won't receive > security fixes from OpenLDAP anymore. > > Also when using buildout systems which pin down module versions the > developer is also responsible to rebuild all the stuff when a security > update of one of the modules is needed. Upgrades of python-ldap provided > by e.g. Linux distributions or the OS admins do not have any effect. > Practice with such buildout systems (my customers use Maven etc.) shows > that most developers are not aware of that fact or most systems are not > maintained in a responsable fashion leading to insecure systems. You are totally right on both points. However, it is *not your decision to make* which versions are used. It's not your responsibility if people run old and insecure systems. That decision is up to the developer/integrator and *no one else*! As package developer your role is advisory only - including advice for people on older versions to upgrade and come back. Please don't try to force others into decisions, even if everyone may agree that yours is better. If people want to shoot themselves in the foot, just let them. Telling them their decision is stupid is much better than denying them the decision completely. > 3. I will rethink my PyPI release strategy for future releases. Thanks - and I hope that means you will just leave things on PyPI.... jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk3zeJYACgkQRAx5nvEhZLJB7QCeO73hUw7PntFuKLBIlNjR+OWR hpwAn3LODVD+48bmZ9JLSfn3bZR/yYK4 =y6KB -----END PGP SIGNATURE----- From peter.jacobs at icts.kuleuven.be Sat Jun 11 22:53:39 2011 From: peter.jacobs at icts.kuleuven.be (Peter Jacobs) Date: Sat, 11 Jun 2011 22:53:39 +0200 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <4DF26BED.9040503@stroeder.com> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> <4DEFC557.30708@stroeder.com> <4DF105C4.9000300@icts.kuleuven.be> <4DF10B78.5020503@stroeder.com> <4DF1DAE4.5050600@icts.kuleuven.be> <4DF1EE69.3090607@dataflake.org> <4DF1F804.7020505@dataflake.org> <4DF26BED.9040503@stroeder.com> Message-ID: <4DF3D5D3.2090609@icts.kuleuven.be> Op 10/06/2011 21:09, Michael Str?der schreef: > 1. Everybody who MUST support old OpenLDAP libs 2.3 MUST upgrade to 2.3.13. > But I won't apply fixes therein, won't release more 2.3.x versions and I won't > re-enable releases prior 2.3.13. > > 2. Everybody else SHOULD upgrade to 2.4.0. For most applications it behaves > exactly like version 2.3.13 except in very rare cases where an application > uses more complex LDAPv3 ext. controls. In the latter case the developers will > definitely appreciate/need the improvements and upgrade anyway. > > 3. I will rethink my PyPI release strategy for future releases. > > Ok? > Great, thanks for considering our requests! Peter From jamesa at daa.com.au Mon Jun 13 06:40:49 2011 From: jamesa at daa.com.au (James Andrewartha) Date: Mon, 13 Jun 2011 12:40:49 +0800 Subject: [python-ldap] older python versions not available anymore In-Reply-To: <4DF26BED.9040503@stroeder.com> References: <36F1A8049C42034584E6F9F245A65115015B9A858478@ICTS-S-EXC1-CA.luna.kuleuven.be> <4DEFC557.30708@stroeder.com> <4DF105C4.9000300@icts.kuleuven.be> <4DF10B78.5020503@stroeder.com> <4DF1DAE4.5050600@icts.kuleuven.be> <4DF1EE69.3090607@dataflake.org> <4DF1F804.7020505@dataflake.org> <4DF26BED.9040503@stroeder.com> Message-ID: <4DF594D1.8030106@daa.com.au> On 11/06/11 03:09, Michael Str?der wrote: > Jens Vagelpohl wrote: >> @Michael: Like everyone else on this thread I am asking you: Please do >> not remove packages from PyPI. Simply uploading later versions will put >> everyone who has not made the conscious decision to stick with a >> specific version on your latest release. Those who have made the >> conscious decision will know to either not bother you, or they simply >> cannot complain when you tell them to, well, "sod off". > > I can see the pros and cons but everybody should also note that all > software is sometimes end-of-life. In case of OpenLDAP version 2.3 is > not supported anymore by its developers. That's a very strong reason not > to use it anymore since we as python-ldap developers also won't receive > security fixes from OpenLDAP anymore. True, but all the old releases are still available from their website: http://www.openldap.org/software/download/OpenLDAP/openldap-release/ James Andrewartha From stefanik at dscon.sk Wed Jun 15 14:42:32 2011 From: stefanik at dscon.sk (Dusan Stefanik) Date: Wed, 15 Jun 2011 14:42:32 +0200 Subject: [python-ldap] python3 Message-ID: <20110615124231.GB11614@portos> Hi, I'm working on python-ldap for python3, my work is on right way. There is principial question but I don't know answer. In my work I changed all strings to bytes - it works. So may better way will be using Unicode string internally. What do you thing about it? Python on Linux use UCS2 schema, on some platform can use UCS4 schema (documentation write). What schema using LDAP servers and does it matter? What will be an impact to functionality? Dusan From michael at stroeder.com Wed Jun 15 17:35:22 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 15 Jun 2011 17:35:22 +0200 Subject: [python-ldap] python3 In-Reply-To: <20110615124231.GB11614@portos> References: <20110615124231.GB11614@portos> Message-ID: <4DF8D13A.1060008@stroeder.com> Dusan Stefanik wrote: > I'm working on python-ldap for python3, my work is on right way. Do you think it will be feasible to have a common code base for Python 2.x and Python 3.x at least for the C wrapper part? > There is principial question but I don't know answer. > In my work I changed all strings to bytes - it works. That's what I would do within the C code in Modules/. > So may better way will be using Unicode string internally. > What do you thing about it? Hmm...not sure... > Python on Linux use UCS2 schema, on some platform can use UCS4 schema (documentation write). > What schema using LDAP servers and does it matter? > What will be an impact to functionality? 1. Attribute values can contain BLOBs like JPEG images, X.509 certs etc. There's no way to automagically converting attribute values to Unicode strings without looking in the relevant subschema or applying a-priori knowledge about the attribute type syntax. 2. For LDAPv3 DNs and attribute types or similar have to be UTF-8 encoded before transmitted on the wire. For LDAPv2 it's T.61 but this varys depending on the server implementation/configuration. => even when thinking more about it the best decision seems to simply use bytes in C code in Modules/. For 2. I was already thinking about automatic Unicode to bytes conversion in Lib/ldap/ldapobject.py with a charset as class attribute. But I have some doubts it's worth the effort. Can somebody point me to a *efficient* recipe how to decide whether to encode a Unicode string or pass along raw string which also works with Python 2.3? Yes, I know type(u'') but I'd like to avoid clutter all the method with such if-statements. Ciao, Michael. From stefanik at dscon.sk Wed Jun 15 20:15:07 2011 From: stefanik at dscon.sk (Dusan Stefanik) Date: Wed, 15 Jun 2011 20:15:07 +0200 Subject: [python-ldap] python3 In-Reply-To: <4DF8D13A.1060008@stroeder.com> References: <20110615124231.GB11614@portos> <4DF8D13A.1060008@stroeder.com> Message-ID: <20110615181505.GC11614@portos> On 15/06/11 at 05:35pm, Michael Str?der wrote: > Dusan Stefanik wrote: > > I'm working on python-ldap for python3, my work is on right way. > > Do you think it will be feasible to have a common code base for Python 2.x and > Python 3.x at least for the C wrapper part? Hmm I don't know. Look at diff (only Module dir). First set of changes is PyString_* to PyBytes_* (Maybe PyUnicode_*) functions. Second is PyInt_* to PyLong_*. Third is C module creation and initialization (I don't know if I made it right but it works). > > > There is principial question but I don't know answer. > > In my work I changed all strings to bytes - it works. > > That's what I would do within the C code in Modules/. > > > So may better way will be using Unicode string internally. > > What do you thing about it? > > Hmm...not sure... > > > Python on Linux use UCS2 schema, on some platform can use UCS4 schema (documentation write). > > What schema using LDAP servers and does it matter? > > What will be an impact to functionality? > > 1. Attribute values can contain BLOBs like JPEG images, X.509 certs etc. > There's no way to automagically converting attribute values to Unicode strings > without looking in the relevant subschema or applying a-priori knowledge about > the attribute type syntax. > > 2. For LDAPv3 DNs and attribute types or similar have to be UTF-8 encoded > before transmitted on the wire. For LDAPv2 it's T.61 but this varys depending > on the server implementation/configuration. > > => even when thinking more about it the best decision seems to simply use > bytes in C code in Modules/. I think so, but it's a little discomfort for user. > > For 2. I was already thinking about automatic Unicode to bytes conversion in > Lib/ldap/ldapobject.py with a charset as class attribute. But I have some > doubts it's worth the effort. Can somebody point me to a *efficient* recipe > how to decide whether to encode a Unicode string or pass along raw string > which also works with Python 2.3? Yes, I know type(u'') but I'd like to avoid > clutter all the method with such if-statements. > > Ciao, Michael. > Dusan -------------- next part -------------- A non-text attachment was scrubbed... Name: ldap-Module.diff Type: text/x-diff Size: 27623 bytes Desc: not available URL: From michael at stroeder.com Thu Jun 23 20:52:45 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 23 Jun 2011 20:52:45 +0200 Subject: [python-ldap] ANNOUNCE: web2ldap release 1.1.0a33 Message-ID: <4E038B7D.5020909@stroeder.com> HI! Find a new pre-release of web2ldap for public testing on http://www.web2ldap.de/download.html See more details on http://www.web2ldap.de Ciao, Michael. Changes since 1.1.0a30: * Added experimental CSV export * If the new password field is empty in the password change input form the new password is randomly generated and displayed * More Unicode-related code-cleaning * An attribute value in the user input is now preserved when re-displaying the input form in case of a syntax error * Attribute list in LDAP URLs are now preserved in case of re-login From stefanik at dscon.sk Fri Jun 24 11:56:17 2011 From: stefanik at dscon.sk (Dusan Stefanik) Date: Fri, 24 Jun 2011 11:56:17 +0200 Subject: [python-ldap] python 2.4 python3 version Message-ID: <20110624095615.GA4495@portos> Hi, this is first version of my work. Huge testing is needed. Basic tests on my 64bit ubuntu (python 3.1.2) was success (search, add, modify, delete, schema search, search with control value, jpeg in/out). There is some hacks for correct schema search working: Schema search result in function urlfetch (subentry.py) is converted from bytes to string because models.py and tokenizer functions are string based. So I added function By2Str() + subschemasubentry_entry = By2Str(subschemasubentry_entry) Schema search is doing in few loops so I convert search attributes to bytes if needed. ldapobject.py: + s2b = lambda x: x.encode() if type(x) is not bytes else x + #for schema search needed convert s2b + if(type(attrlist) is list): + attrlist = [ s2b(li) for li in attrlist] Finally I made some changes on demo scripts to get it work with py3. Dusan -------------- next part -------------- A non-text attachment was scrubbed... Name: python-ldap-cvs-py3.diff Type: text/x-diff Size: 88525 bytes Desc: not available URL: From cwood06 at gmail.com Wed Jun 29 17:31:56 2011 From: cwood06 at gmail.com (Colin Wood) Date: Wed, 29 Jun 2011 11:31:56 -0400 Subject: [python-ldap] Python Ldap Compiliation Issue Message-ID: Hi Everyone, I am having an issue with getting python-ldap to compile in my RHEL enviroment. I am running python 2.7.2 from source, and I have the openldap-devel package installed but still can not get this to work. Here is the output: 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 running build running build_py 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 running egg_info writing requirements to Lib/python_ldap.egg-info/requires.txt writing Lib/python_ldap.egg-info/PKG-INFO writing top-level names to Lib/python_ldap.egg-info/top_level.txt writing dependency_links to Lib/python_ldap.egg-info/dependency_links.txt 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 reading manifest file 'Lib/python_ldap.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' warning: no files found matching 'Makefile' warning: no files found matching 'Modules/LICENSE' writing manifest file 'Lib/python_ldap.egg-info/SOURCES.txt' running build_ext building '_ldap' extension gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DHAVE_LIBLDAP_R -DHAVE_SASL -DHAVE_TLS -DLDAPMODULE_VERSION=2.4.1 -IModules -I/opt/openldap-RE24/include -I/usr/include/sasl -I/opt/home/mradmin/.local/include/python2.7 -c Modules/LDAPObject.c -o build/temp.linux-x86_64-2.7/Modules/LDAPObject.o -g In file included from Modules/LDAPObject.c:18: /usr/include/sasl/sasl.h:349: warning: function declaration isn?t a prototype gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DHAVE_LIBLDAP_R -DHAVE_SASL -DHAVE_TLS -DLDAPMODULE_VERSION=2.4.1 -IModules -I/opt/openldap-RE24/include -I/usr/include/sasl -I/opt/home/mradmin/.local/include/python2.7 -c Modules/ldapcontrol.c -o build/temp.linux-x86_64-2.7/Modules/ldapcontrol.o -g Modules/ldapcontrol.c: In function ?encode_assertion_control?: Modules/ldapcontrol.c:350: warning: implicit declaration of function ?ldap_create_assertion_control_value? gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DHAVE_LIBLDAP_R -DHAVE_SASL -DHAVE_TLS -DLDAPMODULE_VERSION=2.4.1 -IModules -I/opt/openldap-RE24/include -I/usr/include/sasl -I/opt/home/mradmin/.local/include/python2.7 -c Modules/common.c -o build/temp.linux-x86_64-2.7/Modules/common.o -g gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -DHAVE_LIBLDAP_R -DHAVE_SASL -DHAVE_TLS -DLDAPMODULE_VERSION=2.4.1 -IModules -I/opt/openldap-RE24/include -I/usr/include/sasl -I/opt/home/mradmin/.local/include/python2.7 -c Modules/constants.c -o build/temp.linux-x86_64-2.7/Modules/constants.o -g Modules/constants.c: In function ?LDAPinit_constants?: Modules/constants.c:153: error: ?LDAP_OPT_DIAGNOSTIC_MESSAGE? undeclared (first use in this function) Modules/constants.c:153: error: (Each undeclared identifier is reported only once Modules/constants.c:153: error: for each function it appears in.) Modules/constants.c:363: error: ?LDAP_CONTROL_RELAX? undeclared (first use in this function) error: command 'gcc' failed with exit status 1 Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Jun 29 21:41:58 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 29 Jun 2011 21:41:58 +0200 Subject: [python-ldap] Python Ldap Compiliation Issue In-Reply-To: References: Message-ID: <4E0B8006.2010305@stroeder.com> Colin Wood wrote: > I am having an issue with getting python-ldap to compile in my RHEL > enviroment. > I am running python 2.7.2 from source, and I have the > openldap-devel package installed but still can not get this to work. Which OpenLDAP version is this? Note that python-ldap 2.4.0+ requires OpenLDAP 2.4.11 libs to compile. It seems you trying to compile python-ldap from CVS HEAD (upcoming 2.4.1). Why that? Ciao, Michael. P.S.: I had to manually approve your posting to the mailing list since the list only allows subscribers to post. Please subscribe to python-ldap at python.org. It's low-traffic anyway. From cwood06 at gmail.com Wed Jun 29 21:48:38 2011 From: cwood06 at gmail.com (Colin Wood) Date: Wed, 29 Jun 2011 15:48:38 -0400 Subject: [python-ldap] Python Ldap Compiliation Issue In-Reply-To: References: <4E0B8006.2010305@stroeder.com> Message-ID: I figured it out. I had to change the setup.cfg to load from my libs it was usuing the wrong default dir. 2011/6/29 Colin Wood > Hi Michael, > > I actully got it to compile and I used the latest openLdap and that worked. > But now I am getting this. > > Traceback (most recent call last): > File "", line 1, in > File > "/home/mradmin/.local/lib/python2.7/site-packages/python_ldap-2.4.0-py2.7-linux-x86_64.egg/ldap/__init__.py", > line 22, in > from _ldap import * > ImportError: > /home/SOMEUSER/.local/lib/python2.7/site-packages/python_ldap-2.4.0-py2.7-linux-x86_64.egg/_ldap.so: > undefined symbol: ldap_create_assertion_control_value > > > 2011/6/29 Michael Str?der > >> Colin Wood wrote: >> > I am having an issue with getting python-ldap to compile in my RHEL >> > enviroment. >> > I am running python 2.7.2 from source, and I have the >> > openldap-devel package installed but still can not get this to work. >> >> Which OpenLDAP version is this? >> Note that python-ldap 2.4.0+ requires OpenLDAP 2.4.11 libs to compile. >> >> It seems you trying to compile python-ldap from CVS HEAD (upcoming 2.4.1). >> Why >> that? >> >> Ciao, Michael. >> >> P.S.: I had to manually approve your posting to the mailing list since the >> list only allows subscribers to post. Please subscribe to >> python-ldap at python.org. It's low-traffic anyway. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Jun 29 21:52:31 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 29 Jun 2011 21:52:31 +0200 Subject: [python-ldap] Python Ldap Compiliation Issue In-Reply-To: References: <4E0B8006.2010305@stroeder.com> Message-ID: <4E0B827F.7080302@stroeder.com> Colin Wood wrote: > I figured it out. I had to change the setup.cfg to load from my libs it was > usuing the wrong default dir. Yes. ;-) http://www.python-ldap.org/doc/html/installing.html#setup-cfg Ciao, Michael. From cwood06 at gmail.com Wed Jun 29 21:43:56 2011 From: cwood06 at gmail.com (Colin Wood) Date: Wed, 29 Jun 2011 15:43:56 -0400 Subject: [python-ldap] Python Ldap Compiliation Issue In-Reply-To: <4E0B8006.2010305@stroeder.com> References: <4E0B8006.2010305@stroeder.com> Message-ID: Hi Michael, I actully got it to compile and I used the latest openLdap and that worked. But now I am getting this. Traceback (most recent call last): File "", line 1, in File "/home/mradmin/.local/lib/python2.7/site-packages/python_ldap-2.4.0-py2.7-linux-x86_64.egg/ldap/__init__.py", line 22, in from _ldap import * ImportError: /home/SOMEUSER/.local/lib/python2.7/site-packages/python_ldap-2.4.0-py2.7-linux-x86_64.egg/_ldap.so: undefined symbol: ldap_create_assertion_control_value 2011/6/29 Michael Str?der > Colin Wood wrote: > > I am having an issue with getting python-ldap to compile in my RHEL > > enviroment. > > I am running python 2.7.2 from source, and I have the > > openldap-devel package installed but still can not get this to work. > > Which OpenLDAP version is this? > Note that python-ldap 2.4.0+ requires OpenLDAP 2.4.11 libs to compile. > > It seems you trying to compile python-ldap from CVS HEAD (upcoming 2.4.1). > Why > that? > > Ciao, Michael. > > P.S.: I had to manually approve your posting to the mailing list since the > list only allows subscribers to post. Please subscribe to > python-ldap at python.org. It's low-traffic anyway. > -------------- next part -------------- An HTML attachment was scrubbed... URL: