From TimurIzhbulatov at oilspace.com Thu Jul 5 14:37:26 2007 From: TimurIzhbulatov at oilspace.com (Timur Izhbulatov) Date: Thu, 05 Jul 2007 16:37:26 +0400 Subject: python-ldap on PyPI In-Reply-To: <46850A55.8090508@stroeder.com> References: <4684FAEB.5040609@tk-webart.de> <46850A55.8090508@stroeder.com> Message-ID: <468CE606.5050203@oilspace.com> Michael Str?der wrote: > Torsten Kurbad wrote: >> I'm currently involved in a project, using Zope3, there we would need a >> proper python-ldap.egg from the Python Cheeseshop. I realized that >> someone checked in some specs there >> (http://www.python.org/pypi/python-ldap/2.0.11), but there's no .egg >> file attached to this record - therefore my project fails to build. >> >> So my question is twofold: >> a) Who maintains the PyPI entries of python-ldap? Is it actively >> maintained in general? >> b) If not, how can I help to get it done? > > Since I never looked into .egg files I'd appreciate if you could provide > one and I do the rest of putting it on PyPI. Hi guys, Any progress with python-ldap.egg? If nobody's working on this I'll have to make it myself because I need it too. Cheers, -- Timur Izhbulatov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:TimurIzhbulatov at oilspace.com Building Successful Supply Chains - One Solution At A Time. www.oilspace.com From TimurIzhbulatov at oilspace.com Thu Jul 5 15:10:23 2007 From: TimurIzhbulatov at oilspace.com (Timur Izhbulatov) Date: Thu, 05 Jul 2007 17:10:23 +0400 Subject: python-ldap on PyPI In-Reply-To: <468CECAF.5070602@tk-webart.de> References: <4684FAEB.5040609@tk-webart.de> <46850A55.8090508@stroeder.com> <468CE606.5050203@oilspace.com> <468CECAF.5070602@tk-webart.de> Message-ID: <468CEDBF.7000207@oilspace.com> Torsten Kurbad wrote: > Timur Izhbulatov wrote: >> Hi guys, >> >> Any progress with python-ldap.egg? If nobody's working on this I'll >> have to make it myself because I need it too. >> >> Cheers, > Hi Timur, > > yes, me and my colleagues will prepare sth. during the next couple of > days. My boss already has some experience with eggs, so he will provide > some counseling... ;o) Sounds good. Good luck! :) Cheers, -- Timur Izhbulatov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:TimurIzhbulatov at oilspace.com Building Successful Supply Chains - One Solution At A Time. www.oilspace.com From python-ldap at tk-webart.de Fri Jul 13 15:36:13 2007 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Fri, 13 Jul 2007 15:36:13 +0200 Subject: python-ldap on PyPI In-Reply-To: <4684FAEB.5040609@tk-webart.de> References: <4684FAEB.5040609@tk-webart.de> Message-ID: <46977FCD.7080607@tk-webart.de> Hi folks, I just created a first .egg of python-ldap. Using a standard Linux distribution, like Gentoo, this can easily be replayed: 0. Make sure that you have a recent version of openldap, openssl and cyrus-sasl libraries and headers installed. 1. If not already done so, follow the instructions at http://peak.telecommunity.com/DevCenter/EasyInstall#installing-easy-install 2. Download and unpack the latest python-ldap tarball (2.3) 3. cd into python-ldap-2.3 and apply the attached (and hopefully unmangled) patch as follows patch -p1 From michael at stroeder.com Sat Jul 14 16:47:08 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 14 Jul 2007 16:47:08 +0200 Subject: python-ldap on PyPI In-Reply-To: <46977FCD.7080607@tk-webart.de> References: <4684FAEB.5040609@tk-webart.de> <46977FCD.7080607@tk-webart.de> Message-ID: <4698E1EC.4000503@stroeder.com> Torsten Kurbad wrote: > > I just created a first .egg of python-ldap. Thanks for contributing this. > Using a standard Linux distribution, like Gentoo, Hmm, all modifications to setup.py should work on Windows either. > 1. If not already done so, follow the instructions at > http://peak.telecommunity.com/DevCenter/EasyInstall#installing-easy-install Is it a MUST? > -from distutils.core import setup, Extension > +from setuptools import setup, Extension, find_packages Hmm, this replaces distutils completely. Isn't there any pattern for a fall-back to distutils if setuptools is not available? > +if float(sys.version[:3]) < 2.3: > + packages = find_packages('ldap', 'ldap.schema') > [..] > #-- Python packages (doesn't work with Python prior 2.3) > -# packages = ['ldap', 'ldap.schema'], > + packages = packages, And how to build that with Python 2.2 and earlier? > + platforms = ['posix'] Shouldn't that be derived from sys.platform during build? Or at least to be defined in setup.cfg. That's what it's for. For now I consider your patch to solve the .egg thingy for you. I won't patch the general setup.py in standard source distribution. I might add your version of setup.py as setup_egg.py under Build/ in the source distribution. Ciao, Michael. From python-ldap at tk-webart.de Sat Jul 14 22:35:07 2007 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Sat, 14 Jul 2007 22:35:07 +0200 Subject: python-ldap on PyPI Message-ID: <273644106.20070714223507@tk-webart.de> On Saturday, July 14, 2007 at 16:47 Michael Str?der wrote: >> Using a standard Linux distribution, like Gentoo, > Hmm, all modifications to setup.py should work on Windows either. Do you mean _native_ Win32 or rather Cygwin? Is there native OpenLDAP support for Win32? >> 1. If not already done so, follow the instructions at >> http://peak.telecommunity.com/DevCenter/EasyInstall#installing-easy-install > Is it a MUST? For the .egg, yes, since only setuptools provide the necessary bdist_egg command. >> -from distutils.core import setup, Extension >> +from setuptools import setup, Extension, find_packages > Hmm, this replaces distutils completely. Isn't there any pattern for a > fall-back to distutils if setuptools is not available? Oh, something like: setuptools = False try: from setuptools import setup, Extension, find_packages setuptools = True except: from distutils.core import setup, Extension and later on: packages = None if setuptools and float(sys.version[:3]) < 2.3: packages = find_packages('ldap', 'ldap.schema') >> +if float(sys.version[:3]) < 2.3: >> + packages = find_packages('ldap', 'ldap.schema') >> [..] >> #-- Python packages (doesn't work with Python prior 2.3) >> -# packages = ['ldap', 'ldap.schema'], >> + packages = packages, > And how to build that with Python 2.2 and earlier? Oh, the comment: #-- Python packages (doesn't work with Python prior 2.3) is not mine. Thus, I set packages to None above the if-statement (which should actually be the same as leaving the packages variable out completely, which was the case in the original setup.py). >> + platforms = ['posix'] > Shouldn't that be derived from sys.platform during build? > Or at least to be defined in setup.cfg. That's what it's for. Sorry, I didn't know that - this was my first platform-specific egg, so I thought it's to be set there (I found this one in another setup.py). > For now I consider your patch to solve the .egg thingy for you. I won't > patch the general setup.py in standard source distribution. I might add > your version of setup.py as setup_egg.py under Build/ in the source > distribution. Hmm, perhaps we could come to a more general solution cooperatively. PyPI is quickly becoming for Python what CPAN is for Perl, so I don't think that an important package like Python-LDAP should stand back there. On monday I'll try to create a setup.py that still works with distutils and Python 2.2. But due to my lack of experience in Windows programming I'd highly appreciate, if you (or someone else with the necessary experience) could test the whole thing on the Win32 platform... Do we have a deal? ;o) Greetings Torsten -- Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de Never make anything simple and efficient when a way can be found to make it complex and wonderful. - Murphy's Law No. 13 - From python-ldap at tk-webart.de Sun Jul 15 16:13:25 2007 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Sun, 15 Jul 2007 16:13:25 +0200 Subject: python-ldap on PyPI (next version) In-Reply-To: <273644106.20070714223507@tk-webart.de> References: <273644106.20070714223507@tk-webart.de> Message-ID: <331718377.20070715161325@tk-webart.de> Hi folks, greetings Michael, after a few modifications, the patch keeps full backward compatibility to distutils and (hopefully at least ;o) works with Python 2.2 and Windows. Major changes: * fallback to distutils.core, if setuptools are not available * all additional keyword arguments to setup() are set on condition that setuptools could be imported * got rid completely of the packages= and platform= keywords (packages doesn't work, after all - and doesn't seem to be necessary) Would be glad, if someone could try out the whole thing for Win32, Python 2.2, with and without setuptools, etc. Have a nice sunday! Torsten -- Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de Never make anything simple and efficient when a way can be found to make it complex and wonderful. - Murphy's Law No. 13 - -------------- next part -------------- A non-text attachment was scrubbed... Name: 2007-07-15-python-ldap-2.3-setuptools.diff Type: application/octet-stream Size: 1847 bytes Desc: not available URL: From michael at stroeder.com Mon Jul 16 12:40:48 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 16 Jul 2007 12:40:48 +0200 Subject: python-ldap on PyPI (next version) In-Reply-To: <331718377.20070715161325@tk-webart.de> References: <273644106.20070714223507@tk-webart.de> <331718377.20070715161325@tk-webart.de> Message-ID: <469B4B30.4000502@stroeder.com> Hi Torsten, thanks for improving setup.py. Torsten Kurbad wrote: > > after a few modifications, the patch keeps full backward compatibility > to distutils and (hopefully at least ;o) works with Python 2.2 and > Windows. I've tested it (under openSUSE Linux) without setuptools with 2.2 and 2.5 and it works. So I've committed it to CVS. Ciao, Michael. From michael at stroeder.com Mon Jul 16 13:01:36 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 16 Jul 2007 13:01:36 +0200 Subject: Preparing release 2.3.1 Message-ID: <469B5010.1030008@stroeder.com> HI! I'd like to release 2.3.1 soon. There are some interesting improvements in HEAD but not yet released. Therefore testing of HEAD is needed. Thanks to the contributors! Please provide feedback ideally on the mailing list. Thanks. Ciao, Michael. Current CHANGES: Released 2.3.1 2007-07-xx Changes since 2.3.0: * Support for setuptools (building .egg, thanks to Torsten) * Support for matched values control (RFC 3876, thanks to Andreas) Lib/ * Fixed ldif (see SF#1709111, thanks to Dmitry) Modules/ * Added constant MOD_INCREMENT to support modify+increment extension (see RFC 4525, thanks to Andreas) From michael at stroeder.com Mon Jul 16 12:50:30 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 16 Jul 2007 12:50:30 +0200 Subject: [PATCH] RFC 3876 control (return values filter) In-Reply-To: <20070601142745.GA4388@mandriva.com.br> References: <20070601142745.GA4388@mandriva.com.br> Message-ID: <469B4D76.2080909@stroeder.com> Andreas Hasenack wrote: > On Thu, May 31, 2007 at 07:23:36PM -0300, Andreas Hasenack wrote: >> I will still see about the decode part and then post what I have. > > Attached is my current patch. Keep in mind I did this basically using > the current code as a template. I've committed this patch to CVS. I'd appreciate if you could also provide a small script for Demo/. Ciao, Michael. From ahasenack at terra.com.br Tue Jul 17 03:36:19 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Mon, 16 Jul 2007 22:36:19 -0300 Subject: [PATCH] RFC 3876 control (return values filter) In-Reply-To: <469B4D76.2080909@stroeder.com> References: <20070601142745.GA4388@mandriva.com.br> <469B4D76.2080909@stroeder.com> Message-ID: <200707162236.19961.ahasenack@terra.com.br> On Monday 16 July 2007 07:50:30 Michael Str?der wrote: > Andreas Hasenack wrote: > > On Thu, May 31, 2007 at 07:23:36PM -0300, Andreas Hasenack wrote: > >> I will still see about the decode part and then post what I have. > > > > Attached is my current patch. Keep in mind I did this basically using > > the current code as a template. > > I've committed this patch to CVS. I'd appreciate if you could also > provide a small script for Demo/. Thanks, I'll get you such a script soon. From python-ldap at tk-webart.de Tue Jul 17 14:31:59 2007 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Tue, 17 Jul 2007 14:31:59 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <469CA408.1070303@oilspace.com> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> <469CA408.1070303@oilspace.com> Message-ID: <469CB6BF.8060407@tk-webart.de> Timur Izhbulatov wrote: > Don't forget that the easy_install command works perfectly with > project download pages on sf.net. So, I don't think it is necessary to > upload .eggs to PyPI. The question for me is: Does zc.buildout support this method. To clearify: We are developing projects that are widely based on Zope3 (http://www.zope.org). The zope corporation developed a concept named buildout to install .eggs locally in a project directory, which is interesting for users who don't have permission to write into the system's site-packages. This way, also different versions of python packages may coexist peacefully, since buildouts don't know the environment of their neighbors. I will check, if the buildout.cfg supports checking out and building eggs from sf.net, but nevertheless, building on e.g. OS X is a bit tricky, since it lacks the appropriate openldap-2.3 and sasl headers, not even to speak of Win32... And uploading to PyPI is as easy as: # python setup.py register bdist_egg upload Regards, Torsten -- Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de Ich schreibe dir einen langen Brief, weil ich keine Zeit habe, einen kurzen zu schreiben. -- Johann Wolfgang von Goethe -- From TimurIzhbulatov at oilspace.com Tue Jul 17 14:45:37 2007 From: TimurIzhbulatov at oilspace.com (Timur Izhbulatov) Date: Tue, 17 Jul 2007 16:45:37 +0400 Subject: Preparing release 2.3.1 In-Reply-To: <469CB6BF.8060407@tk-webart.de> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> <469CA408.1070303@oilspace.com> <469CB6BF.8060407@tk-webart.de> Message-ID: <469CB9F1.8030602@oilspace.com> Torsten Kurbad wrote: > Timur Izhbulatov wrote: >> Don't forget that the easy_install command works perfectly with >> project download pages on sf.net. So, I don't think it is necessary to >> upload .eggs to PyPI. > The question for me is: Does zc.buildout support this method. To clearify: We are developing projects that are widely based on Zope3 (http://www.zope.org). The zope corporation developed a concept named buildout to install .eggs locally in a project directory, which is interesting for users who don't have permission to write into the system's site-packages. This way, also different versions of python packages may coexist peacefully, since buildouts don't know the environment of their neighbors. > > I will check, if the buildout.cfg supports checking out and building eggs from sf.net, but nevertheless, building on e.g. OS X is a bit tricky, since it lacks the appropriate openldap-2.3 and sasl headers, not even to speak of Win32... According to [1] buildout supports the 'find-links' option which should solve your problem. Also, I don't think it has something to do with the location of your python libraries. For example, I keep most of the stuff I need in $HOME/lib/python. > And uploading to PyPI is as easy as: > > # python setup.py register bdist_egg upload Of course. But I think it's better to keep all eggs in one basket =) [1] http://www.zope.org/DevHome/Buildout/egg.html Cheers, -- Timur Izhbulatov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:TimurIzhbulatov at oilspace.com Building Successful Supply Chains - One Solution At A Time. www.oilspace.com From python-ldap at tk-webart.de Tue Jul 17 15:13:02 2007 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Tue, 17 Jul 2007 15:13:02 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <469CB9F1.8030602@oilspace.com> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> <469CA408.1070303@oilspace.com> <469CB6BF.8060407@tk-webart.de> <469CB9F1.8030602@oilspace.com> Message-ID: <469CC05E.7020006@tk-webart.de> Timur Izhbulatov wrote: > > According to [1] buildout supports the 'find-links' option which > should solve your problem. Yes, I actively use that option to support our local eggs... ;o) So, not to get into some misunderstandings here: You'd like to keep the _precompiled_ .eggs in sf.net , not just the source? That would be perfectly fine with me. Regards, Torsten -- Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de Ich schreibe dir einen langen Brief, weil ich keine Zeit habe, einen kurzen zu schreiben. -- Johann Wolfgang von Goethe -- From aspineux at gmail.com Tue Jul 17 15:22:02 2007 From: aspineux at gmail.com (Alain Spineux) Date: Tue, 17 Jul 2007 15:22:02 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <469B5010.1030008@stroeder.com> References: <469B5010.1030008@stroeder.com> Message-ID: <71fe4e760707170622w357d5107o34bbd3d126bec48a@mail.gmail.com> Hi I tried the CVS head and got problem First I got this error when building the egg cc: unrecognized option '-R/usr/local/openldap-2.3/lib' The full command is /kolab/bin/cc -pthread -shared build/temp.linux-i686-2.4/Modules/LDAPObject.o build/temp.linux-i686-2.4/Modules/ldapcontrol.o build/temp.linux-i686-2.4/Modules/common.o build/temp.linux-i686-2.4/Modules/constants.o build/temp.linux-i686-2.4/Modules/errors.o build/temp.linux-i686-2.4/Modules/functions.o build/temp.linux-i686-2.4/Modules/schema.o build/temp.linux-i686-2.4/Modules/ldapmodule.o build/temp.linux-i686-2.4/Modules/message.o build/temp.linux-i686-2.4/Modules/version.o build/temp.linux-i686-2.4/Modules/options.o -L/usr/local/openldap-2.3/lib -R/usr/local/openldap-2.3/lib -lldap_r -llber -lsasl2 -lssl -lcrypto -o build/lib.linux-i686-2.4/_ldap.so I removed the references to /usr/local/openldap-2.3/ in setup.cfg and got and egg, I installed the egg and removed any old file from site packages rm -rf dsml.py dsml.pyo ldapurl.pyc ldif.py ldif.pyo dsml.pyc ldapurl.py ldapurl.pyo ldif.pyc ldap/ I got the fologing error when starting my project: Traceback (most recent call last): File "./start-emailgency.py", line 53, in ? from emailgency.controllers import Root File "/s0/asx/src/emailgency/trunk/emailgency/controllers.py", line 8, in ? import main_ctrl, pas_sub_ctrl, addr_ctrl, common_ctrl File "/s0/asx/src/emailgency/trunk/emailgency/main_ctrl.py", line 12, in ? from emailgency import json, eg_dns, eg_mail, rrdtoolx, egsyslib, eg_config File "/s0/asx/src/emailgency/trunk/emailgency/egsyslib.py", line 8, in ? from eg_kolab_lib import KolabConnection File "/s0/asx/src/emailgency/trunk/emailgency/eg_kolab_lib.py", line 4, in ? import ldap, ldap.modlist, ldapurl File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/__init__.py", line 48, in ? from functions import open,initialize,init,get_option,set_option File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/functions.py", line 36, in ? from ldap.ldapobject import LDAPObject File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/ldapobject.py", line 40, in ? from ldap.controls import LDAPControl,DecodeControlTuples,EncodeControlTuples File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/controls.py", line 85, in ? class MatchedValuesControl(LDAPControl): File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/controls.py", line 93, in MatchedValuesControl controlType = ldap.LDAP_CONTROL_VALUESRETURNFILTER AttributeError: 'module' object has no attribute 'LDAP_CONTROL_VALUESRETURNFILTER' any idea ? On 7/16/07, Michael Str?der wrote: > HI! > > I'd like to release 2.3.1 soon. There are some interesting improvements > in HEAD but not yet released. Therefore testing of HEAD is needed. > Thanks to the contributors! > > Please provide feedback ideally on the mailing list. Thanks. > > Ciao, Michael. > > Current CHANGES: > > Released 2.3.1 2007-07-xx > > Changes since 2.3.0: > > * Support for setuptools (building .egg, thanks to Torsten) > * Support for matched values control (RFC 3876, thanks to Andreas) > > Lib/ > * Fixed ldif (see SF#1709111, thanks to Dmitry) > > Modules/ > * Added constant MOD_INCREMENT to support > modify+increment extension (see RFC 4525, thanks to Andreas) > > From aspineux at gmail.com Tue Jul 17 15:30:18 2007 From: aspineux at gmail.com (Alain Spineux) Date: Tue, 17 Jul 2007 15:30:18 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <71fe4e760707170622w357d5107o34bbd3d126bec48a@mail.gmail.com> References: <469B5010.1030008@stroeder.com> <71fe4e760707170622w357d5107o34bbd3d126bec48a@mail.gmail.com> Message-ID: <71fe4e760707170630l52f463dck1470c3fdf795a528@mail.gmail.com> I did this, and it looks to be working. Also with my unicode extension :-) diff -r -c python-ldap-2.3.1/Modules/constants.c python-ldap/Modules/constants.c *** python-ldap-2.3.1/Modules/constants.c Tue Jun 5 11:56:15 2007 --- python-ldap/Modules/constants.c Tue Jul 17 15:26:14 2007 *************** *** 263,266 **** --- 263,270 ---- PyDict_SetItemString( d, "LDAP_CONTROL_PAGE_OID", obj ); Py_DECREF(obj); + obj = PyString_FromString(LDAP_CONTROL_VALUESRETURNFILTER); + PyDict_SetItemString( d, "LDAP_CONTROL_VALUESRETURNFILTER", obj ); + Py_DECREF(obj); + } On 7/17/07, Alain Spineux wrote: > Hi > I tried the CVS head and got problem > > First I got this error when building the egg > > cc: unrecognized option '-R/usr/local/openldap-2.3/lib' > > The full command is > > /kolab/bin/cc -pthread -shared > build/temp.linux-i686-2.4/Modules/LDAPObject.o > build/temp.linux-i686-2.4/Modules/ldapcontrol.o > build/temp.linux-i686-2.4/Modules/common.o > build/temp.linux-i686-2.4/Modules/constants.o > build/temp.linux-i686-2.4/Modules/errors.o > build/temp.linux-i686-2.4/Modules/functions.o > build/temp.linux-i686-2.4/Modules/schema.o > build/temp.linux-i686-2.4/Modules/ldapmodule.o > build/temp.linux-i686-2.4/Modules/message.o > build/temp.linux-i686-2.4/Modules/version.o > build/temp.linux-i686-2.4/Modules/options.o > -L/usr/local/openldap-2.3/lib -R/usr/local/openldap-2.3/lib -lldap_r > -llber -lsasl2 -lssl -lcrypto -o build/lib.linux-i686-2.4/_ldap.so > > I removed the references to /usr/local/openldap-2.3/ in setup.cfg and > got and egg, I installed > the egg and removed any old file from site packages > > rm -rf dsml.py dsml.pyo ldapurl.pyc ldif.py ldif.pyo dsml.pyc > ldapurl.py ldapurl.pyo ldif.pyc ldap/ > > I got the fologing error when starting my project: > > Traceback (most recent call last): > File "./start-emailgency.py", line 53, in ? > from emailgency.controllers import Root > File "/s0/asx/src/emailgency/trunk/emailgency/controllers.py", line 8, in ? > import main_ctrl, pas_sub_ctrl, addr_ctrl, common_ctrl > File "/s0/asx/src/emailgency/trunk/emailgency/main_ctrl.py", line 12, in ? > from emailgency import json, eg_dns, eg_mail, rrdtoolx, egsyslib, eg_config > File "/s0/asx/src/emailgency/trunk/emailgency/egsyslib.py", line 8, in ? > from eg_kolab_lib import KolabConnection > File "/s0/asx/src/emailgency/trunk/emailgency/eg_kolab_lib.py", line 4, in ? > import ldap, ldap.modlist, ldapurl > File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/__init__.py", > line 48, in ? > from functions import open,initialize,init,get_option,set_option > File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/functions.py", > line 36, in ? > from ldap.ldapobject import LDAPObject > File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/ldapobject.py", > line 40, in ? > from ldap.controls import > LDAPControl,DecodeControlTuples,EncodeControlTuples > File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/controls.py", > line 85, in ? > class MatchedValuesControl(LDAPControl): > File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/controls.py", > line 93, in MatchedValuesControl > controlType = ldap.LDAP_CONTROL_VALUESRETURNFILTER > AttributeError: 'module' object has no attribute > 'LDAP_CONTROL_VALUESRETURNFILTER' > > any idea ? > > On 7/16/07, Michael Str?der wrote: > > HI! > > > > I'd like to release 2.3.1 soon. There are some interesting improvements > > in HEAD but not yet released. Therefore testing of HEAD is needed. > > Thanks to the contributors! > > > > Please provide feedback ideally on the mailing list. Thanks. > > > > Ciao, Michael. > > > > Current CHANGES: > > > > Released 2.3.1 2007-07-xx > > > > Changes since 2.3.0: > > > > * Support for setuptools (building .egg, thanks to Torsten) > > * Support for matched values control (RFC 3876, thanks to Andreas) > > > > Lib/ > > * Fixed ldif (see SF#1709111, thanks to Dmitry) > > > > Modules/ > > * Added constant MOD_INCREMENT to support > > modify+increment extension (see RFC 4525, thanks to Andreas) > > > > From aspineux at gmail.com Tue Jul 17 15:59:29 2007 From: aspineux at gmail.com (Alain Spineux) Date: Tue, 17 Jul 2007 15:59:29 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <71fe4e760707170630l52f463dck1470c3fdf795a528@mail.gmail.com> References: <469B5010.1030008@stroeder.com> <71fe4e760707170622w357d5107o34bbd3d126bec48a@mail.gmail.com> <71fe4e760707170630l52f463dck1470c3fdf795a528@mail.gmail.com> Message-ID: <71fe4e760707170659n15ec9041h7d54fe647ca0b6a9@mail.gmail.com> Hi again Could you add a note about how to build an egg at the end of INSALL file ? To avoid to spend 10min looking for the correct syntax in the setuptools documentation :-) python setup.py bdist_egg thanks On 7/17/07, Alain Spineux wrote: > I did this, and it looks to be working. > Also with my unicode extension :-) > > > diff -r -c python-ldap-2.3.1/Modules/constants.c python-ldap/Modules/constants.c > *** python-ldap-2.3.1/Modules/constants.c Tue Jun 5 11:56:15 2007 > --- python-ldap/Modules/constants.c Tue Jul 17 15:26:14 2007 > *************** > *** 263,266 **** > --- 263,270 ---- > PyDict_SetItemString( d, "LDAP_CONTROL_PAGE_OID", obj ); > Py_DECREF(obj); > > + obj = PyString_FromString(LDAP_CONTROL_VALUESRETURNFILTER); > + PyDict_SetItemString( d, "LDAP_CONTROL_VALUESRETURNFILTER", obj ); > + Py_DECREF(obj); > + > } > > > > On 7/17/07, Alain Spineux wrote: > > Hi > > I tried the CVS head and got problem > > > > First I got this error when building the egg > > > > cc: unrecognized option '-R/usr/local/openldap-2.3/lib' > > > > The full command is > > > > /kolab/bin/cc -pthread -shared > > build/temp.linux-i686-2.4/Modules/LDAPObject.o > > build/temp.linux-i686-2.4/Modules/ldapcontrol.o > > build/temp.linux-i686-2.4/Modules/common.o > > build/temp.linux-i686-2.4/Modules/constants.o > > build/temp.linux-i686-2.4/Modules/errors.o > > build/temp.linux-i686-2.4/Modules/functions.o > > build/temp.linux-i686-2.4/Modules/schema.o > > build/temp.linux-i686-2.4/Modules/ldapmodule.o > > build/temp.linux-i686-2.4/Modules/message.o > > build/temp.linux-i686-2.4/Modules/version.o > > build/temp.linux-i686-2.4/Modules/options.o > > -L/usr/local/openldap-2.3/lib -R/usr/local/openldap-2.3/lib -lldap_r > > -llber -lsasl2 -lssl -lcrypto -o build/lib.linux-i686-2.4/_ldap.so > > > > I removed the references to /usr/local/openldap-2.3/ in setup.cfg and > > got and egg, I installed > > the egg and removed any old file from site packages > > > > rm -rf dsml.py dsml.pyo ldapurl.pyc ldif.py ldif.pyo dsml.pyc > > ldapurl.py ldapurl.pyo ldif.pyc ldap/ > > > > I got the fologing error when starting my project: > > > > Traceback (most recent call last): > > File "./start-emailgency.py", line 53, in ? > > from emailgency.controllers import Root > > File "/s0/asx/src/emailgency/trunk/emailgency/controllers.py", line 8, in ? > > import main_ctrl, pas_sub_ctrl, addr_ctrl, common_ctrl > > File "/s0/asx/src/emailgency/trunk/emailgency/main_ctrl.py", line 12, in ? > > from emailgency import json, eg_dns, eg_mail, rrdtoolx, egsyslib, eg_config > > File "/s0/asx/src/emailgency/trunk/emailgency/egsyslib.py", line 8, in ? > > from eg_kolab_lib import KolabConnection > > File "/s0/asx/src/emailgency/trunk/emailgency/eg_kolab_lib.py", line 4, in ? > > import ldap, ldap.modlist, ldapurl > > File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/__init__.py", > > line 48, in ? > > from functions import open,initialize,init,get_option,set_option > > File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/functions.py", > > line 36, in ? > > from ldap.ldapobject import LDAPObject > > File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/ldapobject.py", > > line 40, in ? > > from ldap.controls import > > LDAPControl,DecodeControlTuples,EncodeControlTuples > > File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/controls.py", > > line 85, in ? > > class MatchedValuesControl(LDAPControl): > > File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.egg/ldap/controls.py", > > line 93, in MatchedValuesControl > > controlType = ldap.LDAP_CONTROL_VALUESRETURNFILTER > > AttributeError: 'module' object has no attribute > > 'LDAP_CONTROL_VALUESRETURNFILTER' > > > > any idea ? > > > > On 7/16/07, Michael Str?der wrote: > > > HI! > > > > > > I'd like to release 2.3.1 soon. There are some interesting improvements > > > in HEAD but not yet released. Therefore testing of HEAD is needed. > > > Thanks to the contributors! > > > > > > Please provide feedback ideally on the mailing list. Thanks. > > > > > > Ciao, Michael. > > > > > > Current CHANGES: > > > > > > Released 2.3.1 2007-07-xx > > > > > > Changes since 2.3.0: > > > > > > * Support for setuptools (building .egg, thanks to Torsten) > > > * Support for matched values control (RFC 3876, thanks to Andreas) > > > > > > Lib/ > > > * Fixed ldif (see SF#1709111, thanks to Dmitry) > > > > > > Modules/ > > > * Added constant MOD_INCREMENT to support > > > modify+increment extension (see RFC 4525, thanks to Andreas) > > > > > > From python-ldap at tk-webart.de Tue Jul 17 16:08:07 2007 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Tue, 17 Jul 2007 16:08:07 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <71fe4e760707170659n15ec9041h7d54fe647ca0b6a9@mail.gmail.com> References: <469B5010.1030008@stroeder.com> <71fe4e760707170622w357d5107o34bbd3d126bec48a@mail.gmail.com> <71fe4e760707170630l52f463dck1470c3fdf795a528@mail.gmail.com> <71fe4e760707170659n15ec9041h7d54fe647ca0b6a9@mail.gmail.com> Message-ID: <469CCD47.7070401@tk-webart.de> Alain Spineux wrote: > Hi again > > Could you add a note about how to build an egg at the end of INSALL file ? > To avoid to spend 10min looking for the correct syntax in the > setuptools documentation :-) > The setup.py comes with a very neat option that could have saved you lots of trouble and works with both distutils and setuptools. ;o) Try: python setup.py --help-commands Regards, Torsten -- Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de Ich schreibe dir einen langen Brief, weil ich keine Zeit habe, einen kurzen zu schreiben. -- Johann Wolfgang von Goethe -- From python-ldap at tk-webart.de Tue Jul 17 12:59:43 2007 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Tue, 17 Jul 2007 12:59:43 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <469B5010.1030008@stroeder.com> References: <469B5010.1030008@stroeder.com> Message-ID: <469CA11F.7070504@tk-webart.de> Hi Michael, > I'd like to release 2.3.1 soon. still one question: Do you plan to upload some .eggs to PyPI then? I meanwhile successfully build eggs for i686-linux as well as Mac OS X 10.4 PPC (Intel platforms should work the same way) using Py 2.3 + 2.4. Nice to have would be an egg for the Windows platform, which I can't build due to the lack of a proper Windows devel environment. Anyway, after 2.3.1 is released, I'd be happy to contribute the mentioned .egg files - could you then upload them to PyPI? I could do that, too, but it's for you to decide... Best regards, Torsten -- Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de Ich schreibe dir einen langen Brief, weil ich keine Zeit habe, einen kurzen zu schreiben. -- Johann Wolfgang von Goethe -- From TimurIzhbulatov at oilspace.com Tue Jul 17 13:12:08 2007 From: TimurIzhbulatov at oilspace.com (Timur Izhbulatov) Date: Tue, 17 Jul 2007 15:12:08 +0400 Subject: Preparing release 2.3.1 In-Reply-To: <469CA11F.7070504@tk-webart.de> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> Message-ID: <469CA408.1070303@oilspace.com> Torsten Kurbad wrote: > Hi Michael, >> I'd like to release 2.3.1 soon. > still one question: Do you plan to upload some .eggs to PyPI then? > I meanwhile successfully build eggs for i686-linux as well as Mac OS X 10.4 PPC (Intel platforms should work the same way) using Py 2.3 + 2.4. > > Nice to have would be an egg for the Windows platform, which I can't build due to the lack of a proper Windows devel environment. > > Anyway, after 2.3.1 is released, I'd be happy to contribute the mentioned .egg files - could you then upload them to PyPI? > I could do that, too, but it's for you to decide... > Hi guys, Don't forget that the easy_install command works perfectly with project download pages on sf.net. So, I don't think it is necessary to upload .eggs to PyPI. In my opinion it would be better to keep files on sf.net and publish just the URL to the download page on PyPI. Best Regards, -- Timur Izhbulatov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:TimurIzhbulatov at oilspace.com Building Successful Supply Chains - One Solution At A Time. www.oilspace.com From michael at stroeder.com Tue Jul 17 21:38:34 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 17 Jul 2007 21:38:34 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <71fe4e760707170630l52f463dck1470c3fdf795a528@mail.gmail.com> References: <469B5010.1030008@stroeder.com> <71fe4e760707170622w357d5107o34bbd3d126bec48a@mail.gmail.com> <71fe4e760707170630l52f463dck1470c3fdf795a528@mail.gmail.com> Message-ID: <469D1ABA.5040109@stroeder.com> Alain Spineux wrote: > I did this, and it looks to be working. Ouch! Modules/constants.c was not comitted to CVS. Thanks. > Also with my unicode extension :-) I knew you would ask for it. I will follow-up on this later... Ciao, Michael. From michael at stroeder.com Wed Jul 18 08:01:05 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 18 Jul 2007 08:01:05 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <469CA11F.7070504@tk-webart.de> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> Message-ID: <469DACA1.6000504@stroeder.com> Torsten Kurbad wrote: >> I'd like to release 2.3.1 soon. > still one question: Do you plan to upload some .eggs to PyPI then? > I meanwhile successfully build eggs for i686-linux as well as Mac OS > X 10.4 PPC (Intel platforms should work the same way) using Py 2.3 + > 2.4. > > Nice to have would be an egg for the Windows platform, which I can't > build due to the lack of a proper Windows devel environment. > > Anyway, after 2.3.1 is released, I'd be happy to contribute the > mentioned .egg files - could you then upload them to PyPI? I could do > that, too, but it's for you to decide... Being in the role of the maintainer I'm always concerned about continuous support for a certain mechanism. Since .egg files are platform-specific the question arises: Who is going to provide which builds for every new release? On which platforms/distros? With which OpenLDAP/SASL/OpenSSL libs? Today especially the situation regarding Win32 builds is poor. A *strong* commitment of volunteers is needed... Ciao, Michael. From python-ldap at tk-webart.de Wed Jul 18 08:56:42 2007 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Wed, 18 Jul 2007 08:56:42 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <469DACA1.6000504@stroeder.com> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> <469DACA1.6000504@stroeder.com> Message-ID: <194575888.20070718085642@tk-webart.de> On Wednesday, July 18, 2007 at 08:01 Michael Str?der wrote: > Being in the role of the maintainer I'm always concerned about > continuous support for a certain mechanism. Understandable. > Since .egg files are > platform-specific the question arises: > Who is going to provide which builds for every new release? Good question. > On which platforms/distros? > With which OpenLDAP/SASL/OpenSSL libs? There are some systems that make the decision easy: Mac OS X, e.g. comes with a set of SASL and OpenLDAP libs by default. After getting the necessary headers from a Linux-Installation I was able to build .eggs there with the standard system-Python (2.3.5). On Linux, of course, the situation is much more difficult. I use Gentoo, which is in many ways very standards compatible, but I use bleeding edge libraries, like glibc 2.6, OpenLDAP 2.3.36 etc. The past showed that an old distribution, like RedHat 8, combined with some newer libraries, but with an "old" glibc provides almost 100% compatibility of binary builds to other distros. I think, it's a question of defining prerequisites, like: If you want to run this from an .egg, you need at least OpenLDAP 2.3, etc. But still, it's a complex task that should be shared among several people. > Today especially the situation regarding Win32 builds is poor. A > *strong* commitment of volunteers is needed... Yes, I understand that. For the moment let's perhaps agree to the following: After 2.3.1 is out, I will build .eggs on every platform and every OS at my disposal and put them in our "private" distribution at http://svn.kmrc.de/distribution If you want to, you may announce that on the Homepage and/or in the docs then, but with a remark saying that these .eggs may be out of date. Whenever I can spare the time, I'll build .eggs for upcoming releases. Greetings, Torsten -- Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de Never make anything simple and efficient when a way can be found to make it complex and wonderful. - Murphy's Law No. 13 - From d at adaptive-enterprises.com.au Wed Jul 18 10:04:39 2007 From: d at adaptive-enterprises.com.au (David Leonard) Date: Wed, 18 Jul 2007 18:04:39 +1000 Subject: Preparing release 2.3.1 In-Reply-To: <469DACA1.6000504@stroeder.com> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> <469DACA1.6000504@stroeder.com> Message-ID: <469DC997.3050902@adaptive-enterprises.com.au> Perhaps there might be some interest in people running buildbot slaves? (http://buildbot.net/) Michael, you could run a trusted buildmaster, and helpers would run buildslaves that connect to your master. Michael Str?der wrote: > Torsten Kurbad wrote: > >>> I'd like to release 2.3.1 soon. >>> >> still one question: Do you plan to upload some .eggs to PyPI then? >> I meanwhile successfully build eggs for i686-linux as well as Mac OS >> X 10.4 PPC (Intel platforms should work the same way) using Py 2.3 + >> 2.4. >> >> Nice to have would be an egg for the Windows platform, which I can't >> build due to the lack of a proper Windows devel environment. >> >> Anyway, after 2.3.1 is released, I'd be happy to contribute the >> mentioned .egg files - could you then upload them to PyPI? I could do >> that, too, but it's for you to decide... >> > > Being in the role of the maintainer I'm always concerned about > continuous support for a certain mechanism. Since .egg files are > platform-specific the question arises: > Who is going to provide which builds for every new release? > On which platforms/distros? > With which OpenLDAP/SASL/OpenSSL libs? > > Today especially the situation regarding Win32 builds is poor. A > *strong* commitment of volunteers is needed... > > Ciao, Michael. > > - -- David Leonard d at adaptive-enterprises.com.au Ph:+61 404 844 850 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Jul 18 10:19:03 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 18 Jul 2007 10:19:03 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <469DC997.3050902@adaptive-enterprises.com.au> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> <469DACA1.6000504@stroeder.com> <469DC997.3050902@adaptive-enterprises.com.au> Message-ID: <469DCCF7.7010903@stroeder.com> David Leonard wrote: > Perhaps there might be some interest in people running buildbot slaves? > (http://buildbot.net/) > Michael, you could run a trusted buildmaster, and helpers would run > buildslaves that connect to your master. Frankly I don't have currently the time for diving into it. We have so many dependencies, each deployer of python-ldap could have different needs: Python OpenLDAP Cyrus-SASL Kerberos (MIT/heimdal) OpenSSL I'm rather reluctant to open that can of worms... Ciao, Michael. From aspineux at gmail.com Wed Jul 18 14:00:14 2007 From: aspineux at gmail.com (Alain Spineux) Date: Wed, 18 Jul 2007 14:00:14 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <469DCCF7.7010903@stroeder.com> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> <469DACA1.6000504@stroeder.com> <469DC997.3050902@adaptive-enterprises.com.au> <469DCCF7.7010903@stroeder.com> Message-ID: <71fe4e760707180500h2c699c60s841b56d3aa575c7b@mail.gmail.com> Don't forget your package is already included in some distribution and then widely available. Personally I'm happy to have eggs functionality to deploy the same egg on multiple identical machine with custom configuration. The best effort solution is to publish the version you can and all spontaneous contributions. Regards On 7/18/07, Michael Str?der wrote: > David Leonard wrote: > > Perhaps there might be some interest in people running buildbot slaves? > > (http://buildbot.net/) > > Michael, you could run a trusted buildmaster, and helpers would run > > buildslaves that connect to your master. > > Frankly I don't have currently the time for diving into it. > > We have so many dependencies, each deployer of python-ldap could have > different needs: > Python > OpenLDAP > Cyrus-SASL > Kerberos (MIT/heimdal) > OpenSSL > > I'm rather reluctant to open that can of worms... > > Ciao, Michael. > > From ryan at stat.Berkeley.EDU Wed Jul 18 19:21:48 2007 From: ryan at stat.Berkeley.EDU (Ryan Lovett) Date: Wed, 18 Jul 2007 10:21:48 -0700 Subject: Preparing release 2.3.1 In-Reply-To: <71fe4e760707180500h2c699c60s841b56d3aa575c7b@mail.gmail.com> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> <469DACA1.6000504@stroeder.com> <469DC997.3050902@adaptive-enterprises.com.au> <469DCCF7.7010903@stroeder.com> <71fe4e760707180500h2c699c60s841b56d3aa575c7b@mail.gmail.com> Message-ID: <20070718172148.GA29659@stat.berkeley.edu> On Wed, Jul 18, 2007 at 02:00:14PM +0200, Alain Spineux wrote: > Don't forget your package is already included in some distribution > and then widely available. Given that python-ldap is packaged by almost everyone, (excluding Microsoft, Apple, and Sun) what is there to gain with this binary distribution effort? Would anyone using Debian/Ubuntu, Red Hat/Fedora, SuSE, Mandriva, etc. require this project to distribute .egg files? I ask out of genuine curiosity, not to dissuade whoever is interested from pursuing this. I have no experience with using .eggs. Ryan From TimurIzhbulatov at oilspace.com Thu Jul 19 08:47:39 2007 From: TimurIzhbulatov at oilspace.com (Timur Izhbulatov) Date: Thu, 19 Jul 2007 10:47:39 +0400 Subject: Preparing release 2.3.1 In-Reply-To: <20070718172148.GA29659@stat.berkeley.edu> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> <469DACA1.6000504@stroeder.com> <469DC997.3050902@adaptive-enterprises.com.au> <469DCCF7.7010903@stroeder.com> <71fe4e760707180500h2c699c60s841b56d3aa575c7b@mail.gmail.com> <20070718172148.GA29659@stat.berkeley.edu> Message-ID: <469F090B.5030004@oilspace.com> Ryan Lovett wrote: > On Wed, Jul 18, 2007 at 02:00:14PM +0200, Alain Spineux wrote: >> Don't forget your package is already included in some distribution >> and then widely available. > > Given that python-ldap is packaged by almost everyone, (excluding > Microsoft, Apple, and Sun) what is there to gain with this binary > distribution effort? Would anyone using Debian/Ubuntu, Red Hat/Fedora, > SuSE, Mandriva, etc. require this project to distribute .egg files? I ask > out of genuine curiosity, not to dissuade whoever is interested from > pursuing this. I have no experience with using .eggs. Good question. The problem is that setuptools won't detect python-ldap installed from distro (it's not recorded in .pth files) and this prevents developers from declaring their projects' requirements in setup.py. Providing the URL to the python-ldap download page doesn't help because at the moment the source code has to be configured manually before build. I personally would prefer to build an .egg from source because python-ldap is packaged differently across the distros. For example in Debian it is linked against gnutls rather than openssl. So, this is mostly a setuptools'/distribution problem. -- Timur Izhbulatov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:TimurIzhbulatov at oilspace.com Building Successful Supply Chains - One Solution At A Time. www.oilspace.com From michael at stroeder.com Thu Jul 19 08:52:58 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 19 Jul 2007 08:52:58 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <71fe4e760707180500h2c699c60s841b56d3aa575c7b@mail.gmail.com> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> <469DACA1.6000504@stroeder.com> <469DC997.3050902@adaptive-enterprises.com.au> <469DCCF7.7010903@stroeder.com> <71fe4e760707180500h2c699c60s841b56d3aa575c7b@mail.gmail.com> Message-ID: <469F0A4A.2020209@stroeder.com> Alain Spineux wrote: > Don't forget your package is already included in some distribution > and then widely available. Well, the coordination with distribution maintainers is somewhat difficult anyway. But the distributor has to take care of dependencies. > The best effort solution is to publish the version you can and all > spontaneous contributions. Example: I'm using openSUSE 10.2. But if I provide a build for that system it doesn't help anybody since I always have recent OpenLDAP libs under /opt/openldap-2.3. Or I might temporarily build against the heimdal libs instead of MIT libs shipped with openSUSE. => Personally I won't provide any builds. Ciao, Michael. From michael at stroeder.com Thu Jul 19 08:55:27 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 19 Jul 2007 08:55:27 +0200 Subject: Preparing release 2.3.1 In-Reply-To: <20070718172148.GA29659@stat.berkeley.edu> References: <469B5010.1030008@stroeder.com> <469CA11F.7070504@tk-webart.de> <469DACA1.6000504@stroeder.com> <469DC997.3050902@adaptive-enterprises.com.au> <469DCCF7.7010903@stroeder.com> <71fe4e760707180500h2c699c60s841b56d3aa575c7b@mail.gmail.com> <20070718172148.GA29659@stat.berkeley.edu> Message-ID: <469F0ADF.4010908@stroeder.com> Ryan Lovett wrote: > On Wed, Jul 18, 2007 at 02:00:14PM +0200, Alain Spineux wrote: >> Don't forget your package is already included in some distribution >> and then widely available. > > Given that python-ldap is packaged by almost everyone, (excluding > Microsoft, Apple, and Sun) what is there to gain with this binary > distribution effort? One benefit would be to provide a more recent version of python-ldap than the distributor. But IMO this won't really work. > Would anyone using Debian/Ubuntu, Red Hat/Fedora, > SuSE, Mandriva, etc. require this project to distribute .egg files? I don't think so. They have their own packaging system. > I have no experience with using .eggs. Nor have I. Ciao, Michael. From michael at stroeder.com Thu Jul 19 13:21:07 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 19 Jul 2007 13:21:07 +0200 Subject: Experiments with pyasn1 and preread control In-Reply-To: <20070605211241.GF25341@mandriva.com.br> References: <20070605211241.GF25341@mandriva.com.br> Message-ID: <469F4923.1060109@stroeder.com> Hello Andreas, I've added your demo script to python-ldap's CVS as Demo/pyasn1/prereadcontrol.py. I'd appreciate if you could implement the decodeControlValue() method with pyasn1. Ciao, Michael. Andreas Hasenack wrote: > I have been having fun with controls. Today I tried to use the Pre-Read > control together with the modify+increment extension, so that > modify+increment becomes actually useful. > > I first added the encoding part to the ldap.so module, but later got a > response from the pyasn1 mailing list and tried again in pure python. > The result is attached. It's not complete yet, just a test. > > The script uses mod_increment to increment uidNumber and gidNumber by > one. Attached to the modify operation is the preread control, so the > response includes the value prior to the modification. > > Here is the output of two consecutive runs. Both attributes started at > 1000 in LDAP: > > $ ./preread-asn1.py > res: (103, [], 2, [PreReadControl(1.3.6.1.1.13.1,1.3.6.1.1.13.1,'0M\x04\x1fcn=unixIdPool,dc=example,dc=com0*0\x13\x04\tgidNumber1\x06\x04\x0410000\x13\x04\tuidNumber1\x06\x04\x041000')]) > $ ./preread-asn1.py > res: (103, [], 2, [PreReadControl(1.3.6.1.1.13.1,1.3.6.1.1.13.1,'0M\x04\x1fcn=unixIdPool,dc=example,dc=com0*0\x13\x04\tgidNumber1\x06\x04\x0410010\x13\x04\tuidNumber1\x06\x04\x041001')]) > > First one returns "1000", and the second one "1001" for both attributes. > Now it's at 1002. > > The decoding part will probably be more difficult... As the control > response is a SearchResultEntry which is a bit more complex to decode. From michael at stroeder.com Thu Jul 19 15:38:56 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 19 Jul 2007 15:38:56 +0200 Subject: unicode value In-Reply-To: <71fe4e760705290729rd90c462h458d718aa748ab29@mail.gmail.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <71fe4e760705231537g5ab3f519y9116f1357a8383d@mail.gmail.com> <46553B91.3000703@stroeder.com> <71fe4e760705240534y4dced9f2t8da849af81c23cef@mail.gmail.com> <46558B61.4010808@stroeder.com> <71fe4e760705240632j78dc4e53o5270ef2f50929ced@mail.gmail.com> <46559A78.9000105@stroeder.com> <71fe4e760705240750r3daa768fhd7256289d1432d81@mail.gmail.com> <4655C3A9.5050803@stroeder.com> <71fe4e760705241216n52bf6848r9fa0e70512f8fbc9@mail.gmail.com> <71fe4e760705290729rd90c462h458d718aa748ab29@mail.gmail.com> Message-ID: <469F6970.5020203@stroeder.com> Alain, Alain Spineux wrote: > > When investigating about python and unicode, I read somewhere (in a PEP > I thing) that python functions should accept and manage unicode string > as well as normal string. Without knowing the PEP (reference?) I guess this affects functions which takes a string as an argument and process it directly returning a result. In context of python-ldap this would be directly applicable to the functions in modules ldap.dn and ldap.filter. The basic problem here is that for the sake of backward-compability to LDAPv2 the charset has to be passed around either. That's what I'm doing in web2ldap. > Of course if these strings could contains user > readable characters. Let's call that "textual strings". > Anyway I see 2 solutions > > 1. Let result() return non unicode strings. _HERE_ The user know all > returned > strings are normal strings utf-8 encoded and he can do the encoding > himself. A helper function doing the job for the result structure > should be welcome. > > 2. Do the conversion regarding the info provided in the query, as my > source sample does. > > I answer now some of your previous comment: > >> > In this case maybe is it possible to use [ '*', u'givenName', u'sn' ] >> > to convert only 'givenName' and 'sn' > >> But then you will not gain much! Still the application has to know which >> attributes have to be converted. => It's not worth hiding the conversion >> within python-ldap. > > I don't really hide the conversion, because the user has to request it using > unicode field name. I don't like this approach. The type of the attribute names is causing a type conversion side-effect. I don't consider this to be good design and I guess most Python developers would not expect something like this. Think about an application accidently passing in Unicode strings but is not really prepared to get the Unicode/string mix. > Do you really consider to add the schema processing for unicode > integration in the future? Nope. It's up to the application programmer, especially based on whether LDAPv2 support is still needed for a particular application or not. I consider python-ldap to be rather a low-level API. > Keep in mind, none of my code break compatibility with existing application. Generally I don't want to discourage people to work on something. But sorry, I won't add your code to python-ldap's Lib/. I hope you're not upset. My proposal would be to add it under Demo/ so you're work can be considered to be used by others. Or you can put it on your own web page (for further development) and I'll put a link to it on http://python-ldap.sourceforge.net/docs.shtml. Ciao, Michael. From ahasenack at terra.com.br Thu Jul 19 16:07:20 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Thu, 19 Jul 2007 11:07:20 -0300 Subject: Experiments with pyasn1 and preread control In-Reply-To: <469F4923.1060109@stroeder.com> References: <20070605211241.GF25341@mandriva.com.br> <469F4923.1060109@stroeder.com> Message-ID: <20070719140720.GE5069@mandriva.com.br> On Thu, Jul 19, 2007 at 01:21:07PM +0200, Michael Str?der wrote: > Hello Andreas, > > I've added your demo script to python-ldap's CVS as > Demo/pyasn1/prereadcontrol.py. I'd appreciate if you could implement the > decodeControlValue() method with pyasn1. I think that would be more difficult, there are lots of classes that would need to be created, I guess almost the entire LDAP specification :) I'll try something with openldap's internal functions, but last time I hit a rock because I needed the connection object to do that, and it wasn't available. From michael at stroeder.com Thu Jul 19 17:03:12 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 19 Jul 2007 17:03:12 +0200 Subject: Experiments with pyasn1 and preread control In-Reply-To: <20070719140720.GE5069@mandriva.com.br> References: <20070605211241.GF25341@mandriva.com.br> <469F4923.1060109@stroeder.com> <20070719140720.GE5069@mandriva.com.br> Message-ID: <469F7D30.4060106@stroeder.com> Andreas Hasenack wrote: > On Thu, Jul 19, 2007 at 01:21:07PM +0200, Michael Str?der wrote: >> Hello Andreas, >> >> I've added your demo script to python-ldap's CVS as >> Demo/pyasn1/prereadcontrol.py. I'd appreciate if you could implement the >> decodeControlValue() method with pyasn1. > > I think that would be more difficult, there are lots of classes that > would need to be created, I guess almost the entire LDAP specification > :) Hmm...do you really think so? > I'll try something with openldap's internal functions, but last time I > hit a rock because I needed the connection object to do that, and it > wasn't available. I'd be interested to implement support for the post-read control in web2ldap because if you add/modify entries to OpenLDAP's back-config the DNs may be modified (due to X-ORDERED). Ciao, Michael. From aspineux at gmail.com Fri Jul 20 14:52:34 2007 From: aspineux at gmail.com (Alain Spineux) Date: Fri, 20 Jul 2007 14:52:34 +0200 Subject: unicode value In-Reply-To: <469F6970.5020203@stroeder.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <71fe4e760705240534y4dced9f2t8da849af81c23cef@mail.gmail.com> <46558B61.4010808@stroeder.com> <71fe4e760705240632j78dc4e53o5270ef2f50929ced@mail.gmail.com> <46559A78.9000105@stroeder.com> <71fe4e760705240750r3daa768fhd7256289d1432d81@mail.gmail.com> <4655C3A9.5050803@stroeder.com> <71fe4e760705241216n52bf6848r9fa0e70512f8fbc9@mail.gmail.com> <71fe4e760705290729rd90c462h458d718aa748ab29@mail.gmail.com> <469F6970.5020203@stroeder.com> Message-ID: <71fe4e760707200552w648b6fc8v21770939525c14b9@mail.gmail.com> Hi First I'm not upset by anything. You are responsible to maintain the package in an healthy state. This also your responsibility to add or remove some features and then to maintain them. Thanks for doing that. As you have suggested, I made a class wrapper that keep both code as independent as possible, and I'm happy with that. Anyway I'have some comment about your answerer ... On 7/19/07, Michael Str?der wrote: > Alain, > > Alain Spineux wrote: > > > > When investigating about python and unicode, I read somewhere (in a PEP > > I thing) that python functions should accept and manage unicode string > > as well as normal string. > > Without knowing the PEP (reference?) I guess this affects functions > which takes a string as an argument and process it directly returning a > result. In context of python-ldap this would be directly applicable to > the functions in modules ldap.dn and ldap.filter. Unicode string in python are made in a way that let the developer use them in a complete transparent way. If the libraries are respecting this principle too, the developer can exchange data from different sources (user input, SQL, ldap ...) without never making any conversion. The problem is strings are also used for binary storage and LDAP don't make difference between both usage (no charset and unicode types like in SQL), only the developer know and can make the conversion. > > The basic problem here is that for the sake of backward-compability to > LDAPv2 the charset has to be passed around either. That's what I'm doing > in web2ldap. > > > Of course if these strings could contains user > > readable characters. > > Let's call that "textual strings". > > > Anyway I see 2 solutions > > > > 1. Let result() return non unicode strings. _HERE_ The user know all > > returned > > strings are normal strings utf-8 encoded and he can do the encoding > > himself. A helper function doing the job for the result structure > > should be welcome. > > > > 2. Do the conversion regarding the info provided in the query, as my > > source sample does. > > > > I answer now some of your previous comment: > > > >> > In this case maybe is it possible to use [ '*', u'givenName', u'sn' ] > >> > to convert only 'givenName' and 'sn' > > > >> But then you will not gain much! Still the application has to know which > >> attributes have to be converted. => It's not worth hiding the conversion > >> within python-ldap. > > > > I don't really hide the conversion, because the user has to request it using > > unicode field name. > > I don't like this approach. The type of the attribute names is causing a > type conversion side-effect. I don't consider this to be good design and > I guess most Python developers would not expect something like this. > Think about an application accidently passing in Unicode strings but is > not really prepared to get the Unicode/string mix. Today passing unicode argument to ldap functions raise an exception, then no accidents is possible :-) On the other side, with unicode support, things could accidentally work as expected. But this is only speculation about witch inconvenient is the worst. > > > Do you really consider to add the schema processing for unicode > > integration in the future? > > Nope. It's up to the application programmer, especially based on whether > LDAPv2 support is still needed for a particular application or not. I > consider python-ldap to be rather a low-level API. > > > Keep in mind, none of my code break compatibility with existing application. > > Generally I don't want to discourage people to work on something. But > sorry, I won't add your code to python-ldap's Lib/. I hope you're not > upset. My proposal would be to add it under Demo/ so you're work can be > considered to be used by others. Or you can put it on your own web page > (for further development) and I'll put a link to it on > http://python-ldap.sourceforge.net/docs.shtml. I have no website today :-( Please use the last version in attachment. Regards > > Ciao, Michael. > -- -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- A non-text attachment was scrubbed... Name: unicodeldap.py Type: text/x-python Size: 10591 bytes Desc: not available URL: From ahasenack at terra.com.br Fri Jul 20 16:16:09 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Fri, 20 Jul 2007 11:16:09 -0300 Subject: Experiments with pyasn1 and preread control In-Reply-To: <469F7D30.4060106@stroeder.com> References: <20070605211241.GF25341@mandriva.com.br> <469F4923.1060109@stroeder.com> <20070719140720.GE5069@mandriva.com.br> <469F7D30.4060106@stroeder.com> Message-ID: <20070720141608.GB11254@mandriva.com.br> On Thu, Jul 19, 2007 at 05:03:12PM +0200, Michael Str?der wrote: > Andreas Hasenack wrote: > > On Thu, Jul 19, 2007 at 01:21:07PM +0200, Michael Str?der wrote: > >> Hello Andreas, > >> > >> I've added your demo script to python-ldap's CVS as > >> Demo/pyasn1/prereadcontrol.py. I'd appreciate if you could implement the > >> decodeControlValue() method with pyasn1. > > > > I think that would be more difficult, there are lots of classes that > > would need to be created, I guess almost the entire LDAP specification > > :) > > Hmm...do you really think so? That was my impression when I first tried it. Since the control result is exactly like the ldap search result value, it means it can hold a lot of things. > > I'll try something with openldap's internal functions, but last time I > > hit a rock because I needed the connection object to do that, and it > > wasn't available. > > I'd be interested to implement support for the post-read control in > web2ldap because if you add/modify entries to OpenLDAP's back-config the > DNs may be modified (due to X-ORDERED). Does web2ldap have any special handling of the back-config entries? I find that using a regular ldap client to handle these entries is cumbersome (didn't try web2ldap: only lyma and gq so far). From michael at stroeder.com Fri Jul 20 17:46:48 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 20 Jul 2007 17:46:48 +0200 Subject: Experiments with pyasn1 and preread control In-Reply-To: <20070720141608.GB11254@mandriva.com.br> References: <20070605211241.GF25341@mandriva.com.br> <469F4923.1060109@stroeder.com> <20070719140720.GE5069@mandriva.com.br> <469F7D30.4060106@stroeder.com> <20070720141608.GB11254@mandriva.com.br> Message-ID: <46A0D8E8.4030209@stroeder.com> Andreas Hasenack wrote: > > Does web2ldap have any special handling of the back-config entries? Not up to now. But using the LDIF and HTML templates pre-configured for cn=config name space is quite handy. You can contact me off-list if you need further information on that. You might find some therein: http://www.openldap.org/conf/odd-tuebingen-2006/Michael.pdf The templates are available in the normal source distribution. > I find that using a regular ldap client to handle these entries is > cumbersome (didn't try web2ldap: only lyma and gq so far). In web2ldap the DN handling after add/modify is somewhat strange if the DN is changed by X-ORDERED handling. I presented this at ODD 2006. Kurt et al suggested to use post-read control. Ciao, Michael. From michael.milne at gmail.com Mon Jul 23 15:18:48 2007 From: michael.milne at gmail.com (michael nt milne) Date: Mon, 23 Jul 2007 14:18:48 +0100 Subject: Couldn't install PloneLDAP - ImportError: DLL load failed: The specified module could not be found Message-ID: <134b8b710707230618p19888a4dgeede0a1893badc4@mail.gmail.com> Hi I'm getting the following error with PloneLDAP. Any information appreciated. Windows XP is the current operating system. Plone 3. My python version is 2.4.4 and is installed correctly. I Have verified this using the cmd line methond. I used the packages from http://www.agescibs.org/mauro/ , however the message I get is that 'python 2.4.4 can't be found in the registry'. The version for python 3 says the same thing ( I also have an earlier version of Plone installed) Any help appreciated. The documentation for python - ldap on Windows is a bit fragmented shall we say :-) 2007-07-23T12:48:44 ERROR Application Couldn't install PloneLDAP Traceback (most recent call last): File "C:\Program Files\Plone 3\Zope\lib\python\OFS\Application.py", line 752, in install_product global_dict, global_dict, silly) File "C:\Program Files\Plone 3\Data\Products\PloneLDAP\__init__.py", line 4, in ? from Products.PloneLDAP.plugins.ldap import PloneLDAPMultiPlugin File "C:\Program Files\Plone 3\Data\Products\PloneLDAP\plugins\ldap.py", line 5, in ? from Products.LDAPMultiPlugins.LDAPMultiPlugin import LDAPMultiPlugin File "C:\Program Files\Plone 3\Data\Products\LDAPMultiPlugins\__init__.py", line 16, in ? from LDAPMultiPlugin import LDAPMultiPlugin, \ File "C:\Program Files\Plone 3\Data\Products\LDAPMultiPlugins\LDAPMultiPlugin.py", line 25, in ? from Products.LDAPUserFolder import manage_addLDAPUserFolder File "C:\Program Files\Plone 3\Data\Products\LDAPUserFolder\__init__.py", line 13, in ? from Products.LDAPUserFolder.LDAPUserFolder import LDAPUserFolder File "C:\Program Files\Plone 3\Data\Products\LDAPUserFolder\LDAPUserFolder.py", line 34, in ? from Products.LDAPUserFolder.LDAPDelegate import filter_format File "C:\Program Files\Plone 3\Data\Products\LDAPUserFolder\LDAPDelegate.py", line 12, in ? import ldap File "C:\Program Files\Plone 3\Python\Lib\site-packages\ldap\__init__.py", line 23, in ? try: ImportError: DLL load failed: The specified module could not be found. Thanks -- michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From gohmann at univention.de Tue Jul 24 15:36:07 2007 From: gohmann at univention.de (Stefan Gohmann) Date: Tue, 24 Jul 2007 15:36:07 +0200 Subject: ldap.subschema and multiple SUP Message-ID: <200707241536.08014.gohmann@univention.de> Hello, I've got a problem with ldap.subschema and multiple SUP entries. I'm using python-ldap 2.2.0. My test program: ****************************************** root at backupmonk:~# cat schema-test.py #!/usr/bin/python2.4 import ldap.schema attr={ 'cn': ['Subschema'], 'objectClasses': ["( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization' SUP ( organization $ organizationalUnit ) STRUCTURAL MAY buildingName )"], } subschema = ldap.schema.SubSchema(attr) for oid in subschema.listall(ldap.schema.ObjectClass): print 'OID: %s' % oid obj = subschema.get_obj(ldap.schema.ObjectClass, oid) print 'OBJ: %s' % obj ****************************************** If I call the program I got the following output: root at backupmonk:~# ./schema-test.py OID: 0.9.2342.19200300.100.4.20 OBJ: ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization' SUP ( organization organizationalUnit ) STRUCTURAL MAY buildingName ) I think there should be a "$" beetween "organization" and "organizationalUnit". The attached patch seems to work. Cheers Stefan -- Stefan Gohmann Entwicklung gohmann at univention.de Univention GmbH Linux for your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de -------------- next part -------------- A non-text attachment was scrubbed... Name: 30_separate-sup.patch Type: text/x-diff Size: 755 bytes Desc: not available URL: From michael at stroeder.com Tue Jul 24 16:42:26 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 24 Jul 2007 16:42:26 +0200 Subject: ldap.subschema and multiple SUP In-Reply-To: <200707241536.08014.gohmann@univention.de> References: <200707241536.08014.gohmann@univention.de> Message-ID: <46A60FD2.2020109@stroeder.com> Stefan Gohmann wrote: > > I've got a problem with ldap.subschema and multiple SUP entries. I'm using > python-ldap 2.2.0. Thanks for catching this. Same bug in classes AttributeType and DITStructureRule. Committed a fix, will be in next release 2.3.1. Ciao, Michael. P.S.: Hope you find the time to answer my questions regarding your python-heimdal module... From michael at stroeder.com Fri Jul 20 17:46:48 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 20 Jul 2007 17:46:48 +0200 Subject: Experiments with pyasn1 and preread control In-Reply-To: <20070720141608.GB11254@mandriva.com.br> References: <20070605211241.GF25341@mandriva.com.br> <469F4923.1060109@stroeder.com> <20070719140720.GE5069@mandriva.com.br> <469F7D30.4060106@stroeder.com> <20070720141608.GB11254@mandriva.com.br> Message-ID: <46A0D8E8.4030209@stroeder.com> Andreas Hasenack wrote: > > Does web2ldap have any special handling of the back-config entries? Not up to now. But using the LDIF and HTML templates pre-configured for cn=config name space is quite handy. You can contact me off-list if you need further information on that. You might find some therein: http://www.openldap.org/conf/odd-tuebingen-2006/Michael.pdf The templates are available in the normal source distribution. > I find that using a regular ldap client to handle these entries is > cumbersome (didn't try web2ldap: only lyma and gq so far). In web2ldap the DN handling after add/modify is somewhat strange if the DN is changed by X-ORDERED handling. I presented this at ODD 2006. Kurt et al suggested to use post-read control. Ciao, Michael. From gohmann at univention.de Tue Jul 24 21:19:41 2007 From: gohmann at univention.de (Stefan Gohmann) Date: Tue, 24 Jul 2007 21:19:41 +0200 Subject: ldap.subschema and multiple SUP In-Reply-To: <46A60FD2.2020109@stroeder.com> References: <200707241536.08014.gohmann@univention.de> <46A60FD2.2020109@stroeder.com> Message-ID: <200707242119.42055.gohmann@univention.de> Am Dienstag, 24. Juli 2007 16:42 schrieb Michael Str?der: > Stefan Gohmann wrote: > > I've got a problem with ldap.subschema and multiple SUP entries. I'm > > using python-ldap 2.2.0. > > Thanks for catching this. Same bug in classes AttributeType and > DITStructureRule. Committed a fix, will be in next release 2.3.1. Thanks. > Ciao, Michael. > > P.S.: Hope you find the time to answer my questions regarding your > python-heimdal module... Ups, my vacation was too long. Cheers Stefan -- Stefan Gohmann Entwicklung gohmann at univention.de Univention GmbH Linux for your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de From python-ldap at tk-webart.de Wed Jul 25 16:21:20 2007 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Wed, 25 Jul 2007 16:21:20 +0200 Subject: EGGs for 2.3.1 Message-ID: <46A75C60.3080004@tk-webart.de> Hi folks, I just finished building several eggs, for those who are interested: * Linux i686, Python 2.4, glibc 2.6, OpenLDAP 2.3.37, OpenSSL 0.9.8e, cyrus-SASL 2.1.22 * Mac OSX 10.3/4 PPC/Intel (fat), Python 2.4, OS X 10.4's standard OpenLDAP, OpenSSL, cyrus-SASL * Mac OSX 10.4 PPC, Python 2.3, OS X 10.4's standard OpenLDAP, OpenSSL, cyrus-SASL * Win32, Python 2.4, OpenLDAP 2.2.29, bundled OpenSSL 0.9.8a, w/o SASL All eggs as well as the Win32 prerequisite (OpenLDAP installer) can be downloaded from http://svn.kmrc.de/download/distribution Have fun! Torsten -- Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de Ich schreibe dir einen langen Brief, weil ich keine Zeit habe, einen kurzen zu schreiben. -- Johann Wolfgang von Goethe -- From ahasenack at terra.com.br Fri Aug 3 18:20:50 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Fri, 3 Aug 2007 13:20:50 -0300 Subject: [PATCH] RFC 3876 control (return values filter) In-Reply-To: <469B4D76.2080909@stroeder.com> References: <20070601142745.GA4388@mandriva.com.br> <469B4D76.2080909@stroeder.com> Message-ID: <20070803162049.GE4730@mandriva.com.br> On Mon, Jul 16, 2007 at 12:50:30PM +0200, Michael Str?der wrote: > Andreas Hasenack wrote: > > On Thu, May 31, 2007 at 07:23:36PM -0300, Andreas Hasenack wrote: > >> I will still see about the decode part and then post what I have. > > > > Attached is my current patch. Keep in mind I did this basically using > > the current code as a template. > > I've committed this patch to CVS. I'd appreciate if you could also > provide a small script for Demo/. Sorry for the long wait. I'll get to it this weekend (tm). From ahasenack at terra.com.br Sun Aug 5 20:26:27 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Sun, 5 Aug 2007 15:26:27 -0300 Subject: [PATCH] RFC 3876 control (return values filter) In-Reply-To: <20070803162049.GE4730@mandriva.com.br> References: <20070601142745.GA4388@mandriva.com.br> <469B4D76.2080909@stroeder.com> <20070803162049.GE4730@mandriva.com.br> Message-ID: <200708051526.27534.ahasenack@terra.com.br> On Friday 03 August 2007 13:20:50 Andreas Hasenack wrote: > On Mon, Jul 16, 2007 at 12:50:30PM +0200, Michael Str?der wrote: > > Andreas Hasenack wrote: > > > On Thu, May 31, 2007 at 07:23:36PM -0300, Andreas Hasenack wrote: > > >> I will still see about the decode part and then post what I have. > > > > > > Attached is my current patch. Keep in mind I did this basically using > > > the current code as a template. > > > > I've committed this patch to CVS. I'd appreciate if you could also > > provide a small script for Demo/. > > Sorry for the long wait. I'll get to it this weekend (tm). Attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: matchedvalues.py Type: application/x-python Size: 1900 bytes Desc: not available URL: From michael at stroeder.com Mon Aug 6 12:05:20 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 06 Aug 2007 12:05:20 +0200 Subject: [PATCH] RFC 3876 control (return values filter) In-Reply-To: <200708051526.27534.ahasenack@terra.com.br> References: <20070601142745.GA4388@mandriva.com.br> <469B4D76.2080909@stroeder.com> <20070803162049.GE4730@mandriva.com.br> <200708051526.27534.ahasenack@terra.com.br> Message-ID: <46B6F260.8040100@stroeder.com> Andreas Hasenack wrote: > On Friday 03 August 2007 13:20:50 Andreas Hasenack wrote: >> On Mon, Jul 16, 2007 at 12:50:30PM +0200, Michael Str?der wrote: >>> Andreas Hasenack wrote: >>>> On Thu, May 31, 2007 at 07:23:36PM -0300, Andreas Hasenack wrote: >>>>> I will still see about the decode part and then post what I have. >>>> Attached is my current patch. Keep in mind I did this basically using >>>> the current code as a template. >>> I've committed this patch to CVS. I'd appreciate if you could also >>> provide a small script for Demo/. >> Sorry for the long wait. I'll get to it this weekend (tm). > > Attached. Thanks. Committed. Ciao, Michael. From m.zapke-gruendemann at ewerk.com Tue Aug 7 21:04:45 2007 From: m.zapke-gruendemann at ewerk.com (=?utf-8?B?TWFya3VzIFphcGtlLUdyw7xuZGVtYW5u?=) Date: Tue, 7 Aug 2007 21:04:45 +0200 Subject: Python-LDAP for Win32 & Windows 2003 LDAP Message-ID: <6D31001F0497EC49B7E04EBF6DE7F1A16B709D@SELMA02.intranet.ewerk.com> Hi, I'm using the python-ldap module for Win32 to build an application which is able to find users in an LDAP directory. A few days ago I tried the first time a subtree search starting at the root of an Active Directory on a Windows 2003 Server. Before I did only a search starting at a single CN or OU. When doing this search from the root of the tree I got the following error message. Operations error 00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece Connecting and binding to the server is working flawlessly. Searching subtrees is working as well. I did also a test with the ldp client of the Microsoft Support Tools package[1], just to verify that all privileges are correct. With this client a search with the same filter from the root of the directory is working. I tried Mauro's Python-LDAP 2.0.6 for Win32 and Torsten Kurbad's Win32 egg for 2.3.1. Both are working great until it comes to the root of the Windows 2003 LDAP. Has anyone a hint what the problem could be? Many thanks for your help in advance. With kind regards Markus Zapke-Gr?ndemann [1] http://www.microsoft.com/downloads/details.aspx?familyid=49ae8576-9bb9-4126-9761-ba8011fabf38 From michael at stroeder.com Tue Aug 7 23:14:00 2007 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Tue, 07 Aug 2007 23:14:00 +0200 Subject: Python-LDAP for Win32 & Windows 2003 LDAP In-Reply-To: <6D31001F0497EC49B7E04EBF6DE7F1A16B709D@SELMA02.intranet.ewerk.com> References: <6D31001F0497EC49B7E04EBF6DE7F1A16B709D@SELMA02.intranet.ewerk.com> Message-ID: <46B8E098.6020906@stroeder.com> Markus Zapke-Gr?ndemann wrote: > > A few days ago I tried the first time a subtree search starting at > the root of an Active Directory on a Windows 2003 Server. This returns no results (if authenticated). So there's no point trying that. You should rather read namingContexts or defaultNamingContext from rootDSE (base search) to determine the search root on a particular DC. > Operations error > 00000000: LdapErr: DSID-0C090627, comment: In order to perform this > operation a successful bind must be completed on the connection., > data 0, vece Then you tried to connect anonymously which is prohibited in AD's default configuration. > Connecting and binding to the server is working flawlessly. Searching > subtrees is working as well. If you bind everything which is possible in AD should work. > I did also a test with the ldp client of the Microsoft Support Tools > package[1], just to verify that all privileges are correct. With this > client a search with the same filter from the root of the directory > is working. And what did the client return as results? Maybe ldp.exe is using SASL/GSSAPI bind based on your Windows workstation logon seamless without you taking notice of it. And maybe ldp.exe also looks at defaultNamingContext in the rootDSE... Best thing to find out what a client really does it using Wireshark. Ciao, Michael. From m.zapke-gruendemann at ewerk.com Wed Aug 8 17:13:04 2007 From: m.zapke-gruendemann at ewerk.com (=?utf-8?B?TWFya3VzIFphcGtlLUdyw7xuZGVtYW5u?=) Date: Wed, 8 Aug 2007 17:13:04 +0200 Subject: Python-LDAP for Win32 & Windows 2003 LDAP In-Reply-To: <46B8E098.6020906@stroeder.com> Message-ID: <6D31001F0497EC49B7E04EBF6DE7F1A16B70F4@SELMA02.intranet.ewerk.com> Hallo Michael. > -----Original Message----- > Markus Zapke-Gr?ndemann wrote: > > > > A few days ago I tried the first time a subtree search starting at > > the root of an Active Directory on a Windows 2003 Server. > > This returns no results (if authenticated). So there's no point trying > that. You should rather read namingContexts or > defaultNamingContext from > rootDSE (base search) to determine the search root on a particular DC. This is a good suggestion. I will try it. > > Operations error > > 00000000: LdapErr: DSID-0C090627, comment: In order to perform this > > operation a successful bind must be completed on the connection., > > data 0, vece > > Then you tried to connect anonymously which is prohibited in AD's > default configuration. This is also what I read on this error code. But when I use the same credentials on a diffenrent DN below the root everything works. This makes me wonder. > > I did also a test with the ldp client of the Microsoft Support Tools > > package[1], just to verify that all privileges are correct. > With this > > client a search with the same filter from the root of the directory > > is working. > > And what did the client return as results? It returned the results as I expected it. I did a subtree search with the following filter: (&(!(userAccountControl=514))(&(company=*))(&(|(cn=*e*)(sn=*e*)(givenName=*e*)(mail=*e*)(telephoneNumber=*e*)(otherTelephone=*e*)(facsimileTelephoneNumber=*e*)(mobile=*e*)(memberOf=*e*)(physicalDeliveryOfficeName=*e*)(title=*e*)))(objectClass=person)) > Maybe ldp.exe is using SASL/GSSAPI bind based on your Windows > workstation logon seamless without you taking notice of it. And maybe > ldp.exe also looks at defaultNamingContext in the rootDSE... I connected and bound to the LDAP server manually using ldp.exe. My workstation is in a different domain. So I think there are no other credentials which could be used. > Best thing to find out what a client really does it using Wireshark. This is a good idea. Maybe there is something happening under the hood... Thank you for your hints. With kind regards Markus From michael at stroeder.com Thu Aug 9 00:48:02 2007 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Thu, 09 Aug 2007 00:48:02 +0200 Subject: Python-LDAP for Win32 & Windows 2003 LDAP In-Reply-To: <6D31001F0497EC49B7E04EBF6DE7F1A16B70F4@SELMA02.intranet.ewerk.com> References: <6D31001F0497EC49B7E04EBF6DE7F1A16B70F4@SELMA02.intranet.ewerk.com> Message-ID: <46BA4822.1040903@stroeder.com> Markus Zapke-Gr?ndemann wrote: > Michael Str?der wrote: >> Markus Zapke-Gr?ndemann wrote: >>> Operations error >>> 00000000: LdapErr: DSID-0C090627, comment: In order to perform this >>> operation a successful bind must be completed on the connection., >>> data 0, vece >> Then you tried to connect anonymously which is prohibited in AD's >> default configuration. > This is also what I read on this error code. But when I use the same > credentials on a diffenrent DN below the root everything works. This > makes me wonder. Before I sent the answer I've tested it. It works as expected with web2ldap which is heavily based on python-ldap. So I wonder if you're code is exactly doing what you think it should do. ;-) Maybe a *small* test script would be helpful to find out. Ciao, Michael. From nicolas at nexedi.com Fri Aug 17 18:21:06 2007 From: nicolas at nexedi.com (Nicolas Delaby) Date: Fri, 17 Aug 2007 16:21:06 +0000 Subject: Ldif parser Message-ID: <46C5CAF2.5090309@nexedi.com> Hi all, i've improve ldif parser who can manage delete action now. I think he can be usefull to someone else. thanks -- Nicolas Delaby Nexedi: Consulting and Development of Libre / Open Source Software http://www.nexedi.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ldif.nexedi.patch Type: text/x-patch Size: 3019 bytes Desc: not available URL: From geert at boskant.nl Tue Aug 21 22:55:44 2007 From: geert at boskant.nl (Geert Jansen) Date: Tue, 21 Aug 2007 22:55:44 +0200 Subject: [PATCH] default values Message-ID: <46CB5150.7000601@boskant.nl> Hi, the attached patch allows you to use default values for the functions/arguments below. This is helpful in an environment where /etc/openldap/ldap.conf is kept up to date with correct information. ldap.initialize(uri) LDAPObject.search_*(base, scope) The semantics are identical to the command-line "ldapsearch" tool. This means: - uri <- "HOST" from /etc/openldap.conf - base <- "BASE" from /etc/openldap.conf - scope <- SCOPE_SUBTREE The patch is against the latest CVS and has been tested. Regards, Geert -------------- next part -------------- A non-text attachment was scrubbed... Name: python-ldap-CVS-defaults.patch Type: text/x-patch Size: 7267 bytes Desc: not available URL: From fintan.macmahon at gmail.com Thu Aug 30 11:53:40 2007 From: fintan.macmahon at gmail.com (fintan) Date: Thu, 30 Aug 2007 10:53:40 +0100 Subject: searching ldap by guid/uid Message-ID: <63fd106d0708300253i73ee7ea5tefe84b29452ec9ca@mail.gmail.com> Hi I'm trying to search eDirectory by the guid/uid. My query would look something like this. (&(!(loginDisabled=True))(!(givenname=System))(|(guid=809c175abd1eda11bb4c003005470881))) When I try to decode the guid/uid into hex. I get a type error. ldap_result_id = l.search(searchBase, searchScope, searchFilter, retrieveAttributes) File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 478, in search return self.search_ext (base,scope,filterstr,attrlist,attrsonly,None,None) File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 470, in search_ext timeout,sizelimit, File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 94, in _ldap_call result = func(*args,**kwargs) TypeError: argument 3 must be string without null bytes, not str I was wondering is it possible to search by a hex value? Thanks fintan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu Aug 30 12:15:01 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 30 Aug 2007 12:15:01 +0200 Subject: searching ldap by guid/uid In-Reply-To: <63fd106d0708300253i73ee7ea5tefe84b29452ec9ca@mail.gmail.com> References: <63fd106d0708300253i73ee7ea5tefe84b29452ec9ca@mail.gmail.com> Message-ID: <46D698A5.6030305@stroeder.com> fintan wrote: > > I was wondering is it possible to search by a hex value? Chapter 3 of RFC 4515 (LDAPv3 filter strings) starts with: The string representation of an LDAP search filter is a string of UTF-8 [RFC3629] encoded Unicode characters [Unicode] [..] So please have a look at RFC 4515 to find out how to escape hex values in a search filter. Function ldap.filter.escape_filter_chars() is helpful for that. Ciao, Michael. From ericcf.work at gmail.com Thu Sep 13 23:27:28 2007 From: ericcf.work at gmail.com (Eric Carty-Fickes) Date: Thu, 13 Sep 2007 16:27:28 -0500 Subject: Build Errors (LDAP_OPT_X... undeclared) Message-ID: <7fc4c9060709131427y4e536238g3fac0db80538945f@mail.gmail.com> I am trying to build python-ldap (2.3.1) on a RH Linux box. I installed openldap (2.3.38) from source with the default settings and had no problems. I also have a source install of Python 2.4.4. In setup.cfg I modified these two lines: library_dirs = /usr/local/lib include_dirs = /home/eric/openldap-2.2.13/include /usr/include/sasl When I try to build with "python setup.py build" I get this: In file included from Modules/constants.c:11: /home/eric/openldap-2.2.13/include/ldap.h:210:1: warning: "LDAP_CONTROL_VALUESRETURNFILTER" redefined In file included from Modules/constants.c:9: Modules/constants.h:16:1: warning: this is the location of the previous definition Modules/constants.c: In function `LDAPinit_constants': Modules/constants.c:179: error: `LDAP_OPT_X_TLS_CRLCHECK' undeclared (first use in this function) Modules/constants.c:179: error: (Each undeclared identifier is reported only once Modules/constants.c:179: error: for each function it appears in.) Modules/constants.c:180: error: `LDAP_OPT_X_TLS_CRL_NONE' undeclared (first use in this function) Modules/constants.c:181: error: `LDAP_OPT_X_TLS_CRL_PEER' undeclared (first use in this function) Modules/constants.c:182: error: `LDAP_OPT_X_TLS_CRL_ALL' undeclared (first use in this function) error: command 'gcc' failed with exit status 1 What am I doing incorrectly? I've searched high and low and cannot find much reference to these specific errors. Thanks in advance. Eric From python-ldap at tk-webart.de Fri Sep 14 00:18:43 2007 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Fri, 14 Sep 2007 00:18:43 +0200 Subject: Build Errors (LDAP_OPT_X... undeclared) In-Reply-To: <7fc4c9060709131427y4e536238g3fac0db80538945f@mail.gmail.com> References: <7fc4c9060709131427y4e536238g3fac0db80538945f@mail.gmail.com> Message-ID: <1639247575.20070914001843@tk-webart.de> On Thursday, September 13, 2007 at 23:27 Eric Carty-Fickes wrote: > I am trying to build python-ldap (2.3.1) on a RH Linux box. I > installed openldap (2.3.38) from source with the default settings and ^^^^^^^^ > include_dirs = /home/eric/openldap-2.2.13/include /usr/include/sasl ^^^^^^^^ Why do you try to build with 2.2.13 headers, although you already installed 2.3.38? I had similar problems when building python-ldap on Mac OSX, where openldap 2.2.x is installed by default. Simply "stealing" the 2.3 headers from a Linux system did the trick there. Thus, point include_dirs to the location of your 2.3 headers (presumably /usr/local/include, if you installed from source) and everything should work like a charm. Torsten -- Never make anything simple and efficient when a way can be found to make it complex and wonderful. - Murphy's Law No. 13 - From michael at stroeder.com Fri Sep 14 13:47:40 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 14 Sep 2007 13:47:40 +0200 Subject: Build Errors (LDAP_OPT_X... undeclared) In-Reply-To: <7fc4c9060709131427y4e536238g3fac0db80538945f@mail.gmail.com> References: <7fc4c9060709131427y4e536238g3fac0db80538945f@mail.gmail.com> Message-ID: <46EA74DC.1010001@stroeder.com> Eric Carty-Fickes wrote: > I am trying to build python-ldap (2.3.1) on a RH Linux box. I > installed openldap (2.3.38) from source with the default settings and > had no problems. I also have a source install of Python 2.4.4. > > In setup.cfg I modified these two lines: > library_dirs = /usr/local/lib > include_dirs = /home/eric/openldap-2.2.13/include /usr/include/sasl python-ldap 2.3+ strictly requires OpenLDAP libs 2.3.x. Fix include_dirs in your setup.cfg to reflect this. Ciao, Michael. From michael at stroeder.com Fri Sep 14 13:49:29 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 14 Sep 2007 13:49:29 +0200 Subject: Build Errors (LDAP_OPT_X... undeclared) In-Reply-To: <1639247575.20070914001843@tk-webart.de> References: <7fc4c9060709131427y4e536238g3fac0db80538945f@mail.gmail.com> <1639247575.20070914001843@tk-webart.de> Message-ID: <46EA7549.1000203@stroeder.com> Torsten Kurbad wrote: > > I had similar problems when building python-ldap on Mac OSX, where > openldap 2.2.x is installed by default. Simply "stealing" the 2.3 > headers from a Linux system did the trick there. This workaround is very bad practice. You MUST NOT mix headers and libs from different OpenLDAP versions. This can lead to serious crashs. Please don't ask for support if you're doing something like this. Ciao, Michael. From python-ldap at tk-webart.de Fri Sep 14 13:55:49 2007 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Fri, 14 Sep 2007 13:55:49 +0200 Subject: Build Errors (LDAP_OPT_X... undeclared) In-Reply-To: <46EA7549.1000203@stroeder.com> References: <7fc4c9060709131427y4e536238g3fac0db80538945f@mail.gmail.com> <1639247575.20070914001843@tk-webart.de> <46EA7549.1000203@stroeder.com> Message-ID: <20070914135549.2bfa3828@asteria.iwm-kmrc.de> > > I had similar problems when building python-ldap on Mac OSX, where > > openldap 2.2.x is installed by default. Simply "stealing" the 2.3 > > headers from a Linux system did the trick there. > > This workaround is very bad practice. You MUST NOT mix headers and > libs from different OpenLDAP versions. This can lead to serious > crashs. Please don't ask for support if you're doing something like > this. I won't... This was part of my .egg project - and was merely a test. ;o) But it showed clearly that it's problematic to build python-ldap-2.3.1 with OpenLDAP 2.2.x, which I didn't know beforehand. Anyway, Eric HAS the 2.3.x libs installed and used the 2.2.x headers for no good reason. That's what I wanted to point out... Regards, Torsten -- I am a deeply superficial person. -Andy Warhol From michael at stroeder.com Fri Sep 14 14:03:15 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 14 Sep 2007 14:03:15 +0200 Subject: Build Errors (LDAP_OPT_X... undeclared) In-Reply-To: <20070914135549.2bfa3828@asteria.iwm-kmrc.de> References: <7fc4c9060709131427y4e536238g3fac0db80538945f@mail.gmail.com> <1639247575.20070914001843@tk-webart.de> <46EA7549.1000203@stroeder.com> <20070914135549.2bfa3828@asteria.iwm-kmrc.de> Message-ID: <46EA7883.5050106@stroeder.com> Torsten Kurbad wrote: > > Anyway, Eric HAS the 2.3.x libs installed and used the 2.2.x headers > for no good reason. That's what I wanted to point out... Got your message. But I wanted to make sure that it won't get misunderstood. Ciao, Michael. From michael at stroeder.com Fri Sep 14 14:25:19 2007 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Fri, 14 Sep 2007 14:25:19 +0200 Subject: [PATCH] default values In-Reply-To: <46CB5150.7000601@boskant.nl> References: <46CB5150.7000601@boskant.nl> Message-ID: <46EA7DAF.1010902@stroeder.com> Geert Jansen wrote: > > the attached patch allows you to use default values for the > functions/arguments below. This is helpful in an environment where > /etc/openldap/ldap.conf is kept up to date with correct information. Sorry, I won't accept this patch for general use. Note: This behaviour is not guaranteed to work in future versions of python-ldap. In the future there MAY be a change to another/additional LDAP client lib which does not have a ldap.conf at all. I consider python-ldap to rather provide a low-level API. Applications implemented on top of python-ldap should deal with whatever config file they like passing all required parameters around. Hiding config file access within such a low-level module is IMO bad design. Ciao, Michael. From gohmann at univention.de Thu Sep 20 09:56:34 2007 From: gohmann at univention.de (Stefan Gohmann) Date: Thu, 20 Sep 2007 09:56:34 +0200 Subject: ldap controls Message-ID: <200709200956.34825.gohmann@univention.de> Hello, where could I find some examples or docs for using ldap controls with python-ldap? Thanks. Cheers Stefan -- Stefan Gohmann Entwicklung gohmann at univention.de Univention GmbH Linux for your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de From michael at stroeder.com Thu Sep 20 10:57:56 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 20 Sep 2007 10:57:56 +0200 Subject: ldap controls In-Reply-To: <200709200956.34825.gohmann@univention.de> References: <200709200956.34825.gohmann@univention.de> Message-ID: <46F23614.7020706@stroeder.com> Stefan Gohmann wrote: > > where could I find some examples or docs for using ldap controls with > python-ldap? Which particular controls are you interested in? In the source distribution: Demo/page_control.py Demo/ldapcontrols.py Demo/matchedvalues.py Ciao, Michael. From gohmann at univention.de Thu Sep 20 11:21:08 2007 From: gohmann at univention.de (Stefan Gohmann) Date: Thu, 20 Sep 2007 11:21:08 +0200 Subject: ldap controls In-Reply-To: <46F23614.7020706@stroeder.com> References: <200709200956.34825.gohmann@univention.de> <46F23614.7020706@stroeder.com> Message-ID: <200709201121.08565.gohmann@univention.de> Am Donnerstag, 20. September 2007 10:57 schrieb Michael Str?der: > Stefan Gohmann wrote: > > where could I find some examples or docs for using ldap controls with > > python-ldap? > > Which particular controls are you interested in? I want to search for deleted objects, 1.2.840.113556.1.4.417. > In the source distribution: > > Demo/page_control.py > Demo/ldapcontrols.py > Demo/matchedvalues.py Ah, these files are not in the debian package. Thanks. Cheers, Stefan -- Stefan Gohmann Entwicklung gohmann at univention.de Univention GmbH Linux for your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de From gohmann at univention.de Thu Sep 20 11:49:21 2007 From: gohmann at univention.de (Stefan Gohmann) Date: Thu, 20 Sep 2007 11:49:21 +0200 Subject: ldap controls In-Reply-To: <200709201121.08565.gohmann@univention.de> References: <200709200956.34825.gohmann@univention.de> <46F23614.7020706@stroeder.com> <200709201121.08565.gohmann@univention.de> Message-ID: <200709201149.22467.gohmann@univention.de> Am Donnerstag, 20. September 2007 11:21 schrieb Stefan Gohmann: > Am Donnerstag, 20. September 2007 10:57 schrieb Michael Str?der: > > Stefan Gohmann wrote: > > > where could I find some examples or docs for using ldap controls with > > > python-ldap? > > > > Which particular controls are you interested in? > > I want to search for deleted objects, 1.2.840.113556.1.4.417. > > > In the source distribution: > > > > Demo/page_control.py > > Demo/ldapcontrols.py > > Demo/matchedvalues.py > > Ah, these files are not in the debian package. Thanks. The following code works for me: lc1 = LDAPControl('1.2.840.113556.1.4.417',criticality=1) lo.search_ext_s(base,ldap.SCOPE_SUBTREE,filter,serverctrls=[lc1]) Cheers Stefan -- Stefan Gohmann Entwicklung gohmann at univention.de Univention GmbH Linux for your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de From vela at debian.org Thu Sep 20 12:02:16 2007 From: vela at debian.org (Matej Vela) Date: Thu, 20 Sep 2007 12:02:16 +0200 Subject: ldap controls In-Reply-To: <200709201121.08565.gohmann@univention.de> (Stefan Gohmann's message of "Thu\, 20 Sep 2007 11\:21\:08 +0200") References: <200709200956.34825.gohmann@univention.de> <46F23614.7020706@stroeder.com> <200709201121.08565.gohmann@univention.de> Message-ID: <87r6ktiriv.fsf@slavuj.carpriv.carnet.hr> Stefan Gohmann writes: > Am Donnerstag, 20. September 2007 10:57 schrieb Michael Str?der: >> In the source distribution: >> >> Demo/page_control.py >> Demo/ldapcontrols.py >> Demo/matchedvalues.py > > Ah, these files are not in the debian package. Thanks. Actually, they're in the python-ldap-doc package, in /usr/share/doc/python-ldap-doc/examples/. Cheers, Matej