From michael at stroeder.com Tue Jul 1 11:29:39 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 01 Jul 2003 11:29:39 +0200 Subject: FYI: Linuxtag 2003 Message-ID: <3F015483.4040409@stroeder.com> HI! Anyone who wants to talk to me in person about python-ldap programming or web2ldap is invited to come to the Crypto projects booth at Linuxtag 2003 in Karlsruhe, Germany from 2003-07-10 until 2003-07-13. http://www.linuxtag.de See you there! Ciao, Michael. From toxicpulse at sbcglobal.net Tue Jul 15 19:40:59 2003 From: toxicpulse at sbcglobal.net (ryan) Date: Tue, 15 Jul 2003 10:40:59 -0700 Subject: broken link Message-ID: <000b01c34af8$433fb7e0$36be7643@h5p1n4> the "LDAP Programming in Python" link on python-ldap.sourceforge.net/docs.shtml is and always will be a broken link now that that host is no longer with us. It's permenant home is http://linuxjournal.com/article.php?sid=6988&mode=thread&order=0 From michael at stroeder.com Tue Jul 15 19:53:07 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 15 Jul 2003 19:53:07 +0200 Subject: broken link In-Reply-To: <000b01c34af8$433fb7e0$36be7643@h5p1n4> References: <000b01c34af8$433fb7e0$36be7643@h5p1n4> Message-ID: <3F143F83.4000102@stroeder.com> ryan wrote: > the "LDAP Programming in Python" link on > python-ldap.sourceforge.net/docs.shtml is and always will be a broken link > now that that host is no longer with us. It's permenant home is > http://linuxjournal.com/article.php?sid=6988&mode=thread&order=0 Fixed. Thanks for letting us know. Ciao, Michael. From michael at stroeder.com Fri Jul 18 15:10:44 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 18 Jul 2003 15:10:44 +0200 Subject: Need help for ldif module In-Reply-To: <200307181504.55657.marc.krauth@ac-strasbourg.fr> References: <200307181504.55657.marc.krauth@ac-strasbourg.fr> Message-ID: <3F17F1D4.7070607@stroeder.com> Marc KRAUTH wrote: > I would like to save data from a ldap to a ldif file and I would like to load > data (a restore for instance) from a ldif file to the ldap. > > I've done many tests, but nothing is working. I really nead some help and if > possible simple examples. http://python-ldap.sourceforge.net/doc/python-ldap/ldif-example.html http://python-ldap.sourceforge.net/doc/python-ldap/ldap.async-example.LDIFWriter.html Ciao, Michael. From marc.krauth at ac-strasbourg.fr Fri Jul 18 17:04:55 2003 From: marc.krauth at ac-strasbourg.fr (Marc KRAUTH) Date: Fri, 18 Jul 2003 15:04:55 +0000 Subject: Need help for ldif module Message-ID: <200307181504.55657.marc.krauth@ac-strasbourg.fr> I would like to save data from a ldap to a ldif file and I would like to load data (a restore for instance) from a ldif file to the ldap. I've done many tests, but nothing is working. I really nead some help and if possible simple examples. Marc KRAUTH. From Thieu-Hon.Tran at westfleisch.de Thu Jul 31 09:24:53 2003 From: Thieu-Hon.Tran at westfleisch.de (Thieu-Hon Tran) Date: Thu, 31 Jul 2003 09:24:53 +0200 Subject: python-ldap2.0.0pre11 for Win32 available on zope.org Message-ID: <5.1.1.5.2.20030731092100.0472c118@pop.westfleisch.de> [I'm not subscribed this list. Replies should go to my mail-adress, if you want to reach me.] Hi, I just wanted to tell you about a newer (non-ancient) version of a binary for python-ldap win32 (pre11). It's available here: http://www.zope.org/Members/volkerw/LdapWin32 This link should be included in the FAQs, updating the question regarding a win32-version of python-ldap. Best regards, Thieu-Hon Tran -- * WESTFLEISCH eG * IT Department * * Brockhoffstr. 11 * D-48143 Muenster, Germany * * Phone / Fax: +49 251 493-291 / -311 * From michael at stroeder.com Thu Jul 31 09:49:48 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 31 Jul 2003 09:49:48 +0200 Subject: python-ldap2.0.0pre11 for Win32 available on zope.org In-Reply-To: <5.1.1.5.2.20030731092100.0472c118@pop.westfleisch.de> References: <5.1.1.5.2.20030731092100.0472c118@pop.westfleisch.de> Message-ID: <3F28CA1C.6050203@stroeder.com> Thieu-Hon Tran wrote: > > I just wanted to tell you about a newer (non-ancient) version of a > binary for python-ldap win32 (pre11). It's available here: > http://www.zope.org/Members/volkerw/LdapWin32 Good news! Thanks for letting us know. > This link should be included in the FAQs, updating the question > regarding a win32-version of python-ldap. Updated web pages. Ciao, Michael. From ajthomson at optushome.com.au Mon Aug 4 15:20:19 2003 From: ajthomson at optushome.com.au (Andrew Thomson) Date: Mon, 04 Aug 2003 13:20:19 +0000 Subject: openldap 2.1.22 Message-ID: <1060003219.18182.5.camel@oblivion> i've currently been using py-ldap with openldap 2.0.27 with great success. i was curious if it also works with the newer versions of openldap?? i'm also just using the freebsd ports to install these apps and the current port kind of locks in the older version.. ajt at oblivion:/usr/ports/net/py-ldap2 > pwd /usr/ports/net/py-ldap2 ajt at oblivion:/usr/ports/net/py-ldap2 > grep ldap2 Makefile # $FreeBSD: ports/net/py-ldap2/Makefile,v 1.21 2003/02/24 02:56:35 edwin Exp $ PORTNAME= ldap2 LIB_DEPENDS= ldap.2:${PORTSDIR}/net/openldap20 there is a openldap21 port so I was thinking about just changing the LIB_DEPENDS.. status? thanks, ajt. From michael at stroeder.com Mon Aug 4 16:46:37 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 04 Aug 2003 16:46:37 +0200 Subject: openldap 2.1.22 In-Reply-To: <1060003219.18182.5.camel@oblivion> References: <1060003219.18182.5.camel@oblivion> Message-ID: <3F2E71CD.9050807@stroeder.com> Andrew Thomson wrote: > i've currently been using py-ldap with openldap 2.0.27 with great > success. > > i was curious if it also works with the newer versions of openldap?? I'm using it with 2.1.22. > i'm also just using the freebsd ports to install these apps and the > current port kind of locks in the older version.. No clue about FreeBSD ports. Use the force and compile the source... > there is a openldap21 port You should be able to use that. Ciao, Michael. From bjorn.grotan at itea.ntnu.no Mon Aug 4 18:44:05 2003 From: bjorn.grotan at itea.ntnu.no (=?iso-8859-1?Q?Bj=F8rn_Ove_Gr=F8tan?=) Date: Mon, 4 Aug 2003 18:44:05 +0200 Subject: Performance penalty for using python-ldap In-Reply-To: References: Message-ID: <20030804164405.GA20314@itea.ntnu.no> Ed .: > Hi, > > I was tuning an LDAP directory for a client last week and had cause to run > some before and after benchmarks. > > Basically for a 3000 entry directory I wrote a python script which did the > following: > > listed each entry using the filter (cn=*) using python-ldap and also > invoking the shell to use the ldapsearch command. These were done twice: > running all attributes an just returning the cn attribute > > did 3000 random lookups using (cn=exact-match), and then (cn=exact-match*) > again using python-ldap and the ldapsearch command. > > The searches were run twice on unloaded machines, the first time to > populate caches, the second time as a rough best-performance figure > > The findings were somewhat surprising. > > In the list whole directory search. ldap-search was generally and > consistently at least 30% faster than python-ldap. I.e. these figures apply > before and after tuning the directory. Remember the python searches are > pre-bound while ldapsearch binds each time it is called. > > In the random lookup test, the performance figures were comparable but this > compares calling python-ldap to do a search against spawning a shell, > running ldpasearch, binding then doing the search, i.e. the command line > search has a LOT more overhead. > > I'm happy to run some tests to identify the cause to see if we can fix it, > any suggestions where to start? Just ran through some tests of my own. I have a function that leaps through one ou (ou=users,dc=mydomain,dc=com), finds every entry with objectclass=posixAccount and get the uid of that account using the function search_ext_s The result from the search is asigned a variable named 'res', and then the funcion quits. Execution time from this python-script is aprox. 1m30s. Running the same query with ldapsearch from OpenLDAP-package, the query executes, prints output to console and exits in some 30s or so. Total amount of entries found with that objectClass is aprox. 27k. > General conclusions from my tests: > > python-ldap has a suprising performance penalty > > searching is helped by having ample cache (doh!) I'm using OpenLDAP 2.1.22 with BerkeleyDB 4.1.25 with latest patch. While using BDB as backend, OpenLDAP cannot handle caching - BDB has to. Found a mail on the openldap-software at -mailinglist describing this issue and how to setup caching for BDB. That did not help my ldap-search from withing python, nor with ldapsearch. > returning 1 attribute is much faster than returning all of them (doh!) Here I got help from a fellow worker... Well... when running ldapsearch (from OpenLDAP) and supply the argument '-S uid' for sorting, we got a result in about 40s. When applying the argument -S - it seems like ldapsearch fetches one by one into some kind of datastructure and sort it before viewing. Now, it seems like the python-ldap module does the same thing. Fetching the result - one by one. Like ldapsearch does with -S as argument. Is there any way to force search_ext_s to fetch all at once and not one by one other than changing the source-code to pyton-ldap? -- Regards Bj?rn Ove Gr?tan "Resistance is futile. You will be assimilated." From tesno2 at hotmail.com Mon Aug 4 21:03:13 2003 From: tesno2 at hotmail.com (Jerry Lee) Date: Mon, 04 Aug 2003 19:03:13 +0000 Subject: Win32 Binaries? Message-ID: Hi All, Just got this e-mail from Volker Wend who has built Win32 binaries of python-ldap here http://www.zope.org/Members/volkerw/LdapWin32/python-ldap-2.0.0pre11.win32.zip/view They were built against Python 2.1 and I need something built against 2.2 ------------------ I have the Python2.2 Binaries already working. I just forgot to upload those to zope.org, Since they are now transitioning to a new site. I will wait untill that is finished... Regarding building OpenLdap and Python LDAP: I compiled the OpenLdap Library myself and then python-ldap. Its too long to explain ... ------------------ Thanks Volker! Jerry. From ajthomson at optushome.com.au Wed Aug 6 04:51:39 2003 From: ajthomson at optushome.com.au (Andrew Thomson) Date: 06 Aug 2003 12:51:39 +1000 Subject: pyldap and openldap 2.1.22 Message-ID: <1060138298.41812.1.camel@athomson.prv.au.itouchnet.net> Just carrying on from my previous query.. any suggestions here.. this is when I'm trying to build pyldap. thanks, ajt. EQUEST -DLDAPMODULE_VERSION=2.0.0pre04 -IModules -I/usr/local/include -I/usr/local/include/python2.3 -c Modules/constants.c -o build/temp.freebsd-5.0-RELEASE-p7-i386-2.3/Modules/constants.o Modules/constants.c: In function `LDAPinit_constants': Modules/constants.c:171: `LDAP_FILT_MAXSIZ' undeclared (first use in this function) From michael at stroeder.com Wed Aug 6 08:30:13 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 06 Aug 2003 08:30:13 +0200 Subject: pyldap and openldap 2.1.22 In-Reply-To: <1060138298.41812.1.camel@athomson.prv.au.itouchnet.net> References: <1060138298.41812.1.camel@athomson.prv.au.itouchnet.net> Message-ID: <3F30A075.70408@stroeder.com> Andrew Thomson wrote: > Just carrying on from my previous query.. any suggestions here.. this is > when I'm trying to build pyldap. > > EQUEST -DLDAPMODULE_VERSION=2.0.0pre04 -IModules -I/usr/local/include > -I/usr/local/include/python2.3 -c Modules/constants.c -o > build/temp.freebsd-5.0-RELEASE-p7-i386-2.3/Modules/constants.o > Modules/constants.c: In function `LDAPinit_constants': > Modules/constants.c:171: `LDAP_FILT_MAXSIZ' undeclared (first use in > this function) This does give very much information. Did you edit setup.cfg to point to your OpenLDAP client libs? Ciao, Michael. From michael at stroeder.com Wed Aug 6 09:44:36 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 06 Aug 2003 09:44:36 +0200 Subject: pyldap and openldap 2.1.22 In-Reply-To: <1060153544.41812.6.camel@athomson.prv.au.itouchnet.net> References: <1060138298.41812.1.camel@athomson.prv.au.itouchnet.net> <3F30A075.70408@stroeder.com> <1060153544.41812.6.camel@athomson.prv.au.itouchnet.net> Message-ID: <3F30B1E4.3020704@stroeder.com> Andrew Thomson wrote: > On Wed, 2003-08-06 at 16:30, Michael Str?der wrote: > >>Did you edit setup.cfg to point to your OpenLDAP client libs? > > I admit that i'm still using the freebsd ports to compile this.. Since I have no clue about FreeBSD I can't help. Please ask the maintainer of the FreeBSD port. > the port does go through an updated the setup.cfg with the locations of > the ldap libraries and includes. > > # Section for compiling the C extension module > # for wrapping OpenLDAP 2 libs > > [_ldap] > class = OpenLDAP2 > library_dirs = /usr/local/lib > include_dirs = /usr/local/include > libs = lber ldap Can you find ldap.h in /usr/local/include ? > The port is sitting at py23-ldap2-2.0.0pre04.. I noticed a couple of > newer versions had been released.. 2.0.0pre04 is pretty ancient and I'm rather reluctant giving support for outdated versions. Ciao, Michael. From ajthomson at optushome.com.au Wed Aug 6 09:05:44 2003 From: ajthomson at optushome.com.au (Andrew Thomson) Date: 06 Aug 2003 17:05:44 +1000 Subject: pyldap and openldap 2.1.22 In-Reply-To: <3F30A075.70408@stroeder.com> References: <1060138298.41812.1.camel@athomson.prv.au.itouchnet.net> <3F30A075.70408@stroeder.com> Message-ID: <1060153544.41812.6.camel@athomson.prv.au.itouchnet.net> On Wed, 2003-08-06 at 16:30, Michael Str?der wrote: > Andrew Thomson wrote: > > Just carrying on from my previous query.. any suggestions here.. this is > > when I'm trying to build pyldap. > > > > EQUEST -DLDAPMODULE_VERSION=2.0.0pre04 -IModules -I/usr/local/include > > -I/usr/local/include/python2.3 -c Modules/constants.c -o > > build/temp.freebsd-5.0-RELEASE-p7-i386-2.3/Modules/constants.o > > Modules/constants.c: In function `LDAPinit_constants': > > Modules/constants.c:171: `LDAP_FILT_MAXSIZ' undeclared (first use in > > this function) > > This does give very much information. > > Did you edit setup.cfg to point to your OpenLDAP client libs? > > Ciao, Michael. > I admit that i'm still using the freebsd ports to compile this.. the port does go through an updated the setup.cfg with the locations of the ldap libraries and includes. # Section for compiling the C extension module # for wrapping OpenLDAP 2 libs [_ldap] class = OpenLDAP2 library_dirs = /usr/local/lib include_dirs = /usr/local/include libs = lber ldap # Installation options [install] compile = 1 optimize = 1 The port is sitting at py23-ldap2-2.0.0pre04.. I noticed a couple of newer versions had been released.. thanks for the help, ajt. > > > From ajthomson at optushome.com.au Wed Aug 6 09:55:32 2003 From: ajthomson at optushome.com.au (Andrew Thomson) Date: 06 Aug 2003 17:55:32 +1000 Subject: pyldap and openldap 2.1.22 In-Reply-To: <3F30B1E4.3020704@stroeder.com> References: <1060138298.41812.1.camel@athomson.prv.au.itouchnet.net> <3F30A075.70408@stroeder.com> <1060153544.41812.6.camel@athomson.prv.au.itouchnet.net> <3F30B1E4.3020704@stroeder.com> Message-ID: <1060156532.41812.13.camel@athomson.prv.au.itouchnet.net> Thanks Michael, I'll look at updating the port!! -rw-r--r-- 1 root wheel 39901 Aug 5 13:13 ldap.h athomson# pwd /usr/local/include cheers, ajt. On Wed, 2003-08-06 at 17:44, Michael Str?der wrote: > Andrew Thomson wrote: > > On Wed, 2003-08-06 at 16:30, Michael Str?der wrote: > > > >>Did you edit setup.cfg to point to your OpenLDAP client libs? > > > > I admit that i'm still using the freebsd ports to compile this.. > > Since I have no clue about FreeBSD I can't help. Please ask the maintainer > of the FreeBSD port. > > > the port does go through an updated the setup.cfg with the locations of > > the ldap libraries and includes. > > > > # Section for compiling the C extension module > > # for wrapping OpenLDAP 2 libs > > > > [_ldap] > > class = OpenLDAP2 > > library_dirs = /usr/local/lib > > include_dirs = /usr/local/include > > libs = lber ldap > > Can you find ldap.h in /usr/local/include ? > > > The port is sitting at py23-ldap2-2.0.0pre04.. I noticed a couple of > > newer versions had been released.. > > 2.0.0pre04 is pretty ancient and I'm rather reluctant giving support for > outdated versions. > > Ciao, Michael. > > > > From ajthomson at optushome.com.au Wed Aug 6 11:19:29 2003 From: ajthomson at optushome.com.au (Andrew Thomson) Date: 06 Aug 2003 19:19:29 +1000 Subject: pyldap and openldap 2.1.22 In-Reply-To: <3F30B1E4.3020704@stroeder.com> References: <1060138298.41812.1.camel@athomson.prv.au.itouchnet.net> <3F30A075.70408@stroeder.com> <1060153544.41812.6.camel@athomson.prv.au.itouchnet.net> <3F30B1E4.3020704@stroeder.com> Message-ID: <1060161569.41812.18.camel@athomson.prv.au.itouchnet.net> On Wed, 2003-08-06 at 17:44, Michael Str?der wrote: > Andrew Thomson wrote: > > On Wed, 2003-08-06 at 16:30, Michael Str?der wrote: > > > >>Did you edit setup.cfg to point to your OpenLDAP client libs? > > > > I admit that i'm still using the freebsd ports to compile this.. > > Since I have no clue about FreeBSD I can't help. Please ask the maintainer > of the FreeBSD port. > > > the port does go through an updated the setup.cfg with the locations of > > the ldap libraries and includes. > > > > # Section for compiling the C extension module > > # for wrapping OpenLDAP 2 libs > > > > [_ldap] > > class = OpenLDAP2 > > library_dirs = /usr/local/lib > > include_dirs = /usr/local/include > > libs = lber ldap > > Can you find ldap.h in /usr/local/include ? > > > The port is sitting at py23-ldap2-2.0.0pre04.. I noticed a couple of > > newer versions had been released.. > > 2.0.0pre04 is pretty ancient and I'm rather reluctant giving support for > outdated versions. > thanks again Michael, I hacked up the freebsd port for py-ldap and got it to install with the latest version! pkg_info| grep ldap openldap-2.1.22 Open source LDAP client and server software py23-ldap2-2.0.0pre13 An LDAP module for python, for OpenLDAP2 I'll tell you what, this new version of openldap isn't so carefree with this structual objectclass business.. anyway, thanks for the assistance. ajt. > Ciao, Michael. > > > > From joerg_schuetter at heraeus-infosystems.com Wed Aug 6 15:14:21 2003 From: joerg_schuetter at heraeus-infosystems.com (=?ISO-8859-15?Q?J=F6rg,_Sch=FCtter?=) Date: Wed, 6 Aug 2003 15:14:21 +0200 Subject: filter an boolean value Message-ID: <20030806151421.72d15f34.joerg_schuetter@heraeus-infosystems.com> Hello listmembers I hope this is the right mailing list for my problem. With python-ldap (1.9.999.pre13-1, Debian sid) I try to search for a value in my openldap server. Here is the search filter: '(&(&(objectclass=HeraeusWwwProxy)(uid=%s))(HeraeusItemPaidUp=*))' % (user,) What is the right value to replace the wildcard? I only want to find values where this item is true since HeraeusItemPaidUp is defined as a boolean value. TRUE, true, True, 1 and chr(1) failed. attributetype ( 1.3.6.1.4.1.10817.200.25 NAME 'HeraeusItemPaidUp' DESC 'Item has been paid' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) Regards J?rg -- Dipl.-Ing. J?rg Sch?tter - Email Joerg.Schuetter at heraeus-infosystems.com Systemspezialist Internet, Sicherheit From joerg_schuetter at heraeus-infosystems.com Thu Aug 7 08:43:36 2003 From: joerg_schuetter at heraeus-infosystems.com (=?ISO-8859-15?Q?J=F6rg,_Sch=FCtter?=) Date: Thu, 7 Aug 2003 08:43:36 +0200 Subject: filter an boolean value In-Reply-To: <20030806151421.72d15f34.joerg_schuetter@heraeus-infosystems.com> References: <20030806151421.72d15f34.joerg_schuetter@heraeus-infosystems.com> Message-ID: <20030807084336.1974d203.joerg_schuetter@heraeus-infosystems.com> On Wed, 6 Aug 2003 15:14:21 +0200 "J?rg, Sch?tter" wrote: > Hello listmembers > > attributetype ( 1.3.6.1.4.1.10817.200.25 > NAME 'HeraeusItemPaidUp' > DESC 'Item has been paid' EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 > SINGLE-VALUE ) Ooops, this error has nothing to do with python. I missed the equality line in the shema. Gru? J?rg Sch?tter -- Dipl.-Ing. J?rg Sch?tter - Email Joerg.Schuetter at heraeus-infosystems.com Systemspezialist Internet, Sicherheit From mcicogni at siosistemi.it Wed Aug 13 15:37:01 2003 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Wed, 13 Aug 2003 15:37:01 +0200 Subject: Win32 Binaries? In-Reply-To: References: Message-ID: <3F3A3EFD.1070900@siosistemi.it> Jerry Lee wrote: > Hi All, > > Just got this e-mail from Volker Wend who has built Win32 binaries of > python-ldap here > http://www.zope.org/Members/volkerw/LdapWin32/python-ldap-2.0.0pre11.win32.zip/view > > They were built against Python 2.1 and I need something built against 2.2 > > ------------------ > I have the Python2.2 Binaries already working. I just forgot to upload > those > to zope.org, Since they are now transitioning to a new site. I will wait > untill that is finished... > > Regarding building OpenLdap and Python LDAP: I compiled the OpenLdap > Library > myself and then python-ldap. Its too long to explain ... > ------------------ > Thanks Volker! > > Jerry. Hi everybody, I have finally managed and gathered the time to compile Python LDAP on Win32, too. I pulled the sources from CVS two days ago and compiled against all of the new versions of OpenLDAP (2.1.22) and Python (2.3) (and the very latest cyrus-sasl, for that matter). I did not link OpenSSL in since I'm waiting for feedback from the OpenLDAP developers: just compiling *that* under Windows is a pain, as Volker probably knows... and I'm not sure how to pull the SSL/TLS support in properly. If anyone's interested, I have the binaries available now. I will post them on my homepage (http://www.siosistemi.it/~mcicogni/) today or tomorrow, although they lack a nice installer. This is because for some reason the distutils script does not work anymore with my old setup.cfg which used to work beautifully with Python 2.2. Is there anyone familiar with these topics that can lend me a hand? Thanks in advance, Mauro From michael at stroeder.com Wed Aug 13 20:14:49 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 13 Aug 2003 20:14:49 +0200 Subject: Win32 Binaries? In-Reply-To: <3F3A3EFD.1070900@siosistemi.it> References: <3F3A3EFD.1070900@siosistemi.it> Message-ID: <3F3A8019.7030105@stroeder.com> Mauro Cicognini wrote: > > I have finally managed and gathered the time to compile Python LDAP on > Win32, too. > [..] > This is because for some reason the distutils script does not work > anymore with my old setup.cfg which used to work beautifully with Python > 2.2. > Is there anyone familiar with these topics that can lend me a hand? I'm not really familiar with compiling under Win32 but I'd be interested in finding out the issues with setup.cfg. Can you please post your old setup.cfg and the one the build went fine with? Ciao, Michael. From michael at stroeder.com Thu Aug 14 12:34:48 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 14 Aug 2003 12:34:48 +0200 Subject: Win32 Binaries? In-Reply-To: <3F3B46D2.9090304@siosistemi.it> References: <3F3A3EFD.1070900@siosistemi.it> <3F3A8019.7030105@stroeder.com> <3F3B46D2.9090304@siosistemi.it> Message-ID: <3F3B65C8.50102@stroeder.com> Mauro, thanks for your response. I'm very much interested in getting these issues solved. Mauro Cicognini wrote: > I attach the old setup.cfg from PythonLDAP 2.0.0pre04 that used to work > perfectly. I *had* hacked setup.py a little bit then, to make it simple > to define symbols. BTW, the particular symbol I need is just "WIN32". Can you please post your setup.py hack? > 1. There's no way (AFAIK) to simply "define" a preprocessor symbol > within setup.cfg. The distutils scripts expect to have a list of > one- or two-element tuples, but the parser has no way to pull > those from the .cfg. Besides, the one-element tuple means to > "undefine" the symbol, whereas I'd like to just "define" it > without giving it a value, which is unnecessary. I managed to > insert it using a crude hack within setup.py (just as I had done > with the earlier version), but I do not like this solution. Wouldn't extra_compile_args = -DWIN32 help? I can also modify setup.py to properly build the two-tuple list of defines from a line (see attached diff) defines = WIN32 > 2. The "HAVE_XXX" symbol definition in setup.py is Linux-centric: > since the libraries under Windows have slightly different names > (for instance, "olber32" instead of just "lber"), those symbols > would just not get defined. This however was simple enough to fix. Mainly the HAVE_LIBLDAP_R is of interest. How's the libldap_r called on Windows? Additionally you can try to manually set -DHAVE_LIBLDAP_R etc. in setup.cfg. > 3. It appears that any library path under "library_dirs" for some > reason gets copied over to "runtime_library_dirs", which makes no > sense to me. No clue why David did it. I removed it and it stills builds under Linux. I'd appreciate if others test it on different platforms. > 4. The linker get called without the default libraries, and in such a > way that a whole lot of symbols are found twice, so it just barfs > and never links. Any clue how to solve that? > After these unsuccessful attempts, I had modified setup.py (which could > be OK) Please post your modifications to setup.py. Proposals welcome. > but I had also started changing the default Python library > scripts, and I'm not comfortable with this. This is certainly no option. > So I pulled up the old MSVC > project I used for PythonLDAP 1.x, worked on it for a while and got the > library to compile nicely. My goal is to have a setup.py which is suitable to build python-ldap on any platform with a platform-specific setup.cfg. So let's sort out the issues together. I don't have a Win32 system to test a build therefore your input is highly appreciated. I've attached a unified diff for setup.py. Please test. Ciao, Michael. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: setup-1.51.py.diff URL: From mcicogni at siosistemi.it Thu Aug 14 10:22:42 2003 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Thu, 14 Aug 2003 10:22:42 +0200 Subject: Win32 Binaries? In-Reply-To: <3F3A8019.7030105@stroeder.com> References: <3F3A3EFD.1070900@siosistemi.it> <3F3A8019.7030105@stroeder.com> Message-ID: <3F3B46D2.9090304@siosistemi.it> Michael Str?der wrote: > Can you please post your old setup.cfg and the one the build went fine > with? I attach the old setup.cfg from PythonLDAP 2.0.0pre04 that used to work perfectly. I *had* hacked setup.py a little bit then, to make it simple to define symbols. BTW, the particular symbol I need is just "WIN32". However, I could _not_ get it to build this time; I had to resort to a "canonical" MSVC project, built by hand using the GUI. These are the problems I encountered: 1. There's no way (AFAIK) to simply "define" a preprocessor symbol within setup.cfg. The distutils scripts expect to have a list of one- or two-element tuples, but the parser has no way to pull those from the .cfg. Besides, the one-element tuple means to "undefine" the symbol, whereas I'd like to just "define" it without giving it a value, which is unnecessary. I managed to insert it using a crude hack within setup.py (just as I had done with the earlier version), but I do not like this solution. 2. The "HAVE_XXX" symbol definition in setup.py is Linux-centric: since the libraries under Windows have slightly different names (for instance, "olber32" instead of just "lber"), those symbols would just not get defined. This however was simple enough to fix. 3. It appears that any library path under "library_dirs" for some reason gets copied over to "runtime_library_dirs", which makes no sense to me. This chokes the distutil since the Windows link.exe has no notion of a runtime library directory (they are found exclusively in the PATH), so the build stops with an exception. I am absolutely at a loss to understand the reason of this behavior. I hacked (temporarily) the standard msvccompile.py to work around this just to see what the next problem would be, but this isn't obviously an option. 4. The linker get called without the default libraries, and in such a way that a whole lot of symbols are found twice, so it just barfs and never links. After these unsuccessful attempts, I had modified setup.py (which could be OK) but I had also started changing the default Python library scripts, and I'm not comfortable with this. So I pulled up the old MSVC project I used for PythonLDAP 1.x, worked on it for a while and got the library to compile nicely. That's it; if anyone has any clue, please let me know. BR, Mauro -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: setup.cfg URL: From michael at stroeder.com Thu Aug 14 19:30:46 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 14 Aug 2003 19:30:46 +0200 Subject: Win32 Binaries? In-Reply-To: <3F3B94D0.6000009@siosistemi.it> References: <3F3A3EFD.1070900@siosistemi.it> <3F3A8019.7030105@stroeder.com> <3F3B46D2.9090304@siosistemi.it> <3F3B65C8.50102@stroeder.com> <3F3B94D0.6000009@siosistemi.it> Message-ID: <3F3BC746.4050102@stroeder.com> Mauro Cicognini wrote: > >> I can also modify setup.py to properly build the two-tuple list of >> defines from a line (see attached diff) >> >> defines = WIN32 > > As I said, I would like this. I second your implementation. > [..] >>> 3. It appears that any library path under "library_dirs" for some >>> reason gets copied over to "runtime_library_dirs", which makes no >>> sense to me. >> >> No clue why David did it. I removed it and it stills builds under >> Linux. I'd appreciate if others test it on different platforms. > > I removed it too, and didn't hurt. I'm wondering too. Ok, checked in both changes in setup.py. Ciao, Michael. From mcicogni at siosistemi.it Thu Aug 14 15:55:28 2003 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Thu, 14 Aug 2003 15:55:28 +0200 Subject: Win32 Binaries? In-Reply-To: <3F3B65C8.50102@stroeder.com> References: <3F3A3EFD.1070900@siosistemi.it> <3F3A8019.7030105@stroeder.com> <3F3B46D2.9090304@siosistemi.it> <3F3B65C8.50102@stroeder.com> Message-ID: <3F3B94D0.6000009@siosistemi.it> Michael Str?der wrote: > Mauro, > > thanks for your response. I'm very much interested in getting these > issues solved. > > Mauro Cicognini wrote: > >> I attach the old setup.cfg from PythonLDAP 2.0.0pre04 that used to >> work perfectly. I *had* hacked setup.py a little bit then, to make it >> simple to define symbols. BTW, the particular symbol I need is just >> "WIN32". > > > Can you please post your setup.py hack? Well, it really is functionally identical to the modifications in your diff that do the same thing :-) What I added was: if cfg.has_section('_ldap'): if cfg.has_option('_ldap', 'class'): LDAP_CLASS = eval(cfg.get('_ldap', 'class')) else: LDAP_CLASS = OpenLDAP2 for name in LDAP_CLASS.__dict__.keys(): if cfg.has_option('_ldap', name): setattr(LDAP_CLASS, name, string.split(cfg.get('_ldap', name))) + if cfg.has_option('_ldap', 'defines'): + for defname in string.split(cfg.get('_ldap', 'defines')): + LDAP_CLASS.defines.append((defname, None)) but I like your solution better. > 1. There's no way (AFAIK) to simply "define" a preprocessor symbol > >> within setup.cfg. The distutils scripts expect to have a list of >> one- or two-element tuples, but the parser has no way to pull >> those from the .cfg. Besides, the one-element tuple means to >> "undefine" the symbol, whereas I'd like to just "define" it >> without giving it a value, which is unnecessary. I managed to >> insert it using a crude hack within setup.py (just as I had done >> with the earlier version), but I do not like this solution. > > > Wouldn't > > extra_compile_args = -DWIN32 > > help? As I said, I am not familiar with distutils at all. Yes, it would help, I only wasn't really thinking <:-) > > I can also modify setup.py to properly build the two-tuple list of > defines from a line (see attached diff) > > defines = WIN32 As I said, I would like this. I second your implementation. > >> 2. The "HAVE_XXX" symbol definition in setup.py is Linux-centric: >> since the libraries under Windows have slightly different names >> (for instance, "olber32" instead of just "lber"), those symbols >> would just not get defined. This however was simple enough to fix. > > > Mainly the HAVE_LIBLDAP_R is of interest. How's the libldap_r called > on Windows? Additionally you can try to manually set -DHAVE_LIBLDAP_R > etc. in setup.cfg. The current OpenLDAP version calls it oldap_r.lib. > >> 3. It appears that any library path under "library_dirs" for some >> reason gets copied over to "runtime_library_dirs", which makes no >> sense to me. > > > No clue why David did it. I removed it and it stills builds under > Linux. I'd appreciate if others test it on different platforms. I removed it too, and didn't hurt. I'm wondering too. > >> 4. The linker get called without the default libraries, and in such a >> way that a whole lot of symbols are found twice, so it just barfs >> and never links. > > > Any clue how to solve that? None whatsoever :-( I'll work on this more next week, I'll let you know. > > My goal is to have a setup.py which is suitable to build python-ldap > on any platform with a platform-specific setup.cfg. Me too. I loved the friendly binary installer I got with 2.0.0pre04 :-) > So let's sort out the issues together. I don't have a Win32 system to > test a build therefore your input is highly appreciated. I've attached > a unified diff for setup.py. Please test. I will, more on this next week (tomorrow is a national holiday here ;-). Thanks a lot and keep up the great work. BR, Mauro From jcollier001 at yahoo.com Mon Aug 18 12:39:20 2003 From: jcollier001 at yahoo.com (James Collier) Date: Mon, 18 Aug 2003 03:39:20 -0700 (PDT) Subject: SASL EXTERNAL Authentication Message-ID: <20030818103920.15145.qmail@web41811.mail.yahoo.com> Many thanks to the authors for python-ldap - a very clean and comprehensive wrapping. I'd nevertheless like to request a small extension to offer explicit support of SASL EXTERNAL authentication (i.e. bind authentication with credentials inherited from TLS client certification). As an indication of how clean python-ldap is, I've tested the following trivial snippet and it works perfectly (no callback is needed in this case). If anyone feels it's worthwhile putting this in permanently I'd appreciate it. While it may be trivial, having such explicit support encourages package builders to support SASL/EXTERNAL in turn when they come to build on top of python_ldap. ............... cat >> sasl.py class sasl_external(sasl): """This class handles SASL EXTERNAL (i.e. X.509 client certificate) authentication.""" def __init__(self): sasl.__init__(self, {}, "EXTERNAL") ................ -- James Collier. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From michael at stroeder.com Mon Aug 18 13:40:24 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 18 Aug 2003 13:40:24 +0200 Subject: SASL EXTERNAL Authentication In-Reply-To: <20030818103920.15145.qmail@web41811.mail.yahoo.com> References: <20030818103920.15145.qmail@web41811.mail.yahoo.com> Message-ID: <3F40BB28.2010209@stroeder.com> James Collier wrote: > > cat >> sasl.py > > class sasl_external(sasl): > """This class handles SASL EXTERNAL > (i.e. X.509 client certificate) > authentication.""" > def __init__(self): > sasl.__init__(self, {}, "EXTERNAL") Many thanks for your contribution. I've committed it to CVS but with class name ldap.sasl.external. I've added building a dictionary ldap.sasl.saslmech_handler_class for all the known SASL mechs from class definitions. $ python -c "import ldap.sasl; print ldap.sasl.saslmech_handler_class" {'DIGEST-MD5': , 'EXTERNAL': , 'GSSAPI': } As usual please test. Ciao, Michael. From mcicogni at siosistemi.it Tue Aug 19 17:25:24 2003 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Tue, 19 Aug 2003 17:25:24 +0200 Subject: Win32 Binaries? In-Reply-To: <3F3BC746.4050102@stroeder.com> References: <3F3A3EFD.1070900@siosistemi.it> <3F3A8019.7030105@stroeder.com> <3F3B46D2.9090304@siosistemi.it> <3F3B65C8.50102@stroeder.com> <3F3B94D0.6000009@siosistemi.it> <3F3BC746.4050102@stroeder.com> Message-ID: <3F424164.4030501@siosistemi.it> Hi all, it looks like I do have a setup.cfg that builds correctly under win32. I attach it here. (BTW Michael, how would you let the different setp.cfg versions co-exist? Should we put the Win32 one under the Win32 directory? That particular directory used to host the old build files that I had cobbled together manually to build python-ldap 1.x. In fact I could also provide the new versions of those, for those folks who are more comfortable with the GUI (which does not build the nice graphical installer, though)). I did have to extend setup.py a bit; I attach the unified diff here. In fact, I also think that it's better to put the whole of "ldap" and "ldap.schema" as "packages" (in distutils jargon) rather than inserting every individual file by hand into setup.py as a "module". So I took the liberty of changing that, too, and that is reflected into the diff. Many more lines seem to have changed but it's just an artefact of having reformatted the whole file to use consistently 4-space tabs everywhere. Please forgive me if this conflicts with anyone else's tabbing style. The only feature missing at this time is SSL support; the OpenLDAP guys haven't finished the port for Win32 and there are also "political" tangles so it isn't clear what's going to happen. I do hope they will get their act together sometime in the near future, since they claim that Windows is now one of the "officially supported" platforms. So I hope for interesting developments Very Soon Now. Now, what I have is a nice graphical installer of Python-ldap 2.0.0pre14 for Python 2.3. All one had to do is download it and double-click it. I was amazed at the amount of work the distutils guys have done; it even plugs in nicely with the "uninstall" features of Windows. As an added convenience, I made it install the SASL DLL. LDAP support is linked in statically, which is handier. I have built python-ldap (and everything else) using the new .NET compiler, which is different than the version used to build the Python distribution; however, in my tests everything runs smoothly. I'd love to have someone else test my work, since I have limited testing possibilities. So, please anyone interested let me know and I'll mail you the setup exe. I'd attach it here but I doubt that it would be very interesting for the majority of the readers of this list. BR, Mauro -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: setup.cfg URL: From michael at stroeder.com Wed Aug 20 11:57:00 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 20 Aug 2003 11:57:00 +0200 Subject: Win32 Binaries? In-Reply-To: <3F424164.4030501@siosistemi.it> References: <3F3A3EFD.1070900@siosistemi.it> <3F3A8019.7030105@stroeder.com> <3F3B46D2.9090304@siosistemi.it> <3F3B65C8.50102@stroeder.com> <3F3B94D0.6000009@siosistemi.it> <3F3BC746.4050102@stroeder.com> <3F424164.4030501@siosistemi.it> Message-ID: <3F4345EC.4080306@stroeder.com> Mauro Cicognini wrote: > it looks like I do have a setup.cfg that builds correctly under win32. Thanks for working on it. > (BTW Michael, how would you let the different setp.cfg versions > co-exist? I think Build/ is the right place. > Should we put the Win32 one under the Win32 directory? No. Now that everything seems to work with DistUtils I'd like to abandon this directory completely. > That > particular directory used to host the old build files that I had cobbled > together manually to build python-ldap 1.x. In fact I could also provide > the new versions of those, for those folks who are more comfortable with > the GUI No. We should stick with one way which is DistUtils. > I did have to extend setup.py a bit; I attach the unified diff here. Hmm, can web apply changes one-by-one? I'd really like to see in the diff what was changed. > In fact, I also think that it's better to put the whole of "ldap" and > "ldap.schema" as "packages" (in distutils jargon) rather than inserting > every individual file by hand into setup.py as a "module". I already tried this to avoid DistUtils warning messages. Unfortunately this doesn't work with Python versions prior 2.3. error: build_py: supplying both 'packages' and 'py_modules' options is not allowed > Many > more lines seem to have changed but it's just an artefact of having > reformatted the whole file to use consistently 4-space tabs everywhere. Hmm, I'd like to see every single change... > Now, what I have is a nice graphical installer of Python-ldap 2.0.0pre14 > for Python 2.3. Note that this is the CVS version. There's no release of 2.0.0pre14 yet. > I made it install the SASL DLL. Which version of Cyrus SASL? Is the name 'libsasl' also version dependent like on Linux/Unices (sasl vs. sasl2)? > So, please anyone interested let me know and I'll mail you the setup > exe. Could you please send it to me personally? I will make it available as public download with experimental status. > I'd attach it here but I doubt that it would be very interesting > for the majority of the readers of this list. Glad you didn't... ;-) Ciao, Michael. From mcicogni at siosistemi.it Wed Aug 20 12:56:31 2003 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Wed, 20 Aug 2003 12:56:31 +0200 Subject: Win32 Binaries? In-Reply-To: <3F4345EC.4080306@stroeder.com> References: <3F3A3EFD.1070900@siosistemi.it> <3F3A8019.7030105@stroeder.com> <3F3B46D2.9090304@siosistemi.it> <3F3B65C8.50102@stroeder.com> <3F3B94D0.6000009@siosistemi.it> <3F3BC746.4050102@stroeder.com> <3F424164.4030501@siosistemi.it> <3F4345EC.4080306@stroeder.com> Message-ID: <3F4353DF.4080907@siosistemi.it> Michael Str?der wrote: > >BTW Michael, how would you let the different setp.cfg versions co-exist? > I think Build/ is the right place. Right. I'd create a "Build/win32" dir and put the setup.cfg there. Obviously the main dir should have pointers to let people know they should look into "Build/". > We should stick with one way which is DistUtils. OK. I guess you can zap directory "Win32" from the CVS tree altogether, then. >> I did have to extend setup.py a bit; I attach the unified diff here. > > Hmm, can web apply changes one-by-one? I'd really like to see in the > diff what was changed. Right. I attach a file where I try to let changes stand out more. The changes I had to insert are: 1. I needed extra options for the linker; so I added "extra_link_args" to the class definition and passed it to the constructor. 2. I hijacked the "data files" mechanism in Distutils to carry over the Cyrus-SASL DLL. I added "extra_files" to the class definition and passed it to setup() as the "data_files" param. I also had to add a loop to process that setting in the setup.cfg. 3. I added the library names I got under Win32 for LDAP (oldap_r) and SASL (libsasl) to the macro-definition logic. > ... avoid DistUtils warning messages. Unfortunately this doesn't work > with Python versions prior 2.3. > > error: build_py: supplying both 'packages' and 'py_modules' options is > not allowed Hmmm, this is unfortunate. I wasn't aware of this limitation. I wonder why? If so, let's revert to the old style. However, there's one file missing from the manually-built list (ldap/filter.py). Is this intentional? > Which version of Cyrus SASL? I got it from their CVS a few days ago; so it must be later than 2.1.2 which is the latest source tarball available on their site. I didn't use 2.1.2 because it has serious problems building on Windows, whereas the CVS version builds like a charm out of the box. > Is the name 'libsasl' also version dependent like on Linux/Unices > (sasl vs. sasl2)? It appears not to; in fact, the MSVC project files included with the sources build a DLL called LIBSASL without any indication of the version. > Could you please send it to me personally? I will make it available as > public download with experimental status. Done. You'll get it in a separate message ;-) Mauro -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: From michael at stroeder.com Wed Aug 20 22:27:39 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 20 Aug 2003 22:27:39 +0200 Subject: Win32 Binaries? In-Reply-To: <3F4353DF.4080907@siosistemi.it> References: <3F3A3EFD.1070900@siosistemi.it> <3F3A8019.7030105@stroeder.com> <3F3B46D2.9090304@siosistemi.it> <3F3B65C8.50102@stroeder.com> <3F3B94D0.6000009@siosistemi.it> <3F3BC746.4050102@stroeder.com> <3F424164.4030501@siosistemi.it> <3F4345EC.4080306@stroeder.com> <3F4353DF.4080907@siosistemi.it> Message-ID: <3F43D9BB.7030705@stroeder.com> Mauro Cicognini wrote: > Michael Str?der wrote: > >> >BTW Michael, how would you let the different setp.cfg versions co-exist? >> I think Build/ is the right place. > > Right. I'd create a "Build/win32" dir and put the setup.cfg there. Already checked in Build/setup.cfg.win32 and Build/setup.cfg.suse-linux and added it to MANIFEST.in. > Obviously the main dir should have pointers to let people know they > should look into "Build/". Already added comment to INSTALL. >> We should stick with one way which is DistUtils. > > OK. I guess you can zap directory "Win32" from the CVS tree altogether, > then. Was never in the normal source distribution anyway. >>> I did have to extend setup.py a bit; I attach the unified diff here. >> >> Hmm, can web apply changes one-by-one? I'd really like to see in the >> diff what was changed. > > Right. I attach a file where I try to let changes stand out more. I already checked in your previous diffs. In the end it wasn't that hard to figure out what has changed. But just as advice for next time... > 1. I needed extra options for the linker; so I added "extra_link_args" > to the class definition and passed it to the constructor. > 2. I hijacked the "data files" mechanism in Distutils to carry over the > Cyrus-SASL DLL. I added "extra_files" to the class definition and passed > it to setup() as the "data_files" param. I also had to add a loop to > process that setting in the setup.cfg. > 3. I added the library names I got under Win32 for LDAP (oldap_r) and > SASL (libsasl) to the macro-definition logic. Noted. >> error: build_py: supplying both 'packages' and 'py_modules' options is >> not allowed > > Hmmm, this is unfortunate. I wasn't aware of this limitation. I wonder why? I wonder why, too. :-/ > If so, let's revert to the old style. Already done. > However, there's one file missing > from the manually-built list (ldap/filter.py). Is this intentional? Ouch! Good catch! Fixed. I will now test your Win32 build... Ciao, Michael. From lars at pixar.com Thu Aug 21 22:18:28 2003 From: lars at pixar.com (Lars Damerow) Date: Thu, 21 Aug 2003 13:18:28 -0700 Subject: small fix for cidict.get() Message-ID: <20030821201828.GY24568@pixar.com> Hello! Attached is a patch that makes cidict.get() act more like the regular dictionary get method. failobj shouldn't always need to be specified by the caller. cheers, lars ___________________________________________________________ lars damerow button pusher pixar animation studios lars at pixar.com "I'll have my lunch now; a single pillow of shredded wheat, some steamed toast, and a dodo egg." Montgomery Burns -------------- next part -------------- --- python-ldap-2.0.0pre06/Lib/ldap/cidict.py.org 2003-08-21 13:10:41.000000000 -0700 +++ python-ldap-2.0.0pre06/Lib/ldap/cidict.py 2003-08-21 13:11:03.000000000 -0700 @@ -41,7 +41,7 @@ def has_key(self,key): return UserDict.has_key(self,lower(key)) - def get(self,key,failobj): + def get(self,key,failobj = None): try: return self[key] except KeyError: From michael at stroeder.com Sun Aug 24 18:28:11 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 24 Aug 2003 18:28:11 +0200 Subject: small fix for cidict.get() In-Reply-To: <20030821201828.GY24568@pixar.com> References: <20030821201828.GY24568@pixar.com> Message-ID: <3F48E79B.8090907@stroeder.com> Lars Damerow wrote: > > Attached is a patch that makes cidict.get() act more like the regular > dictionary get method. failobj shouldn't always need to be specified by the > caller. Good catch! Committed to CVS. Ciao, Michael. From mengelhart at katahdinsoftware.com Tue Aug 26 15:52:57 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Tue, 26 Aug 2003 09:52:57 -0400 Subject: modifyTimeStamp code Message-ID: <99105752-D7CC-11D7-B277-000393A48A3C@katahdinsoftware.com> I need to retrieve all records with a filter such as: (modifyTimeStamp>=20030826093828Z) OpenLDAP doesn't support this for some reason or at least it doesn't work correctly (in my test it returns all the entries) I'm wondering if there is any workaround using Python-LDAP to solve this. I saw a post on OpenLDAP lists suggesting negating it like: !(modifyTimeStamp>=20030826093828Z) but this just hung up my app and there are only like 15 entries in my test directory. THanks Mike From michael at stroeder.com Wed Aug 27 17:14:43 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 27 Aug 2003 17:14:43 +0200 Subject: modifyTimeStamp code In-Reply-To: <99105752-D7CC-11D7-B277-000393A48A3C@katahdinsoftware.com> References: <99105752-D7CC-11D7-B277-000393A48A3C@katahdinsoftware.com> Message-ID: <3F4CCAE3.70603@stroeder.com> Michael Engelhart wrote: > I need to retrieve all records with a filter such as: > (modifyTimeStamp>=20030826093828Z) > > OpenLDAP doesn't support this for some reason or at least it doesn't > work correctly (in my test it returns all the entries) Which version of OpenLDAP? This works for me with OpenLDAP server 2.1.22 which has generalizedTimeOrderingMatch implemented. Check subschema subentry for existence of that matching rule. > I'm wondering if there is any workaround using Python-LDAP to solve this. Not for high number of entries. Ciao, Michael. From mcicogni at siosistemi.it Tue Aug 26 12:45:18 2003 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Tue, 26 Aug 2003 12:45:18 +0200 Subject: Enhancement proposal for setup.py Message-ID: <3F4B3A3E.60503@siosistemi.it> Hi all, since we've now got a Build/ directory containing the various setup.cfg files for the different platforms, I thought we could enhance setup.py to simply guess the correct CFG and pull that in directly from Build. We could also make it recognize a debug build and use a debug CFG. This comes in handy for me, at least, since this way I put my different configs into two different files which don't clutter the main dir and I cannot miss settings anymore. Obviously this should be extended to override this and use a particular CFG (esp. when cross-compiling), but I'd say it's a start. Here's the diff: Index: setup.py =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/setup.py,v retrieving revision 1.54 diff -u -w -b -r1.54 setup.py --- setup.py 20 Aug 2003 20:27:10 -0000 1.54 +++ setup.py 26 Aug 2003 10:39:36 -0000 @@ -38,9 +38,17 @@ LDAP_CLASS = OpenLDAP2 +# pull the right CFG in +if '--debug' in sys.argv: + debug = 'debug' +else: + debug = 'release' +setup_cfg = 'Build/%s-%s.setup.cfg' % (sys.platform, debug) +print "Using " + setup_cfg + #-- Read the [_ldap] section of setup.cfg cfg = ConfigParser() -cfg.read('setup.cfg') +cfg.read(setup_cfg) if cfg.has_section('_ldap'): for name in dir(LDAP_CLASS): if cfg.has_option('_ldap', name): How's the idea? Mauro From michael at stroeder.com Fri Sep 5 00:47:40 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 05 Sep 2003 00:47:40 +0200 Subject: Enhancement proposal for setup.py In-Reply-To: <3F4B3A3E.60503@siosistemi.it> References: <3F4B3A3E.60503@siosistemi.it> Message-ID: <3F57C10C.8020902@stroeder.com> Mauro Cicognini wrote: > since we've now got a Build/ directory containing the various setup.cfg > files for the different platforms, I thought we could enhance setup.py > to simply guess the correct CFG and pull that in directly from Build. We > could also make it recognize a debug build and use a debug CFG. We could set the defaults for the LDAP_CLASS instance according to the platform. Anyway. Unless this works really perfect for *all* platforms I'm rather reluctant to do something automagically. Ciao, Michael. From kirbysdl at hotmail.com Thu Sep 18 04:06:11 2003 From: kirbysdl at hotmail.com (Curby .) Date: Thu, 18 Sep 2003 02:06:11 +0000 Subject: persisting ldap_first_reference problems Message-ID: Hi, I'm experiencing the ldap_first_reference problem that others have alluded to before. The specific error message is as follows: ----- BEGIN ERROR ----- >>>import ldap Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/site-packages/ldap/__init__.py", line 21, in ? from _ldap import * ImportError: /usr/local/lib/python2.3/site-packages/_ldap.so: undefined symbol: ldap_first_reference ----- END ERROR ----- I am installing python-ldap 2.0.0 pre13 on python2.3 and openldap 2.1.22. all three are being installed manually (without the use of rpms). Things I have tried (that others have suggested) include: adding references.c and references.lo to openldap-2.1.22/libraries/libldap_r/Makefile.in and modifying python-ldap-2.0.0pre13/setup.cfg to try all of: libs = ldap_r lber libs = ldap lber libs = ldap_r ldap lber Unfortunately, nothing is working at the moment. My OS is Redhat 9, generally well-patched. Any help would be most appreciated. Thank you! From michael at stroeder.com Thu Sep 18 13:57:19 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 18 Sep 2003 13:57:19 +0200 Subject: persisting ldap_first_reference problems In-Reply-To: References: Message-ID: <3F699D9F.1000502@stroeder.com> Curby . wrote: > ImportError: /usr/local/lib/python2.3/site-packages/_ldap.so: undefined > symbol: ldap_first_reference Where are your OpenLDAP libs installed? You might have to adjust /etc/ld.so.conf or set LD_LIBRARY_PATH to match the value of library_dirs set in python-ldap's setup.cfg. Also make sure you don't have a mix of OpenLDAP libs installed by RPM and your local installation. Ciao, Michael. From mcicogni at siosistemi.it Fri Sep 19 10:08:35 2003 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Fri, 19 Sep 2003 10:08:35 +0200 Subject: <--- SPAM ---> persisting ldap_first_reference problems In-Reply-To: References: Message-ID: <3F6AB983.7020401@siosistemi.it> Curby . wrote: > ImportError: /usr/local/lib/python2.3/site-packages/_ldap.so: > undefined symbol: ldap_first_reference This is typically caused by an OpenLDAP library version mismatch (ldap_first_reference is a relatively recent addition to the API). AFAIK, recent PythonLDAP compile against OpenLDAP 2.1.x, not 2.0.x, so you might want to check you don't have old versions sitting around. Mauro -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2855 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Tue Sep 23 19:43:10 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 23 Sep 2003 19:43:10 +0200 Subject: python-ldap port to OpenBSD In-Reply-To: <20030923140051.6a073d1b.marc@msys.ch> References: <20030923140051.6a073d1b.marc@msys.ch> Message-ID: <3F70862E.2060006@stroeder.com> Marc Balmer wrote: > > FYI: python-ldap has been ported to the OpenBSD operating system (as > port py-ldap). The port is available for download at > http://www.etc.msys.ch/ports/. Thanks for letting us know. > You may want to take not of this on the python-ldap website. /bin/done Ciao, Michael. From marc at msys.ch Tue Sep 23 14:00:51 2003 From: marc at msys.ch (Marc Balmer) Date: Tue, 23 Sep 2003 14:00:51 +0200 Subject: python-ldap port to OpenBSD Message-ID: <20030923140051.6a073d1b.marc@msys.ch> Hello! FYI: python-ldap has been ported to the OpenBSD operating system (as port py-ldap). The port is available for download at http://www.etc.msys.ch/ports/. You may want to take not of this on the python-ldap website. Regards, Marc Balmer From patrick.gelin at rpn.ch Thu Sep 25 13:37:07 2003 From: patrick.gelin at rpn.ch (Patrick Gelin) Date: 25 Sep 2003 13:37:07 +0200 Subject: How to install LDAP for python2.1.3 or python2.2 under redhat 9.0.. Message-ID: <1064489827.6996.9.camel@rheisxa001.rpn.ch> Hi, I'm trying to use LDAPUserFolder with Zope 2.6.1 and python2.1.3 under RedHat 9.0. (By the way, RedHat 9.0 installed python2.2 too) I installed python-ldap-2.0.Opre13.tar.gz. The result go through /usr/lib/python2.2/site-packages/ld* files and sub directory ldap... I copied /usr/lib/python2.2/site-packages/ld* files and subdirectory ldap to /zope/lib/python2.1/site-packages. (Is it really necessary?) Now if I go to /zope/bin/python and type import _ldap I've got an error message which is: importError /usr/lib/python2.2/site-packages/_ldap.so: undefined symbol:ldap_first_reference I believed /zope/bin/python use /zope/lib/python2.1 but its seems wrong!!! Now I think I have to install an openldap package to resolve ldap_first_reference. I try to instal some RPM: openldap-servers 2.0.27-8 openldap-devel 2.0.27-8 openldap 2.0.27-8 openldap-clients 2.0.27-8 I don't reinstall python-ldap after may be it's a mistake but nothing change... I looked for an advice on the Internet and I saw it's recommended to compile openldap and not use REDHAT 9.0 RPM package... So, I tried to do it with (openldap-2-1-22) but I get the error message below: [root at rheisxa001 openldap-2.1.22]# ./configure Copyright 1998-2003 The OpenLDAP Foundation, All Rights Reserved. Restrictions apply, see COPYRIGHT and LICENSE files. Configuring OpenLDAP 2.1.22-Release ... checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking for a BSD compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for mawk... no checking for gawk... gawk checking whether make sets ${MAKE}... yes checking for working aclocal... found checking for working autoconf... found checking for working automake... found checking for working autoheader... found checking for working makeinfo... found checking for gnutar... no checking for gtar... gtar checking configure arguments... done checking for a BSD compatible install... /usr/bin/install -c checking for cc... cc checking for ar... ar checking for Cygwin environment... no checking for mingw32 environment... no checking for EMX OS/2 environment... no checking how to run the C preprocessor... cc -E checking for gcc... (cached) cc checking whether the C compiler (cc ) works... yes checking whether the C compiler (cc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether cc accepts -g... yes checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking for a sed that does not truncate output... /bin/sed checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... no checking command to parse /usr/bin/nm -B output... ok checking for dlfcn.h... yes checking for ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc static flag -static works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc supports -fno-rtti -fno-exceptions... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... no checking for dlopen in -ldl... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... no checking whether -lc should be explicitly linked in... no creating libtool checking whether ln works... yes checking whether ln -s works... (cached) yes checking how to run the C preprocessor... cc -E checking for Cygwin environment... (cached) no checking for mingw32 environment... (cached) no checking for executable suffix... (cached) no checking for object suffix... (cached) o checking for be_app in -lbe... no checking for cc option to accept ANSI C... none needed checking for cc depend flag... -M checking for afopen in -ls... no checking for EBCDIC... no checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for sys/wait.h that is POSIX.1 compatible... yes checking POSIX termios... yes checking whether use of TIOCGWINSZ requires sys/ioctl.h... yes checking for arpa/inet.h... yes checking for arpa/nameser.h... yes checking for assert.h... yes checking for conio.h... no checking for crypt.h... yes checking for direct.h... no checking for errno.h... yes checking for fcntl.h... yes checking for filio.h... no checking for getopt.h... yes checking for grp.h... yes checking for io.h... no checking for libutil.h... no checking for limits.h... yes checking for locale.h... yes checking for netinet/tcp.h... yes checking for malloc.h... yes checking for memory.h... yes checking for psap.h... no checking for pwd.h... yes checking for process.h... no checking for resolv.h... yes checking for sgtty.h... yes checking for shadow.h... yes checking for stddef.h... yes checking for string.h... yes checking for strings.h... yes checking for sysexits.h... yes checking for sys/file.h... yes checking for sys/filio.h... no checking for sys/errno.h... yes checking for sys/ioctl.h... yes checking for sys/param.h... yes checking for sys/resource.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/stat.h... yes checking for sys/syslog.h... yes checking for sys/time.h... yes checking for sys/types.h... yes checking for sys/ucred.h... no checking for sys/uio.h... yes checking for syslog.h... yes checking for termios.h... yes checking for unistd.h... yes checking for winsock.h... no checking for winsock2.h... no checking for dlopen... (cached) no checking for dlopen in -ldl... (cached) yes checking for sigset in -lV3... no checking for winsock... no checking for socket... yes checking for select... yes checking types of arguments for select()... int,fd_set *,struct timeval * checking for regex.h... yes checking for library containing regfree... none required checking for compatible POSIX regex... yes checking for sys/uuid.h... no checking to see if -lrpcrt4 is needed for win32 UUID support... no checking for res_query... no checking for __res_query... no checking for res_query in -lbind... no checking for __res_query in -lbind... no checking for res_query in -lresolv... yes checking for getaddrinfo... yes checking for getnameinfo... yes checking for gai_strerror... yes checking for inet_ntop... yes checking INET6_ADDRSTRLEN... yes checking struct sockaddr_storage... yes checking for sys/un.h... yes checking for openssl/ssl.h... no checking for ssl.h... no configure: warning: Could not locate TLS/SSL package configure: warning: TLS data protection not supported! checking for _beginthread... no checking for pthread.h... yes checking POSIX thread version... 10 checking for LinuxThreads pthread.h... yes checking for GNU Pth pthread.h... no checking for sched.h... yes checking for pthread_create in default libraries... no checking for pthread link with -kthread... no checking for pthread link with -pthread... yes checking for sched_yield... yes checking for pthread_yield... yes checking for thr_yield... no checking for pthread_kill... yes checking for pthread_rwlock_destroy... yes checking for pthread_detach with ... yes checking for pthread_setconcurrency... yes checking for pthread_getconcurrency... yes checking for thr_setconcurrency... no checking for thr_getconcurrency... no checking for pthread_kill_other_threads_np... yes checking for LinuxThreads implementation... yes checking for LinuxThreads consistency... yes checking if pthread_create() works... yes checking if select yields when using pthreads... yes checking for thread specific errno... yes checking for thread specific h_errno... yes checking for ctime_r... yes checking for gethostbyname_r... yes checking for gethostbyaddr_r... yes checking number of arguments of ctime_r... 2 checking number of arguments of gethostbyname_r... 6 checking number of arguments of gethostbyaddr_r... 8 checking for db.h... yes checking for Berkeley DB link (default)... no checking for Berkeley DB link (-ldb41)... no checking for Berkeley DB link (-ldb-41)... no checking for Berkeley DB link (-ldb-4.1)... no checking for Berkeley DB link (-ldb-4-1)... no checking for Berkeley DB link (-ldb-4)... no checking for Berkeley DB link (-ldb4)... no checking for Berkeley DB link (-ldb)... yes checking for Berkeley DB thread support... yes checking Berkeley DB version for BDB backend... no configure: error: BDB: BerkeleyDB version incompatible Is there anybody to help me? Thanks. Patrick Gelin From jlittle at open-it.org Thu Sep 25 18:35:47 2003 From: jlittle at open-it.org (Joe Little) Date: Thu, 25 Sep 2003 09:35:47 -0700 Subject: How to install LDAP for python2.1.3 or python2.2 under redhat 9.0.. In-Reply-To: <1064489827.6996.9.camel@rheisxa001.rpn.ch> Message-ID: <5147F2E9-EF76-11D7-903C-0003931A4574@open-it.org> I provide OpenLDAP 2.1.2x and python-ldap packages on ftp.open-it.org. The OpenLDAP packages are for RedHat9. On Thursday, September 25, 2003, at 04:37 AM, Patrick Gelin wrote: > Hi, > > I'm trying to use LDAPUserFolder with Zope 2.6.1 and python2.1.3 under > RedHat 9.0. (By the way, RedHat 9.0 installed python2.2 too) > > I installed python-ldap-2.0.Opre13.tar.gz. The result go through > /usr/lib/python2.2/site-packages/ld* files and sub directory ldap... > > I copied /usr/lib/python2.2/site-packages/ld* files and subdirectory > ldap to /zope/lib/python2.1/site-packages. (Is it really necessary?) > > Now if I go to /zope/bin/python and type import _ldap I've got an error > message which is: > > importError /usr/lib/python2.2/site-packages/_ldap.so: undefined > symbol:ldap_first_reference > > I believed /zope/bin/python use /zope/lib/python2.1 but its seems > wrong!!! > > Now I think I have to install an openldap package to resolve > ldap_first_reference. I try to instal some RPM: > > openldap-servers 2.0.27-8 > openldap-devel 2.0.27-8 > openldap 2.0.27-8 > openldap-clients 2.0.27-8 > > I don't reinstall python-ldap after may be it's a mistake but nothing > change... > > I looked for an advice on the Internet and I saw it's recommended to > compile openldap and not use REDHAT 9.0 RPM package... So, I tried to > do > it with (openldap-2-1-22) but I get the error message below: > > [root at rheisxa001 openldap-2.1.22]# ./configure > Copyright 1998-2003 The OpenLDAP Foundation, All Rights Reserved. > Restrictions apply, see COPYRIGHT and LICENSE files. > Configuring OpenLDAP 2.1.22-Release ... > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > checking build system type... i686-pc-linux-gnu > checking for a BSD compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for mawk... no > checking for gawk... gawk > checking whether make sets ${MAKE}... yes > checking for working aclocal... found > checking for working autoconf... found > checking for working automake... found > checking for working autoheader... found > checking for working makeinfo... found > checking for gnutar... no > checking for gtar... gtar > checking configure arguments... done > checking for a BSD compatible install... /usr/bin/install -c > checking for cc... cc > checking for ar... ar > checking for Cygwin environment... no > checking for mingw32 environment... no > checking for EMX OS/2 environment... no > checking how to run the C preprocessor... cc -E > checking for gcc... (cached) cc > checking whether the C compiler (cc ) works... yes > checking whether the C compiler (cc ) is a cross-compiler... no > checking whether we are using GNU C... yes > checking whether cc accepts -g... yes > checking for ld used by GCC... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for /usr/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/bin/nm -B > checking for a sed that does not truncate output... /bin/sed > checking whether ln -s works... yes > checking how to recognise dependent libraries... pass_all > checking for object suffix... o > checking for executable suffix... no > checking command to parse /usr/bin/nm -B output... ok > checking for dlfcn.h... yes > checking for ranlib... ranlib > checking for strip... strip > checking for objdir... .libs > checking for cc option to produce PIC... -fPIC > checking if cc PIC flag -fPIC works... yes > checking if cc static flag -static works... yes > checking if cc supports -c -o file.o... yes > checking if cc supports -c -o file.lo... yes > checking if cc supports -fno-rtti -fno-exceptions... yes > checking whether the linker (/usr/bin/ld) supports shared libraries... > yes > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking dynamic linker characteristics... GNU/Linux ld.so > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... yes > checking for shl_load... no > checking for shl_load in -ldld... no > checking for dlopen... no > checking for dlopen in -ldl... yes > checking whether a program can dlopen itself... yes > checking whether a statically linked program can dlopen itself... no > checking whether -lc should be explicitly linked in... no > creating libtool > checking whether ln works... yes > checking whether ln -s works... (cached) yes > checking how to run the C preprocessor... cc -E > checking for Cygwin environment... (cached) no > checking for mingw32 environment... (cached) no > checking for executable suffix... (cached) no > checking for object suffix... (cached) o > checking for be_app in -lbe... no > checking for cc option to accept ANSI C... none needed > checking for cc depend flag... -M > checking for afopen in -ls... no > checking for EBCDIC... no > checking for ANSI C header files... yes > checking for dirent.h that defines DIR... yes > checking for opendir in -ldir... no > checking for sys/wait.h that is POSIX.1 compatible... yes > checking POSIX termios... yes > checking whether use of TIOCGWINSZ requires sys/ioctl.h... yes > checking for arpa/inet.h... yes > checking for arpa/nameser.h... yes > checking for assert.h... yes > checking for conio.h... no > checking for crypt.h... yes > checking for direct.h... no > checking for errno.h... yes > checking for fcntl.h... yes > checking for filio.h... no > checking for getopt.h... yes > checking for grp.h... yes > checking for io.h... no > checking for libutil.h... no > checking for limits.h... yes > checking for locale.h... yes > checking for netinet/tcp.h... yes > checking for malloc.h... yes > checking for memory.h... yes > checking for psap.h... no > checking for pwd.h... yes > checking for process.h... no > checking for resolv.h... yes > checking for sgtty.h... yes > checking for shadow.h... yes > checking for stddef.h... yes > checking for string.h... yes > checking for strings.h... yes > checking for sysexits.h... yes > checking for sys/file.h... yes > checking for sys/filio.h... no > checking for sys/errno.h... yes > checking for sys/ioctl.h... yes > checking for sys/param.h... yes > checking for sys/resource.h... yes > checking for sys/select.h... yes > checking for sys/socket.h... yes > checking for sys/stat.h... yes > checking for sys/syslog.h... yes > checking for sys/time.h... yes > checking for sys/types.h... yes > checking for sys/ucred.h... no > checking for sys/uio.h... yes > checking for syslog.h... yes > checking for termios.h... yes > checking for unistd.h... yes > checking for winsock.h... no > checking for winsock2.h... no > checking for dlopen... (cached) no > checking for dlopen in -ldl... (cached) yes > checking for sigset in -lV3... no > checking for winsock... no > checking for socket... yes > checking for select... yes > checking types of arguments for select()... int,fd_set *,struct timeval > * > checking for regex.h... yes > checking for library containing regfree... none required > checking for compatible POSIX regex... yes > checking for sys/uuid.h... no > checking to see if -lrpcrt4 is needed for win32 UUID support... no > checking for res_query... no > checking for __res_query... no > checking for res_query in -lbind... no > checking for __res_query in -lbind... no > checking for res_query in -lresolv... yes > checking for getaddrinfo... yes > checking for getnameinfo... yes > checking for gai_strerror... yes > checking for inet_ntop... yes > checking INET6_ADDRSTRLEN... yes > checking struct sockaddr_storage... yes > checking for sys/un.h... yes > checking for openssl/ssl.h... no > checking for ssl.h... no > configure: warning: Could not locate TLS/SSL package > configure: warning: TLS data protection not supported! > checking for _beginthread... no > checking for pthread.h... yes > checking POSIX thread version... 10 > checking for LinuxThreads pthread.h... yes > checking for GNU Pth pthread.h... no > checking for sched.h... yes > checking for pthread_create in default libraries... no > checking for pthread link with -kthread... no > checking for pthread link with -pthread... yes > checking for sched_yield... yes > checking for pthread_yield... yes > checking for thr_yield... no > checking for pthread_kill... yes > checking for pthread_rwlock_destroy... yes > checking for pthread_detach with ... yes > checking for pthread_setconcurrency... yes > checking for pthread_getconcurrency... yes > checking for thr_setconcurrency... no > checking for thr_getconcurrency... no > checking for pthread_kill_other_threads_np... yes > checking for LinuxThreads implementation... yes > checking for LinuxThreads consistency... yes > checking if pthread_create() works... yes > checking if select yields when using pthreads... yes > checking for thread specific errno... yes > checking for thread specific h_errno... yes > checking for ctime_r... yes > checking for gethostbyname_r... yes > checking for gethostbyaddr_r... yes > checking number of arguments of ctime_r... 2 > checking number of arguments of gethostbyname_r... 6 > checking number of arguments of gethostbyaddr_r... 8 > checking for db.h... yes > checking for Berkeley DB link (default)... no > checking for Berkeley DB link (-ldb41)... no > checking for Berkeley DB link (-ldb-41)... no > checking for Berkeley DB link (-ldb-4.1)... no > checking for Berkeley DB link (-ldb-4-1)... no > checking for Berkeley DB link (-ldb-4)... no > checking for Berkeley DB link (-ldb4)... no > checking for Berkeley DB link (-ldb)... yes > checking for Berkeley DB thread support... yes > checking Berkeley DB version for BDB backend... no > configure: error: BDB: BerkeleyDB version incompatible > > > Is there anybody to help me? > > Thanks. > > Patrick Gelin > > > > From michael at stroeder.com Fri Sep 26 13:05:03 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 26 Sep 2003 13:05:03 +0200 Subject: How to build python-ldap correctly... In-Reply-To: <1064568773.10489.9.camel@rheisxa001.rpn.ch> References: <1064568773.10489.9.camel@rheisxa001.rpn.ch> Message-ID: <3F741D5F.6080303@stroeder.com> Patrick Gelin wrote: > > My configuration is RedHat 9.0 with python 2.2 and Zope 2.6.1 with > python 2.1.3. > > My file system is like this: > > /usr/lib/python2.2 > /zope/lib/python2.1 > > (I installed too python 2.1 here /usr/local/lib/python2.1) > > How to do if I want to install python-ldap for python 2.6.1 under Zope ? > Where are include and lib directories I have to config in setup.cfg ? > > Is there a global variable to positioning ? (I want to keep alive > python2.2 because there is a lot of redhat stuff using it...) You have to invoke setup.py with exactly the Python interpreter binary Zope is using. E.g. if your system's Python is installed in /usr/bin/python and the Python 2.1.3 for Zope is in /zope/bin/python you have to invoke $ /zope/bin/python setup.py build # /zope/bin/python setup.py install Ciao, Michael. From patrick.gelin at rpn.ch Fri Sep 26 11:32:53 2003 From: patrick.gelin at rpn.ch (Patrick Gelin) Date: 26 Sep 2003 11:32:53 +0200 Subject: How to build python-ldap correctly... Message-ID: <1064568773.10489.9.camel@rheisxa001.rpn.ch> Hi, My configuration is RedHat 9.0 with python 2.2 and Zope 2.6.1 with python 2.1.3. My file system is like this: /usr/lib/python2.2 /zope/lib/python2.1 (I installed too python 2.1 here /usr/local/lib/python2.1) How to do if I want to install python-ldap for python 2.6.1 under Zope ? Where are include and lib directories I have to config in setup.cfg ? Is there a global variable to positioning ? (I want to keep alive python2.2 because there is a lot of redhat stuff using it...) Thanks. From patrick.gelin at rpn.ch Fri Sep 26 13:17:51 2003 From: patrick.gelin at rpn.ch (Patrick Gelin) Date: 26 Sep 2003 13:17:51 +0200 Subject: How to build python-ldap correctly... In-Reply-To: <3F741D5F.6080303@stroeder.com> References: <1064568773.10489.9.camel@rheisxa001.rpn.ch> <3F741D5F.6080303@stroeder.com> Message-ID: <1064575071.10489.13.camel@rheisxa001.rpn.ch> On Fri, 2003-09-26 at 13:05, Michael Str?der wrote: > Patrick Gelin wrote: > > > > My configuration is RedHat 9.0 with python 2.2 and Zope 2.6.1 with > > python 2.1.3. > > > > My file system is like this: > > > > /usr/lib/python2.2 > > /zope/lib/python2.1 > > > > (I installed too python 2.1 here /usr/local/lib/python2.1) > > > > How to do if I want to install python-ldap for python 2.6.1 under Zope ? > > Where are include and lib directories I have to config in setup.cfg ? > > > > Is there a global variable to positioning ? (I want to keep alive > > python2.2 because there is a lot of redhat stuff using it...) > > You have to invoke setup.py with exactly the Python interpreter binary Zope > is using. > > E.g. if your system's Python is installed in /usr/bin/python and the Python > 2.1.3 for Zope is in /zope/bin/python you have to invoke > > $ /zope/bin/python setup.py build > # /zope/bin/python setup.py install > > Ciao, Michael. > ok I tried but now there is an other problem: [root at rheisxa001 python-ldap-2.0.0pre13]# /zope/bin/python setup.cfg build File "setup.cfg", line 10 library_dirs = /usr/local/openldap-REL_ENG_2_1/lib ^ /usr/local/cyrus-sasl/lib SyntaxError: invalid syntax I don't understand why there is a syntax error here! Please, help me... Thanks. > > > From michael at stroeder.com Fri Sep 26 16:01:59 2003 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Fri, 26 Sep 2003 16:01:59 +0200 Subject: How to build python-ldap correctly... In-Reply-To: <1064575071.10489.13.camel@rheisxa001.rpn.ch> References: <1064568773.10489.9.camel@rheisxa001.rpn.ch> <3F741D5F.6080303@stroeder.com> <1064575071.10489.13.camel@rheisxa001.rpn.ch> Message-ID: <3F7446D7.9060905@stroeder.com> Patrick Gelin wrote: >> >>$ /zope/bin/python setup.py build >># /zope/bin/python setup.py install ^^^^^^^^ Please take note of details... > ok I tried but now there is an other problem: > [root at rheisxa001 python-ldap-2.0.0pre13]# /zope/bin/python setup.cfg ^^^^^^^^^ Why not make use of the fine copy&paste feature? Ciao, Michael. From jlittle at open-it.org Fri Sep 26 18:24:34 2003 From: jlittle at open-it.org (Joe Little) Date: Fri, 26 Sep 2003 09:24:34 -0700 Subject: I'm looking for python-ldap for python 2.1.3 under redhat 9.0... In-Reply-To: <1064564642.4957.4.camel@rheisxa001.rpn.ch> Message-ID: As noted in the python-ldap downloads, its in ftp://ftp.open-it.org/pub/redhat/8.0/RPMS or SRPMS. You can take the SRPM for 8.0 and rebuild it for 9.0 easily enough. On Friday, September 26, 2003, at 01:24 AM, Patrick Gelin wrote: > Hi, > > I'm looking for python-ldap for python 2.1.3 to install under redhat > 9.0. > > I saw ftp.open-it.org bug the only package I found is > /pub/prototypes/python-ldap-1.10alpha3.1.i386.rpm and it's for python > 1.5 (too old) > > Do you know where I can find it ? > > Thanks. > > > > From marc at msys.ch Sun Sep 28 09:19:29 2003 From: marc at msys.ch (Marc Balmer) Date: Sun, 28 Sep 2003 09:19:29 +0200 Subject: How to build python-ldap correctly... In-Reply-To: <1064568773.10489.9.camel@rheisxa001.rpn.ch> References: <1064568773.10489.9.camel@rheisxa001.rpn.ch> Message-ID: <20030928091929.5b1dee81.marc@msys.ch> On 26 Sep 2003 11:32:53 +0200 Patrick Gelin wrote: > How to do if I want to install python-ldap for python 2.6.1 under Zope ? Well, first you'll have to wait until python 2.6.1 gets released... > Is there a global variable to positioning ? (I want to keep alive > python2.2 because there is a lot of redhat stuff using it...) Always compile an install the modules with the python version you want to use, i.e. python2.1 setup.py build etc. In the case of ZOpe, you often find the python interpreter in $ZOPEHOME/bin. - mb From jens at zope.com Mon Sep 29 20:04:32 2003 From: jens at zope.com (Jens Vagelpohl) Date: Mon, 29 Sep 2003 14:04:32 -0400 Subject: Problems with comma inside RDN elements Message-ID: <6052C4B6-F2A7-11D7-9302-000393D58818@zope.com> Hi Michael (and whoever else is still listening ;) I have something where I am not sure whether the problem is in python-ldap or in my software. Calls to "search_s" hang when the RDN element contains a comma (escaped with backslash or not does not make a difference). Here's a simple test script that I am using against a server here:: conn = ldap.initialize('ldap://my.ldap.server') conn.set_option(ldap.VERSION, ldap.VERSION3) conn.simple_bind_s(ADMIN, PASSWD) res = conn.search_s(BASE, ldap.SCOPE_SUBTREE, 'member=%s' % MEMBER) conn.unbind_s() It works fine for "normal" RDN elements, such as when MEMBER looks like this:: cn=Jens Vagelpohl,cn=Users,dc=as,dc=zope,dc=com but it hangs completely with these MEMBERs:: cn=Doe\, John,cn=Users,dc=as,dc=zope,dc=com cn=Doe, John,cn=Users,dc=as,dc=zope,dc=com I am working with python-ldap version 2.0.0pre13, running on OS X 10.2.6 against the built-in OpenLDAP libraries (it is not exactly clear which exact OpenLDAP version these are). This is probably not a OS-dependent problem because I am coming against it reproducing it for someone else. Any pointers welcome - maybe I just need to escape that comma differently? jens From michael at stroeder.com Mon Sep 29 21:56:17 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Sep 2003 21:56:17 +0200 Subject: Problems with comma inside RDN elements In-Reply-To: <6052C4B6-F2A7-11D7-9302-000393D58818@zope.com> References: <6052C4B6-F2A7-11D7-9302-000393D58818@zope.com> Message-ID: <3F788E61.5060401@stroeder.com> Jens Vagelpohl wrote: > I have something where I am not sure whether the problem is in > python-ldap or in my software. Calls to "search_s" hang when the RDN > element contains a comma (escaped with backslash or not does not make a > difference). > [..] > res = conn.search_s(BASE, ldap.SCOPE_SUBTREE, 'member=%s' % MEMBER) 1. The parentheses for the filter template are missing. 2. Use ldap.filter.escape_filter_chars() for escaping the necessary back-slash and other chars special to filter strings (new in 2.0.0pre12). res = conn.search_s( BASE, ldap.SCOPE_SUBTREE, '(member=%s)' % ldap.filter.escape_filter_chars(MEMBER) ) OpenLDAP shouldn't hang though. > cn=Doe, John,cn=Users,dc=as,dc=zope,dc=com This is not a valid DN anyway. Ciao, Michael. From michael at stroeder.com Mon Sep 29 22:16:45 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Sep 2003 22:16:45 +0200 Subject: Problems with comma inside RDN elements In-Reply-To: <3F788E61.5060401@stroeder.com> References: <6052C4B6-F2A7-11D7-9302-000393D58818@zope.com> <3F788E61.5060401@stroeder.com> Message-ID: <3F78932D.3060103@stroeder.com> Michael Str?der wrote: > > 2. Use ldap.filter.escape_filter_chars() for escaping the necessary > back-slash and other chars special to filter strings (new in 2.0.0pre12). Or even better use ldap.filter.filter_format(). res = conn.search_s( BASE, ldap.SCOPE_SUBTREE, ldap.filter.filter_format( '(member=%s)',(MEMBER,) ) ) Ciao, Michael. From jens at zope.com Mon Sep 29 22:12:49 2003 From: jens at zope.com (Jens Vagelpohl) Date: Mon, 29 Sep 2003 16:12:49 -0400 Subject: Problems with comma inside RDN elements In-Reply-To: <3F788E61.5060401@stroeder.com> Message-ID: <4C181EC8-F2B9-11D7-9302-000393D58818@zope.com> > 1. The parentheses for the filter template are missing. Yup, I know. I was just testing all kinds of combinations just to force some kind of solution :) > 2. Use ldap.filter.escape_filter_chars() for escaping the necessary > back-slash and other chars special to filter strings (new in > 2.0.0pre12). I see the module inside the source package, but it never gets put anywhere by distutils from what I can tell. "ldap.filter" gives me an AttributeError. > res = conn.search_s( > BASE, > ldap.SCOPE_SUBTREE, > '(member=%s)' % ldap.filter.escape_filter_chars(MEMBER) > ) I'll try as soon as the filter module is in place 8-) > OpenLDAP shouldn't hang though. The query itself was against a M$ CraptiveDirectory server. I found myself unable to force a record like that into OpenLDAP... hehe >> cn=Doe, John,cn=Users,dc=as,dc=zope,dc=com > > This is not a valid DN anyway. Yup, I know :) jens P.S.: Today I realized that I must have been unsubscribed from the list for quite a while. I just thought it had gotten really quiet... From michael at stroeder.com Mon Sep 29 22:20:27 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Sep 2003 22:20:27 +0200 Subject: Problems with comma inside RDN elements In-Reply-To: <4C181EC8-F2B9-11D7-9302-000393D58818@zope.com> References: <4C181EC8-F2B9-11D7-9302-000393D58818@zope.com> Message-ID: <3F78940B.7050809@stroeder.com> Jens Vagelpohl wrote: > >> 2. Use ldap.filter.escape_filter_chars() for escaping the necessary >> back-slash and other chars special to filter strings (new in 2.0.0pre12). > > I see the module inside the source package, but it never gets put > anywhere by distutils from what I can tell. "ldap.filter" gives me an > AttributeError. You're right. It was fixed in CVS some weeks ago. :-/ revision 1.54 date: 2003/08/20 20:27:10; author: stroeder; state: Exp; lines: +2 -1 Added ldap.filter to py_modules > P.S.: Today I realized that I must have been unsubscribed from the list > for quite a while. I just thought it had gotten really quiet... It was really low-traffic indeed. Ciao, Michael. From jens at zope.com Mon Sep 29 23:12:22 2003 From: jens at zope.com (Jens Vagelpohl) Date: Mon, 29 Sep 2003 17:12:22 -0400 Subject: Problems with comma inside RDN elements In-Reply-To: <3F78932D.3060103@stroeder.com> Message-ID: <9E43519A-F2C1-11D7-9302-000393D58818@zope.com> > Or even better use ldap.filter.filter_format(). > > res = conn.search_s( > BASE, > ldap.SCOPE_SUBTREE, > ldap.filter.filter_format( > '(member=%s)',(MEMBER,) > ) > ) This is great and solves the original problem. The only problem I am finding is that if I happen to have a wildcard filter such as... (objectClass=*) or (cn=*jens*) the replacement of '*' with r'\2a' seems problematic. I'm not getting the expected results, as a maatter of fact I am not getting any results. jens From patrick.gelin at rpn.ch Tue Sep 30 08:55:36 2003 From: patrick.gelin at rpn.ch (Patrick Gelin) Date: 30 Sep 2003 08:55:36 +0200 Subject: Too many results for this query... Message-ID: <1064904935.4580.18.camel@rheisxa001.rpn.ch> Hi, I would like to go through all LDAP users to register them into my Plone site (I need to use localroles and it's possible only after a Plone registration...) So, I'm writing a python script (may be I have to write an external method) which use the LDAPUserFolder::getUserNames API, and I've got the error message below: getUserNames: Cannot find any users (Too many results for this query) Is there a solution to grow the size of result accepted by python-ldap ? Is there an other solution ? Thanks. Patrick Gelin From michael at stroeder.com Tue Sep 30 10:25:16 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 30 Sep 2003 10:25:16 +0200 Subject: Too many results for this query... In-Reply-To: <1064904935.4580.18.camel@rheisxa001.rpn.ch> References: <1064904935.4580.18.camel@rheisxa001.rpn.ch> Message-ID: <3F793DEC.1000200@stroeder.com> Patrick Gelin wrote: > > I would like to go through all LDAP users to register them into my Plone > site (I need to use localroles and it's possible only after a Plone > registration...) > [..] > getUserNames: Cannot find any users (Too many results for this query) This is a matter of the server-side configuration. Check size limits with the LDAP server's admin. Some LDAP server products allow setting user-specific limits. > Is there a solution to grow the size of result accepted by python-ldap ? Nope. Ciao, Michael. From jean-marc.pouchoulon at ac-montpellier.fr Tue Sep 30 13:41:07 2003 From: jean-marc.pouchoulon at ac-montpellier.fr (jean-marc pouchoulon) Date: Tue, 30 Sep 2003 13:41:07 +0200 Subject: Segmention fault on redhat 9 on ldap_simple_bind_s Message-ID: <004301c38747$bc718590$baa71dac@in.acmontpellier.fr> Helo , After read mails from archives, I sucessfully install python-ldap on redhat 9. (install tgz of openldap-2.1.22 Modify source with python-ldap_libs.patch ( -libs = ldap_r lber sasl2 ssl crypto +libs = ldap_r ldap lber sasl2 ssl crypto ) before that I have an error messages on import undefined symbol: ldap_first_reference) Now I have a segmentation fault on simple bind >>> import ldap >>> l = ldap.open('ip_address') >>> l.simple_bind_s('','') Erreur de segmentation I install the package on an xp system and it works perfectly. I try to install the package on a debian and I have python setup.py build Traceback (most recent call last): File "setup.py", line 10, in ? from distutils.core import setup, Extension ImportError: No module named distutils.core Any help would be greatly appreciated, especially on RedHat. Jean-Marc Pouchoulon From bjorn.grotan at itea.ntnu.no Tue Sep 30 13:54:00 2003 From: bjorn.grotan at itea.ntnu.no (=?iso-8859-1?Q?Bj=F8rn_Ove_Gr=F8tan?=) Date: Tue, 30 Sep 2003 13:54:00 +0200 Subject: Segmention fault on redhat 9 on ldap_simple_bind_s In-Reply-To: <004301c38747$bc718590$baa71dac@in.acmontpellier.fr> References: <004301c38747$bc718590$baa71dac@in.acmontpellier.fr> Message-ID: <20030930115400.GB9448@itea.ntnu.no> jean-marc pouchoulon: > Helo , > After read mails from archives, I sucessfully install > python-ldap on redhat 9. (install tgz of openldap-2.1.22 > Modify source with python-ldap_libs.patch ( -libs = ldap_r lber sasl2 > ssl crypto > +libs = ldap_r ldap lber sasl2 ssl crypto ) before that I have an error > messages on import undefined > symbol: ldap_first_reference) > Now I have a segmentation fault on simple bind > >>> import ldap > >>> l = ldap.open('ip_address') > >>> l.simple_bind_s('','') > Erreur de segmentation > > I install the package on an xp system and it works perfectly. > > I try to install the package on a debian and I have > > python setup.py build > Traceback (most recent call last): > File "setup.py", line 10, in ? > from distutils.core import setup, Extension > ImportError: No module named distutils.core > > > Any help would be greatly appreciated, especially on RedHat. For ldap: install apt for redhat and use e.g. the following in your /etc/apt/sources.list : rpm http://apt.freshrpms.net redhat/9.0/en/i386 os updates freshrpms rpm ftp://apt-rpm.tuxfamily.org/apt redhat/9.0/en/i386 os updates extra (just sed'ed s/"7.3"/"9.0"/g, so I don't know if the url is correct.) then, for both redhat and debian, run the following commands: $ apt-get update && apt-get upgrade $ apt-get install python-ldap that's it. -- Regards Bj?rn Ove Gr?tan From jens at zope.com Tue Sep 30 13:58:09 2003 From: jens at zope.com (Jens Vagelpohl) Date: Tue, 30 Sep 2003 07:58:09 -0400 Subject: Segmention fault on redhat 9 on ldap_simple_bind_s In-Reply-To: <004301c38747$bc718590$baa71dac@in.acmontpellier.fr> Message-ID: <5C2D54B6-F33D-11D7-837F-000393D58818@zope.com> > After read mails from archives, I sucessfully install > python-ldap on redhat 9. (install tgz of openldap-2.1.22 > Modify source with python-ldap_libs.patch ( -libs = ldap_r lber sasl2 > ssl crypto > +libs = ldap_r ldap lber sasl2 ssl crypto ) before that I have an error > messages on import undefined > symbol: ldap_first_reference) A guy here at work replaced "ldap_r" with "ldap" in the LIBS line and it worked. He traced it to a broken Makefile in OpenLDAP itself (even in the latest RPMs) that did not mention all the right things (don't have the details here). > Now I have a segmentation fault on simple bind >>>> import ldap >>>> l = ldap.open('ip_address') >>>> l.simple_bind_s('','') > Erreur de segmentation ldap.open is deprecated. Read the docs and use ldap.initialize instead. Michael has produced wonderful python-style documentation, see python-ldap.sourceforge.net. > I try to install the package on a debian and I have > > python setup.py build > Traceback (most recent call last): > File "setup.py", line 10, in ? > from distutils.core import setup, Extension > ImportError: No module named distutils.core I don't do Debian. I bet Debian's python package might be split up in all kinds of pieces and you need to install more of them. They're weird that way. jens From cle_kolab at gmx.net Mon Sep 1 14:50:20 2003 From: cle_kolab at gmx.net (cle_kolab at gmx.net) Date: Mon, 1 Sep 2003 14:50:20 +0200 (MEST) Subject: ldapmodule.so Message-ID: <32438.1062420620@www63.gmx.net> when i compile python-ldap-2.0.0pre13.tar.gz i dont get the ldapmodule.so which i need for the zope ldapuserfolder. this file is also _not_ included in the standard python-ldap in debian woody. i only get an ldapmodule.o when i call setup.py buld gcc complains about an unrecognized option -R what am i doing wrong -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualit?tssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post