From Jean-Eric.Cuendet at linkvest.com Mon Apr 2 16:25:23 2001 From: Jean-Eric.Cuendet at linkvest.com (Jean-Eric Cuendet) Date: Mon, 2 Apr 2001 16:25:23 +0200 Subject: Problem with modify in python-LDAP Message-ID: Hi, Would anyone try this little program? LDAPSearch.find() works great but I always have these errors when updating ( LDAPEntry.commit() ): Modlist: [(2, 'loginshell', ['/bin/bash', '/bin/ash'])] Traceback (most recent call last): File "./class_test.py", line 98, in ? entry.commit(); File "/usr/lib/python2.0/site-packages/python-ldap/ldap/entry.py", line 254, in commit self.connection._modify(self.dn, mod) File "/usr/lib/python2.0/site-packages/python-ldap/ldap/connection.py", line 63, in _modify self.__connection.modify_s(self.__check_base(dn), modlist) ldap.LDAPError: / Ld-error: 0 / Result: 21 / Invalid syntax Thanks -jec <> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Jean-Eric Cuendet Linkvest SA Av des Baumettes 19, 1020 Renens Switzerland Tel +41 21 632 9043 Fax +41 21 632 9090 http://www.linkvest.com E-mail: jean-eric.cuendet at linkvest.com _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ -------------- next part -------------- A non-text attachment was scrubbed... Name: class_test.py Type: application/octet-stream Size: 2315 bytes Desc: not available URL: From mirko at picard.inka.de Tue Apr 10 13:47:05 2001 From: mirko at picard.inka.de (Mirko Zeibig) Date: Tue, 10 Apr 2001 13:47:05 +0200 Subject: [ANN] python-ldap (1.10alpha3) RPMs for RedHat 7.0 Message-ID: <20010410134705.A15344@picard.inka.de> Hello everybody, I just put together RPMS for python-ldap, built on RedHat 7.0: - python 1.5 and 2.0 - openldap 1.2.11 available at: http://www.webideal.de/ldap When rebuilding the src-rpm setting the environment variable PYTHON will influence the build: env PYTHON=python2.0 rpm --rebuild python-ldap-XXX.src.rpm will produce an python2.0-RPM. Even the RPMs will have different names, so you may install the package for both Python 1.5 and 2.0. Best Regards Mirko Zeibig -- mirko at picard.inka.de http://sites.inka.de/picard/ From michael at stroeder.com Tue Apr 17 16:05:10 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 17 Apr 2001 16:05:10 +0200 Subject: Completely async... Message-ID: <3ADC4D96.85F0182A@stroeder.com> HI! I wrote a drop-in replacement class for LDAPObject for locking calls into the LDAP libs since these are not completely thread-safe (see attached gzip-ped module ldapthreading). For letting other threads run the *_s() methods internally convert the synchronous call from the application to asynchronous LDAPObject method calls. Especially the result() method tries to do the timeout handling to avoid hanging around in a ldap_result() call. This seems to work in most situations (on my S.u.S.E. Linux 7.0 box). However it seems to me that the implementation of the result() in python-ldap's LDAPObject.c is not really asynchronous. Look at the following situation: The LDAPObject.result() method is called like r = l.result(msgid,all=0,timeout=0) This returns a tuple (restype,result) if the LDAP server has already sent a result. But what happens if the LDAP server did not send anything so far? I would expect l.result() to return None in this case indicating that no result was received so far which seems to be the case. But how to distinguish between the LDAP server is still gathering data and sent nothing so far and reaching the end of received results? My tests are showing that in most cases None is also given back byresult() when end of search results is reached. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: ldapthreading-1.9.py.gz Type: application/x-gzip Size: 1591 bytes Desc: not available URL: From fog at mixadlive.com Mon Apr 2 00:41:15 2001 From: fog at mixadlive.com (Federico Di Gregorio) Date: Mon, 2 Apr 2001 00:41:15 +0200 Subject: Question in LDAPEntry.set() In-Reply-To: ; from Jean-Eric.Cuendet@linkvest.com on Sun, Apr 01, 2001 at 05:18:57PM +0200 References: Message-ID: <20010402004114.A712@mixadlive.com> Scavenging the mail folder uncovered Jean-Eric Cuendet's letter: > But I can't modify them. > I'm unable to use the LDAPEntry.set() method. > Could someone explain me what means: > def set(self, key, *values): > The star (*) before "values" ? > What should be the type of this parameter? And the value? in ldap you can have the same field/attribute repeated more that once. if you give .set() a list, it will generate multiple attributes with the same name but different values, e.g., entry.set('cn', ['Federico', 'fog]) note that you are using my first try at a high level python interface. after some comments on this list i begun to slowly rewrite this api following the java-ldap api. so, you are using something that will go away in the future... Scavenging the mail folder uncovered Jean-Eric Cuendet's letter: > > Just another thing: > When I run my program (attached), I have the following error: > Begin changing > Traceback (most recent call last): > File "./class_test.py", line 79, in ? > res.set("gecos", list); > File "/usr/lib/python2.0/site-packages/python-ldap/ldap/entry.py", line > 133, in set > self.data[key] = (self.data[key][0]+values, 1) > TypeError: can only concatenate list (not "tuple") to list you gave it a tuple, .set() only accept lists. ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog at mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog at debian.org Best friends are often failed lovers. -- Me From Jean-Eric.Cuendet at linkvest.com Sun Apr 1 17:18:57 2001 From: Jean-Eric.Cuendet at linkvest.com (Jean-Eric Cuendet) Date: Sun, 1 Apr 2001 17:18:57 +0200 Subject: Question in LDAPEntry.set() Message-ID: Hi, I'm new to this list and very interested in LDAP-python. I have some problems with it. I use CVS version and I'm able to get entries from the LDAP repository. But I can't modify them. I'm unable to use the LDAPEntry.set() method. Could someone explain me what means: def set(self, key, *values): The star (*) before "values" ? What should be the type of this parameter? And the value? I'm using Python 2.0 + OpenLDAP 2.0.7, is there problems with this combination or is everything OK? Thanks -jec From michael at stroeder.com Thu Apr 19 16:55:49 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 19 Apr 2001 16:55:49 +0200 Subject: -lpthread + -D_REENTRANT Message-ID: <3ADEFC75.260DEBC8@stroeder.com> HI! Is it possible to set gcc compiler option -D_REENTRANT and linker option -lpthread in the autoconf script if Python was built --with-threads? Ciao, Michael. From bortzmeyer at netaktiv.com Sun Apr 22 21:28:21 2001 From: bortzmeyer at netaktiv.com (Stephane Bortzmeyer) Date: Sun, 22 Apr 2001 21:28:21 +0200 Subject: 1.10alpha3 compiles against OpenLDAP 1 but not 2 Message-ID: <20010422212821.A30226@internatif.org> I can compile 1.0alpha3 without any problem on my Debian 2.2 ("potato") machine (this is OpenLDAP version 1) but, on a future-2.3 ("woody") machine, which has OpenLDAP 2: % gcc -fPIC -I. -DLDAP_REFERRALS -g -O2 -Wall -Wstrict-prototypes -I/usr/include/python2.0 -I/usr/include/python2.0 -DHAVE_CONFIG_H -c /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c: In function `LDAPinit_constants': /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c:69: `LDAP_MAX_ATTR_LEN' undeclared (first use in this function) /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c:69: (Each undeclared identifier is reported only once /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c:69: for each function it appears in.) /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c:82: `LDAP_REQ_UNBIND_30' undeclared (first use in this function) ... Rightly, I do not find these symbols anywhere in OpenLDAP header files. I've read the archives of the mailing list and noted the thread "compiling against OpenLDAP 2.0.7" last month but I'm pessimistic: it seems there is no known solution. Is is incredible that OpenLDAP 2 is still not supported. Is the software dead? Is there another Python-LDAP solution? Should I program in Perl? From bortzmeyer at netaktiv.com Sun Apr 22 21:28:21 2001 From: bortzmeyer at netaktiv.com (Stephane Bortzmeyer) Date: Sun, 22 Apr 2001 21:28:21 +0200 Subject: Bug#76717: 1.10alpha3 compiles against OpenLDAP 1 but not 2 Message-ID: <20010422212821.A30226@internatif.org> I can compile 1.0alpha3 without any problem on my Debian 2.2 ("potato") machine (this is OpenLDAP version 1) but, on a future-2.3 ("woody") machine, which has OpenLDAP 2: % gcc -fPIC -I. -DLDAP_REFERRALS -g -O2 -Wall -Wstrict-prototypes -I/usr/include/python2.0 -I/usr/include/python2.0 -DHAVE_CONFIG_H -c /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c: In function `LDAPinit_constants': /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c:69: `LDAP_MAX_ATTR_LEN' undeclared (first use in this function) /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c:69: (Each undeclared identifier is reported only once /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c:69: for each function it appears in.) /home/bortzmeyer/tmp/python-ldap-1.10alpha3/Modules/constants.c:82: `LDAP_REQ_UNBIND_30' undeclared (first use in this function) ... Rightly, I do not find these symbols anywhere in OpenLDAP header files. I've read the archives of the mailing list and noted the thread "compiling against OpenLDAP 2.0.7" last month but I'm pessimistic: it seems there is no known solution. Is is incredible that OpenLDAP 2 is still not supported. Is the software dead? Is there another Python-LDAP solution? Should I program in Perl? -- To UNSUBSCRIBE, email to debian-bugs-dist-request at lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org From michael at stroeder.com Mon Apr 30 19:37:52 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 30 Apr 2001 18:37:52 +0100 Subject: Bug#76717: 1.10alpha3 compiles against OpenLDAP 1 but not 2 References: <20010422212821.A30226@internatif.org> Message-ID: <3AEDA2F0.69245DDB@stroeder.com> Stephane Bortzmeyer wrote: > > I can compile 1.0alpha3 without any problem on my Debian 2.2 > ("potato") machine (this is OpenLDAP version 1) but, on a future-2.3 > ("woody") machine, which has OpenLDAP 2: > [..] > I've read the archives of the mailing list and noted the thread > "compiling against OpenLDAP 2.0.7" last month but I'm pessimistic: it > seems there is no known solution. There were two patches posted to the list earlier (December 2000?). One of them (Konstantin's patch) even had support for LDAPv3 binds and search continuations but is not ready for prime time yet. web2ldap already contains code to abstract from the differences of python-ldap built against OpenLDAP 2.0.x and do LDAPv3 binds (see module ldapsession). > Is is incredible that OpenLDAP 2 is still not supported. There are so many incredible things out there...why bother with python-ldap? ;-} Serious: One of the main problems is that the OpenLDAP 2 API is quite different. They dropped support for the old RFC1823 API heading to LDAPEXT-API (Internet Draft). The other C APIs like e.g. Netscape are quite different too (e.g. with setting options, SASL and SSL/TLS). I did not manage to build against a recent version of the Netscape SDK (which is a pity since it's the only thread-safe LDAP C SDK out there). > Is the software dead? David Leonhard does not have the time to contribute anymore. I'm not a C programmer myself. Therefore I can't help with the C part (except excessively testing it). Feel free to jump on in. > Is there another Python-LDAP solution? You might find some discussion about Sascha's SWIG-based approach in python-ldap-dev list archive. Another approach would be to build a completely new python-ldap module maybe implemented mainly in Python with CPU intensive BER en-/de-coding done in C (or optionally pure Python like the cPickle/Pickle approach). The API design could be derived from the Internet-Draft for a Java API which is still heavily discussed on the ldapext list. But this would be a lot of ASN.1-related work and I do not have enough unpayed spare time for it. Again: Feel free to jump on in. > Should I program in Perl? Yes, probably. ;-} Ciao, Michael. From michael at stroeder.com Sat May 5 20:11:58 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sat, 05 May 2001 19:11:58 +0100 Subject: Python and OpenLDAP 2 References: <20010505083209.A12256@sverresborg.uninett.no> Message-ID: <3AF4426E.D08BE238@stroeder.com> Stig, Konstantin, sorry for the late reply. I was on vacation for two weeks. Stig Venaas wrote: > > A coworker asked me about Python and OpenLDAP 2. Does your co-worker really need features of the OpenLDAP 2 libs? > I thought you > Konstantin were porting Python in order to help Michael use > LDAPv3 stuff in web2ldap. How's it going? The patches of Konstantin work but not thoroughly tested. You can do a LDAPv3 bind a get search continuations, no schema or SSL/STARTTLS support. There might be some cave-ats because the OpenLDAP 2 libs seem to behave somewhat different. > Will this be in official Python distribution at some point? Many people are asking... Cc: to python-ldap-dev list. > If my coworker wants to try > Python and OpenLDAP 2, what should he do? 1. Grab the patches from the mailing list archive or ask me. 2. Subscribe to python-ldap-dev list. 3. Jump on in. > Don't know anything about > Python myself, although I've got friends raving about it (: Stig, it's a shame! ;-) Ciao, Michael. From michael at stroeder.com Mon May 7 19:27:27 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 07 May 2001 19:27:27 +0200 Subject: Updated Lib/ldif.py Message-ID: <3AF6DAFF.5B4F82EE@stroeder.com> HI! I've committed a slightly modified module ldif.py to the CVS archive. Anyone using this module should check if there are any problems. Ciao, Michael. From michael at stroeder.com Wed May 9 12:28:46 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 09 May 2001 12:28:46 +0200 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available References: <200105082317.f48NHdG10729@kodama.stanford.edu> Message-ID: <3AF91BDE.8D878014@stroeder.com> Joe Little wrote: > > So I > will either need to figure out how to fix python-ldap for modern ldap > libraries (OpenLDAP, mozilla, etc), or redo it completely. Unfortunately the LDAP C SDKs diverged to incorporate new features like SASL, SSL, etc. Another thing to take care of: All people are asking for building against the OpenLDAP 2 libs. Note that the only thread-safe LDAP C SDK seems to be the Mozilla C SDK. ---------------------- snip ---------------------- Subject: Re: OpenLDAP libs thread-safe? Date: Fri, 13 Apr 2001 09:00:45 -0700 From: "Kurt D. Zeilenga" To: michael at stroeder.com CC: openldap-software At 02:42 PM 4/13/01 +0200, Michael Str?der wrote: >The OpenLDAP 1.2.11 libs does not seem to be thread-safe. How about >OpenLDAP 2.0.x libs? While 2.0 provides an experimental -lldap_r. It is not generally thread-safe, but thread-safe if used in a specific manner. As use of -lldap_r requires detailed knowledge of how the library works, I do not recommend developers attempt to make use of it. You might consider using the Mozilla LDAP C API which has more general thread-safety features. Of course, we welcome those wanting to work on the OpenLDAP C API to improve its thread-safety features. Kurt ---------------------- snip ---------------------- Ciao, Michael. From michael at stroeder.com Wed May 9 12:20:57 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 09 May 2001 12:20:57 +0200 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available References: Message-ID: <3AF91A09.B6C96FA2@stroeder.com> David Leonard wrote: > > i feel its important to discuss how you'd like to see yourself interacting > with ldap through python. Yes! What makes me angry is that most people just complain about python-ldap being abandonware because it cannot be linked against OpenLDAP 2 libs. That's definitely not enough! You can write a lot of standard LDAP applications with python-ldap by reading the _ldap.pdf carefully. Most of you wouldn't need more. python-ldap does not do your homework nor cook your coffee off course. People should really list the particular defecencies they *personally* experienced. I can easily list a few *I* experienced (as I already did - see the list archive). But I would like to know what others have as requirements and discuss them in detail. On the other side all people are free to come up with their own home-grown modules and see how they fit into this project. Some people did and I appreciate this although I might have a different opinion. But note: getting something to a maturity you all are expecting from python-ldap is much work (maintaining, support, documentation) - a quick hack/patch will not do. > there have been some past emails containing my > suggestions and fog has some work towards a high level X.500 interface > for python. I could also release some higher-level modules (e.g. ldapsession found in web2ldap) with a more relaxed license. But people have to be willing to at least test them. There's not much feedback on this list. Just complaints. > on the other hand, just getting something to work with openldap2 via swig > would make progress and maybe that's all that you and other people > really need? If there's not a requirement list which features of OpenLDAP 2 people really need this will just produce a quick hack/patch of not much use. And if the producer looses interest it's not maintained. Ciao, Michael. From michael at stroeder.com Wed May 9 12:00:34 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 09 May 2001 12:00:34 +0200 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available References: <200105090106.f4916WG11374@kodama.stanford.edu> Message-ID: <3AF91542.B65BA66D@stroeder.com> Joe Little wrote: > > Indeed. I know one of the maintainers of the PerLDAP stuff. Its not very > pretty, but even the python-ldap code has gotten less pretty than I'd > like. I definitely want to keep away from the PerLDAP api which doesn't > provide much abstraction or object-orientation (good, standard > initialization) Take a look at "section LDAP APIs" found on: http://www.ietf.org/html.charters/ldapext-charter.html The Java API is still heavily discussed but already on a very detailed level. I would like to stick to that. Ciao, Michael. From david.leonard at csee.uq.edu.au Wed May 9 03:30:15 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Wed, 9 May 2001 11:30:15 +1000 (EST) Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available In-Reply-To: <200105090106.f4916WG11374@kodama.stanford.edu> Message-ID: On Tue, 8 May 2001, Joe Little typed thusly: > Link all you want :) done! > Indeed. I know one of the maintainers of the PerLDAP stuff. Its not very > pretty, but even the python-ldap code has gotten less pretty than I'd > like. I definitely want to keep away from the PerLDAP api which doesn't > provide much abstraction or object-orientation (good, standard > initialization) i suppose a first question is, how object-oriented do you want the directory to appear? If you just want an 'ldap' object on which you call various methods, with DNs and so forth, then that's pretty straight forward. swig will do it. you get an ldap object per ldap server connection. on the other hand, if you want every entry in the directory to be an object, and maybe the attributes too then that's a bit more work and perhaps too fine grained to get real work done with. for people who want to (say) write graphical directory browsers, they'd end up using those patterns that parallel object trees and it will get quite messy. > > i feel its important to discuss how you'd like to see yourself > > interacting > > with ldap through python. there have been some past emails containing my > > suggestions and fog has some work towards a high level X.500 interface > > for python. > > I'll try and look into it. Any specific time period off hand? now? ;) > Full-featured would be great, but you are correct that there are new > requirements and possibly a secure-access only API may be sufficient (as > in more LDAP support and less LBER requirements). sounds good. different people on this list have different needs. d -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 Why are apartments so close together? From jlittle at open-it.org Wed May 9 03:11:06 2001 From: jlittle at open-it.org (Joe Little) Date: Tue, 8 May 2001 18:11:06 -0700 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available In-Reply-To: Message-ID: <200105090106.f4916WG11374@kodama.stanford.edu> Comments are below On Tuesday, May 8, 2001, at 06:01 PM, David Leonard wrote: > >> http://open-it.org/download (in either redhat6.2/RPMS or the like you >> find it) > > ok to link to this from the 'download' page? > Link all you want :) > I've used swig before, and ended up writing such python-specific code > that swig was becoming a nusiance. You may have different experience, > or maybe swig has gotten better. > It would appear that both SWIG and Zope's python-scripting have gotten better. The key definitely is making ldap OO enough... > the point of using swig is to make it accessible in more scripting > languages > than just python.. which is admittedly a nice thing. it means that more > thought has to be put into the api. > >> Is python-ldap basically abandon-ware at this point? Being in "a3" for >> about a year is pretty "abandoned" to me. > > yes its pretty close to abandonware :) > with openldap2 a rewrite is a good idea. i personally just don't have > much time nor motivation to do it all again. that's why its in > sourceforge :) > > the other thing that i do not track, but that stroeder seems to, is what > o-o apis are emerging for ldap. there is the java-ldap ietf draft, there > is also perl's (ugly imho). > Indeed. I know one of the maintainers of the PerLDAP stuff. Its not very pretty, but even the python-ldap code has gotten less pretty than I'd like. I definitely want to keep away from the PerLDAP api which doesn't provide much abstraction or object-orientation (good, standard initialization) > i feel its important to discuss how you'd like to see yourself > interacting > with ldap through python. there have been some past emails containing my > suggestions and fog has some work towards a high level X.500 interface > for python. > I'll try and look into it. Any specific time period off hand? > on the other hand, just getting something to work with openldap2 via > swig > would make progress and maybe that's all that you and other people > really need? > Full-featured would be great, but you are correct that there are new requirements and possibly a secure-access only API may be sufficient (as in more LDAP support and less LBER requirements). > go for it. > > d > > On Tue, 8 May 2001, Joe Little typed thusly: > >> Well, OpenLDAP feature sets do trully need to be supported, since I'll >> be managing certificates and require TLS and such. Lovely that. So I >> will either need to figure out how to fix python-ldap for modern ldap >> libraries (OpenLDAP, mozilla, etc), or redo it completely. Again the >> SWIG approach may be necessary. What are list member preferences at >> this >> stage. I was not utterly thrilled when I glanced at the current code >> base. Associated with the swig approach, I may only need specific >> functions to access LDAP and thus need only build a new simplified API >> that hides c-specific calls to do the rest. > > > -- > David Leonard David.Leonard at csee.uq.edu.au > Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 > The University of Queensland |+| > http://www.csee.uq.edu.au/~leonard/ > QLD 4072 AUSTRALIA ~` '~ > B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 > > Why are apartments so close together? > From david.leonard at csee.uq.edu.au Wed May 9 03:01:44 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Wed, 9 May 2001 11:01:44 +1000 (EST) Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available In-Reply-To: <200105082317.f48NHdG10729@kodama.stanford.edu> Message-ID: > http://open-it.org/download (in either redhat6.2/RPMS or the like you > find it) ok to link to this from the 'download' page? I've used swig before, and ended up writing such python-specific code that swig was becoming a nusiance. You may have different experience, or maybe swig has gotten better. the point of using swig is to make it accessible in more scripting languages than just python.. which is admittedly a nice thing. it means that more thought has to be put into the api. > Is python-ldap basically abandon-ware at this point? Being in "a3" for > about a year is pretty "abandoned" to me. yes its pretty close to abandonware :) with openldap2 a rewrite is a good idea. i personally just don't have much time nor motivation to do it all again. that's why its in sourceforge :) the other thing that i do not track, but that stroeder seems to, is what o-o apis are emerging for ldap. there is the java-ldap ietf draft, there is also perl's (ugly imho). i feel its important to discuss how you'd like to see yourself interacting with ldap through python. there have been some past emails containing my suggestions and fog has some work towards a high level X.500 interface for python. on the other hand, just getting something to work with openldap2 via swig would make progress and maybe that's all that you and other people really need? go for it. d On Tue, 8 May 2001, Joe Little typed thusly: > Well, OpenLDAP feature sets do trully need to be supported, since I'll > be managing certificates and require TLS and such. Lovely that. So I > will either need to figure out how to fix python-ldap for modern ldap > libraries (OpenLDAP, mozilla, etc), or redo it completely. Again the > SWIG approach may be necessary. What are list member preferences at this > stage. I was not utterly thrilled when I glanced at the current code > base. Associated with the swig approach, I may only need specific > functions to access LDAP and thus need only build a new simplified API > that hides c-specific calls to do the rest. -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 Why are apartments so close together? From rsalz at zolera.com Wed May 9 02:37:52 2001 From: rsalz at zolera.com (Rich Salz) Date: Tue, 08 May 2001 20:37:52 -0400 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available References: <200105082317.f48NHdG10729@kodama.stanford.edu> Message-ID: <3AF89160.1D7E3C99@zolera.com> I heartily endorse a SWIG approach. Your source distribution can even include the generated SWIG output for those without swig. /r$ From jlittle at open-it.org Wed May 9 01:22:13 2001 From: jlittle at open-it.org (Joe Little) Date: Tue, 8 May 2001 16:22:13 -0700 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available Message-ID: <200105082317.f48NHdG10729@kodama.stanford.edu> So, I put together python-ldap RPMs/SRPMs for redhat 6.2 and 7.0 to go with my OpenLDAP 2.0.x RPMs on open-it.org. these include the patches spoken of before to support OpenLDAP 2.x. http://open-it.org/download (in either redhat6.2/RPMS or the like you find it) This was done a while ago when I was doing some python-scripts against an LDAP tree (November). I'm now hell bent on using Zope to manage openldap, samba-tng, and other components necessary for Open-IT's goals. Well, OpenLDAP feature sets do trully need to be supported, since I'll be managing certificates and require TLS and such. Lovely that. So I will either need to figure out how to fix python-ldap for modern ldap libraries (OpenLDAP, mozilla, etc), or redo it completely. Again the SWIG approach may be necessary. What are list member preferences at this stage. I was not utterly thrilled when I glanced at the current code base. Associated with the swig approach, I may only need specific functions to access LDAP and thus need only build a new simplified API that hides c-specific calls to do the rest. Is python-ldap basically abandon-ware at this point? Being in "a3" for about a year is pretty "abandoned" to me. Just trolling through the list via ZopeLDAP links and realized that I never did post my RPMs... From michael at stroeder.com Wed May 9 18:25:22 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 09 May 2001 18:25:22 +0200 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available References: <200105091551.f49FptG15014@kodama.stanford.edu> Message-ID: <3AF96F72.B709F8FD@stroeder.com> Joe Little wrote: > > I'm not complaining.. Joe, since you are really contributing code be assured that I did not point to you. > we need specifically to support v3 schema, Could be done in higher-level Python modules. (Not trivial though.) Not sure if you won't have to fiddle with BER-encoded data (implementing syntax matching). > OpenLDAP v2 ACLs, Currently this whole ACL thing is vendor-specific => you would have to write a specific module for each LDAP server. Finding a good abstraction level would be required. See also "Access Control Model for LDAP" on http://www.ietf.org/html.charters/ldapext-charter.html for an attempt to define a standard. There's no need for a modified C extension module. You could also implement this in Python. > StartTLS, Or LDAP over SSL (ldaps://..). IMHO STARTTLS is not widely implemented up to now. Let me add two things. Thread-safety/reentrant: Would require to go with the Mozilla SDK or use ldap_r of OpenLDAP 2.0.x (experimental, see my other posting with Kurt's not about it). Proper handling of referrals / search continuations: Konstantin's patch already provides this but there are sometimes strange LDAP referral URLs returned. Might be a bug of the OpenLDAP 2.0.x libs. Ciao, Michael. From jlittle at open-it.org Wed May 9 17:56:32 2001 From: jlittle at open-it.org (Joe Little) Date: Wed, 9 May 2001 08:56:32 -0700 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available In-Reply-To: Message-ID: <200105091551.f49FptG15014@kodama.stanford.edu> Yes, Open-IT would "love" help :) BTW -- I'm new to the list and not entirely interested in doing work already done by others. I'm not complaining.. just trying to gauge current level of functionality and interest. First, let me state that a) Open-IT, if it does port something or create something, it will be maintained by the group.. all our other software kinda depends on it :) b) check out http://open-it.org/LDAPAdaptor -- Ryan did this work for me back in the OpenLDAP 1.x days. It was an EO adaptor for WebObjects which is more similar to Zope than not. NeXT/Apple didn't think the abstraction necessary to treat an LDAP server as a DB for its enterprise objects was possible, so we stupidly tried and succeeded. They have since made a commercial version based on Ryan's ideas for WebObjects. The key thing was the OO level abstraction that was obtained to allow the GUI kit to work. Python-LDAP may be suitable to fit this role. But "unmaintained" code is not. I'd either need to be assured its maintained or maintain something, the current stuff or something new, myself. I just wish an LDAP module was standard to Python and/or Zope. Its kind of odd that there isn't one. I may need to use SWIG, use the current code, or model connectivity after ZyDB style modules (again, it can be done!). You ask for feature requirements? Since we plan on working on OpenLDAP backends (transactions, etc), we need specifically to support v3 schema, OpenLDAP v2 ACLs, StartTLS, among others to name a few. I have myself put together and "maintain" RPMs for Python-LDAP w/ the patches to work against OpenLDAP v2. David Leonard... I had a nice reply to your last message all written up when I experienced my first MacOSX "desktop" crash... apparently the internet radio station I was listening to wedged up and there went my interface for whatever reason. Most of my long ranting is in the above details. People may hate pine, but its disaster-recovery for lost sessions would be a nice feature in ALL mailers. -Joe On Wednesday, May 9, 2001, at 05:11 AM, Jens Vagelpohl wrote: > joe, > > i am "hell-bent" on using Zope for managing records in OpenLDAP (or > other > LDAP servers for that matter) myself. at this point i have released the > LDAPLoginAdapter and LDAPUserManager (see > http://www.dataflake.org/software/) for authenticating and managing user > records in Zope but i am thinking about a more generic LDAP record > management application. > > if you would like help (on the zope side, i'm no C programmer ;), > suggestions, beta testers, etc let me know. > > jens > > > Jens Vagelpohl > Digital Creations > The Zope Dealers > > > > On 5/8/01 19:22, "Joe Little" wrote: > >> So, I put together python-ldap RPMs/SRPMs for redhat 6.2 and 7.0 to go >> with my OpenLDAP 2.0.x RPMs on open-it.org. these include the patches >> spoken of before to support OpenLDAP 2.x. >> >> http://open-it.org/download (in either redhat6.2/RPMS or the like you >> find it) >> >> This was done a while ago when I was doing some python-scripts against >> an LDAP tree (November). I'm now hell bent on using Zope to manage >> openldap, samba-tng, and other components necessary for Open-IT's >> goals. >> Well, OpenLDAP feature sets do trully need to be supported, since I'll >> be managing certificates and require TLS and such. Lovely that. So I >> will either need to figure out how to fix python-ldap for modern ldap >> libraries (OpenLDAP, mozilla, etc), or redo it completely. Again the >> SWIG approach may be necessary. What are list member preferences at >> this >> stage. I was not utterly thrilled when I glanced at the current code >> base. Associated with the swig approach, I may only need specific >> functions to access LDAP and thus need only build a new simplified API >> that hides c-specific calls to do the rest. >> >> Is python-ldap basically abandon-ware at this point? Being in "a3" for >> about a year is pretty "abandoned" to me. >> >> Just trolling through the list via ZopeLDAP links and realized that I >> never did post my RPMs... > From jens at digicool.com Wed May 9 14:11:09 2001 From: jens at digicool.com (Jens Vagelpohl) Date: Wed, 09 May 2001 08:11:09 -0400 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available In-Reply-To: <200105082317.f48NHdG10729@kodama.stanford.edu> Message-ID: joe, i am "hell-bent" on using Zope for managing records in OpenLDAP (or other LDAP servers for that matter) myself. at this point i have released the LDAPLoginAdapter and LDAPUserManager (see http://www.dataflake.org/software/) for authenticating and managing user records in Zope but i am thinking about a more generic LDAP record management application. if you would like help (on the zope side, i'm no C programmer ;), suggestions, beta testers, etc let me know. jens Jens Vagelpohl Digital Creations The Zope Dealers On 5/8/01 19:22, "Joe Little" wrote: > So, I put together python-ldap RPMs/SRPMs for redhat 6.2 and 7.0 to go > with my OpenLDAP 2.0.x RPMs on open-it.org. these include the patches > spoken of before to support OpenLDAP 2.x. > > http://open-it.org/download (in either redhat6.2/RPMS or the like you > find it) > > This was done a while ago when I was doing some python-scripts against > an LDAP tree (November). I'm now hell bent on using Zope to manage > openldap, samba-tng, and other components necessary for Open-IT's goals. > Well, OpenLDAP feature sets do trully need to be supported, since I'll > be managing certificates and require TLS and such. Lovely that. So I > will either need to figure out how to fix python-ldap for modern ldap > libraries (OpenLDAP, mozilla, etc), or redo it completely. Again the > SWIG approach may be necessary. What are list member preferences at this > stage. I was not utterly thrilled when I glanced at the current code > base. Associated with the swig approach, I may only need specific > functions to access LDAP and thus need only build a new simplified API > that hides c-specific calls to do the rest. > > Is python-ldap basically abandon-ware at this point? Being in "a3" for > about a year is pretty "abandoned" to me. > > Just trolling through the list via ZopeLDAP links and realized that I > never did post my RPMs... From michael at stroeder.com Wed May 9 19:44:10 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 09 May 2001 19:44:10 +0200 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available References: <200105091647.f49GlaG15291@kodama.stanford.edu> Message-ID: <3AF981EA.D5E41464@stroeder.com> Joe Little wrote: > > regarding LDAP thread safety, etc.. Luke Howard and other people > associated with Open-IT have had ideas about this, and thus the project > "kodama" was born to fix issues with OpenLDAP, including referrals. Can you give us an URL of "kodama"? Can you describe how they wanted to solve thread safety? (one of my urgent requirements!) Why to "fix issues with OpenLDAP" in a separate project and not as direct contributions to OpenLDAP? (No offense, just curiousity.) > Some things can/will need to be done in python instead of the c-level > api. As to vendor specific ACL's, etc., that is a decision that will be > hard to make. One proposal would be ideal for Zope, bad for Python: > Using zope-based ACL primitives (dare I call it that) to handle ACLs and > then simple use SSL-certs (client and server) to authenticate. I'm not sure about which ACLs and authentication you're talking. Authorization schemes at your client/gateway side or at the LDAP server side? I don't understand how Zope is involved at that level. As I understand you specify ACLs on some LDAP servers by setting operational attributes (e.g. attribute aci on Netscape server). Most times this is done by a vendor-specific directory managing software. Do you plan to write an ACL managing software for OpenLDAP? AFAIK in OpenLDAP ACLs are solely defined in the configuration file (see http://www.openldap.org/doc/admin/slapdconfig.html#Access Control). Therefore I don't see how python-ldap could be involved at all. Anyway, for the upcoming I-D on LDAP ACLs it is interesting that http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-07.txt states in section ABSTRACT: "The current LDAP APIs are sufficient for the access control operations." > Kurt and > others keep on saying that OpenLDAP should not be the authentication > server, and we should rely upon 3rd party auth (Krb5, etc). The end > result is have OpenLDAP use some external auth and some external > ACL-mapping to layer upon basic ACL mapping on OpenLDAP. I don't like > the sound of this approach as an engineered solution. Instead, work is > still progressing on OpenLDAP's ACL, and again it may be a backend issue > (thats were ACLs/transactions are implemented in OpenLDAP). A true > solution could be in kodama, in that kodama-specific API calls could be > used by a python-ldap to systems that can use kodama (more and more > development here). Alternatively, native ACL support would be used on > others. All of this decided from some config key in the LDAP server > itself. Yes, its one big hairy #ifdef. I'm babbling here simply on some > of that ideas thrown out about this. Suffice it to say that it won't be > easily solved, but that creating mature python-objects that contain the > solution will sufficiently hide these details from a higher level app > environment like Zope. And at the end of the day, that is all that > matters. Sorry, I can't figure out what exactly you're talking about. Most of us simply need the following: Authenticate a user by binding with the user entry's DN and a credential against an arbitrary LDAP server. How the LDAP server performs authentication (external or internal or whatever) is not of interest for your application (except having to provide the necessary credential data). E.g. strong authentication with client certs is handled via SASL. But again that's a special bind call. > As to StartTLS vs ldaps: in pam_ldap and nss_ldap, there is an issue > with configuration and compiled versions. Basically, you have > configuration files that point to an LDAP server with port, hostname, > etc. Pointing to port 636 for all traffic fails for LDAP v2 > configurations. ??? If you really take care of security I doubt that you want to leave use of SSL/TLS as option. Simply use a SSL wrapper (e.g. stunnel) running on that port you can mandate the use of LDAP over SSL even on non-SSL LDAP servers. > You will generally find that for large deployed > environments, you must support StartTLS and a configuration of port 389 > since multiple apps will key off the same "ldap seed" info and only a > percentage will be SSL-aware. Run the server on both ports... > Also, its always ugly when you have > distros/OSes (like Solaris!) that support LDAP v3 but have the SSL > libraries as optional installs that are configured at run-time by config > files, etc. Well, we're really getting off-topic. > In the end, StartTLS and port 389 is the way to go... See also for a discussion about RFC 2817: http://marc.theaimsgroup.com/?l=openssl-users&m=97733852307779&w=2 Ciao, Michael. From jlittle at open-it.org Wed May 9 18:52:13 2001 From: jlittle at open-it.org (Joe Little) Date: Wed, 9 May 2001 09:52:13 -0700 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available In-Reply-To: <3AF96F72.B709F8FD@stroeder.com> Message-ID: <200105091647.f49GlaG15291@kodama.stanford.edu> yeah.. regarding LDAP thread safety, etc.. Luke Howard and other people associated with Open-IT have had ideas about this, and thus the project "kodama" was born to fix issues with OpenLDAP, including referrals. Kodama has stagnated since the various qualified people are too busy and I'm not up to par to handle that bit. Some things can/will need to be done in python instead of the c-level api. As to vendor specific ACL's, etc., that is a decision that will be hard to make. One proposal would be ideal for Zope, bad for Python: Using zope-based ACL primitives (dare I call it that) to handle ACLs and then simple use SSL-certs (client and server) to authenticate. Kurt and others keep on saying that OpenLDAP should not be the authentication server, and we should rely upon 3rd party auth (Krb5, etc). The end result is have OpenLDAP use some external auth and some external ACL-mapping to layer upon basic ACL mapping on OpenLDAP. I don't like the sound of this approach as an engineered solution. Instead, work is still progressing on OpenLDAP's ACL, and again it may be a backend issue (thats were ACLs/transactions are implemented in OpenLDAP). A true solution could be in kodama, in that kodama-specific API calls could be used by a python-ldap to systems that can use kodama (more and more development here). Alternatively, native ACL support would be used on others. All of this decided from some config key in the LDAP server itself. Yes, its one big hairy #ifdef. I'm babbling here simply on some of that ideas thrown out about this. Suffice it to say that it won't be easily solved, but that creating mature python-objects that contain the solution will sufficiently hide these details from a higher level app environment like Zope. And at the end of the day, that is all that matters. As to StartTLS vs ldaps: in pam_ldap and nss_ldap, there is an issue with configuration and compiled versions. Basically, you have configuration files that point to an LDAP server with port, hostname, etc. Pointing to port 636 for all traffic fails for LDAP v2 configurations. You will generally find that for large deployed environments, you must support StartTLS and a configuration of port 389 since multiple apps will key off the same "ldap seed" info and only a percentage will be SSL-aware. Also, its always ugly when you have distros/OSes (like Solaris!) that support LDAP v3 but have the SSL libraries as optional installs that are configured at run-time by config files, etc. In the end, StartTLS and port 389 is the way to go... On Wednesday, May 9, 2001, at 09:25 AM, Michael Str?der wrote: > Joe Little wrote: >> >> I'm not complaining.. > > Joe, since you are really contributing code be assured that I did > not point to you. > >> we need specifically to support v3 schema, > > Could be done in higher-level Python modules. (Not trivial though.) > Not sure if you won't have to fiddle with BER-encoded data > (implementing syntax matching). > >> OpenLDAP v2 ACLs, > > Currently this whole ACL thing is vendor-specific => you would have > to write a specific module for each LDAP server. Finding a good > abstraction level would be required. See also "Access Control Model > for LDAP" on http://www.ietf.org/html.charters/ldapext-charter.html > for an attempt to define a standard. There's no need for a modified > C extension module. You could also implement this in Python. > >> StartTLS, > > Or LDAP over SSL (ldaps://..). IMHO STARTTLS is not widely > implemented up to now. > > Let me add two things. > > Thread-safety/reentrant: Would require to go with the Mozilla SDK or > use ldap_r of OpenLDAP 2.0.x (experimental, see my other posting > with Kurt's not about it). > > Proper handling of referrals / search continuations: Konstantin's > patch already provides this but there are sometimes strange LDAP > referral URLs returned. Might be a bug of the OpenLDAP 2.0.x libs. > > Ciao, Michael. > > From michael at stroeder.com Thu May 10 20:36:44 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 10 May 2001 20:36:44 +0200 Subject: web pages of python-ldap References: <3AFAB21D.339DCF29@stroeder.com> Message-ID: <3AFADFBC.EFE1D9D6@stroeder.com> Michael Str?der wrote: > > I would be willing to contribute a new version of the python-ldap > web pages. Any suggestions for a sparse "Pythonic" web design? Find a first draft of new web pages for python on-line: http://stroeder.com/python-ldap/ Please comment. Especially the "Binaries" section could need more detailed information of pre-built packages with links and maintainers. If you want your work related to python-ldap to be listed to the "Apps" section I'd be happy to add it. Preferrably write something like
Project title
Short description
Ciao, Michael. From michael at stroeder.com Fri May 11 01:35:25 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 11 May 2001 01:35:25 +0200 Subject: web pages of python-ldap References: Message-ID: <3AFB25BD.AEDE027C@stroeder.com> David Leonard wrote: > > > Michael Str?der wrote: > > > I would be willing to contribute a new version of the python-ldap > > > web pages. Any suggestions for a sparse "Pythonic" web design? > > i don't mind sparseness. i use the w3m text browser :) Bah, what a bloat browser with support for tables! Real men use lynx. ;-} > > Find a first draft of new web pages for python on-line: > > http://stroeder.com/python-ldap/ > > did you use php? No, I hope they support SSI (server-side includes). > if you commit to the htdocs part of the python-ldap CVS tree, the > sourceforge web server should automatically update the "live" copy > either immediately, or within 30 mins.. Good to now. Shall I remove the other things? > > Please comment. Especially the "Binaries" section could need more > > detailed information of pre-built packages with links and > > maintainers. > > downloads/binaries should have mini-toc to the platforms. > don't forget the platform architecture (x86, sparc etc). > not everyone has PCs :) Hmm, I'm not sure if I want to maintain a very detailed overview of binaries. Off course the RPMs should contain arch. BTW: Did you have a look on how to use the compile farm on SourceForge? > a first question for the faq should be "Is python-ldap abandon-ware?" :) And the answer: "Jump on in!" Ciao, Michael. From david.leonard at csee.uq.edu.au Fri May 11 00:47:01 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Fri, 11 May 2001 08:47:01 +1000 (EST) Subject: web pages of python-ldap In-Reply-To: <3AFADFBC.EFE1D9D6@stroeder.com> Message-ID: > Michael Str?der wrote: > > I would be willing to contribute a new version of the python-ldap > > web pages. Any suggestions for a sparse "Pythonic" web design? i don't mind sparseness. i use the w3m text browser :) > Find a first draft of new web pages for python on-line: > http://stroeder.com/python-ldap/ did you use php? if you commit to the htdocs part of the python-ldap CVS tree, the sourceforge web server should automatically update the "live" copy either immediately, or within 30 mins.. > Please comment. Especially the "Binaries" section could need more > detailed information of pre-built packages with links and > maintainers. downloads/binaries should have mini-toc to the platforms. don't forget the platform architecture (x86, sparc etc). not everyone has PCs :) a first question for the faq should be "Is python-ldap abandon-ware?" :) > If you want your work related to python-ldap to be listed to the > "Apps" section I'd be happy to add it. an apps section is a good idea. that was something certainly missing d -- David Leonard David.Leonard at dstc.edu.au CRC For Distributed Systems Technology Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 EERROR - Erroneous error. Nothing wrong. From michael at stroeder.com Fri May 11 03:20:45 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 11 May 2001 03:20:45 +0200 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available References: <200105082317.f48NHdG10729@kodama.stanford.edu> <3AF91BDE.8D878014@stroeder.com> Message-ID: <3AFB3E6D.19475273@stroeder.com> Michael Str?der wrote: > > Unfortunately the LDAP C SDKs diverged [..] Read more about differences of LDAP C SDKs on http://www.OpenLDAP.org/lists/openldap-software/200003/msg00082.html Ciao, Michael. From michael at stroeder.com Fri May 11 19:31:21 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 11 May 2001 19:31:21 +0200 Subject: LDAP options with OpenLDAP 2.0 (was: ANNC and query: ldapmodule-1.10a3-patched RPMs available) References: <200105082317.f48NHdG10729@kodama.stanford.edu> Message-ID: <3AFC21E9.871F085D@stroeder.com> Joe Little wrote: > > So, I put together python-ldap RPMs/SRPMs for redhat 6.2 and 7.0 to go > with my OpenLDAP 2.0.x RPMs on open-it.org. these include the patches > spoken of before to support OpenLDAP 2.x. Note that those patches might break some python-ldap applications (e.g. web2ldap). Setting LDAP options seems to be different with OpenLDAP 2.0. If I remember correctly Konstantin's patch addresses setting options by making available LDAPObject attributes "referrals" and "restart". Ciao, Michael. From michael at stroeder.com Sat May 12 14:29:31 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sat, 12 May 2001 14:29:31 +0200 Subject: distutils References: Message-ID: <3AFD2CAB.7221FCB7@stroeder.com> David Leonard wrote: > > i plan to > * move towards just supporting OpenLDAP 2, and > * delete all the gnu autoconf gunk How about thread-safety only possible with Mozilla SDK? Hmm, I thought of the following: SWIG modules for every LDAP C SDK out there which should not be directly used by an application. The SWIG modules should wrap *all* functions provided by a C SDK. Python LDAPObject class as an abstraction layer which hides the SWIG-ed functions of the C SDK providing an API compatible to recent python-ldap. For each underlying C SDK there should be a specific implementation class. Now the SWIG folks could start wrapping the OpenLDAP 1.2.x, 2.0.x and Mozilla C SDK without having to provide a nice Python API and I promise to write Python wrapper classes compatible to recent python-ldap. This is just an quick idea. Let me know what you all think. Ciao, Michael. From david.leonard at csee.uq.edu.au Sat May 12 14:04:25 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Sat, 12 May 2001 22:04:25 +1000 (EST) Subject: distutils Message-ID: fellas, I have committed two files (setup.py and setup.cfg) into CVS. this is because I want to use Python's distutils package for distributing future python-ldap modules. distutils should make it easier to build binary distributions that do the right thing when installing. much less hassle to build releases. (people who add new stuff to CVS may also have to edit setup.py now!) So, to build python-ldap in the new way, simply type python setup.py build You may need to edit setup.cfg first. Full documentation for distutils is on the python web site. fortunately, (or unfortunately depending on how you look at it) there is no support in distutils for autodetecting features about the ldap library. i plan to * move towards just supporting OpenLDAP 2, and * delete all the gnu autoconf gunk If someone wants to support mozilla's or solaris' library etc they should speak up now and be willing to help add support. (email me now!) for this contingency, I have created rough, manual descriptions of what #defines etc to enable when OpenLDAP2 is selected. By default, openldap is selected in setup.cfg, which is a file that looks like this: [_ldap] class = OpenLDAP2 perhaps in the future, python programs will be able to check what library is being used by doing something with it; e.g.: if _ldap.libclass == "OpenLDAP2": do_something_openldap_specific() your comments? d -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 Why are apartments so close together? From donal.hunt2 at mail.dcu.ie Sat May 12 11:25:55 2001 From: donal.hunt2 at mail.dcu.ie (donal.hunt2 at mail.dcu.ie) Date: Sat, 12 May 2001 10:25:55 +0100 Subject: =?iso-8859-1?Q?python=2Dldap=20and=20openldap=202=2E07?= Message-ID: <3AF98EEB00001C67@hawk.dcu.ie> I'm fairly new to this list but came across the python-ldap module while searching for components for a project I'm doing. Basically I'm writing some code for the Mailman mailing list software, so that it can do authentication, subscription, etc by LDAP. Have the authentication working after some initial playing with the python-ldap module, but I can't for the life of me modify any values in the ldap directory. Having read some of the previous discussion on this list (ANNC and query: ldapmodule-1.10a3-patched RPMs available), it looks like the problem I'm having is to do with OpenLDAP and it's ACLs. Am i correct in thinking this??? If so, am i correct in thinking there is a "patch" to solve the problem or should i look at what other modules or APIs that allow python to use the LDAP protocol? I'm using: RedHat 6.2, OpenLDAP 2.07, BeOpen-Python-2.0 and python-ldap-1.10alpha3. Thanks Donal Hunt *I may just be just making errors in my code, but i'm nearly sure i'm not* the line of code i'm using: res = l.modify_s(user_dn, [(MOD_REPLACE, 'userPassword', [new_pw])]) where: user_dn = cn=huntd2,ou=RedGiant,o=DCU new_pw = newpw is there a way to get the LDAP error codes back from the python-ldap module?? From michael at stroeder.com Sat May 12 12:24:47 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sat, 12 May 2001 12:24:47 +0200 Subject: python-ldap and openldap 2.07 References: <3AF98EEB00001C67@hawk.dcu.ie> Message-ID: <3AFD0F6F.2A6A37A8@stroeder.com> donal.hunt2 at mail.dcu.ie wrote: > > Basically I'm writing some code for the Mailman mailing list software, so > that it can do authentication, subscription, etc by LDAP. Have the authentication > working after some initial playing with the python-ldap module, but I can't > for the life of me modify any values in the ldap directory. > > Having read some of the previous discussion on this list (ANNC and query: > ldapmodule-1.10a3-patched RPMs available), it looks like the problem I'm > having is to do with OpenLDAP and it's ACLs. Am i correct in thinking this??? I don't think so. Do the following: 1. Remove all ACLs in your slapd.conf for testing your Python code to make sure you don't have wrong ACLs. Off course do this on a test machine! 2. Run your OpenLDAP server with ACLs in place with verbose logging. > If so, am i correct in thinking there is a "patch" to solve the problem No. ACLs with OpenLDAP 1 and 2 are configured in slapd.conf. This has nothing to do with python-ldap. Take questions related to ACL configuration with OpenLDAP to openldap-software at openldap.org list. > *I may just be just making errors in my code, but i'm nearly sure i'm not* > the line of code i'm using: > res = l.modify_s(user_dn, [(MOD_REPLACE, 'userPassword', [new_pw])]) > where: > user_dn = cn=huntd2,ou=RedGiant,o=DCU ^ ^ Forgot the quotes? > new_pw = newpw ??? Feel free to dig into web2ldap's module w2lpasswd... > is there a way to get the LDAP error codes back from the python-ldap module?? In case of an error an exception is raise. See http://python-ldap.sourceforge.net/doc/lib/subsec:exceptfrommeth.html Ciao, Michael. From jlittle at open-it.org Sat May 12 22:39:30 2001 From: jlittle at open-it.org (Joe Little) Date: Sat, 12 May 2001 13:39:30 -0700 (PDT) Subject: distutils In-Reply-To: <3AFD2CAB.7221FCB7@stroeder.com> Message-ID: I've been conversing with sasha at free.de, who has a rough cut python-ldap swig module done. He has had it work against Netscape, OpenLDAP, etc. to various extents (you can build out separate modules for each SDK). Maybe we can finish that work and thus allow for what you ask.. Especially if you are willing to finish off the python-ldap api stuff :) On Sat, 12 May 2001, Michael Str?der wrote: > David Leonard wrote: > > > > i plan to > > * move towards just supporting OpenLDAP 2, and > > * delete all the gnu autoconf gunk > > How about thread-safety only possible with Mozilla SDK? > > Hmm, I thought of the following: > > SWIG modules for every LDAP C SDK out there which should not be > directly used by an application. The SWIG modules should wrap *all* > functions provided by a C SDK. > > Python LDAPObject class as an abstraction layer which hides the > SWIG-ed functions of the C SDK providing an API compatible to recent > python-ldap. For each underlying C SDK there should be a specific > implementation class. > > Now the SWIG folks could start wrapping the OpenLDAP 1.2.x, 2.0.x > and Mozilla C SDK without having to provide a nice Python API and I > promise to write Python wrapper classes compatible to recent > python-ldap. > > This is just an quick idea. Let me know what you all think. > > Ciao, Michael. > > From michael at stroeder.com Sat May 12 23:11:55 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sat, 12 May 2001 23:11:55 +0200 Subject: distutils References: Message-ID: <3AFDA71B.A971ADBE@stroeder.com> Joe Little wrote: > > I've been conversing with sasha at free.de, who has a rough cut > python-ldap swig module done. He has had it work against Netscape, > OpenLDAP, Sascha, please give us a status report which vendors/versions of LDAP C SDKs you wrapped with your SWIG approach and which functionality it has. Ciao, Michael. From sascha.gresk at opensource-consult.de Sun May 13 09:58:08 2001 From: sascha.gresk at opensource-consult.de (Sascha Gresk) Date: Sun, 13 May 2001 09:58:08 +0200 Subject: distutils In-Reply-To: <3AFDA71B.A971ADBE@stroeder.com> References: <3AFDA71B.A971ADBE@stroeder.com> Message-ID: <20010513095808.2d522b74.sascha.gresk@opensource-consult.de> On Sat, 12 May 2001 23:11:55 +0200 Michael Str?der wrote: > Joe Little wrote: > > > > I've been conversing with sasha at free.de, who has a rough cut > > python-ldap swig module done. He has had it work against Netscape, > > OpenLDAP, > Just openldap1.x. I have send a plan to jlittle at open-it.org, how swig-ldap-0.2 *could* look like. This plan didn't have much text going with it - I just thought its clear it couldnt match current swig-ldap, since no interface for netscape, sun or whatever is included. Sorry for not communicating clear enough. > Sascha, > > please give us a status report which vendors/versions of LDAP C SDKs > you wrapped with your SWIG approach and which functionality it has. > Nothing compared to python-ldap. Some basic stuff to handle some simple adding, searching and deletion of records. -- /* Yeah */ From jlittle at open-it.org Wed May 9 20:19:02 2001 From: jlittle at open-it.org (Joe Little) Date: Wed, 9 May 2001 11:19:02 -0700 Subject: ANNC and query: ldapmodule-1.10a3-patched RPMs available In-Reply-To: <3AF981EA.D5E41464@stroeder.com> Message-ID: <200105091814.f49IEPG15874@kodama.stanford.edu> I'll try to be a bit more concise... On Wednesday, May 9, 2001, at 10:44 AM, Michael Str?der wrote: > Joe Little wrote: >> >> regarding LDAP thread safety, etc.. Luke Howard and other people >> associated with Open-IT have had ideas about this, and thus the project >> "kodama" was born to fix issues with OpenLDAP, including referrals. > > Can you give us an URL of "kodama"? > Can you describe how they wanted to solve thread safety? (one of my > urgent requirements!) > Why to "fix issues with OpenLDAP" in a separate project and not as > direct contributions to OpenLDAP? (No offense, just curiousity.) > Here's a spew of URLs discussing ActiveDirectory on UNIX and how it would be built: http://openit.stanford.edu/access/article/_02/article.html (discuss item on old site) http://openit.stanford.edu/access/article/_00/article.html (same, more on OpenLDAP issues) http://kodama.open-it.org/pipermail/core-dev/2000-October/thread.html (this month was busy with lots-o-discussions) Our big presentation is http://kodama.open-it.org/roadmap/index.html this probably has the most concrete aspect of what kodama is. In the end, we had people in the OpenLDAP project, but there was a difference of opinion of what was "LDAP" the protocol and "LDAP" the server with the OpenLDAP folks. The solution to some issues would be a better backend for OpenLDAP than ldbm and perhaps increases features that may not be kosher for OpenLDAP now but could be directly used for our ActiveDirectory purposes through a straight API -- development use only and all that. >> Some things can/will need to be done in python instead of the c-level >> api. As to vendor specific ACL's, etc., that is a decision that will be >> hard to make. One proposal would be ideal for Zope, bad for Python: >> Using zope-based ACL primitives (dare I call it that) to handle ACLs >> and >> then simple use SSL-certs (client and server) to authenticate. > > I'm not sure about which ACLs and authentication you're talking. > Authorization schemes at your client/gateway side or at the LDAP > server side? I don't understand how Zope is involved at that level. It has its own interface for users, access, and such, and so one can mask LDAP link up simple LDAP ACLs and access (groups, and such) and form different access rules in Zope of possibly finer grain via abstraction... It would be zope specific, but would allow use to make a secure conduit from Zope to OpenLDAP and provide the most access via the web only through Zope. > > As I understand you specify ACLs on some LDAP servers by setting > operational attributes (e.g. attribute aci on Netscape server). Most > times this is done by a vendor-specific directory managing software. > > Do you plan to write an ACL managing software for OpenLDAP? AFAIK in > OpenLDAP ACLs are solely defined in the configuration file (see > http://www.openldap.org/doc/admin/slapdconfig.html#Access Control). > Therefore I don't see how python-ldap could be involved at all. > Part of Open-IT, "shiido" is designed to seed a directory server. Luke Howard has already be working on ldapprofile support (sun draft) and a few other things that would allow one to create the slapd.conf file. Thus, we'd get into the business of generating slapd.conf file ACLs, likely out of some schema def. > Anyway, for the upcoming I-D on LDAP ACLs it is interesting that > http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-07.txt > states in section ABSTRACT: "The current LDAP APIs are sufficient > for the access control operations." > >> Kurt and >> others keep on saying that OpenLDAP should not be the authentication >> server, and we should rely upon 3rd party auth (Krb5, etc). The end >> result is have OpenLDAP use some external auth and some external >> ACL-mapping to layer upon basic ACL mapping on OpenLDAP. I don't like >> the sound of this approach as an engineered solution. Instead, work is >> still progressing on OpenLDAP's ACL, and again it may be a backend >> issue >> (thats were ACLs/transactions are implemented in OpenLDAP). A true >> solution could be in kodama, in that kodama-specific API calls could be >> used by a python-ldap to systems that can use kodama (more and more >> development here). Alternatively, native ACL support would be used on >> others. All of this decided from some config key in the LDAP server >> itself. Yes, its one big hairy #ifdef. I'm babbling here simply on some >> of that ideas thrown out about this. Suffice it to say that it won't be >> easily solved, but that creating mature python-objects that contain the >> solution will sufficiently hide these details from a higher level app >> environment like Zope. And at the end of the day, that is all that >> matters. > > Sorry, I can't figure out what exactly you're talking about. > > Most of us simply need the following: Authenticate a user by binding > with the user entry's DN and a credential against an arbitrary LDAP > server. How the LDAP server performs authentication (external or > internal or whatever) is not of interest for your application > (except having to provide the necessary credential data). E.g. > strong authentication with client certs is handled via SASL. But > again that's a special bind call. > It is a problem when the application you are making is supposed to manage LDAP (data, configs, etc,), Samba-TNG, cyrus, etc.. We'd be mucking with the auth and stuff, and the app would likely even need to "de-auth, test, and re-auth" to the LDAP after executing a change. Most of this is outside the scope of the ldap-python specific module, but full support will need to be there to not duplicate code unnecessarily. >> As to StartTLS vs ldaps: in pam_ldap and nss_ldap, there is an issue >> with configuration and compiled versions. Basically, you have >> configuration files that point to an LDAP server with port, hostname, >> etc. Pointing to port 636 for all traffic fails for LDAP v2 >> configurations. > > ??? > > If you really take care of security I doubt that you want to leave > use of SSL/TLS as option. Simply use a SSL wrapper (e.g. stunnel) > running on that port you can > mandate the use of LDAP over SSL even on non-SSL LDAP servers. > when LDAP is used with configuration services, many implementations are v2 or v3, and the v3 are not necessarily SSL-enabled. I don't but the stunnel approach. It needs to use the protocol support path and not a wrapper. I can't easily get access to the firmware of a cisco DEN-enabled device to add stunnel to its LDAP queries :) >> You will generally find that for large deployed >> environments, you must support StartTLS and a configuration of port 389 >> since multiple apps will key off the same "ldap seed" info and only a >> percentage will be SSL-aware. > > Run the server on both ports... > Server is not the issue.. its the client config file. Most clients refer to one config file and accept only the first LDAP port value listed there. We can't rewrite ALL the ldap enabled-apps :) >> Also, its always ugly when you have >> distros/OSes (like Solaris!) that support LDAP v3 but have the SSL >> libraries as optional installs that are configured at run-time by >> config >> files, etc. > > Well, we're really getting off-topic. > >> In the end, StartTLS and port 389 is the way to go... > > See also for a discussion about RFC 2817: > http://marc.theaimsgroup.com/?l=openssl-users&m=97733852307779&w=2 > > Ciao, Michael. > > From michael at stroeder.com Mon May 14 12:28:23 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 14 May 2001 12:28:23 +0200 Subject: Completely async... References: <3ADC4D96.85F0182A@stroeder.com> Message-ID: <3AFFB347.E3CAC4E0@stroeder.com> Michael Str?der wrote: > > I wrote a drop-in replacement class for LDAPObject for locking calls > into the LDAP libs since these are not completely thread-safe I've added this module as python-ldap/Lib/ldapthreadlock.py to the CVS repository. See __doc__ string: """ ldapthreadlock.py - mimics LDAPObject class in a thread-safe way (c) by Michael Stroeder License: Do anything you want with this module. Compability: - The behaviour of the ldapthreadlock.LDAPObject class should be exactly the same like ldap.LDAPObject - This module needs your Python installation to be built with thread support (module threading is imported). Usage: You can simply use function open() of this module instead of function open() of module ldap to create an instance of LDAPObject class. Basically calls into the LDAP lib are serialized by the module-wide lock _ldapmodule_lock. To avoid blocking of other threads synchronous methods like search_s() etc. and the result() method were rewritten to do solely asynchronous LDAP lib calls with zero timeout. The timeout handling is done within the method result() which probably leads to less exact timing. """ Ciao, Michael. From david.leonard at csee.uq.edu.au Tue May 15 03:27:00 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Tue, 15 May 2001 11:27:00 +1000 (EST) Subject: -lpthread + -D_REENTRANT In-Reply-To: <3AFFD57C.A3B88F06@stroeder.com> Message-ID: On Mon, 14 May 2001, Michael Str?der typed thusly: > I'll raise this one again: > We should set gcc compiler option -D_REENTRANT aka -D_THREAD_SAFE > and linker option -lpthread in the autoconf script if Python was > built > --with-threads. > > Anybody capable of adding that to the autoconf stuff? if you're talking about setting these when building _ldap then, no, I don't think that's right. Different platforms have different ways of doing threads. The autoconf way currently uses the options and libraries that python itself was using when it was compiling its builtin modules, so you don't need any more or any less. _ldap does not use the platform thread api (and nor should it). there is (or should be) sufficient communication between _ldap and python about blockable points to make it work with and without threads. I am led to believe from the python documentation that that's the right way. so, python-ldap should link and work with threads as it stands now. the ldap libraries may not be thread safe, but that's another issue.. (but you've addressed that somewhat at the python level) d -- David Leonard David.Leonard at csee.uq.edu.au Dept of Comp. Sci. and Elec. Engg _ Room:78-640 Ph:+61 7 336 51187 The University of Queensland |+| http://www.csee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 Why are apartments so close together? From michael at stroeder.com Mon May 14 14:54:20 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 14 May 2001 14:54:20 +0200 Subject: -lpthread + -D_REENTRANT Message-ID: <3AFFD57C.A3B88F06@stroeder.com> HI! I'll raise this one again: We should set gcc compiler option -D_REENTRANT aka -D_THREAD_SAFE and linker option -lpthread in the autoconf script if Python was built --with-threads. Anybody capable of adding that to the autoconf stuff? Ciao, Michael. From michael at stroeder.com Mon May 14 16:44:09 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 14 May 2001 16:44:09 +0200 Subject: Compiling woes on Solaris Message-ID: <3AFFEF39.8B914AAC@stroeder.com> Since Brian did not re-post his question here I'll do it. Ciao, Michael. -------- Original Message -------- Subject: web2ldap feedback Date: Fri, 27 Apr 2001 14:18:14 -0700 From: Brian Doherty To: feedback at web2ldap.de [..] I have the Netscape SDK in /usr/local/mozilla and the openldap v2 in /usr/local. Neither worked, and the ./Misc/openldap.sh didn't either. I downloaded openldap 1.2.11 myself and installed it in /usr/local/openldap1. Then I tried to configure python-ldap with ./configure --with-ldap=/usr/local/openldap1 This configured OK, but the make failed with the following: make[1]: Entering directory `/usr/local/src/LDAP/Web/python-ldap-1.10alpha3/Modules' gcc -shared ./LDAPObject.o ./common.o ./constants.o ./errors.o ./functions.o ./ldapmodule.o ./message.o ./version.o ./linkedlist.o ./template.o ./CIDict.o -L/usr/local/openldap1/lib -lldap -llber -lsocket -lnsl -lm -o ./_ldapmodule.so Text relocation remains referenced against symbol offset in file 0x430 /usr/local/openldap1/lib/libldap.a(getfilter.o) 0x434 /usr/local/openldap1/lib/libldap.a(getfilter.o) 0x438 /usr/local/openldap1/lib/libldap.a(getfilter.o) ... (many many many more lines like this) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make[1]: *** [_ldapmodule.so] Error 1 make[1]: Leaving directory `/usr/local/src/LDAP/Web/python-ldap-1.10alpha3/Modules' make: *** [_ldapmodule-build] Error 2 From jlittle at open-it.org Tue May 15 03:33:51 2001 From: jlittle at open-it.org (Joe Little) Date: Mon, 14 May 2001 18:33:51 -0700 Subject: Compiling woes on Solaris In-Reply-To: <3AFFEF39.8B914AAC@stroeder.com> Message-ID: <200105150128.f4F1Sq629399@kodama.stanford.edu> My first stab at this is pathing.. Its not finding lber correctly since I think getfilter is in that. No? I'm also concerned that there are two ldap libraries on this. for instance, Solaris 8 already has a /usr/lib/libldap.so.4 provided. That is likely what is being linked in!!! On Monday, May 14, 2001, at 07:44 AM, Michael Str?der wrote: > Since Brian did not re-post his question here I'll do it. > > Ciao, Michael. > > -------- Original Message -------- > Subject: web2ldap feedback > Date: Fri, 27 Apr 2001 14:18:14 -0700 > From: Brian Doherty > To: feedback at web2ldap.de > > [..] > > I have the Netscape SDK in /usr/local/mozilla and the openldap v2 > in /usr/local. Neither worked, and the ./Misc/openldap.sh didn't > either. I downloaded openldap 1.2.11 myself and installed it in > /usr/local/openldap1. Then I tried to configure python-ldap with > ./configure --with-ldap=/usr/local/openldap1 > This configured OK, but the make failed with the following: > > make[1]: Entering directory > `/usr/local/src/LDAP/Web/python-ldap-1.10alpha3/Modules' > gcc -shared ./LDAPObject.o ./common.o ./constants.o ./errors.o > ./functions.o ./ldapmodule.o ./message.o ./version.o ./linkedlist.o > ./template.o ./CIDict.o -L/usr/local/openldap1/lib -lldap -llber > -lsocket -lnsl -lm -o ./_ldapmodule.so > Text relocation remains referenced > against symbol offset in file > 0x430 > /usr/local/openldap1/lib/libldap.a(getfilter.o) > 0x434 > /usr/local/openldap1/lib/libldap.a(getfilter.o) > 0x438 > /usr/local/openldap1/lib/libldap.a(getfilter.o) > > ... (many many many more lines like this) > > ld: fatal: relocations remain against allocatable but non-writable > sections > collect2: ld returned 1 exit status > make[1]: *** [_ldapmodule.so] Error 1 > make[1]: Leaving directory > `/usr/local/src/LDAP/Web/python-ldap-1.10alpha3/Modules' > make: *** [_ldapmodule-build] Error 2 > > From jens at digicool.com Sat May 12 15:44:24 2001 From: jens at digicool.com (Jens Vagelpohl) Date: Sat, 12 May 2001 09:44:24 -0400 Subject: python-ldap and openldap 2.07 In-Reply-To: <3AF98EEB00001C67@hawk.dcu.ie> Message-ID: donal, > Basically I'm writing some code for the Mailman mailing list software, so > that it can do authentication, subscription, etc by LDAP. Have the > authentication > working after some initial playing with the python-ldap module, but I can't > for the life of me modify any values in the ldap directory. i'm ctually very interested in having mailman get auth info from ldap myself. mind sharing your experiences / code? i haven't gotten to even looking at mailman yet, but it will be a requirement for all zope-related mailing lists real soon now. > *I may just be just making errors in my code, but i'm nearly sure i'm not* > the line of code i'm using: > res = l.modify_s(user_dn, [(MOD_REPLACE, 'userPassword', [new_pw])]) > where: > user_dn = cn=huntd2,ou=RedGiant,o=DCU > new_pw = newpw > > is there a way to get the LDAP error codes back from the python-ldap module?? take a look at the manage_editUserPassword method in the LDAPUserManager module here: http://cvs.dataflake.org/LDAPUserManager/LDAPUserManager.py?rev=1.27&content -type=text/vnd.viewcvs-markup the call to modify_s is wrapped in a try/except and if an exception occurs i catch it and feed it to a formatting routine so i can return it back to a web page. the code is pretty zope-specific, but you can see the pattern. jens From michael at stroeder.com Tue May 8 14:28:19 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 08 May 2001 14:28:19 +0200 Subject: Updated Lib/ldif.py References: Message-ID: <3AF7E663.E5598685@stroeder.com> Cc:-ed to python-ldap-dev list since it might be interesting for others... Michael Schwartz wrote: > > On Tue, 8 May 2001, Michael [iso-8859-1] Str?der wrote: > > > Ah, ldif.CreateLDIF() does not add the necessary empty line to > > separate entries. > > > That's great that you found the bug. There seem to be a misunderstanding. This is an intended and documented behaviour. I'm not sure why I left it out but there was some reason (probably for having the possibility to add comment lines with LDIF 1 format). See web2ldap's module w2lsearch.py on how to write LDIF. Here's the relevant excerpt. ------------------------ snip ------------------------ # async search initiated before... result_type,result_dnlist = ls.l.result(ldap_msgid,0) while result_dnlist: for dn,entry in result_dnlist: outf.write('%s\n' % ldif.CreateLDIF(dn,entry,w2lcore.ldap_binaryattrkeys)) result_type,result_dnlist = ls.l.result(ldap_msgid,0) ------------------------ snip ------------------------ Ciao, Michael. From michael at stroeder.com Thu May 24 15:34:02 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 24 May 2001 15:34:02 +0200 Subject: compilation error References: Message-ID: <3B0D0DCA.61CE698@stroeder.com> Joe Little wrote: > > you'll notice that 1.2.x will slowly be unsupported/unavailable. OpenLDAP 1.2.x is actively maintained. See the recent 1.2.12 release a couple of days ago. > If nothing else, the OpenLDAP 2.x patches should like become > proper to the source tree so that users can use any modern system. Unfortunately your patch for linking python-ldap against OpenLDAP 2.0.x breaks some existing python-ldap code (deref, alias options) without giving extra functionality. Look into Konstantin's patch which is a little bit more complete regarding LDAP options. We already had this discussion on-list and off-list several times. Up to now *nobody* raised his virtual hand saying "I will do it, maintain it for at least a couple of months and write documentation". David is not available for working on it at the moment. Although I personally don't like a SWIG approach I already made suggestions how I could contribute to a SWIG-based low-level LDAP API by writing a nice Python wrapper above it. This means I'm really willing to put my time into this. I'm still waiting for at least one serious response from the SWIG crowd saying "Yes, I will do it!". I had a short look at the swig-ldap code posted by Sascha but could not compile it on my box. The argument that OpenLDAP 2.x is more modern does not stand for its own. Solaris developers could argue that Solaris already ships with Netscape/Mozilla SDK which is quite incompatible to the OpenLDAP 2.x libs - but thread-safe. Which way to go? My question regarding which SDK to choose was not answered by anybody here yet. It was not even discussed at all! Just to show you one example how detailed problems are: Today I experienced that OpenLDAP 2.0.10 has a slightly different behaviour regarding referrals with Konstantin's python-ldap patches than OpenLDAP 2.0.7. If you actually don't have to deal with these kind of problems it's far less hassle to stick to the OpenLDAP 1.2.x libs until one of you really bites the bullet and does the heavy work. I repeat myself: A couple of patches will not fit the bill because otherwise people will complain that it's immature and unusable. Ciao, Michael. From peter.peltonen at fivetec.com Wed May 23 10:26:20 2001 From: peter.peltonen at fivetec.com (Peter Peltonen) Date: Wed, 23 May 2001 11:26:20 +0300 Subject: compilation error Message-ID: <3B0B742C.76459599@fivetec.com> I am trying to install web2ldap software which requires python-ldap version 1.8 or higher. The author of web2ldap provided me with the package python-ldap-CVS-20010510.tar.gz which I tried to install in my RH 7.1 system which has the following packages installed: --snip-- python2-2.1-4 (from python.org) python2-tkinter-2.1-4 python2-devel-2.1-4 python2-tools-2.1-4 python-2.0-14 (from rpmfind.net, built for ConnectivaLinux) python-devel-2.0-14 python-xmlrpc-1.4-1 (from RH7.1 CD) rpm-python-4.0.2-8 openldap-2.0.7-14 (from RH7.1 CD) openldap-servers-2.0.7-14 openldap-clients-2.0.7-14 openldap-devel-2.0.7-14 openldap12-1.2.11-4 krbafs-1.0.5-1 (from RH7.1 CD) pam_krb5-1.31-1 krb5-libs-1.2.2-5 (from RH7.1 Updates) krb5-workstation-1.2.2-5 krb5-devel-1.2.2-5 krb5-server-1.2.2-5 --snip-- I configured python-ldap: --snip-- [root at jolo python-ldap]# ./configure --with-ldap-lib=/usr/lib --with-ldap-inc=/usr/include --with-python=/usr/bin/python2.1 --with-kerberos --with-kerberos-lib=/usr/kerberos/lib --snip-- And then tried to run make: --snip-- [root at jolo python-ldap]# make cd Modules && make srcdir=/usr/src/python-ldap/Modules VPATH=/usr/src/python-ldap/Modules make[1]: Entering directory `/usr/src/python-ldap/Modules' gcc -fPIC -g -O2 -Wall -Wstrict-prototypes -I/usr/include/python2.1 -I/usr/include/python2.1 -DHAVE_CONFIG_H -I. -DLDAP_REFERRALS -I/usr/include -c /usr/src/python-ldap/Modules/./constants.c -o ./constants.o /usr/src/python-ldap/Modules/./constants.c: In function `LDAPinit_constants': /usr/src/python-ldap/Modules/./constants.c:69: `LDAP_MAX_ATTR_LEN' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:69: (Each undeclared identifier is reported only once /usr/src/python-ldap/Modules/./constants.c:69: for each function it appears in.) /usr/src/python-ldap/Modules/./constants.c:82: `LDAP_REQ_UNBIND_30' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:83: `LDAP_REQ_DELETE_30' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:84: `LDAP_REQ_ABANDON_30' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:109: `LDAP_AUTH_SIMPLE_30' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:110: `LDAP_AUTH_KRBV41_30' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:111: `LDAP_AUTH_KRBV42_30' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:121: `LDAP_FILTER_PRESENT_30' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:125: `LDAP_SUBSTRING_INITIAL_30' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:126: `LDAP_SUBSTRING_ANY_30' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:127: `LDAP_SUBSTRING_FINAL_30' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:138: `LDAP_DEFAULT_REFHOPLIMIT' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:164: `LDAP_URL_ERR_NOTLDAP' undeclared (first use in this function) /usr/src/python-ldap/Modules/./constants.c:165: `LDAP_URL_ERR_NODN' undeclared (first use in this function) make[1]: *** [constants.o] Error 1 make[1]: Leaving directory `/usr/src/python-ldap/Modules' make: *** [_ldapmodule-build] Error 2 --snip-- I get the same error if I try to recompile the .src.rpm found at http://www.webideal.de/ldap/. Any help appreciated, Peter From michael at stroeder.com Wed May 23 10:59:58 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 23 May 2001 10:59:58 +0200 Subject: compilation error References: <3B0B742C.76459599@fivetec.com> Message-ID: <3B0B7C0E.F05AFC38@stroeder.com> Peter Peltonen wrote: > > openldap-devel-2.0.7-14 > openldap12-1.2.11-4 I'd suggest that you try to grab OpenLDAP 1.2.12 sources and compile them yourself in a local directory for making sure that the OpenLDAP libs are not mixed up: In directory openldap-1.2.12/ invoke: ./configure make depend make Then go to the python-ldap source directory: ./configure --prefix=/usr --with-python=/usr/bin/python2.1 --with-ldap-lib=/home/michael/src/openldap-1.2.12/libraries --with-ldap-inc=/home/michael/src/openldap-1.2.12/include make make install > krbafs-1.0.5-1 (from RH7.1 CD) > pam_krb5-1.31-1 > krb5-libs-1.2.2-5 (from RH7.1 Updates) > krb5-workstation-1.2.2-5 > krb5-devel-1.2.2-5 > krb5-server-1.2.2-5 Note: web2ldap is not Kerberos-aware yet. Ciao, Michael. From jlittle at open-it.org Wed May 23 20:00:00 2001 From: jlittle at open-it.org (Joe Little) Date: Wed, 23 May 2001 11:00:00 -0700 (PDT) Subject: compilation error In-Reply-To: <3B0B7C0E.F05AFC38@stroeder.com> Message-ID: you'll notice that 1.2.x will slowly be unsupported/unavailable. If nothing else, the OpenLDAP 2.x patches should like become proper to the source tree so that users can use any modern system. Also, there is a bug in my packages that I just noticed. The makefile for python-ldap does not explicitly install _ldapmodule.so in the python path, so an RPM actually doesn't see it (alternative build root). I've made a new RPM but I'm stuck on a lousy windows box for my net connection at the moment. Happily, I have Zope working with python-ldap as of this morning. My current solution to the above problem is to install _ldapmodule.so into /usr/lib/py*/site-packages alogn with ldap.pth. This way, packagers will get it with "make DESTDIR=ALTROOT/blah/blah" -Joe On Wed, 23 May 2001, Michael Str?der wrote: > Peter Peltonen wrote: > > > > openldap-devel-2.0.7-14 > > openldap12-1.2.11-4 > > I'd suggest that you try to grab OpenLDAP 1.2.12 sources and compile > them yourself in a local directory for making sure that the OpenLDAP > libs are not mixed up: > > In directory openldap-1.2.12/ invoke: > ./configure > make depend > make > > Then go to the python-ldap source directory: > > ./configure --prefix=/usr --with-python=/usr/bin/python2.1 > --with-ldap-lib=/home/michael/src/openldap-1.2.12/libraries > --with-ldap-inc=/home/michael/src/openldap-1.2.12/include > make > make install > > > krbafs-1.0.5-1 (from RH7.1 CD) > > pam_krb5-1.31-1 > > krb5-libs-1.2.2-5 (from RH7.1 Updates) > > krb5-workstation-1.2.2-5 > > krb5-devel-1.2.2-5 > > krb5-server-1.2.2-5 > > Note: web2ldap is not Kerberos-aware yet. > > Ciao, Michael. > > From michael at stroeder.com Fri May 25 02:34:08 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 25 May 2001 02:34:08 +0200 Subject: compilation error References: Message-ID: <3B0DA880.6B715AC0@stroeder.com> David Leonard wrote: > > mmmm, release... everyone is eager to do an interim release. > I think 1.10 could be "released" by just renaming 1.10a3 to 1.10 :) No! That's not right. Review the CVS logs! There were patches after 1.10a3 adressing proper handling of (error) results of ldap_result (also by Konstantin) which slightly changes the result returned by LDAPObject.result() method in case of no result received. (Uuuh, did anybody of you understand this sentence? ;-) AFAIK also another memory leak was fixed (if you didn't loose the patch... ;-). > 1.11 can also appear soon. it just needs a little more removing of > non-openldapisms testing and then packaging. No! Just leave it as it is. Please, please... Call it 1.11 to avoid confusion because *it is* significantly different from 1.10a3. But it's stable. Ciao, Michael. From jlittle at open-it.org Thu May 24 21:59:19 2001 From: jlittle at open-it.org (Joe Little) Date: Thu, 24 May 2001 12:59:19 -0700 (PDT) Subject: compilation error In-Reply-To: <3B0D0DCA.61CE698@stroeder.com> Message-ID: BTW -- can anyone post to the list the most recent patches (Konstanin's) I'll grab them soon. I'll be connected to the net every other day for a bit, and the connection is so slow.. no web surfeing for me. As to the message, you have valid points. From my standpoint, the problems require further research, so any reply would be less than adequate at this stage.. On Thu, 24 May 2001, Michael Str?der wrote: > Joe Little wrote: > > > > you'll notice that 1.2.x will slowly be unsupported/unavailable. > > OpenLDAP 1.2.x is actively maintained. See the recent 1.2.12 release > a couple of days ago. > > > If nothing else, the OpenLDAP 2.x patches should like become > > proper to the source tree so that users can use any modern system. > > Unfortunately your patch for linking python-ldap against OpenLDAP > 2.0.x breaks some existing python-ldap code (deref, alias options) > without giving extra functionality. Look into Konstantin's patch > which is a little bit more complete regarding LDAP options. > > We already had this discussion on-list and off-list several > times. Up to now *nobody* raised his virtual hand saying "I will do > it, maintain it for at least a couple of months and write > documentation". David is not available for working on it at the > moment. > > Although I personally don't like a SWIG approach I already made > suggestions how I could contribute to a SWIG-based low-level LDAP > API by writing a nice Python wrapper above it. This means I'm really > willing to put my time into this. I'm still waiting for at least one > serious response from the SWIG crowd saying "Yes, I will do it!". I > had a short look at the swig-ldap code posted by Sascha but could > not compile it on my box. > > The argument that OpenLDAP 2.x is more modern does not stand for its > own. > Solaris developers could argue that Solaris already ships with > Netscape/Mozilla SDK which is quite incompatible to the OpenLDAP 2.x > libs - but thread-safe. Which way to go? My question regarding which > SDK to choose was not answered by anybody here yet. It was not even > discussed at all! > > Just to show you one example how detailed problems are: > Today I experienced that OpenLDAP 2.0.10 has a slightly different > behaviour regarding referrals with Konstantin's python-ldap patches > than OpenLDAP 2.0.7. If you actually don't have to deal with these > kind of problems it's far less hassle to stick to the OpenLDAP 1.2.x > libs until one of you really bites the bullet and does the heavy > work. > > I repeat myself: A couple of patches will not fit the bill because > otherwise people will complain that it's immature and unusable. > > Ciao, Michael. > > From david.leonard at csee.uq.edu.au Thu May 24 23:27:46 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Fri, 25 May 2001 07:27:46 +1000 (EST) Subject: compilation error In-Reply-To: Message-ID: On Thu, 24 May 2001, Joe Little typed thusly: > BTW -- can anyone post to the list the most recent patches (Konstanin's) shame on you! ;) go to the python-ldap web page, click on mailing list archive, type 'konstantin patch' in the search field... and the first result is: http://www.geocrawler.com/archives/3/1568/2000/11/0/4676963/ d -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 I put my chin on my knee, and looked for flaws in the soft grain of my beige plastic monitor casing. - Julian Assange From jlittle at open-it.org Fri May 25 01:47:21 2001 From: jlittle at open-it.org (Joe Little) Date: Thu, 24 May 2001 16:47:21 -0700 (PDT) Subject: compilation error In-Reply-To: Message-ID: Does anyone out there have original copies of these? The mailing list softwre did a good munge job on it. For instance, in the errors.c patch it has a nonsensical: +#if defined(LDAP_API_VERSION) + if (ldap_get_option(l, LDAP_OPT_MATCHED_DN, &matched) >= 0 + && matched != NULL) { + if (*matched != `f, name ); +#endif /* defined(LDAP_API_VERSION) */ } /* set attribute */ @@ -1798,7 +1865,12 @@ static int setattr( LDAPObject* self, char* name, PyObject* value ) { +#if defined(LDAP_API_VERSION) First, `f, name doesn't work. Second, I found out that the file being edited was actually LDAPObject.c and not errors.c at that point. A whole segment is thus missing and a 4th file should be in the MMIME encode. The message is offically screwed :) To quickly answer your last message, the package did not use the setup.py component. I'm using hte non-CVS version of 1.10a3. Should ther be another "release" this stage just to seperate things? Maybe a4 or b1? On Fri, 25 May 2001, David Leonard wrote: > On Thu, 24 May 2001, Joe Little typed thusly: > > > BTW -- can anyone post to the list the most recent patches (Konstanin's) > > shame on you! ;) go to the python-ldap web page, click on mailing list archive, > type 'konstantin patch' in the search field... and the first result is: > > http://www.geocrawler.com/archives/3/1568/2000/11/0/4676963/ > > d > From michael at stroeder.com Fri May 25 02:26:33 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Fri, 25 May 2001 02:26:33 +0200 Subject: compilation error References: Message-ID: <3B0DA6B9.11813715@stroeder.com> Joe Little wrote: > > Does anyone out there have original copies of these? The mailing list > softwre did a good munge job on it. I've attached a tar.gz containing the diffs. > To quickly answer your last message, the package did not use the setup.py > component. I'm using hte non-CVS version of 1.10a3. Should ther be another > "release" this stage just to seperate things? Maybe a4 or b1? Yes. I'd also suggest to make a 1.11 release before doing anything else. The CVS version without any OpenLDAP 2.0.x related stuff works pretty well. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: konstantins-openldap2-patches.tar.gz Type: application/x-gzip Size: 4309 bytes Desc: not available URL: From david.leonard at csee.uq.edu.au Fri May 25 02:10:27 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Fri, 25 May 2001 10:10:27 +1000 (EST) Subject: compilation error In-Reply-To: Message-ID: On Thu, 24 May 2001, Joe Little typed thusly: > Does anyone out there have original copies of these? The mailing list > softwre did a good munge job on it. choose the 'Print' option at the top of the web page. you'll get a 'raw' version of the message which you can save to a file, or pipe straight into patch if you're keen. > To quickly answer your last message, the package did not use the setup.py > component. I'm using hte non-CVS version of 1.10a3. Should ther be another > "release" this stage just to seperate things? Maybe a4 or b1? mmmm, release... everyone is eager to do an interim release. I think 1.10 could be "released" by just renaming 1.10a3 to 1.10 :) 1.11 can also appear soon. it just needs a little more removing of non-openldapisms testing and then packaging. d -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 I put my chin on my knee, and looked for flaws in the soft grain of my beige plastic monitor casing. - Julian Assange From jlittle at open-it.org Thu May 24 22:29:40 2001 From: jlittle at open-it.org (Joe Little) Date: Thu, 24 May 2001 13:29:40 -0700 (PDT) Subject: new Python-LDAP RPMs Message-ID: I've posted new RPMS (and source RPMS) for redhat 7.1 of python-ldap. This addresses a lack of functionality (missing a library), but does not change the patch used. I'll await final details on what is the best patch and hope to apply those soon. Time will tell what is the best solution to supporting ldapv3 From michael at stroeder.com Mon May 28 20:30:57 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 28 May 2001 20:30:57 +0200 Subject: latest ldap.i References: Message-ID: <3B129961.7B55ECFA@stroeder.com> Joe Little wrote: > > I've sent this to Sascha. It now contains the extended LDAP v3 API, with > only the netscape quasi-specific v3 extensions (server side sorts, and > other server or client side ops) > > build against Mozilla and openldap 2.x, but I need to check the openldap > 2.x again for some things. Still working.. I tried to compile it against Netscape/Mozilla LDAP C SDK 5.0 (binaries from Sun's web site downloaded today). After some tweaking of the Makefile (see attachment) it was built. But during import of ldapc it chokes with: Traceback (most recent call last): File "tests/ldapsearch.py", line 9, in ? import ldap File "/home/michael/src/swig-ldap-0.17-stable-13/ldap.py", line 2, in ? import ldapc ImportError: undefined symbol: lber_debug Tried this again with OpenLDAP 2.0.11 libs. Same result. Ciao, Michael. -------------- next part -------------- INCLUDEFLAGS =-I/usr/include/python2.1 INCLUDEFLAGS+=-I/usr/local/include INCLUDEFLAGS+=-I/home/michael/src/ldapcsdk50/include LIBFLAGS=-L/usr/local/lib -L/usr/lib -L/home/michael/src/ldapcsdk50/lib #DMALLOC_LIB=-ldmalloc LIBS=-llber50 -lldap50 ${DMALLOC_LIB} LINK=./link CFLAGS=-g -DSWIG_LDAP_DEBUG -DVERSION=${SWIG_LDAP_VERSION} INSTALLDIR=/usr/local/etc/MB/bin all: ldapcmodule.so lbermodule.so ldap_wrap.c: version.h ldap.i swig -python -shadow ldap.i ldap_wrap.o: ldap_wrap.c gcc $(CFLAGS) -c ldap_wrap.c $(INCLUDEFLAGS) ldapcmodule.so: ldap_wrap.o `$(LINK)` ldap_wrap.o $(LIBFLAGS) $(LIBS) -o ldapcmodule.so lber_wrap.c: version.h lber.i swig -python -shadow lber.i lber_wrap.o: lber_wrap.c gcc $(CFLAGS) -c lber_wrap.c $(INCLUDEFLAGS) lbermodule.so: lber_wrap.o `$(LINK)` lber_wrap.o $(LIBFLAGS) $(LIBS) -o lbermodule.so test: all (cd tests;make) shutdown: (cd tests;make shutdown) clean: rm -rf *.*\~ ldap_wrap.doc lber_wrap.doc lber_wrap.c ldap_wrap.c *\~ \#*\# *.o *.so *.pyc *.core (cd tests;make clean) setup: (cd tools;./setup.sh) install: setup ldapcmodule.so ldap.py lbermodule.so cp -p ldapcmodule.so lbermodule.so ldap.py lber.py ${INSTALLDIR} header: setup ldap_wrap.c lber_wrap.c ./tools/make.header tar: clean header (cd ..; tar cvzf swig-ldap-`cat swig-ldap/VERSION`.tgz swig-ldap) From jlittle at open-it.org Sat May 26 18:16:20 2001 From: jlittle at open-it.org (Joe Little) Date: Sat, 26 May 2001 09:16:20 -0700 (PDT) Subject: konstantin's patches now in RPM In-Reply-To: Message-ID: I've place my python-ldap-*-3 RPMs (i386 and src) for RedHat 7.1 on Open-IT.org. Yes, they now include the full patches in all their glory. Enjoy. Remember, these are built against python 1.5.2 On Fri, 25 May 2001, Joe Little wrote: > included are ldap/lber swig files (uses swig 1.3a5 or whatever the latest > snapshot is..). They _compile_ against both OpenLDAP 2.0.x and mozilla > ldap sdk 5.0. They only match Sascha's current swig files and do not as > yet address other API needs. It is a work in progress, but I wnated to > post it. You can grap Sasha's swig-ldap package and replace the > ldap/lber.i files (remember to erase *_swap.c!) and then "make" it. > > On Fri, 25 May 2001, Michael Str?der wrote: > > > Joe Little wrote: > > > > > > I do understand that openldap 1.x is being maintained by OpenLDAP, but the > > > distribution sets no longer maintain such. Thus any software created with > > > the hope for inclusion in a distro (like my management software ideas) > > > need to be on the current build set. > > > > I disagree. E.g. recent S.u.S.E. Linux 7.1 ships with both libs and > > python-ldap 1.10a3. I think Red Hat does also. Not sure about > > Debian. > > > > Believe me I have exactly the same problems with 1st-level-support > > for web2ldap. > > > > > I'll need to look further into the 2.x thread-safe issues. It would appear > > > from various notes/code that OpenLDAP 2.0.7 and beyond is now thread-safe. > > > > No, it isn't. > > > > > I saw your message from before. Is there anything more current that > > > confirms/refutes that? > > > > This message by Kurt Zeilenga was at the time 2.0.7 was already out. > > Please re-read it. Note that there are still significant changes > > with the OpenLDAP 2.0.x releases. You can't stick to 2.0.7 (2.0.11 > > was released yesterday). > > > > Regarding re-entrant LDAP libs Kurt mentioned ldap_r which provides > > sort of a re-entrant lib but not without taking special care in the > > LDAP application's C code. It might be a solution to wrap this into > > a low-level API and write a thread-safe wrapper class around it. > > > > > I also DLed the newly minted ldapsdk5.0 for mozilla, and will work on the > > > SWIG stuff there. > > > > According to various messages by Kurt Zeilenga and others this is > > the only thread-safe LDAP lib. > > > > -------- Original Message -------- > > Subject: Re: [ldap] LDAP C SDK's thread-safe? > > Date: Tue, 08 May 2001 09:08:29 -0400 > > From: mcs at netscape.com (Mark C Smith) > > Organization: iPlanet E-Commerce Solutions > > To: michael at stroeder.com > > > > Just found this in my overflowing inbox... the Netscape/Mozilla SDK > > is > > multithread safe, although in older versions you must write and > > install > > some callback functions to allow for safe sharing of one LDAP * > > session > > handle among multiple threads. This is documented. > > > > -Mark > > ----------------------------------- > > > > > The OpenLDAP 2.x include files give swig indigestion. My > > > current approach to this whole mess is the get a passable swig module for > > > some LDAP v3 library working, and then work with python-ldap (ie you?) to > > > build toward a stable solution. > > > > Feel free to send me code for testing. Please mention the SWIG > > version it requires. I have currently installed swig-1.3a5. > > > > > Once we have a working v3 backend to > > > python-ldap, it will be easier to code for the differences in each SDK. > > > This is why I DLed the mozilla one, since it was one you felt was most > > > complete. If we can move on that, we have something to work with. > > > > I'd suggest to write low-level SWIG-wrappers around each LDAP C SDK > > and write a nice Python class API for common use above it. So you > > don't have to deal with the dirty details at the C level. Just wrap > > 1:1 *everything* in libldap and libber and let me do the > > higher-level abstraction. > > > > > At the same time, I'll be using the current python-ldap w/ openldap 2.x > > > patches to work on the ZopeLDAP adaptor and that code. I hope to get the > > > sdk bit done this weekend, and devote a good week to the Zope code. > > > > I'm pretty sure Jens will catch up quickly and modify the ZopeLDAP > > stuff if there's a new usable API. Leave that part up to him. > > > > > That is where I stand, and I hope its agreeable to you. My hand is > > > "raised" on the maintenance issue, I am still just unsure of how best to > > > tackle the problem. > > > > Since you are able to produce the SWIG wrapper code simply stick to > > that. Leave the Python part to me and the Zope part to Jens. Is that > > clear enough? > > > > Ciao, Michael. > > > From jlittle at open-it.org Sat May 26 05:18:53 2001 From: jlittle at open-it.org (Joe Little) Date: Fri, 25 May 2001 20:18:53 -0700 (PDT) Subject: other things In-Reply-To: <3B0E7381.BD7EE1FD@stroeder.com> Message-ID: included are ldap/lber swig files (uses swig 1.3a5 or whatever the latest snapshot is..). They _compile_ against both OpenLDAP 2.0.x and mozilla ldap sdk 5.0. They only match Sascha's current swig files and do not as yet address other API needs. It is a work in progress, but I wnated to post it. You can grap Sasha's swig-ldap package and replace the ldap/lber.i files (remember to erase *_swap.c!) and then "make" it. On Fri, 25 May 2001, Michael Str?der wrote: > Joe Little wrote: > > > > I do understand that openldap 1.x is being maintained by OpenLDAP, but the > > distribution sets no longer maintain such. Thus any software created with > > the hope for inclusion in a distro (like my management software ideas) > > need to be on the current build set. > > I disagree. E.g. recent S.u.S.E. Linux 7.1 ships with both libs and > python-ldap 1.10a3. I think Red Hat does also. Not sure about > Debian. > > Believe me I have exactly the same problems with 1st-level-support > for web2ldap. > > > I'll need to look further into the 2.x thread-safe issues. It would appear > > from various notes/code that OpenLDAP 2.0.7 and beyond is now thread-safe. > > No, it isn't. > > > I saw your message from before. Is there anything more current that > > confirms/refutes that? > > This message by Kurt Zeilenga was at the time 2.0.7 was already out. > Please re-read it. Note that there are still significant changes > with the OpenLDAP 2.0.x releases. You can't stick to 2.0.7 (2.0.11 > was released yesterday). > > Regarding re-entrant LDAP libs Kurt mentioned ldap_r which provides > sort of a re-entrant lib but not without taking special care in the > LDAP application's C code. It might be a solution to wrap this into > a low-level API and write a thread-safe wrapper class around it. > > > I also DLed the newly minted ldapsdk5.0 for mozilla, and will work on the > > SWIG stuff there. > > According to various messages by Kurt Zeilenga and others this is > the only thread-safe LDAP lib. > > -------- Original Message -------- > Subject: Re: [ldap] LDAP C SDK's thread-safe? > Date: Tue, 08 May 2001 09:08:29 -0400 > From: mcs at netscape.com (Mark C Smith) > Organization: iPlanet E-Commerce Solutions > To: michael at stroeder.com > > Just found this in my overflowing inbox... the Netscape/Mozilla SDK > is > multithread safe, although in older versions you must write and > install > some callback functions to allow for safe sharing of one LDAP * > session > handle among multiple threads. This is documented. > > -Mark > ----------------------------------- > > > The OpenLDAP 2.x include files give swig indigestion. My > > current approach to this whole mess is the get a passable swig module for > > some LDAP v3 library working, and then work with python-ldap (ie you?) to > > build toward a stable solution. > > Feel free to send me code for testing. Please mention the SWIG > version it requires. I have currently installed swig-1.3a5. > > > Once we have a working v3 backend to > > python-ldap, it will be easier to code for the differences in each SDK. > > This is why I DLed the mozilla one, since it was one you felt was most > > complete. If we can move on that, we have something to work with. > > I'd suggest to write low-level SWIG-wrappers around each LDAP C SDK > and write a nice Python class API for common use above it. So you > don't have to deal with the dirty details at the C level. Just wrap > 1:1 *everything* in libldap and libber and let me do the > higher-level abstraction. > > > At the same time, I'll be using the current python-ldap w/ openldap 2.x > > patches to work on the ZopeLDAP adaptor and that code. I hope to get the > > sdk bit done this weekend, and devote a good week to the Zope code. > > I'm pretty sure Jens will catch up quickly and modify the ZopeLDAP > stuff if there's a new usable API. Leave that part up to him. > > > That is where I stand, and I hope its agreeable to you. My hand is > > "raised" on the maintenance issue, I am still just unsure of how best to > > tackle the problem. > > Since you are able to produce the SWIG wrapper code simply stick to > that. Leave the Python part to me and the Zope part to Jens. Is that > clear enough? > > Ciao, Michael. > -------------- next part -------------- %module ldap %include lber.i %include pointer.i %include array.i %include typemaps.i %{ #include "/opt/ldapsdk/include/lber.h" #include "/opt/ldapsdk/include/ldap.h" #include "version.h" // #include %} %include "constants.h" %include "version.h" %inline %{ // global variables LDAPMessage *res; %} %typemap(python,out) char * { if ($source==NULL){ Py_INCREF(Py_None); $target = Py_None; } else { $target = PyString_FromString($source); } } %inline %{ static PyObject *version(){ return PyString_FromString(SWIG_LDAP_VERSION); } static PyObject *build_date(){ return PyString_FromString(SWIG_LDAP_BUILD_DATE); } %} %name(abandon) extern int ldap_abandon ( LDAP *ld, int msgid ); /* * in add.c: */ %name(add) extern int ldap_add ( LDAP *ld, const char *dn, LDAPMod **attrs ); %name(add_s) extern int ldap_add_s ( LDAP *ld, const char *dn, LDAPMod **attrs ); /* * in bind.c: */ %name(bind) extern int ldap_bind ( LDAP *ld, const char *who, const char *passwd, int authmethod ); %name(bind_s) extern int ldap_bind_s ( LDAP *ld, const char *who, const char *cred, int method ); /* * in sbind.c: */ %name(simple_bind) extern int ldap_simple_bind ( LDAP *ld, const char *who, const char *passwd ); %name(simple_bind_s) extern int ldap_simple_bind_s ( LDAP *ld, const char *who, const char *passwd ); /* * in cache.c */ //%name(enable_cache) extern int ldap_enable_cache ( LDAP *ld, long timeout, long maxmem ); //%name(disable_cache) extern void ldap_disable_cache ( LDAP *ld ); //%name(set_cache_options) extern void ldap_set_cache_options ( LDAP *ld, unsigned long opts ); //%name(destroy_cache) extern void ldap_destroy_cache ( LDAP *ld ); //%name(flush_cache) extern void ldap_flush_cache ( LDAP *ld ); //%name(uncache_entry) extern void ldap_uncache_entry ( LDAP *ld, char *dn ); //%name(uncache_request) extern void ldap_uncache_request ( LDAP *ld, int msgid ); /* * in compare.c: */ %name(compare) extern int ldap_compare ( LDAP *ld, const char *dn, const char *attr, const char *value ); %name(compare_s) extern int ldap_compare_s ( LDAP *ld, const char *dn, const char *attr, const char *value ); /* * in delete.c: */ %name(delete) extern int ldap_delete ( LDAP *ld, const char *dn ); %name(delete_s) extern int ldap_delete_s ( LDAP *ld, const char *dn ); /* * in error.c: */ %name(result2error) extern int ldap_result2error ( LDAP *ld, LDAPMessage *r, int freeit ); %name(err2string) extern char *ldap_err2string ( int err ); %name(perror) extern void ldap_perror ( LDAP *ld, const char *s ); /* * in modify.c: */ %name(modify) extern int ldap_modify ( LDAP *ld, const char *dn, LDAPMod **mods ); %name(modify_s) extern int ldap_modify_s ( LDAP *ld, const char *dn, LDAPMod **mods ); /* * in modrdn.c: */ %name(modrdn) extern int ldap_modrdn ( LDAP *ld, const char *dn, const char *newrdn ); %name(modrdn_s) extern int ldap_modrdn_s ( LDAP *ld, const char *dn, const char *newrdn ); %name(modrdn2) extern int ldap_modrdn2 ( LDAP *ld, const char *dn, const char *newrdn, int deleteoldrdn ); %name(modrdn2_s)extern int ldap_modrdn2_s ( LDAP *ld, const char *dn, const char *newrdn, int deleteoldrdn); /* * in open.c: */ %name(open) extern LDAP* ldap_open ( const char *host, int port ); %name(init) extern LDAP* ldap_init ( const char *defhost, int defport ); /* * in getentry.c: */ %name(first_entry) extern LDAPMessage *ldap_first_entry ( LDAP *ld, LDAPMessage *res ); %name(next_entry) extern LDAPMessage *ldap_next_entry ( LDAP *ld, LDAPMessage *res ); %name(count_entries) extern int ldap_count_entries ( LDAP *ld, LDAPMessage *res ); /* * in addentry.c */ %name(delete_result_entry) extern LDAPMessage *ldap_delete_result_entry ( LDAPMessage **list,LDAPMessage *e ); %name(add_result_entry) extern void ldap_add_result_entry ( LDAPMessage **list, LDAPMessage *e ); /* * in getdn.c */ %name(get_dn) extern char *ldap_get_dn ( LDAP *ld, LDAPMessage *entry ); %name(dn2ufn) extern char *ldap_dn2ufn ( const char *dn ); %name(explode_dn) extern char **ldap_explode_dn ( const char *dn, const int notypes ); %name(explode_dns) extern char **ldap_explode_dns ( const char *dn ); %name(is_dns_dn) extern int ldap_is_dns_dn ( const char *dn ); /* * in getattr.c */ %name(first_attribute) extern char *ldap_first_attribute ( LDAP *ld, LDAPMessage *entry, BerElement **berptr ); %name(next_attribute) extern char *ldap_next_attribute ( LDAP *ld, LDAPMessage *entry, BerElement *berptr ); %inline %{ BerElement ** makeBerElementPtrPtr(){ BerElement **ptrptr; ptrptr = PyMem_NEW(BerElement *,sizeof(BerElement*)); return (BerElement **)ptrptr; } BerElement * derefBerElementPtrPtr(BerElement **p){ return *p; } %} /* * in getvalues.c */ %name(get_values) extern char **ldap_get_values ( LDAP *ld, LDAPMessage *entry, const char *target ); %name(get_values_len) extern struct berval **ldap_get_values_len ( LDAP *ld, LDAPMessage *entry,const char *target ); %name(count_values) extern int ldap_count_values ( char **vals ); %name(count_values_len) extern int ldap_count_values_len ( struct berval **vals ); %name(value_free) extern void ldap_value_free ( char **vals ); %name(value_free_len) extern void ldap_value_free_len ( struct berval **vals ); /* * in result.c: */ %name(result) extern int ldap_result ( LDAP *ld, int msgid, int all, struct timeval *timeout, LDAPMessage **result ); %name(msgfree) extern int ldap_msgfree (LDAPMessage *res); //%name(msgdelete) extern int ldap_msgdelete ( LDAP *ld, int msgid ); /* * in search.c: */ %name(search) extern int ldap_search ( LDAP *ld, const char *base, int scope, const char *filter, char **attrs, int attrsonly ); %name(search_s) extern int ldap_search_s ( LDAP *ld, const char *base, int scope, const char *filter, char **attrs, int attrsonly, LDAPMessage **res ); %inline %{ LDAPMessage ** makeLDAPMessagePtrPtr(){ return (LDAPMessage **)&res; } LDAPMessage * derefLDAPMessagePtrPtr(LDAPMessage **p){ return *p; } %} /* * in ufn.c */ /* * in unbind.c */ %name(unbind) extern int ldap_unbind ( LDAP *ld ); %name(unbind_s) extern int ldap_unbind_s ( LDAP *ld ); /* * in getfilter.c */ %name(init_getfilter) extern LDAPFiltDesc *ldap_init_getfilter ( char *fname ); %name(init_getfilter_buf) extern LDAPFiltDesc *ldap_init_getfilter_buf ( char *buf, long buflen ); %name(getfirstfilter) extern LDAPFiltInfo *ldap_getfirstfilter ( LDAPFiltDesc *lfdp, char *tagpat,char *value ); %name(getnextfilter) extern LDAPFiltInfo *ldap_getnextfilter ( LDAPFiltDesc *lfdp ); %name(setfilteraffixes) extern void ldap_setfilteraffixes ( LDAPFiltDesc *lfdp, char *prefix, char *suffix ); %name(build_filter) extern void ldap_build_filter ( char *buf, unsigned long buflen,char *pattern, char *prefix, char *suffix, char *attr,char *value, char **valwords ); /* * in free.c */ %name(getfilter_free) extern void ldap_getfilter_free ( LDAPFiltDesc *lfdp ); %name(mods_free) extern void ldap_mods_free ( LDAPMod **mods, int freemods ); /* * in friendly.c */ %name(friendly_name) extern char *ldap_friendly_name ( char *filename, char *uname, FriendlyMap *map ); %name(free_friendlymap) extern void ldap_free_friendlymap ( FriendlyMap *map ); /* * in url.c */ %name(is_ldap_url) extern int ldap_is_ldap_url ( const char *url ); %name(url_parse) extern int ldap_url_parse ( const char *url, LDAPURLDesc **ludpp ); %name(free_urldesc) extern void ldap_free_urldesc ( LDAPURLDesc *ludp ); %name(url_search) extern int ldap_url_search ( LDAP *ld, const char *url, int attrsonly ); %name(url_search_s) extern int ldap_url_search_s ( LDAP *ld, const char *url, int attrsonly, LDAPMessage **res ); %name(url_search_st) extern int ldap_url_search_st ( LDAP *ld, const char *url, int attrsonly, struct timeval *timeout, LDAPMessage **res ); /* * in msdos/winsock/wsa.c * * void ldap_memfree ( void *p ); */ -------------- next part -------------- %module lber %{ #include "/opt/ldapsdk/include/lber.h" %} extern int lber_debug; /* * in bprint.c: */ extern void lber_bprint ( char *data, int len ); /* * in decode.c: */ extern unsigned long ber_get_tag ( BerElement *ber ); extern unsigned long ber_skip_tag ( BerElement *ber, unsigned long *len ); extern unsigned long ber_peek_tag ( BerElement *ber, unsigned long *len ); extern unsigned long ber_get_int ( BerElement *ber, long *num ); extern unsigned long ber_get_stringb ( BerElement *ber, char *buf, unsigned long *len ); extern unsigned long ber_get_stringa ( BerElement *ber, char **buf ); extern unsigned long ber_get_stringal ( BerElement *ber, struct berval **bv ); extern unsigned long ber_get_bitstringa ( BerElement *ber, char **buf, unsigned long *len ); extern unsigned long ber_get_null ( BerElement *ber ); extern unsigned long ber_get_boolean ( BerElement *ber, int *boolval ); extern unsigned long ber_first_element ( BerElement *ber, unsigned long *len, char **last ); extern unsigned long ber_next_element ( BerElement *ber, unsigned long *len, char *last ); /* Variable length arguments not supported - sascha at free.de extern unsigned long ber_scanf ( BerElement *ber, char *fmt, ... ); */ extern void ber_bvfree ( struct berval *bv ); extern void ber_bvecfree ( struct berval **bv ); extern struct berval *ber_bvdup ( const struct berval *bv ); /* not yet extern void ber_set_string_translators ( BerElement *ber, BERTranslateProc encode_proc, BERTranslateProc decode_proc ); */ /* * in encode.c */ extern int ber_put_enum ( BerElement *ber, long num, unsigned long tag ); extern int ber_put_int ( BerElement *ber, long num, unsigned long tag ); extern int ber_put_ostring ( BerElement *ber, char *str, unsigned long len, unsigned long tag ); extern int ber_put_string ( BerElement *ber, char *str, unsigned long tag ); extern int ber_put_bitstring ( BerElement *ber, char *str, unsigned long bitlen, unsigned long tag ); extern int ber_put_null ( BerElement *ber, unsigned long tag ); extern int ber_put_boolean ( BerElement *ber, int boolval, unsigned long tag ); extern int ber_start_seq ( BerElement *ber, unsigned long tag ); extern int ber_start_set ( BerElement *ber, unsigned long tag ); extern int ber_put_seq ( BerElement *ber ); extern int ber_put_set ( BerElement *ber ); /* Variable length arguments not supported - sascha at free.de extern int ber_printf ( BerElement *ber, char *fmt, ... ); */ /* * in io.c: */ extern long ber_read ( BerElement *ber, char *buf, unsigned long len ); extern long ber_write ( BerElement *ber, char *buf, unsigned long len, int nosos ); extern void ber_free ( BerElement *ber, int freebuf ); extern int ber_flush ( Sockbuf *sb, BerElement *ber, int freeit ); extern BerElement *ber_alloc ( void ); extern BerElement *der_alloc ( void ); extern BerElement *ber_alloc_t ( int options ); extern BerElement *ber_dup ( BerElement *ber ); extern void ber_dump ( BerElement *ber, int inout ); //extern void ber_sos_dump ( Seqorset *sos ); extern unsigned long ber_get_next ( Sockbuf *sb, unsigned long *len, BerElement *ber ); extern BerElement *ber_init ( const struct berval *bv ); extern void ber_reset ( BerElement *ber, int was_writing ); From jlittle at open-it.org Tue May 29 17:45:47 2001 From: jlittle at open-it.org (Joe Little) Date: Tue, 29 May 2001 08:45:47 -0700 (PDT) Subject: latest ldap.i In-Reply-To: <3B129961.7B55ECFA@stroeder.com> Message-ID: I'll need to look into the lber libs and their build mechanism. On Mon, 28 May 2001, Michael Str?der wrote: > Joe Little wrote: > > > > I've sent this to Sascha. It now contains the extended LDAP v3 API, with > > only the netscape quasi-specific v3 extensions (server side sorts, and > > other server or client side ops) > > > > build against Mozilla and openldap 2.x, but I need to check the openldap > > 2.x again for some things. Still working.. > > I tried to compile it against Netscape/Mozilla LDAP C SDK 5.0 > (binaries from Sun's web site downloaded today). After some tweaking > of the Makefile (see attachment) it was built. > > But during import of ldapc it chokes with: > > Traceback (most recent call last): > File "tests/ldapsearch.py", line 9, in ? > import ldap > File "/home/michael/src/swig-ldap-0.17-stable-13/ldap.py", line 2, > in ? > import ldapc > ImportError: undefined symbol: lber_debug > > Tried this again with OpenLDAP 2.0.11 libs. Same result. > > Ciao, Michael. From jlittle at open-it.org Wed May 30 04:30:23 2001 From: jlittle at open-it.org (Joe Little) Date: Tue, 29 May 2001 19:30:23 -0700 (PDT) Subject: latest ldap.i UPDATE! In-Reply-To: <3B129961.7B55ECFA@stroeder.com> Message-ID: Ok.. stuck on windows box for network access, but here's the deal. edit lber.i that I submitted, and comment out these function defs: lber_debug lber_pbrint ber_dump Next, edit Sascha's make file to explicitly include ldap50 and lber50 as your included libraries. Last, make sure /opt/ldapsdk/lib or wherever mozilla is in your LD_LIBRARY_PATH, and before any other ldap libs (like Oracle, OpenLDAP, or the like) I did a test ldapsearch with the test dir (its now ldap.open(host,port)!!) with the libraries and ldap.py/lber.py files present, and it all worked fine against my openldap 2.0.x server. Yeah Kudos to Michael for catching my not testing my latest lber.i file before submitting to the list :) On Mon, 28 May 2001, Michael Str?der wrote: > Joe Little wrote: > > > > I've sent this to Sascha. It now contains the extended LDAP v3 API, with > > only the netscape quasi-specific v3 extensions (server side sorts, and > > other server or client side ops) > > > > build against Mozilla and openldap 2.x, but I need to check the openldap > > 2.x again for some things. Still working.. > > I tried to compile it against Netscape/Mozilla LDAP C SDK 5.0 > (binaries from Sun's web site downloaded today). After some tweaking > of the Makefile (see attachment) it was built. > > But during import of ldapc it chokes with: > > Traceback (most recent call last): > File "tests/ldapsearch.py", line 9, in ? > import ldap > File "/home/michael/src/swig-ldap-0.17-stable-13/ldap.py", line 2, > in ? > import ldapc > ImportError: undefined symbol: lber_debug > > Tried this again with OpenLDAP 2.0.11 libs. Same result. > > Ciao, Michael. From michael at stroeder.com Wed May 30 14:51:17 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 30 May 2001 14:51:17 +0200 Subject: latest ldap.i UPDATE! References: Message-ID: <3B14ECC5.35DAA967@stroeder.com> HI! I've built the swig-ldap with Joe's ldap.i and lber.i. After modifications to lber.i import works now. But I still have some problems. Note: The module is built as ldapcmodule.so on my system. Python 2.1 (#8, Apr 20 2001, 19:22:23) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import ldapc >>> attrs=ldapc.string_array(1) >>> ldapc.string_set(attrs,0,'objectClass') 'objectClass' >>> l=ldapc.open('localhost',389) >>> resPtr=ldapc.makeLDAPMessagePtrPtr() >>> status=ldapc.search_s(l,'O=MICHAELS',ldapc.SCOPE_BASE, '(objectClass=*)',attrs,0,resPtr) Segmentation fault Am I doing something wrong? I have to admit that these kind of error messages endorse my prejudices about SWIG-produced modules... Ciao, Michael. From jlittle at open-it.org Wed May 30 20:29:25 2001 From: jlittle at open-it.org (Joe Little) Date: Wed, 30 May 2001 11:29:25 -0700 (PDT) Subject: latest ldap.i UPDATE! In-Reply-To: <3B14ECC5.35DAA967@stroeder.com> Message-ID: My only concern is your libraries. do an ldd on the ldapcmodule (there is also the lbermodule.so). Make sure it sees the same ldap libraries you built it with. I'd then use the test ldapsearch in Sacha's test directory (with the aforementioned changed in ldap.open instead of ldap.LDAP for opening a connection. On Wed, 30 May 2001, Michael Str?der wrote: > HI! > > I've built the swig-ldap with Joe's ldap.i and lber.i. After > modifications to lber.i import works now. But I still have some > problems. > > Note: The module is built as ldapcmodule.so on my system. > > Python 2.1 (#8, Apr 20 2001, 19:22:23) > [GCC 2.95.2 19991024 (release)] on linux2 > Type "copyright", "credits" or "license" for more information. > >>> import ldapc > >>> attrs=ldapc.string_array(1) > >>> ldapc.string_set(attrs,0,'objectClass') > 'objectClass' > >>> l=ldapc.open('localhost',389) > >>> resPtr=ldapc.makeLDAPMessagePtrPtr() > >>> status=ldapc.search_s(l,'O=MICHAELS',ldapc.SCOPE_BASE, > '(objectClass=*)',attrs,0,resPtr) > Segmentation fault > > Am I doing something wrong? > > I have to admit that these kind of error messages endorse my > prejudices about SWIG-produced modules... > > Ciao, Michael. > > From michael at stroeder.com Wed May 30 20:54:58 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 30 May 2001 20:54:58 +0200 Subject: latest ldap.i UPDATE! References: Message-ID: <3B154202.F3F6C144@stroeder.com> Joe Little wrote: > > My only concern is your libraries. do an ldd on the ldapcmodule (there is > also the lbermodule.so). Make sure it sees the same ldap libraries you > built it with. Off course I already did this every time. Seemed ok to me: > ldd ldapcmodule.so /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x40015000) libldap50.so => /home/michael/src/ldapcsdk50/lib/libldap50.so (0x40017000) libc.so.6 => /lib/libc.so.6 (0x40047000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > ldd lbermodule.so /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x4000a000) libldap50.so => /home/michael/src/ldapcsdk50/lib/libldap50.so (0x4000c000) libc.so.6 => /lib/libc.so.6 (0x4003c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > I'd then use the test ldapsearch in Sacha's test directory (with the > aforementioned changed in ldap.open instead of ldap.LDAP for opening a > connection. This did not work. I took a look at the source to figure out how it works and tried to track things down by typing the actions manually. Now please tell me what I did wrong in this transcript? It uses ldapc.open() to make the connection. That's definitely not problem. Maybe something's fishy with building "attrs"? Python 2.1 (#8, Apr 20 2001, 19:22:23) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import ldapc >>> attrs=ldapc.string_array(1) >>> ldapc.string_set(attrs,0,'objectClass') 'objectClass' >>> l=ldapc.open('localhost',389) >>> resPtr=ldapc.makeLDAPMessagePtrPtr() >>> status=ldapc.search_s(l,'O=MICHAELS',ldapc.SCOPE_BASE, '(objectClass=*)',attrs,0,resPtr) Segmentation fault Am I doing something wrong? Ciao, Michael. From f.glasner at feldmann-mg.com Fri Jun 1 20:53:23 2001 From: f.glasner at feldmann-mg.com (f.glasner at feldmann-mg.com) Date: Fri, 1 Jun 2001 20:53:23 +0200 Subject: Using set_rebind_proc(func) with a bound method Message-ID: Hi, currently I'm playing with python-ldap-1.10a3 on WinNT with ActivePython 2.1.0-210b. When dealing with LDAP referrals I tried to pass a bound method object to set_rebind_proc, but it failed with the exception "expected function or None". But there is no reason why this "callback" should only work with "normal" functions in Python. So I patched the sources in file LDAPObject.c and changed the function "l_ldap_set_rebind_proc": Now the very specific check "PyFunction_Check(func)" is replaced by "PyCallable_Check(func)". Passing bound methods now work. I dont know whether this also works for older versions of Python (and there is no check whether func is a unbound method object, but here is the diff: @@ -595,15 +595,18 @@ ldap_set_rebind_proc( self->ldap, NULL, 0); #else ldap_set_rebind_proc( self->ldap, NULL ); #endif + Py_XDECREF(rebind_callback_func); rebind_callback_func = NULL; rebind_callback_ld = NULL; Py_INCREF(Py_None); return Py_None; } - if ( PyFunction_Check(func) ) { + if ( PyCallable_Check(func) ) { + Py_XDECREF(rebind_callback_func); + Py_INCREF(func); rebind_callback_func = func; rebind_callback_ld = self; #ifdef LDAP_SET_REBIND_PROC_3ARGS ldap_set_rebind_proc( self->ldap, rebind_callback, 0); @@ -613,9 +616,9 @@ Py_INCREF(Py_None); return Py_None; } - PyErr_SetString( PyExc_TypeError, "expected function or None" ); + PyErr_SetString( PyExc_TypeError, "expected function, bound method or None" ); return NULL; } static char doc_set_rebind_proc[] = Regards, Franz From david.leonard at csee.uq.edu.au Sun Jun 3 06:15:52 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Sun, 3 Jun 2001 14:15:52 +1000 (EST) Subject: Using set_rebind_proc(func) with a bound method In-Reply-To: Message-ID: On Fri, 1 Jun 2001, f.glasner at feldmann-mg.com typed thusly: > But there is no reason why this "callback" should only work > with "normal" functions in Python. > - if ( PyFunction_Check(func) ) { > + if ( PyCallable_Check(func) ) { > > - PyErr_SetString( PyExc_TypeError, "expected function or None" ); > + PyErr_SetString( PyExc_TypeError, "expected function, bound method or None" ); you are absoluetly correct I will add this patch > + Py_XDECREF(rebind_callback_func); > + Py_INCREF(func); > + Py_XDECREF(rebind_callback_func); and this one after i look at it more carefully.. d -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 I put my chin on my knee, and looked for flaws in the soft grain of my beige plastic monitor casing. - Julian Assange From michael at stroeder.com Tue Jun 5 17:00:09 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 05 Jun 2001 17:00:09 +0200 Subject: Minor bug in ldif.py References: Message-ID: <3B1CF3F9.516C20F2@stroeder.com> David Leonard wrote: > > On Thu, 31 May 2001, Roger Moore typed thusly: > > > I just noticed a slight bug in ldif.py to do with the deletion of the > > object class list. The problem is that if you name the attribute > > 'objectClass' then the first attrs.remove() statement generates an > > exception and the second statement is not reached. > > [..] > i have committed a different fix. Since the whole object class thingy was just for writing the objectClass lines at the beginning of an entry I completely removed it. It causes nothing but grief... BTW: I made more modifications (__doc__ strings, more readable code, etc.). Ciao, Michael. From rwmoore at fnal.gov Fri Jun 1 01:15:39 2001 From: rwmoore at fnal.gov (Roger Moore) Date: Thu, 31 May 2001 18:15:39 -0500 (CDT) Subject: Minor bug in ldif.py In-Reply-To: Message-ID: Hi, I just noticed a slight bug in ldif.py to do with the deletion of the object class list. The problem is that if you name the attribute 'objectClass' then the first attrs.remove() statement generates an exception and the second statement is not reached. To fix this you can check for the key first. I've attached the patch to this email. As a very quick work around call the attribute 'objectclass'. Roger -------------- next part -------------- --- /usr/lib/python1.5/site-packages/python-ldap/ldif.py Sun Jul 30 07:27:51 2000 +++ ldif.py Thu May 31 18:10:53 2001 @@ -87,11 +87,10 @@ for oc in objectclasses: result.append('objectclass: %s\n' % oc) attrs = entry.keys()[:] - try: - attrs.remove('objectclass') - attrs.remove('objectClass') - except: - pass + if attrs.has_key('objectclass'): + attrs.remove('objectclass') + if attrs.has_key('objectClass'): + attrs.remove('objectClass') attrs.sort() for attr in attrs: if attr in binary_attrs: From david.leonard at csee.uq.edu.au Mon Jun 4 05:05:25 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Mon, 4 Jun 2001 13:05:25 +1000 (EST) Subject: Minor bug in ldif.py In-Reply-To: Message-ID: On Thu, 31 May 2001, Roger Moore typed thusly: > I just noticed a slight bug in ldif.py to do with the deletion of the > object class list. The problem is that if you name the attribute > 'objectClass' then the first attrs.remove() statement generates an > exception and the second statement is not reached. To fix this you can > check for the key first. I've attached the patch to this email. > > As a very quick work around call the attribute 'objectclass'. i have committed a different fix. michael, you should check that this is right. d ---------------------------- revision 1.3 date: 2001/06/04 03:05:26; author: leonard; state: Exp; lines: +6 -0 add RCS tag fix bug found by Roger Moore where objectclass attributes weren't always removed Index: ldif.py =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Lib/ldif.py,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ldif.py 2001/05/07 17:25:42 1.2 +++ ldif.py 2001/06/04 03:05:26 1.3 @@ -1,3 +1,6 @@ +# python +# $Id: ldif.py,v 1.3 2001/06/04 03:05:26 leonard Exp $ + """ ldif.py - Various routines for handling LDIF data @@ -81,6 +84,9 @@ attrs = entry.keys()[:] try: attrs.remove('objectclass') + except ValueError: + pass + try: attrs.remove('objectClass') except ValueError: pass -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 I put my chin on my knee, and looked for flaws in the soft grain of my beige plastic monitor casing. - Julian Assange From f.glasner at feldmann-mg.com Tue Jun 5 23:54:46 2001 From: f.glasner at feldmann-mg.com (f.glasner at feldmann-mg.com) Date: Tue, 5 Jun 2001 23:54:46 +0200 Subject: Using set_rebind_proc(func) with a bound method Message-ID: Hi, the problem is to check whether a callable object is either a function object or a *bound* method object. >> - if ( PyFunction_Check(func) ) { >> + if ( PyCallable_Check(func) ) { Maybe its better to check + if ( PyCallable_Check(func) ) { - if ( PyFunction_Check(func) || (PyCFunction_Check(func) && PyCFunction_GET_SELF(func)) ) { I havn't tested it and, again, I don't know whether it works on older Python versions before 2.1. Franz From david.leonard at csee.uq.edu.au Wed Jun 6 14:33:55 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Wed, 6 Jun 2001 22:33:55 +1000 (EST) Subject: Using set_rebind_proc(func) with a bound method In-Reply-To: Message-ID: On Tue, 5 Jun 2001, f.glasner at feldmann-mg.com typed thusly: > the problem is to check whether a callable object is either a function object > or a *bound* method object. just callable will do for now. passing an unbound method will still result in a runtime error when a rebind is needed... which I think is fine, since we can't completely check for all type errors there - we could end up falsly prohibiting or falsely allowing cases that we never thought of. good testing is still required, ie do coverage testing/analysis and find your type mistakes that way. d -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 I put my chin on my knee, and looked for flaws in the soft grain of my beige plastic monitor casing. - Julian Assange From david.leonard at csee.uq.edu.au Wed Jun 6 14:50:32 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Wed, 6 Jun 2001 22:50:32 +1000 (EST) Subject: Using set_rebind_proc(func) with a bound method In-Reply-To: Message-ID: Actually, I just realised that rebind_callback is incompatible with multiple LDAP objects. when rebind_callback() is called, it should look up the LDAP object based on LDAP*ld, and not use a global var rebind_callback_ld (although it does check that they're related).. unless there's a nice part of the LDAP structure I can stick a backreference to the python LDAPObject in, this could be done by having a global hash (dictionary) of LDAP pointers to LDAPObjects... has anyone experienced problems with multiple LDAP objects and rebinding? d -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 The entire history of the world is the triumph of the heartless over the mindless. - Sir Humphrey Appleby, Yes Minister. From david.leonard at csee.uq.edu.au Thu Jun 7 01:44:09 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Thu, 7 Jun 2001 09:44:09 +1000 (EST) Subject: unknown error In-Reply-To: Message-ID: Um, the whole point of LDAP_TYPE_IS_OPAQUE is that ld_errno is just not there. i.e. the C header files just don't mention ld_errno, and we can't guess where it is. However, I recall that there are other (non-standard) APIs to get to the error code.. something like ldap_get_error(LDAP *) which we could use. On Wed, 6 Jun 2001, David Margrave typed thusly: > > self.ldapconn.modify_s(self.dn, modlist) > ldap.LDAPError: unknown error (C API does not expose error) > > This was from the latest packaged release (1.10a3 i think) > > Maybe we could make the exception for unknown errors include the numeric > error code: > > #ifdef LDAP_TYPE_IS_OPAQUE > else { > PyErr_SetString(LDAPexception_class, > "unknown error (C API does not expose error > %d)", l->ld_errno); > > return NULL; > } > #else > > My $.02 -- David Leonard David.Leonard at dstc.edu.au CRC For Distributed Systems Technology Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 EERROR - Erroneous error. Nothing wrong. From davidma at eskimo.com Wed Jun 6 23:44:51 2001 From: davidma at eskimo.com (David Margrave) Date: Wed, 6 Jun 2001 14:44:51 -0700 (PDT) Subject: unknown error Message-ID: self.ldapconn.modify_s(self.dn, modlist) ldap.LDAPError: unknown error (C API does not expose error) This was from the latest packaged release (1.10a3 i think) Maybe we could make the exception for unknown errors include the numeric error code: #ifdef LDAP_TYPE_IS_OPAQUE else { PyErr_SetString(LDAPexception_class, "unknown error (C API does not expose error %d)", l->ld_errno); return NULL; } #else My $.02 Dave From michael at stroeder.com Thu Jun 7 00:14:22 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 07 Jun 2001 00:14:22 +0200 Subject: Building current CVS version Message-ID: <3B1EAB3E.6611275B@stroeder.com> HI! Was there a change in the configure script? Does the autoconf method still work? Ciao, Michael. From david.leonard at csee.uq.edu.au Thu Jun 7 01:40:42 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Thu, 7 Jun 2001 09:40:42 +1000 (EST) Subject: Bug in 3 day old commit of LDAPObject.c? In-Reply-To: <3B1E2C40.6EDFC285@dante.org.uk> Message-ID: On Wed, 6 Jun 2001, Konstantin Chuguev typed thusly: > It looks like the last CVS commit for LDAPObject.c (1.9 -> 1.10) has a > bug. It should be changed this way: > PY_XDECREF -> Py_XDECREF > PY_INCREF -> Py_INCREF revision 1.11 date: 2001/06/06 23:40:04; author: leonard; state: Exp; lines: +7 -7 PY->Py. Thanks, Konstantin. -- David Leonard David.Leonard at dstc.edu.au CRC For Distributed Systems Technology Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 EERROR - Erroneous error. Nothing wrong. From Konstantin.Chuguev at dante.org.uk Wed Jun 6 15:12:32 2001 From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev) Date: Wed, 06 Jun 2001 14:12:32 +0100 Subject: Bug in 3 day old commit of LDAPObject.c? Message-ID: <3B1E2C40.6EDFC285@dante.org.uk> Hi, It looks like the last CVS commit for LDAPObject.c (1.9 -> 1.10) has a bug. It should be changed this way: PY_XDECREF -> Py_XDECREF PY_INCREF -> Py_INCREF I'm not quite sure, but at least Python-2.1c2 has the right hand format macros in its installed header files, not those introduced in the commit. Maybe it worked fine in previous versions of Python? Regards, Konstantin. -- * * Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW: http://www.dante.net From michael at stroeder.com Thu Jun 7 16:23:05 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 07 Jun 2001 16:23:05 +0200 Subject: python-ldap builds against OpenLDAP 2.0.11 but not 1.2.12 Message-ID: <3B1F8E49.7463E671@stroeder.com> David, did you drop the support for builing python-ldap against OpenLDAP 1.2.x? Ciao, Michael. From david.leonard at csee.uq.edu.au Thu Jun 7 20:48:45 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Fri, 8 Jun 2001 04:48:45 +1000 (EST) Subject: python-ldap builds against OpenLDAP 2.0.11 but not 1.2.12 In-Reply-To: <3B1F8E49.7463E671@stroeder.com> Message-ID: On Thu, 7 Jun 2001, Michael Str?der typed thusly: > did you drop the support for builing python-ldap against OpenLDAP > 1.2.x? in my local tree, and for the future, yes.. but i havent committed anything into cvs about that though.. d -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 The entire history of the world is the triumph of the heartless over the mindless. - Sir Humphrey Appleby, Yes Minister. From michael at stroeder.com Thu Jun 7 20:55:57 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Thu, 07 Jun 2001 20:55:57 +0200 Subject: python-ldap builds against OpenLDAP 2.0.11 but not 1.2.12 References: Message-ID: <3B1FCE3C.B2EBE04B@stroeder.com> David Leonard wrote: > > On Thu, 7 Jun 2001, Michael Str?der typed thusly: > > > did you drop the support for builing python-ldap against OpenLDAP > > 1.2.x? > > in my local tree, and for the future, yes.. but i havent committed > anything into cvs about that though.. Are you sure you did not commit anything? The current CVS builds against OpenLDAP 2.0. Unfortunately this breaks some important code in web2ldap since I can't set options anymore. Can we first make a release which definitely can be built against OpenLDAP 1.2.12? I have troubles building python-ldap from CVS against 1.2.12. configure fails on ldap_open check. After making a cleanly working release there should be a CVS branch made instead of just silently dropping support for 1.2.x. Ciao, Michael. From dirk.meyer at dinoex.sub.org Fri Jun 8 08:09:36 2001 From: dirk.meyer at dinoex.sub.org (Dirk Meyer) Date: Fri, 08 Jun 2001 08:09:36 +0200 Subject: python-ldap builds against OpenLDAP 2.0.11 but not 1.2.12 References: <3B1FCE3C.B2EBE04B@stroeder.com> Message-ID: Michael Str?der wrote, > Are you sure you did not commit anything? The current CVS builds > against OpenLDAP 2.0. Unfortunately this breaks some important code > in web2ldap since I can't set options anymore. > > Can we first make a release which definitely can be built against > OpenLDAP 1.2.12? I have troubles building python-ldap from CVS > against 1.2.12. configure fails on ldap_open check. > > After making a cleanly working release there should be a CVS branch > made instead of just silently dropping support for 1.2.x. Please release more often ... I still can't update the package for FreeBSD as neither patch nor cvs compiles here. kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany From david.leonard at csee.uq.edu.au Tue Jun 12 15:38:32 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Tue, 12 Jun 2001 23:38:32 +1000 (EST) Subject: ldapmodule.so In-Reply-To: Message-ID: On Tue, 12 Jun 2001, Isabelle Moullet typed thusly: > >Try downloading a source code release (1.10alpha3 is okay) and building it > >in the same environment you want to run it. > I have in fact downloaded the source code release (1.10alpha3 ) and > installed it on my platform (Solaris 8 machine) following the README > instructions(configure, make, make install). Is there something I > should change in the Makefile to make it run ? maybe a patch like that below would help. because solaris might have ldap_init_templates() but not ldap_name2template(). if all else fails, undefine HAVE_LDAP_INIT_TEMPLATES in config.h and re-make all the .o files d Index: configure.in =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/configure.in,v retrieving revision 1.14 diff -u -r1.14 configure.in --- configure.in 2001/05/16 17:03:57 1.14 +++ configure.in 2001/06/12 13:17:49 @@ -207,7 +207,8 @@ AC_DEFINE(LDAP_TYPE_IS_OPAQUE) fi -AC_CHECK_FUNCS(ldap_modrdn2_s ldap_modrdn2 ldap_init_templates) +AC_CHECK_FUNCS(ldap_modrdn2_s ldap_modrdn2) +AC_CHECK_FUNCS(ldap_init_templates ldap_name2template) AC_CHECK_HEADERS(disptmpl.h) dnl Index: Modules/template.c =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Modules/template.c,v retrieving revision 1.9 diff -u -r1.9 template.c --- Modules/template.c 2001/05/12 08:08:39 1.9 +++ Modules/template.c 2001/06/12 13:18:07 @@ -235,6 +235,7 @@ return ret; } +#ifdef HAVE_LDAP_NAME2TEMPLATE /* retrieve a template by name */ static PyObject * Templates_name2template(self, args) @@ -257,6 +258,7 @@ static char Templates_name2template_doc[] = "name2template(name) -> template\n" "Do stuff."; +#endif /* HAVE_LDAP_NAME2TEMPLATE */ /* retrieve a template by objectClass */ static PyObject * @@ -307,8 +309,10 @@ "Do stuff."; static PyMethodDef Templates_methods[] = { +#ifdef HAVE_LDAP_NAME2TEMPLATE { "name2template", (PyCFunction)Templates_name2template, METH_VARARGS, Templates_name2template_doc }, +#endif /* HAVE_LDAP_NAME2TEMPLATE */ { "oc2template", (PyCFunction)Templates_oc2template, METH_VARARGS, Templates_oc2template_doc }, { NULL, NULL } -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 The entire history of the world is the triumph of the heartless over the mindless. - Sir Humphrey Appleby, Yes Minister. From david.leonard at csee.uq.edu.au Sun Jun 17 06:54:57 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Sun, 17 Jun 2001 14:54:57 +1000 (EST) Subject: compiling against OpenLDAP 2.0.11 In-Reply-To: <200106151529.LAA32322@ns2.digicool.com> Message-ID: On Fri, 15 Jun 2001, Jens Vagelpohl typed thusly: > can anyone confirm what the status is vis-a-vis OpenLDAP 2.x (or just 2.0. > 11)? the postings led me to believe that no extra patches were needed at > this point. if they are, can someone point them out? :) python-ldap 1.10a3 won't work with OpenLDAP 2.x unless you apply those patches that you refer to. (is that right?) the current status of the development tree seems to be: * removing autoconf, in favour of python's distutils (which is weaker at detecting what is there but slightly more configurable and supposedly easier to build distributions with) * supporting OpenLDAP 2.* (but dropping support for earlier versions) d -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 .signature: Invalid argument From jens at digicool.com Fri Jun 15 17:29:57 2001 From: jens at digicool.com (Jens Vagelpohl) Date: Fri, 15 Jun 2001 11:29:57 -0400 Subject: compiling against OpenLDAP 2.0.11 Message-ID: <200106151529.LAA32322@ns2.digicool.com> hi guys, a couple days ago there were some posts indicating that python-ldap does indeed build against 2.0.11. i just tried building a python-ldap head CVS checkout against 2.0.11 and it stops with the well-known... checking for library containing ber_free... -llber checking for library containing ldap_open... no checking for ldap_open... no configure: error: Couldn't find LDAP library can anyone confirm what the status is vis-a-vis OpenLDAP 2.x (or just 2.0. 11)? the postings led me to believe that no extra patches were needed at this point. if they are, can someone point them out? :) jens From jlittle at open-it.org Fri Jun 15 17:37:26 2001 From: jlittle at open-it.org (Joe Little) Date: Fri, 15 Jun 2001 08:37:26 -0700 Subject: compiling against OpenLDAP 2.0.11 In-Reply-To: <200106151529.LAA32322@ns2.digicool.com> Message-ID: <200106151531.f5FFVWp30746@kodama.stanford.edu> well, the patches are now a part of my RPM at open-it.org (Thanks to Michael and Konstantin). I haven't been able to get an unpatched version to compile either. David has his own tree which he indicated does compile against 2.x, but I am unsure if/when that may be added to the main tree. Some people like to stick w. 1.x for stability and completeness, others just want 2.0. :) Separately, email me directly. I've been playing around with ZopeLDAP and jshell hasn't answered back. Maybe you can clue me in to the status of all things LDAP in regards to Zope. (I'm most interested in documentation of current ZClass integration, etc) On Friday, June 15, 2001, at 08:29 AM, Jens Vagelpohl wrote: > hi guys, > > a couple days ago there were some posts indicating that python-ldap > does indeed build against 2.0.11. > > i just tried building a python-ldap head CVS checkout against 2.0.11 > and it stops with the well-known... > > > checking for library containing ber_free... -llber > checking for library containing ldap_open... no > checking for ldap_open... no > configure: error: Couldn't find LDAP library > > > can anyone confirm what the status is vis-a-vis OpenLDAP 2.x (or just > 2.0. > 11)? the postings led me to believe that no extra patches were needed > at this point. if they are, can someone point them out? :) > > jens > > From jens at digicool.com Fri Jun 15 17:52:45 2001 From: jens at digicool.com (Jens Vagelpohl) Date: Fri, 15 Jun 2001 11:52:45 -0400 Subject: compiling against OpenLDAP 2.0.11 In-Reply-To: <200106151531.f5FFVWp30746@kodama.stanford.edu> Message-ID: <200106151552.LAA01555@ns2.digicool.com> joe, > well, the patches are now a part of my RPM at open-it.org (Thanks to > Michael and Konstantin). I haven't been able to get an unpatched version > to compile either. David has his own tree which he indicated does compile > against 2.x, but I am unsure if/when that may be added to the main tree. > Some people like to stick w. 1.x for stability and completeness, others > just want 2.0. :) unfortunately, RPM is of no help to me. i am trying to set it up so i can do development work on the Zope LDAPLoginAdapter and LDAPUserManager on my OS X-based powerbook while i'm abroad. i would need patches for the source, i already got OpenLDAP 2.0.11 running successfully. and no, this is not a combo i would use for "production", it's just so i can work away from my development servers ;) > Separately, email me directly. I've been playing around with ZopeLDAP and > jshell hasn't answered back. Maybe you can clue me in to the status of > all things LDAP in regards to Zope. (I'm most interested in documentation > of current ZClass integration, etc) ZopeLDAP development has pretty much ended. jeffrey hasn't worked on it in a while and us unwilling (and has no time) to continue it. if i had time i would consider keeping it alive, but at this point i really don't. there is a couple other LDAP products for zope that i know of: - LDAPLoginAdapter: my own product. active development, will be combined with the LDAPUserManager into a single LDAPUserFolder product at some point - LDAPUserManager: my own product. active development, will be combined with the LDAPLoginAdapter into a single LDAPUserFolder at some point - LDAPAdapter: ross lazarus' and soren roug's LDAP-based user folder. i think development has pretty much ended. i do not know about any ZClass integration. i personally do not use ZClasses at all, only file system-based python products. jens From daniel at mastyx.de Sat Jun 16 02:16:27 2001 From: daniel at mastyx.de (Daniel Schlenzig) Date: Sat, 16 Jun 2001 02:16:27 +0200 Subject: compiling against OpenLDAP 2.0.11 In-Reply-To: <200106151529.LAA32322@ns2.digicool.com>; from jens@digicool.com on Fri, Jun 15, 2001 at 11:29:57AM -0400 References: <200106151529.LAA32322@ns2.digicool.com> Message-ID: <20010616021626.A26281@www.smash-designs.de> On Fri, Jun 15, 2001 at 11:29:57AM -0400, Jens Vagelpohl wrote: > a couple days ago there were some posts indicating that python-ldap does > indeed build against 2.0.11. > > i just tried building a python-ldap head CVS checkout against 2.0.11 and > it stops with the well-known... > > > checking for library containing ber_free... -llber > checking for library containing ldap_open... no > checking for ldap_open... no > configure: error: Couldn't find LDAP library > When I first tried to compile python-ldap it behaved exactly like this. Actually I do have a workaround, but it is not anchored in the autoconf scripts, so you have to do it by hand. --- cut from the logs --- I startet vi on configure, skipped to line 1403 and replaced LIBS="$ac_func_search_save_LIBS" with LIBS="$ac_func_search_save_LIBS -lldap -lresolv" After rerunning configure and make everything worked as it should. --- cut --- This should do. libldap.so is after that recognized as "not needed", but do not worry about, because it still links correctly. bye, Daniel From jlittle at open-it.org Sat Jun 16 02:25:32 2001 From: jlittle at open-it.org (Joe Little) Date: Fri, 15 Jun 2001 17:25:32 -0700 Subject: compiling against OpenLDAP 2.0.11 In-Reply-To: <20010616021626.A26281@www.smash-designs.de> Message-ID: <200106160019.f5G0Jbp16287@kodama.stanford.edu> I answered this to Jens.. The problem is with the inclusion of ssl silently into MacOSX builds of OpenLDAP. He had to rebuild OpenLDAP --without-tls or to add -lssl to that lines. second, its not a shared library, so you need to have _ldapmodule.so build with the libraries as objects (full path to libldap.a etc) On Friday, June 15, 2001, at 05:16 PM, Daniel Schlenzig wrote: > On Fri, Jun 15, 2001 at 11:29:57AM -0400, Jens Vagelpohl wrote: > >> a couple days ago there were some posts indicating that python-ldap >> does >> indeed build against 2.0.11. >> >> i just tried building a python-ldap head CVS checkout against 2.0.11 >> and >> it stops with the well-known... >> >> >> checking for library containing ber_free... -llber >> checking for library containing ldap_open... no >> checking for ldap_open... no >> configure: error: Couldn't find LDAP library >> > When I first tried to compile python-ldap it behaved exactly like this. > Actually I do have a workaround, but it is not anchored in the autoconf > scripts, so you have to do it by hand. > > --- cut from the logs --- > > I startet vi on configure, skipped to line 1403 and replaced > > LIBS="$ac_func_search_save_LIBS" > > with > > LIBS="$ac_func_search_save_LIBS -lldap -lresolv" > > After rerunning configure and make everything worked as it should. > > --- cut --- > > This should do. libldap.so is after that recognized as "not needed", but > do not worry about, because it still links correctly. > > bye, Daniel > > From david.leonard at csee.uq.edu.au Sun Jun 17 06:48:02 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Sun, 17 Jun 2001 14:48:02 +1000 (EST) Subject: core dump / Objects/dictobject.c:471: bad argument to internal function In-Reply-To: <992743577.3b2c10993916f@redivi.com> Message-ID: On Sat, 16 Jun 2001, (::) Bob Ippolito typed thusly: > I got it to work.. what I had to do was turn off CIDict.. like this in setup.py > > > ActivePython 2.1, build 210 > > SystemError: Objects/dictobject.c:471: bad argument to internal > > function > > Segmentation fault (core dumped) my lazily written CIDict module worked by copying the python dict type and then 'patching' it so that it lowercased its keys. Python (2.0?) seems to check that the objects being passed back are really dicts, and so thats why you get an internal error.. which leads later to a core dump. i've rewritten cidict to get rid of that ugly hack... the patch below indicates what i've done .. i haven't committed (or compiled) it yet because i am re-installing python2.1 on this machine at the moment. i just wanted to let you know that i'll try and get it tested and fixed today because its so awful. and if anyone wants to run their eye over it for memory leaks, please do :) d Index: functions.c =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Modules/functions.c,v retrieving revision 1.4 diff -u -r1.4 functions.c --- functions.c 2000/08/17 23:50:28 1.4 +++ functions.c 2001/06/17 04:39:31 @@ -10,6 +10,7 @@ #include "LDAPObject.h" #include "errors.h" #include "template.h" +#include "CIDict.h" /* ldap_open */ @@ -131,6 +132,16 @@ "\tThis function returns true if url `looks like' an LDAP URL\n" "\t(as opposed to some other kind of URL)."; +#if defined(USE_CIDICT) +static PyObject * +cidict(PyObject *unused, PyObject *args) +{ + if (!PyArg_NoArgs(args)) + return NULL; + return CIDict_New(); +} +#endif + /* methods */ static PyMethodDef methods[] = { @@ -146,6 +157,11 @@ { "init_templates", (PyCFunction)l_init_templates, METH_VARARGS, l_init_templates_doc }, #endif +#if defined(USE_CIDICT) + { "cidict", (PyCFunction)cidict, METH_VARARGS, + NULL }, +#endif + { NULL, NULL } }; Index: CIDict.c =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Modules/CIDict.c,v retrieving revision 1.4 diff -u -r1.4 CIDict.c --- CIDict.c 2001/05/12 08:08:39 1.4 +++ CIDict.c 2001/06/17 04:39:33 @@ -23,13 +23,18 @@ * XXX I forget whose idea this originally was, but its a good one. - d */ +typedef struct { + PyObject_HEAD + PyObject *dict; +} CIDictObject; + /* * Return a new object representing a lowercased version of the argument. * Typically this is a string -> string conversion. * Returns: New Reference */ static PyObject * -case_insensitive(PyObject *o) +lowercase(PyObject *o) { char *str, *cp; int len, i; @@ -55,74 +60,146 @@ return s; } -/* read-access the dictionary after lowercasing the subscript */ - static PyObject * -cid_subscript(PyObject *d, PyObject *k) +subscript(CIDictObject *self, PyObject *k) { PyObject *ret; PyObject *cik; - cik = case_insensitive(k); - ret = (*PyDict_Type.tp_as_mapping->mp_subscript)(d, cik); - Py_XDECREF(cik); + cik = lowercase(k); + if (cik == NULL) + return NULL; + ret = PyObject_GetItem(self->dict, cik); + Py_DECREF(cik); return ret; } + +static int +length(CIDictObject *self) +{ + return PyMapping_Length(self->dict); +} -/* write-access the dictionary after lowecasing the subscript */ static int -cid_ass_subscript(PyObject *d, PyObject *k, PyObject *v) +ass_subscript(CIDictObject *self, PyObject *k, PyObject *v) { int ret; PyObject *cik; - cik = case_insensitive(k); - ret = (*PyDict_Type.tp_as_mapping->mp_ass_subscript)(d, cik, v); - Py_XDECREF(cik); + cik = lowercase(k); + if (cik == NULL) + return -1; + ret = PyObject_SetItem(self->dict, cik, v); + Py_DECREF(cik); return ret; } -/* This type and mapping structure gets filled in from the PyDict structs */ - -static PyMappingMethods CIDict_mapping; -PyTypeObject CIDict_Type; +static void +dealloc(CIDictObject *self) +{ + Py_DECREF(self->dict); + PyMem_DEL(self); +} -/* Initialise the case-insensitive dictionary type */ +static int +print(CIDictObject *self, FILE *fp, int flags) +{ + return PyObject_Print(self->dict, fp, flags); +} -static void -CIDict_init() +PyObject * +getattr(CIDictObject *self, char *attr_name) +{ + return PyObject_GetAttr(self->dict, attr_name); +} + +static int +compare(CIDictObject *self, PyObject *o) +{ + PyObject *lo = NULL; + PyObject *oitems = NULL; + PyObject *key = NULL; + PyObject *item = NULL; + int len, i, ret = -1; + + if (!PyMapping_Check(o)) + return PyObject_Compare(self->dict, o); + + /* Create equivalent dictionary with lowercased keys */ + if ((lo = PyDict_New()) == NULL) + goto done; + if ((oitems = PyMapping_Items(o)) == NULL) + goto done; + len = PyObject_Length(oitems); + for (i = 0; i < len; i++) { + Py_XDECREF(item); + if ((item = PySequence_GetItem(oitems, i)) == NULL) + goto done; + Py_XDECREF(key); + if ((key = lowercase(PyTuple_GET_ITEM(item, 0))) == NULL) + goto done; + PyMapping_SetItem(key, PyTuple_GET_ITEM(item, 1)); + } + ret = PyObject_Compare(self->dict, lo); + done: + Py_XDECREF(key); + Py_XDECREF(item); + Py_XDECREF(oitems); + Py_XDECREF(lo); + return ret; +} + +static PyObject * +repr(CIDictObject *self) { - /* - * Duplicate the standard python dictionary type, - * but override the subscript accessor methods - */ - memcpy(&CIDict_Type, &PyDict_Type, sizeof CIDict_Type); - CIDict_Type.tp_name = "cidictionary"; - CIDict_Type.tp_as_mapping = &CIDict_mapping; - - memcpy(&CIDict_mapping, PyDict_Type.tp_as_mapping, - sizeof CIDict_mapping); - CIDict_mapping.mp_subscript = cid_subscript; - CIDict_mapping.mp_ass_subscript = cid_ass_subscript; + return PyObject_Repr(self->dict); } +static PyMappingMethods as_mapping = { + length, /* mp_length */ + subscript, /* mp_subscript */ + ass_subscript /* mp_ass_subscript */ +}; + +PyTypeObject CIDict_Type = { +#if defined(WIN32) || defined(__CYGWIN__) + /* see http://www.python.org/doc/FAQ.html#3.24 */ + PyObject_HEAD_INIT(NULL) +#else /* ! WIN32 */ + PyObject_HEAD_INIT(&PyType_Type) +#endif /* ! WIN32 */ + "cidictionary", /* tp_name */ + sizeof (CIDictObject), /* tp_basicsize */ + 0, /* tp_itemsize */ + (destructor)dealloc, /* tp_dealloc */ + (printfunc)print, /* tp_print */ + (getattrfunc)getattr, /* tp_getattr */ + NULL, /* tp_setattr */ + (cmpfunc)compare, /* tp_compare */ + (reprfunc)repr, /* tp_repr */ + NULL, /* tp_as_number */ + NULL, /* tp_as_sequence */ + &as_mapping, /* tp_as_mapping */ +}; + /* Create a new case-insensitive dictionary, based on PyDict */ PyObject * CIDict_New() { - PyObject *mp; - static int initialised = 0; + CIDictObject *o; + PyObject *dict; - if (!initialised) { - CIDict_init(); - initialised = 1; - } - - mp = PyDict_New(); - mp->ob_type = &CIDict_Type; - return (mp); + dict = PyDict_New(); + if (dict == NULL) + return NULL; + o = PyObject_NEW(CIDictObject, &CIDict_Type); + if (o == NULL) + Py_DECREF(dict); + else + o->dict = dict; + return o; } #endif /* USE_CIDICT */ -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 .signature: Invalid argument From bob at redivi.com Sun Jun 17 03:24:49 2001 From: bob at redivi.com ((::) Bob Ippolito) Date: Sat, 16 Jun 2001 21:24:49 -0400 (EDT) Subject: core dump / Objects/dictobject.c:471: bad argument to internal function Message-ID: <992741089.3b2c06e1eb4bf@redivi.com> I'm having a problem using python-ldap (redhat linux). ActivePython 2.1, build 210 OpenLDAP 2.0.11 This is with the latest CVS version of python-ldap.. 1.10alpha3 wouldn't compile with OpenLDAP 2.0.11, I haven't found the patch to try it. Any ideas? I've tried using different values for bind and search, and it worked fine if I issued a search that doesn't have any results.. but any search that has results gets that dictobject error, or just core dumps! (from the interpreter) >>> import _ldap >>> l=_ldap.open("localhost") >>> l.simple_bind_s("","") >>> l.search_s("",0,"objectclass=*") Traceback (most recent call last): File "", line 1, in ? SystemError: Objects/dictobject.c:471: bad argument to internal function >>> l.search("",0,"objectclass=*") 3 >>> print l.result(3) Segmentation fault (core dumped) It's a weird install of redhat, and I haven't been using RPM's.. so I don't want to try one. I just want to compile it myself and have it work. (::) bob From bob at redivi.com Sun Jun 17 04:06:17 2001 From: bob at redivi.com ((::) Bob Ippolito) Date: Sat, 16 Jun 2001 22:06:17 -0400 (EDT) Subject: core dump / Objects/dictobject.c:471: bad argument to internal function In-Reply-To: <992741089.3b2c06e1eb4bf@redivi.com> References: <992741089.3b2c06e1eb4bf@redivi.com> Message-ID: <992743577.3b2c10993916f@redivi.com> I got it to work.. what I had to do was turn off CIDict.. like this in setup.py line 16: defines = [#-- ('USE_CIDICT', None), it fixed both modes (I guess they're called synchronous and asynchronous?).. no more SystemError or core dump. Quoting "(::) Bob Ippolito" : > I'm having a problem using python-ldap (redhat linux). > > ActivePython 2.1, build 210 > OpenLDAP 2.0.11 > > This is with the latest CVS version of python-ldap.. 1.10alpha3 wouldn't > > compile with OpenLDAP 2.0.11, I haven't found the patch to try it. > > Any ideas? I've tried using different values for bind and search, and > it > worked fine if I issued a search that doesn't have any results.. but any > search > that has results gets that dictobject error, or just core dumps! > > (from the interpreter) > > >>> import _ldap > >>> l=_ldap.open("localhost") > >>> l.simple_bind_s("","") > >>> l.search_s("",0,"objectclass=*") > Traceback (most recent call last): > File "", line 1, in ? > SystemError: Objects/dictobject.c:471: bad argument to internal > function > >>> l.search("",0,"objectclass=*") > 3 > >>> print l.result(3) > Segmentation fault (core dumped) > > It's a weird install of redhat, and I haven't been using RPM's.. so I > don't > want to try one. I just want to compile it myself and have it work. > > (::) bob > > From michael at stroeder.com Sun Jun 17 11:44:18 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sun, 17 Jun 2001 11:44:18 +0200 Subject: compiling against OpenLDAP 2.0.11 References: Message-ID: <3B2C7BF2.147B9F21@stroeder.com> David Leonard wrote: > > the current status of the development tree seems to be: > * removing autoconf, in favour of python's distutils > (which is weaker at detecting what is there but slightly more > configurable and supposedly easier to build distributions with) > * supporting OpenLDAP 2.* (but dropping support for earlier > versions) I have to say that I'm feeling *very* unhappy about the current situation. I have absolutely no clue what to tell my users about how to install python-ldap. - There's no proper stable release since months although the CVS tree was pretty stable until a few weeks ago. I suggested to make a release before tinkering with the CVS version several times... - It's completely unclear what the status of the current CVS tree is. Who really knows? - There were no on-list announcements about changes to the CVS tree but maybe there were significant changes. Who knows? - People ask for building against OpenLDAP 2.0.x libs without having enough knowledge about the differences of the APIs. - Undocumented OpenLDAP 2.0.x-related patches are floating around which actually break existing python-ldap applications. I'd really prefer a stable version which builds against OpenLDAP 1.2.x, works rock-solid without memory leaks, do not core-dump and behaves as documented instead of OpenLDAP 2.0.x-patched version which break code and do not have any additional benefits. I'm seriously considering switching to another LDAP programming platform. Ciao, Michael. From david.leonard at csee.uq.edu.au Sun Jun 17 15:43:28 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Sun, 17 Jun 2001 23:43:28 +1000 (EST) Subject: ANNOUNCE: new mailing list python-ldap-commits In-Reply-To: <20010617133319.3E5921395B@kermit.dataflake.org> Message-ID: Announcing a new mailing list on which CVS commits get announced. I just committed some stuff and it seems to work fine. http://lists.sourceforge.net/lists/listinfo/python-ldap-commits or send 'help' to the email interface at: python-ldap-commits-request at lists.sourceforge.net I'm using syncmail as recommended by the sf docs. But I'll probably switch to log_accum (buy David Hampton et al) since it's output is easier to read. d PS If you want to look at how this is done, check out our CVSROOT module, and look at these files: loginfo syncmail checkoutlist -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 .signature: Invalid argument From bob at redivi.com Sun Jun 17 12:03:33 2001 From: bob at redivi.com ((::) Bob Ippolito) Date: Sun, 17 Jun 2001 06:03:33 -0400 (EDT) Subject: compiling against OpenLDAP 2.0.11 In-Reply-To: <3B2C7BF2.147B9F21@stroeder.com> References: <3B2C7BF2.147B9F21@stroeder.com> Message-ID: <992772213.3b2c807584bd4@redivi.com> Quoting Michael Str?der : > David Leonard wrote: > > > > the current status of the development tree seems to be: > > * removing autoconf, in favour of python's distutils > > (which is weaker at detecting what is there but slightly > more > > configurable and supposedly easier to build distributions > with) > > * supporting OpenLDAP 2.* (but dropping support for earlier > > versions) > > I have to say that I'm feeling *very* unhappy about the current > situation. I have absolutely no clue what to tell my users about how > to install python-ldap. Are you paying for the development of python-ldap? Don't whine, it doesn't encourage people to give you stuff. I feel sorry for "your users". Anyways, dropping support for old APIs isn't a terrible idea, people don't change APIs because it's fun, they typically do it for a pretty good reason. > > - There's no proper stable release since months although the CVS > tree was pretty stable until a few weeks ago. I suggested to make a > release before tinkering with the CVS version several times... checkout an older version. what do you think cvs is for? > > - It's completely unclear what the status of the current CVS tree > is. Who really knows? I just managed to compile it and have it working with python 2.1 and openldap 2.0.x.. all I had to do was make a change in setup.py to make it use normal dicts instead. hasn't crashed yet (but i admit I've only been using it for like 10 hours, and never doing more than one search per connection). > > - There were no on-list announcements about changes to the CVS tree > but maybe there were significant changes. Who knows? > > - People ask for building against OpenLDAP 2.0.x libs without having > enough knowledge about the differences of the APIs. > > - Undocumented OpenLDAP 2.0.x-related patches are floating around > which actually break existing python-ldap applications. > > I'd really prefer a stable version which builds against OpenLDAP > 1.2.x, works rock-solid without memory leaks, do not core-dump and > behaves as documented instead of OpenLDAP 2.0.x-patched version > which break code and do not have any additional benefits. so checkout an older version that you recall working well and fix the bugs yourself.. create your own python-ldap branch > > I'm seriously considering switching to another LDAP programming > platform. so do it, perl has a decent and working interface last I used it. but be productive, whining is *not* productive. (::) bob From david.leonard at csee.uq.edu.au Sun Jun 17 13:16:48 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Sun, 17 Jun 2001 21:16:48 +1000 (EST) Subject: compiling against OpenLDAP 2.0.11 In-Reply-To: <3B2C7BF2.147B9F21@stroeder.com> Message-ID: sorry, michael :( it just takes too much time to get all this stuff organised and done. for me its usually a bit of tinkering on weekends when i get some time. truthfully, i'm hoping for someone to step up and say "I'm doing all this good work that would fit well into python-ldap, I'm incorporating it, and have time and resources to do a comprehensive release. Give me commit access." (anyone?) in my situation, i don't seriously use ldap at all any more, which is a big problem since I still want to help keep things going. i can detect some talented and interested people on the list who may want to do the dedicated work on this - but I can't force them to.. that's how this open source game seems to work: it's pretty much supply-driven. > - It's completely unclear what the status of the current CVS tree > is. Who really knows? > - There were no on-list announcements about changes to the CVS tree > but maybe there were significant changes. Who knows? perhaps a read-only mailing list that receives emails on commits? i've found that works pretty good. sf docs don't mention anything about how to do it simply though... i may as well commit everything I have in my tree now.. it seems to be working for openldap2.0.7 and python2.1.. i thought the current tree was stable, but if its not, then i'll put in what i have and think is. > - People ask for building against OpenLDAP 2.0.x libs without having > enough knowledge about the differences of the APIs. > - Undocumented OpenLDAP 2.0.x-related patches are floating around > which actually break existing python-ldap applications. > I'd really prefer a stable version which builds against OpenLDAP > 1.2.x, works rock-solid without memory leaks, do not core-dump and um, why is openldap 1.2.x support still needed? > behaves as documented instead of OpenLDAP 2.0.x-patched version > which break code and do not have any additional benefits. if you want to create a cvs branch of the last release and incorporate the various patches etc, and build releases on compile.sf, please feel free to do so. you can find some of my attempts and maybe some helpful notes in ~leonard/. d -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 .signature: Invalid argument From michael at stroeder.com Sun Jun 17 13:38:33 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sun, 17 Jun 2001 13:38:33 +0200 Subject: compiling against OpenLDAP 2.0.11 References: Message-ID: <3B2C96B9.3C91B55F@stroeder.com> David Leonard wrote: > > perhaps a read-only mailing list that receives > emails on commits? i've found that works pretty good. sf docs don't > mention anything about how to do it simply though... That's definitely a good idea! I'll try to find out in SF docs. Ciao, Michael. From rsalz at zolera.com Sun Jun 17 15:31:51 2001 From: rsalz at zolera.com (Rich Salz) Date: Sun, 17 Jun 2001 09:31:51 -0400 Subject: compiling against OpenLDAP 2.0.11 References: Message-ID: <3B2CB147.4E04AA0F@zolera.com> > truthfully, i'm hoping for someone to step up and say "I'm doing all > this good work that would fit well into python-ldap, I'm incorporating it, > and have time and resources to do a comprehensive release. Give me commit > access." (anyone?) C'mon Michael -- go for it. From david.leonard at csee.uq.edu.au Sun Jun 17 13:45:27 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Sun, 17 Jun 2001 21:45:27 +1000 (EST) Subject: compiling against OpenLDAP 2.0.11 In-Reply-To: <3B2C96B9.3C91B55F@stroeder.com> Message-ID: On Sun, 17 Jun 2001, Michael Str?der typed thusly: > > perhaps a read-only mailing list that receives > > emails on commits? i've found that works pretty good. sf docs don't > > mention anything about how to do it simply though... > > That's definitely a good idea! I'll try to find out in SF docs. well after looking one iota harder, i find section 6 of the sf docs that describes this :) d -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 .signature: Invalid argument From jens at digicool.com Sun Jun 17 15:33:14 2001 From: jens at digicool.com (Jens Vagelpohl) Date: Sun, 17 Jun 2001 09:33:14 -0400 Subject: compiling against OpenLDAP 2.0.11 In-Reply-To: Message-ID: <20010617133319.3E5921395B@kermit.dataflake.org> > perhaps a read-only mailing list that receives > emails on commits? i've found that works pretty good. sf docs don't > mention anything about how to do it simply though... > we have a setup here at digital creations which handles emailing people after commits. it's just a couple python scripts. i've used it to do the same to my own CVS machine at home. if bad comes to worse and there is direct access to the repository i'd be glad to put it in. jens From michael at stroeder.com Sun Jun 17 15:42:28 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Sun, 17 Jun 2001 15:42:28 +0200 Subject: compiling against OpenLDAP 2.0.11 References: <20010617133319.3E5921395B@kermit.dataflake.org> Message-ID: <3B2CB3C4.FC63560E@stroeder.com> Jens Vagelpohl wrote: > > we have a setup here at digital creations which handles emailing people > after commits. David set it up and it seems to work: http://lists.sourceforge.net/lists/listinfo/python-ldap-commits Ciao, Michael. From michael at stroeder.com Mon Jun 25 12:53:27 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 25 Jun 2001 12:53:27 +0200 Subject: Building python-ldap from CVS against OpenLDAP 1.2.11/12 Message-ID: <3B371827.7F8CB3@stroeder.com> HI! Could someone with autoconf knowledge please have a look into the config.log attached? I simply do not understand why this won't work. I guess it mainly fails because of this: /usr/local/openldap1/lib/libldap.so: undefined reference to `__dn_expand' /usr/local/openldap1/lib/libldap.so: undefined reference to `__res_search' /usr/local/openldap1/lib/libldap.so: undefined reference to `_getshort' Ciao, Michael. -------------- next part -------------- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:601: checking for gcc configure:714: checking whether the C compiler (gcc ) works configure:730: gcc -o conftest conftest.c 1>&5 configure:756: checking whether the C compiler (gcc ) is a cross-compiler configure:761: checking whether we are using GNU C configure:770: gcc -E conftest.c configure:789: checking whether gcc accepts -g configure:862: checking python version configure:872: checking python install prefix configure:925: checking for socket configure:953: gcc -o conftest -g -O2 conftest.c 1>&5 configure:925: checking for gethostbyname configure:953: gcc -o conftest -g -O2 conftest.c 1>&5 configure:925: checking for inet_addr configure:953: gcc -o conftest -g -O2 conftest.c 1>&5 configure:925: checking for inet_ntoa configure:953: gcc -o conftest -g -O2 conftest.c 1>&5 configure:925: checking for connect configure:953: gcc -o conftest -g -O2 conftest.c 1>&5 configure:1027: checking for fmod configure:1055: gcc -o conftest -g -O2 conftest.c 1>&5 /tmp/ccdo41Kp.o: In function `main': /home/michael/Proj/python/ldap/python-ldap-CVS/python-ldap/configure:1049: undefined reference to `fmod' collect2: ld returned 1 exit status configure: failed program was: #line 1032 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char fmod(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char fmod(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_fmod) || defined (__stub___fmod) choke me #else fmod(); #endif ; return 0; } configure:1082: checking for fmod in -lm configure:1101: gcc -o conftest -g -O2 conftest.c -lm 1>&5 configure:1027: checking for floor configure:1055: gcc -o conftest -g -O2 conftest.c -lm 1>&5 configure:1353: checking for library containing ber_free configure:1371: gcc -o conftest -g -O2 -I/usr/local/openldap1/include -L/usr/local/openldap1/lib conftest.c -lm 1>&5 /tmp/ccjLYVKm.o: In function `main': /home/michael/Proj/python/ldap/python-ldap-CVS/python-ldap/configure:1367: undefined reference to `ber_free' collect2: ld returned 1 exit status configure: failed program was: #line 1360 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char ber_free(); int main() { ber_free() ; return 0; } configure:1393: gcc -o conftest -g -O2 -I/usr/local/openldap1/include -L/usr/local/openldap1/lib conftest.c -llber -lm 1>&5 configure:1415: checking for library containing ldap_open configure:1433: gcc -o conftest -g -O2 -I/usr/local/openldap1/include -L/usr/local/openldap1/lib conftest.c -llber -lm 1>&5 /tmp/ccR5dNE7.o: In function `main': /home/michael/Proj/python/ldap/python-ldap-CVS/python-ldap/configure:1429: undefined reference to `ldap_open' collect2: ld returned 1 exit status configure: failed program was: #line 1422 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char ldap_open(); int main() { ldap_open() ; return 0; } configure:1455: gcc -o conftest -g -O2 -I/usr/local/openldap1/include -L/usr/local/openldap1/lib conftest.c -lldap -llber -lm 1>&5 /usr/local/openldap1/lib/libldap.so: undefined reference to `__dn_expand' /usr/local/openldap1/lib/libldap.so: undefined reference to `__res_search' /usr/local/openldap1/lib/libldap.so: undefined reference to `_getshort' collect2: ld returned 1 exit status configure: failed program was: #line 1444 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char ldap_open(); int main() { ldap_open() ; return 0; } configure:1476: checking for ldap_open configure:1504: gcc -o conftest -g -O2 -I/usr/local/openldap1/include -L/usr/local/openldap1/lib conftest.c -llber -lm 1>&5 /tmp/ccEdInrV.o: In function `main': /home/michael/Proj/python/ldap/python-ldap-CVS/python-ldap/configure:1498: undefined reference to `ldap_open' collect2: ld returned 1 exit status configure: failed program was: #line 1481 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char ldap_open(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char ldap_open(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_ldap_open) || defined (__stub___ldap_open) choke me #else ldap_open(); #endif ; return 0; } From michael at stroeder.com Mon Jun 25 12:37:21 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Mon, 25 Jun 2001 12:37:21 +0200 Subject: Memory leaks with new LDAP API (the one in OpenLDAP 2.x.x) Message-ID: <3B371461.5FEF31CB@stroeder.com> HI! Find below one more important note about hasty patches for linking python-ldap against OpenLDAP 2 libs. Ciao, Michael. -------- Original Message -------- Subject: Re: Thanx for helping me... Date: Mon, 25 Jun 2001 12:19:04 +0200 From: Stig Venaas To: Michael Str?der [..] One more thing. I've realized after looking more at the new LDAP API (the one in OpenLDAP 2.x.x) that code using the old API will compile and work just fine with the new API except for one important thing. There will be memory leaks! So people should be warned a bit against just using old applications with OpenLDAP 2.x.x libs perhaps. The reason is changes in the memory allocation. When using ldap_first_attribute and next attribute, the attribute string must be freed, and one must also free the ber structure used by those. Same holds for get_dn or whatever it's called. I've just been fixing this in PHP. Stig From david.leonard at csee.uq.edu.au Wed Jun 13 02:52:11 2001 From: david.leonard at csee.uq.edu.au (David Leonard) Date: Wed, 13 Jun 2001 10:52:11 +1000 (EST) Subject: result timeout In-Reply-To: <3B2626A5.F3BB62A7@stroeder.com> Message-ID: On Tue, 12 Jun 2001, Michael Str?der typed thusly: > The result() method of current CVS version does not return > (None,None) as mentioned on > http://python-ldap.sourceforge.net/doc/lib/node9.html if timeout > occured. Simply None is returned. Which should be changed? The code or the documentation? or should it raise a timeout exception instead? its not hard to fix... but what to do? --- LDAPObject.c 2001/06/03 08:11:19 1.10 +++ LDAPObject.c 2001/06/13 00:43:53 @@ -1235,8 +1235,7 @@ if (res_type == 0) { /* Timeout has occured */ - Py_INCREF(Py_None); - return Py_None; + return Py_BuildValue("(OO)", Py_None, Py_None); } /* thanks to Konstantin Chuguev for this */ --- libldap.tex Wed May 16 11:33:00 2001 +++ /tmp/x Wed Jun 13 10:44:50 2001 @@ -524,7 +524,7 @@ the method will wait indefinitely for a response. The timeout can be expressed as a floating-point value, and a value of \constant{0} effects a poll. -If a timeout does occur, the tuple \constant{(None,None)} is returned. +If a timeout does occur, \constant{None} is returned. (This should really have been a \exception{TIMEOUT} exception!) The \method{result()} method returns a tuple of the form --- LDAPObject.c 2001/06/03 08:11:19 1.10 +++ LDAPObject.c 2001/06/13 00:51:12 @@ -1235,8 +1235,7 @@ if (res_type == 0) { /* Timeout has occured */ - Py_INCREF(Py_None); - return Py_None; + return PyErr_SetObject(errobjects[LDAP_TIMEOUT], Py_None); } /* thanks to Konstantin Chuguev for this */ -- David Leonard David.Leonard at dstc.edu.au DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 The entire history of the world is the triumph of the heartless over the mindless. - Sir Humphrey Appleby, Yes Minister. From michael at stroeder.com Wed Jun 13 10:56:24 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Wed, 13 Jun 2001 10:56:24 +0200 Subject: result timeout References: Message-ID: <3B272AB8.EF2061F0@stroeder.com> David Leonard wrote: > > On Tue, 12 Jun 2001, Michael Str?der typed thusly: > > > The result() method of current CVS version does not return > > (None,None) as mentioned on > > http://python-ldap.sourceforge.net/doc/lib/node9.html if timeout > > occured. Simply None is returned. > > Which should be changed? The code or the documentation? Rather the code. > or should it raise a timeout exception instead? > its not hard to fix... but what to do? Returning (None,None) has the advantage of not breaking existing code. Hmm, but most people are not really using all the feature of the API. Raising an exception seems the better design. But on the other hand I think it costs more performance to raise and handle an exception which could be a drawback when polling with timeout parameter set to 0. Well, I'd suggest raising timeout exception but would like to hear other opinions as well - especially regarding compatibility to existing code. Ciao, Michael. From michael at stroeder.com Tue Jun 26 00:31:36 2001 From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=) Date: Tue, 26 Jun 2001 00:31:36 +0200 Subject: Building python-ldap from CVS against OpenLDAP 1.2.11/12 References: <3B371827.7F8CB3@stroeder.com> Message-ID: <3B37BBC8.16FECD31@stroeder.com> Michael Str?der wrote: > > Could someone with autoconf knowledge please have a look into the > config.log attached? I simply do not understand why this won't work. > > I guess it mainly fails because of this: > /usr/local/openldap1/lib/libldap.so: undefined reference to > `__dn_expand' > /usr/local/openldap1/lib/libldap.so: undefined reference to > `__res_search' > /usr/local/openldap1/lib/libldap.so: undefined reference to > `_getshort' (Sigh!) I had to link explicitly against libresolv on my system (S.u.S.E. Linux 7.1 with glibc-2.2). export "LDFLAGS=-lresolv" ./configure Hmm, I wonder why this worked under 7.0...grrr! Ciao, Michael.