From michael at stroeder.com Mon Jul 1 01:15:40 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Mon, 01 Jul 2002 01:15:40 +0200 Subject: Issues with NON-ASCII chars and OpenLDAP 2.1 libs Message-ID: <3D1F911C.2030108@stroeder.com> HI! For those of you planning to build python-ldap against OpenLDAP 2.1.x.: I get ldap.NO_SUCH_OBJECT when a distinguished name for a search operation contains non-ASCII characters (as UTF-8 off course). It works smoothly with python-ldap build against OpenLDAP 2 libs. AFAIR OpenLDAP 2.1 contains a completely new Unicode normalization... Ciao, Michael. From david.leonard at itee.uq.edu.au Mon Jul 1 01:42:02 2002 From: david.leonard at itee.uq.edu.au (David Leonard) Date: Mon, 1 Jul 2002 09:42:02 +1000 (EST) Subject: Bug in LDAPObject.c, l_ldap_result() In-Reply-To: <3D1F1039.30505@stroeder.com> Message-ID: On Sun, 30 Jun 2002, Michael Str?der typed thusly: > > | >I also think the C function needs > > | >to be modified to treat Py_None as NULL to allow python code to > > | >specify a timeout that is indefinitely long. > > | > > | IMHO that's done with timeout=-1. Looking at l_ldap_result() in > > | LDAPObject.c it seems to be implemented correctly > > > > Ahh, yeah, that is one suitable convention. Doesn't > > timeout=None > > sound amusingly accurate though? (in english at least) > > Well, I have no clue why David chose -1 instead of None. that's the C/unix convention. however, looking at the documentation of select.select() it seems that using None could be better justified select(rlist, wlist, xlist[, timeout]) -> (rlist, wlist, xlist) [...] The optional 4th argument specifies a timeout in seconds; it may be a floating point number to specify fractions of seconds. If it is absent or None, the call will never time out. d -- David Leonard David.Leonard at itee.uq.edu.au Dept of Inf. Tech. and Elec. Engg _ Ph:+61 404 844 850 The University of Queensland |+| http://www.itee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 From michael at stroeder.com Mon Jul 1 02:31:27 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 01 Jul 2002 02:31:27 +0200 Subject: Bug in LDAPObject.c, l_ldap_result() References: <3D1B4E3C.3040609@stroeder.com> <20020628210724.GB8082@dman.ddts.net> Message-ID: <3D1FA2DF.9010707@stroeder.com> Derrick 'dman' Hudson wrote: > > - pmsg = Py_None; > + pmsg = LDAPmessage_to_python( self->ldap, msg ); > > It really does help to not ignore the data that's returned :-). There's still something wrong with that when a search continuation is returned. It simply does not return the last empty search result which terminates the while loop. Strange enough it works from web2ldap but not from a simple demo using ldap.async. Hmm... Ciao, Michael. From michael at stroeder.com Mon Jul 1 15:14:29 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 01 Jul 2002 15:14:29 +0200 Subject: Building python-ldap with libldap_r (was: defect) References: <3D1D9EDC.9020402@stroeder.com> Message-ID: <3D2055B5.3090000@stroeder.com> Michael Str?der wrote: > > I tried to build python-ldap against libldap_r from OpenLDAP's REL_ENG_2 > branch by simply modifying setup.cfg: > > libs = ldap_r lber sasl > > The build went fine. ldd shows output like expected: > [..] > > But import does not work. > [..] > ImportError: /usr/lib/python2.2/site-packages/_ldap.so: undefined > symbol: ldap_first_reference Hmm I saw some postings on using libldap_r with other software packages. They used libldap_r *and* libldap for linking. I tried this in setup.cfg: libs = ldap_r ldap lber sasl It seems to work and ldd shows this: $ ldd /usr/lib/python2.2/site-packages/_ldap.so libldap_r.so.2 => /usr/local/openldap2/lib/libldap_r.so.2 (0x4001f000) libldap.so.2 => /usr/local/openldap2/lib/libldap.so.2 (0x40052000) liblber.so.2 => /usr/local/openldap2/lib/liblber.so.2 (0x40082000) libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4008e000) Can anyone confirm that it's supposed to work that way using both libldap_r and libldap for linking? How can I be sure that the reentrant version of a ldaplib function is used? (Again revealing my lack of C compiling knowledge...) Ciao, Michael. From michael at stroeder.com Mon Jul 1 16:03:46 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 01 Jul 2002 16:03:46 +0200 Subject: Building python-ldap with libldap_r (was: defect) References: <3D1D9EDC.9020402@stroeder.com> <3D2055B5.3090000@stroeder.com> Message-ID: <3D206142.9080500@stroeder.com> Michael Str?der wrote: > > libs = ldap_r ldap lber sasl libldap_r allows finer-grained locking for each LDAPObject instance. I've checked in a new ldap/__init__.py and ldap/ldapobject.py which allows to use separate Lock instances for global function calls into LDAP lib and for each LDAPObject instance created. At the moment you have to create a LDAPObject instance directly for using that (not through ldap.open() or ldap.initialize()). Example: l = ldap.ldapobject.LDAPObject('ldap://www.openldap.org',ldap_r=1) Also there's a more elegant fall-back if the Python installation used has no thread support (translates to import threading failed). Please read the changed source and comment! Please try to build a python-ldap with libldap_r and test! Also test with Python without thread support! Ciao, Michael. From michael at stroeder.com Tue Jul 2 12:58:41 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Tue, 02 Jul 2002 12:58:41 +0200 Subject: Fat memory leaks Message-ID: <3D218761.7020101@stroeder.com> HI! I remember that someone reported memory leaks quite a while ago and there was no further action. Running some test scripts I can observe that the python-ldap using process grows quite fast. Does anybody have the time to look into this? If yes, please dig into Modules/LDAPObject.c, functions l_ldap_result() and l_ldap_search(). Ciao, Michael. From Isabelle.Moullet at ci.unil.ch Tue Jul 2 11:00:16 2002 From: Isabelle.Moullet at ci.unil.ch (Isabelle Moullet) Date: Tue, 02 Jul 2002 11:00:16 +0200 Subject: python-ldap 2.0.0pre04 Installation problem Message-ID: <3D216B9F.52B79419@ci.unil.ch> Bonjour, I got the following error message as I tried to install python-ldap 2.0.0pre04 release on a 2.8 Solaris machine with the command :python setup.py build ( I use python 2.0) super at cisun50$ python setup.py build running build running build_py warning: build_py: file Lib/ldap.py (for module ldap) not found creating build creating build/lib.solaris-2.8-sun4u-2.0 creating build/lib.solaris-2.8-sun4u-2.0/ldap copying Lib/ldap/__init__.py -> build/lib.solaris-2.8-sun4u-2.0/ldap copying Lib/ldap/async.py -> build/lib.solaris-2.8-sun4u-2.0/ldap copying Lib/ldap/functions.py -> build/lib.solaris-2.8-sun4u-2.0/ldap copying Lib/ldap/ldapobject.py -> build/lib.solaris-2.8-sun4u-2.0/ldap copying Lib/ldap/modlist.py -> build/lib.solaris-2.8-sun4u-2.0/ldap copying Lib/ldapurl.py -> build/lib.solaris-2.8-sun4u-2.0 copying Lib/ldif.py -> build/lib.solaris-2.8-sun4u-2.0 warning: build_py: file Lib/ldap.py (for module ldap) not found running build_ext building '_ldap' extension creating build/temp.solaris-2.8-sun4u-2.0 creating build/temp.solaris-2.8-sun4u-2.0/Modules cc -O -DLDAP_TYPE_IS_OPAQUE -DHAVE_LDAP_DESTROY_CACHE -DHAVE_LDAP_DISABLE_CACHE-DHAVE_LDAP_ENABLE_CACHE -DHAVE_LDAP_FLUSH_CACHE -DHAVE_LDAP_MODRDN2 -DHAVE_LDA_MODRDN2_S -DHAVE_LDAP_SET_CACHE_OPTIONS -DHAVE_LDAP_START_TLS_S -DHAVE_LDAP_UNACHE_ENTRY -DHAVE_LDAP_UNCACHE_REQUEST -DLDAPMODULE_VERSION=2.0.0pre04 -IModule -I/usr/local/include -I/usr/local/include/python2.0 -c Modules/LDAPObject.c -obuild/temp.solaris-2.8-sun4u-2.0/Modules/LDAPObject.o "Modules/LDAPObject.c", line 900: warning: syntax error: empty declaration "Modules/LDAPObject.c", line 918: undefined symbol: LDAP_CONTROL_MANAGEDSAIT "Modules/LDAPObject.c", line 918: warning: improper pointer/integer combination op "=" "Modules/LDAPObject.c", line 936: warning: syntax error: empty declaration cc: acomp failed for Modules/LDAPObject.c error: command 'cc' failed with exit status 2 Is it normal he could not find th efile Lib/ldap.py ? Here is my setup.cfg file # Section for compiling the C extension module # for wrapping OpenLDAP 2 libs [_ldap] class = OpenLDAP2 library_dirs = /usr/local/lib include_dirs = /usr/local/include libs = lber ldap resolv # Installation options [install] compile = 1 optimize = 1 Thanks a lof for your help.. -- Isabelle Moullet Centre Informatique Universite de Lausanne email: isabelle.moullet at ci.unil.ch -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Tue Jul 2 16:55:03 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 02 Jul 2002 16:55:03 +0200 Subject: python-ldap 2.0.0pre04 Installation problem References: <3D216B9F.52B79419@ci.unil.ch> Message-ID: <3D21BEC7.7020403@stroeder.com> Isabelle Moullet wrote: > > I got the following error message as I tried to install python-ldap 2.0.0pre04 > release on a 2.8 Solaris machine with the command :python setup.py build Did you install the required OpenLDAP 2 libs before? If yes, did you make sure that they don't conflict with Netscape/iPlanet LDAP libs probably shipped with Solaris? Check which libldap is really used. > [_ldap] > class = OpenLDAP2 > library_dirs = /usr/local/lib > include_dirs = /usr/local/include I'd suggest that you build OpenLDAP 2.0.x with --prefix=/usr/local/openldap2 and modify setup.cfg accordingly. library_dirs = /usr/local/openldap2/lib include_dirs = /usr/local/openldap2/include > cc -O -DLDAP_TYPE_IS_OPAQUE -DHAVE_LDAP_DESTROY_CACHE -DHAVE_LDAP_DISABLE_CACHE-DHAVE_LDAP_ENABLE_CACHE -DHAVE_LDAP_FLUSH_CACHE -DHAVE_LDAP_MODRDN2 -DHAVE_LDA_MODRDN2_S -DHAVE_LDAP_SET_CACHE_OPTIONS -DHAVE_LDAP_START_TLS_S -DHAVE_LDAP_UNACHE_ENTRY -DHAVE_LDAP_UNCACHE_REQUEST -DLDAPMODULE_VERSION=2.0.0pre04 -IModule -I/usr/local/include -I/usr/local/include/python2.0 -c Modules/LDAPObject.c -obuild/temp.solaris-2.8-sun4u-2.0/Modules/LDAPObject.o > "Modules/LDAPObject.c", line 900: warning: syntax error: empty declaration > "Modules/LDAPObject.c", line 918: undefined symbol: LDAP_CONTROL_MANAGEDSAIT > "Modules/LDAPObject.c", line 918: warning: improper pointer/integer combination op "=" > "Modules/LDAPObject.c", line 936: warning: syntax error: empty declaration > cc: acomp failed for Modules/LDAPObject.c > error: command 'cc' failed with exit status 2 I guess you're using Sun's C compiler. Right? Hmm, anyone here having experience with that? > Is it normal he could not find th efile Lib/ldap.py ? Yes, this message is caused by a limitation of DistUtils. Ciao, Michael. From olivier.guillossou at c2a.fr Tue Jul 2 18:59:27 2002 From: olivier.guillossou at c2a.fr (Olivier Guillossou) Date: Tue, 02 Jul 2002 18:59:27 +0200 Subject: timeout on bind() function Message-ID: <3D21DBEF.2070304@c2a.fr> Hello everybody, I've a question: is there any option in the bind() function to make it raising a timeout exception ? I'm testing the python-ldap library, and I wouldn't like the program to hang if the LDAP server is down, for example. If there's no embedded timeout function, how can I make my program "timeouting" when the bind() function hangs ? Yours, -- Olivier Guillossou Sp?cialiste Linux / ADELUX 146 Bd Voltaire 92600 Asni?res sur Seine - FRANCE tel: 01 46 88 60 55 fax: 01 47 90 26 32 From michael at stroeder.com Tue Jul 2 19:18:37 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Tue, 02 Jul 2002 19:18:37 +0200 Subject: LDAP_TYPE_IS_OPAQUE? Message-ID: <3D21E06D.5090005@stroeder.com> HI! I have no clue what define LDAP_TYPE_IS_OPAQUE is for? Can we get rid of it because we require OpenLDAP 2.x libs for python-ldap 2.x? Ciao, Michael. From michael at stroeder.com Tue Jul 2 19:28:48 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Tue, 02 Jul 2002 19:28:48 +0200 Subject: timeout on bind() function References: <3D21DBEF.2070304@c2a.fr> Message-ID: <3D21E2D0.8060409@stroeder.com> Olivier Guillossou wrote: > > I've a question: is there any option in the bind() function to make it > raising a timeout exception ? There's no timeout parameter for bind() method. > I'm testing the python-ldap library, and I wouldn't like the program to > hang if the LDAP server is down, for example. If the server is really down you get a ldap.SERVER_DOWN when firing the first LDAP operation (no matter which). The really tricky things are servers which do accept the connection but don't proceed. > If there's no embedded timeout function, how can I make my program > "timeouting" when the bind() function hangs ? >>> import ldap >>> l=ldap.open('localhost:1389') >>> m=l.bind(ldap.AUTH_SIMPLE,'','') >>> m=l.bind('','',ldap.AUTH_SIMPLE) >>> r=l.result(m,1,30) Hmm, is there any interest in setting a LDAPObject.timeout which would automagically apply to all *_s() methods? Ciao, Michael. From michael at stroeder.com Tue Jul 2 18:00:15 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 02 Jul 2002 18:00:15 +0200 Subject: python-ldap 2.0.0pre04 Installation problem References: <3D216B9F.52B79419@ci.unil.ch> <3D21BEC7.7020403@stroeder.com> Message-ID: <3D21CE0F.2090806@stroeder.com> Isabelle Moullet wrote: >> Isabelle Moullet wrote: >> >>> I got the following error message as I tried to install python-ldap >>> 2.0.0pre04 >>> release on a 2.8 Solaris machine with the command :python setup.py build >> >> Did you install the required OpenLDAP 2 libs before? > > No I didn't ! Maybe that's my problem.. But I remember that with verison > 1.10alpha3 it was not useful, right ? python-ldap 1.x only works with OpenLDAP 1.x, Netscape 3.x(?) and old Novell libs. python-ldap 2.x requires OpenLDAP 2.x libs installed. > Do you think it is better to use 1.10alpha3 or the latest release ? I'd recommend to use python-ldap 2.0.0pre04. There are a couple of issues there. But they will be solved. python-ldap 1.x is not actively maintained anymore. Ciao, Michael. From david.leonard at itee.uq.edu.au Wed Jul 3 06:34:26 2002 From: david.leonard at itee.uq.edu.au (David Leonard) Date: Wed, 3 Jul 2002 14:34:26 +1000 (EST) Subject: LDAP_TYPE_IS_OPAQUE? In-Reply-To: <3D21E06D.5090005@stroeder.com> Message-ID: On Tue, 2 Jul 2002, Michael Str?der typed thusly: > I have no clue what define LDAP_TYPE_IS_OPAQUE is for? > > Can we get rid of it because we require OpenLDAP 2.x libs for > python-ldap 2.x? the type-is-opaque test was introduced when the LDAP type was not defined in the ldap.h header file (netscape's from memory). to determine the error number from failed LDAP operations, you either had to access an errno field of the structure, or use a function such as ldap_get_error() or something. (its getting foggy in my mind) so, in the early days, if LDAP_TYPE_IS_OPAQUE was detected by configure, and if no ldap_get_error() function was provided, then - well errors were all generic. if the focus is now on simply supporting the OpenLDAP client library, then getting rid of LDAP_TYPE_IS_OPAQUE makes sense. d From michael at stroeder.com Thu Jul 4 16:56:00 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 04 Jul 2002 16:56:00 +0200 Subject: [Fwd: libldap_r: undefined symbol: ldap_first_reference (ITS#1922)] Message-ID: <3D246200.4010509@stroeder.com> HI! I filed a bug report for the problems with libldap_r: http://www.OpenLDAP.org/its/index.cgi?findid=1922 Credits go to Johannes Stezenbach for sorting that out. Now adding references.c and references.lo in libraries/libldap_r/Makefile.in makes it possible to build with this line in setup.cfg: libs = ldap_r lber sasl BTW: Make sure to bring your CVS working tree in sync. There are some changes in there related to using libldap_r. Verify if everything works after installing: # python -c "import ldap" Under Linux you can check with ldd: # ldd /usr/lib/python2.2/site-packages/_ldap.so libldap_r.so.2 => /usr/local/openldap2/lib/libldap_r.so.2 (0x4001f000) liblber.so.2 => /usr/local/openldap2/lib/liblber.so.2 (0x40052000) libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4005e000) libldap.so.2 must not be mentioned there! Mauro, I'd be happy if you also test that on Win32. Ciao, Michael. From michael at stroeder.com Thu Jul 4 20:01:27 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Thu, 04 Jul 2002 20:01:27 +0200 Subject: #ifdef HAVE_SASL Message-ID: <3D248D77.8000904@stroeder.com> HI! For those who haven't built their local OpenLDAP libs with SASL support I have introduced #ifdef HAVE_SASL in setup.py and Modules/*.c. HAVE_SASL is automagically set according to the line libs in setup.cfg. It seems to work but please test! Ciao, Michael. (I really hate C!) From jlittle at open-it.org Fri Jul 5 18:38:42 2002 From: jlittle at open-it.org (Joe Little) Date: Fri, 5 Jul 2002 09:38:42 -0700 Subject: RedHat 8.0 RPMS -- what they foretell Message-ID: I'll downloaded the isos for limbo, the first RedHat 8.0 beta release. Its a true .0 release, in that a lot of major changes are in the works. Primarily, they have migrated their whole installation system from python 1.5.x to 2.2.x. Along with this, they have adopted OpenLDAP 2.1.2, and their compat libs are only for OpenLDAP 1.2.13. This means that at least for this vendor, a CVS release of python-ldap will be the bare minimum requirement. My guess is that 8.0 may be an August release, or perhaps later. Regardless, the list will get more questions about OpenLDAP 2.1.x in the future. The good news is that Python 1.5.x is going away and so my RPMs won't need to deal with "python == python-1.5.x and python2 == python 2.x.y?" notation.. From michael at stroeder.com Fri Jul 5 19:15:17 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 05 Jul 2002 19:15:17 +0200 Subject: RedHat 8.0 RPMS -- what they foretell References: Message-ID: <3D25D425.2020304@stroeder.com> Joe Little wrote: > I'll downloaded the isos for limbo, the first RedHat 8.0 beta release. > > Its a true .0 release, in that a lot of major changes are in the works. > Primarily, they have migrated their whole installation system from > python 1.5.x to 2.2.x. Along with this, they have adopted OpenLDAP > 2.1.2, and their compat libs are only for OpenLDAP 1.2.13. This means > that at least for this vendor, a CVS release of python-ldap will be the > bare minimum requirement. My guess is that 8.0 may be an August release, > or perhaps later. Regardless, the list will get more questions about > OpenLDAP 2.1.x in the future. Now how about testing the current CVS instead of counting version numbers? Did you read about my problems with OpenLDAP 2.1.x libs? I filed two bug reports to OpenLDAP's ITS related to problems I found when working on python-ldap during the last days. So far I had no feedback from list members when requesting tests during the last days! :-( Red Hat is famous for packaging premature software into RPMs such causing a 1st-level support nightmare on mailing lists which they simply don't have to pay (e.g. the gcc catastrophy). Sorry, Red Hat nor any other Linux distributors' packaging decisions will influence my schedule. Joe, if you want to push things forward then there are several things to dig into: 1. Solve problems with NON-ASCII chars in DN when using OpenLDAP 2.1.x libs. 2. Find huge memory leaks reported to the list. 3. Dig into thread-safety issues with libldap_r. Despite your personal conversation with Luke I have some doubts that this is really solved. 4. Test build process with several flavors of OpenLDAP (./configure --help to give you an idea). 5. Clean up the nightmare of DEFINE's used. 6. At least test the CVS version! Not to speak of adding new features... Ciao, Michael. From jlittle at open-it.org Fri Jul 5 19:35:12 2002 From: jlittle at open-it.org (Joe Little) Date: Fri, 5 Jul 2002 10:35:12 -0700 Subject: RedHat 8.0 RPMS -- what they foretell In-Reply-To: <3D25D425.2020304@stroeder.com> Message-ID: <8F4B6F73-903D-11D6-93D9-0003930B38C0@open-it.org> Yeah.. I know there is a lot to do. I was just relating what I saw in one of my primary tasks (maintain a university's Linux distro). I sincerely hope to dig into builds against 2.1.x and libldap_r. I also noted the issue with OpenLDAP and the problem report, and will await whatever they respond to. I just don't have much code to test OpenLDAP 2.1 or any version against. I need to get sufficient code that will provide bug reports. As to the mem leaks, I'm at a loss as to how to tackle that one on Python. On Friday, July 5, 2002, at 10:15 AM, Michael Str?der wrote: > Joe Little wrote: >> I'll downloaded the isos for limbo, the first RedHat 8.0 beta release. >> Its a true .0 release, in that a lot of major changes are in the works. Primarily, they have migrated their whole installation system from python 1.5.x to 2.2.x. Along with this, they have adopted OpenLDAP 2.1.2, and their compat libs are only for OpenLDAP 1.2.13. This means that at least for this vendor, a CVS release of python-ldap will be the bare minimum requirement. My guess is that 8.0 may be an August release, or perhaps later. Regardless, the list will get more questions about OpenLDAP 2.1.x in the future. > > Now how about testing the current CVS instead of counting version numbers? Did you read about my problems with OpenLDAP 2.1.x libs? I filed two bug reports to OpenLDAP's ITS related to problems I found when working on python-ldap during the last days. > > So far I had no feedback from list members when requesting tests during the last days! :-( > > Red Hat is famous for packaging premature software into RPMs such causing a 1st-level support nightmare on mailing lists which they simply don't have to pay (e.g. the gcc catastrophy). > > Sorry, Red Hat nor any other Linux distributors' packaging decisions will influence my schedule. > > Joe, if you want to push things forward then there are several things to dig into: > > 1. Solve problems with NON-ASCII chars in DN when using OpenLDAP 2.1.x libs. > > 2. Find huge memory leaks reported to the list. > > 3. Dig into thread-safety issues with libldap_r. Despite your personal conversation with Luke I have some doubts that this is really solved. > > 4. Test build process with several flavors of OpenLDAP (./configure --help to give you an idea). > > 5. Clean up the nightmare of DEFINE's used. > > 6. At least test the CVS version! > > Not to speak of adding new features... > > Ciao, Michael. From michael at stroeder.com Fri Jul 5 19:48:39 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 05 Jul 2002 19:48:39 +0200 Subject: Urgent issues (was: RedHat 8.0 RPMS -- what they foretell) References: Message-ID: <3D25DBF7.9080007@stroeder.com> I forgot something. Several things to dig into: 0. At least test the CVS version! 1. Solve problems with NON-ASCII chars in DN when using OpenLDAP 2.1.x libs. 2. Find huge memory leaks reported to the list. 3. Dig into thread-safety issues with libldap_r. Despite your personal conversation with Luke I have some doubts that this is really solved. 4. Test build process with several flavors of OpenLDAP (./configure --help to give you an idea). 5. Clean up the nightmare of DEFINE's used. 6. Find subtle problem with search continuations blocking the search in ldap.async when using the latest CVS versions. Ciao, Michael. From michael at stroeder.com Sat Jul 6 17:39:59 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Sat, 06 Jul 2002 17:39:59 +0200 Subject: FYI: ldaptor Message-ID: <3D270F4F.3050300@stroeder.com> HI! There's a pure Python implementation of the LDAP protocol: http://twistedmatrix.com/users/tv/ldaptor/ Looks nicely designed! Maybe it's thread-safe... Ciao, Michael. From mcicogni at siosistemi.it Tue Jul 9 15:19:30 2002 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Tue, 09 Jul 2002 15:19:30 +0200 Subject: [Fwd: libldap_r: undefined symbol: ldap_first_reference (ITS#1922)] References: <3D246200.4010509@stroeder.com> Message-ID: <3D2AE2E2.8080200@siosistemi.it> Michael Str?der wrote: > HI! > > I filed a bug report for the problems with libldap_r: > > http://www.OpenLDAP.org/its/index.cgi?findid=1922 > > Credits go to Johannes Stezenbach for sorting that out. > > Now adding references.c and references.lo in > libraries/libldap_r/Makefile.in makes it possible to build with this > line in setup.cfg: > > libs = ldap_r lber sasl > > BTW: Make sure to bring your CVS working tree in sync. There are some > changes in there related to using libldap_r. > > Verify if everything works after installing: > > # python -c "import ldap" > > Under Linux you can check with ldd: > > # ldd /usr/lib/python2.2/site-packages/_ldap.so > libldap_r.so.2 => /usr/local/openldap2/lib/libldap_r.so.2 > (0x4001f000) > liblber.so.2 => /usr/local/openldap2/lib/liblber.so.2 > (0x40052000) > libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4005e000) > > libldap.so.2 must not be mentioned there! > > Mauro, I'd be happy if you also test that on Win32. I'd be happy to do so; how do I proceed? Do I have to get everything from CVS? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2926 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Wed Jul 10 22:33:59 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 10 Jul 2002 22:33:59 +0200 Subject: [Fwd: libldap_r: undefined symbol: ldap_first_reference (ITS#1922)] References: <3D246200.4010509@stroeder.com> <3D2AE2E2.8080200@siosistemi.it> Message-ID: <3D2C9A37.3000607@stroeder.com> Mauro Cicognini wrote: > Michael Str?der wrote: > >> libs = ldap_r lber sasl >> >> BTW: Make sure to bring your CVS working tree in sync. There are some >> changes in there related to using libldap_r. >> >> Mauro, I'd be happy if you also test that on Win32. > > I'd be happy to do so; how do I proceed? > Do I have to get everything from CVS? Yes, please bring your working tree in sync. Ciao, Michael. From michael at stroeder.com Thu Jul 11 19:54:51 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 11 Jul 2002 19:54:51 +0200 Subject: FYI: Solved problems with NON-ASCII chars in DN when using OpenLDAP 2.1.x libs. References: <3D25DBF7.9080007@stroeder.com> Message-ID: <3D2DC66B.4020209@stroeder.com> Michael Str?der wrote: > > 1. Solve problems with NON-ASCII chars in DN when using OpenLDAP > 2.1.x libs. Now this turned out to be a problem with ldap.explode_dn() and errornous handling of NON-ASCII chars in DNs (e.g. for search root) in OpenLDAP servers 1.x and 2.0.x. Unlike former versions ldap_explode_dn() returns escaped values if the DN of OpenLDAP 2.1.x returns contains NON-ASCII chars. This is valid according to RFC2253 but causes compability problems with old OpenLDAP servers. The older OpenLDAP servers do not match the escaped values in DNs properly. See the following trace log of a situation hitting in web2ldap when accessing OpenLDAP 2.0.x (it works e.g. against Netscape Directory 4.1x): *** _ldap. (('cn=Michael >Str\xc3\xb6der+mail=michael at stroeder.com,ou=Testing,dc=stroeder,dc=com', >0),{}) >=> result: ['cn=Michael Str\\C3\\B6der+mail=michael at stroeder.com', >'ou=Testing', 'dc=stroeder', 'dc=com'] >*** ldap.ldapobject.SimpleLDAPObject.search (('cn=Michael >Str\\C3\\B6der+mail=michael at stroeder.com,ou=Testing,dc=stroeder,dc=com', >0, '(objectclass=*)', ['cn'], 0),{}) >=> result: 1 >*** ldap.ldapobject.SimpleLDAPObject.result ((1, 1, -1),{}) >=> LDAPError: {'info': '', 'matched': >'ou=Testing,dc=stroeder,dc=com', 'desc': 'No such object'} Note also that ldap_explode_dn() is marked as deprecated in OpenLDAP 2.1.x's ldap.h. Ciao, Michael. From jlittle at open-it.org Thu Jul 11 21:38:25 2002 From: jlittle at open-it.org (Joe Little) Date: Thu, 11 Jul 2002 12:38:25 -0700 Subject: FYI: Solved problems with NON-ASCII chars in DN when using OpenLDAP 2.1.x libs. In-Reply-To: <3D2DC66B.4020209@stroeder.com> Message-ID: I've worked with the latest CVS code a bit. Hope to have more code to push it soon. I did note the new 2.1.3 update too, and saw the libldap_r build fix. Did you get a separate email from Kurt saying that it was going to be addressed in a 2.0.x release as well? On Thursday, July 11, 2002, at 10:54 AM, Michael Str?der wrote: > Michael Str?der wrote: >> 1. Solve problems with NON-ASCII chars in DN when using OpenLDAP >> 2.1.x libs. > > Now this turned out to be a problem with ldap.explode_dn() and errornous handling of NON-ASCII chars in DNs (e.g. for search root) in OpenLDAP servers 1.x and 2.0.x. > > Unlike former versions ldap_explode_dn() returns escaped values if the DN of OpenLDAP 2.1.x returns contains NON-ASCII chars. This is valid according to RFC2253 but causes compability problems with old OpenLDAP servers. The older OpenLDAP servers do not match the escaped values in DNs properly. > > See the following trace log of a situation hitting in web2ldap when accessing OpenLDAP 2.0.x (it works e.g. against Netscape Directory 4.1x): > > *** _ldap. (('cn=Michael > >Str\xc3\xb6der+mail=michael at stroeder.com,ou=Testing,dc=stroeder,dc=com', > >0),{}) > >=> result: ['cn=Michael Str\\C3\\B6der+mail=michael at stroeder.com', > >'ou=Testing', 'dc=stroeder', 'dc=com'] > >*** ldap.ldapobject.SimpleLDAPObject.search (('cn=Michael > >Str\\C3\\B6der+mail=michael at stroeder.com,ou=Testing,dc=stroeder,dc=com', > >0, '(objectclass=*)', ['cn'], 0),{}) > >=> result: 1 > >*** ldap.ldapobject.SimpleLDAPObject.result ((1, 1, -1),{}) > >=> LDAPError: {'info': '', 'matched': > >'ou=Testing,dc=stroeder,dc=com', 'desc': 'No such object'} > > Note also that ldap_explode_dn() is marked as deprecated in OpenLDAP 2.1.x's ldap.h. > > Ciao, Michael. > > > > From AshishG at lambenttek.com Mon Jul 15 14:24:55 2002 From: AshishG at lambenttek.com (Ashish Gautam) Date: Mon, 15 Jul 2002 17:54:55 +0530 Subject: updating python from openLDAP Message-ID: <2AE7EB3FF3B9E14D9559582C5BA1E1A0013718@Development.LAMBENT.COM> Hello everybody, I have a runnning openLDAP server on linux. I want to write a module in python that will add entries to the openLDAP server. i have python-ldap module installed too. I just dont find any API documentation help and examples on this that will help me write the module. so if there are any API documentation and examples,plz let me know. Thanx in advance, Ashish. From jens at zope.com Mon Jul 15 15:31:30 2002 From: jens at zope.com (Jens Vagelpohl) Date: Mon, 15 Jul 2002 09:31:30 -0400 Subject: updating python from openLDAP In-Reply-To: <2AE7EB3FF3B9E14D9559582C5BA1E1A0013718@Development.LAMBENT.COM> Message-ID: <2C2C8D69-97F7-11D6-9B86-0003939EFEBC@zope.com> http://python-ldap.sourceforge.net/ On Monday, July 15, 2002, at 08:24 , Ashish Gautam wrote: > Hello everybody, > I have a runnning openLDAP server on linux. > I want to write a module in python that will add entries to the openLDAP > server. > i have python-ldap module installed too. > I just dont find any API documentation help and examples on this that will > help me write the module. > so if there are any API documentation and examples,plz let me know. > > Thanx in advance, > Ashish. From michael at stroeder.com Mon Jul 15 18:29:07 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 15 Jul 2002 18:29:07 +0200 Subject: updating python from openLDAP References: <2AE7EB3FF3B9E14D9559582C5BA1E1A0013718@Development.LAMBENT.COM> Message-ID: <3D32F853.3040403@stroeder.com> Ashish Gautam wrote: > i have python-ldap module installed too. > [..] > so if there are any API documentation and examples,plz let me > know. http://python-ldap.sf.net/docs.shtml Check out sub-directory Demo/ for examples of non-documented stuff. Ciao, Michael. From AshishG at lambenttek.com Tue Jul 16 10:42:14 2002 From: AshishG at lambenttek.com (Ashish Gautam) Date: Tue, 16 Jul 2002 14:12:14 +0530 Subject: Accessing openLDAP Server from Python Script inside a Zope CMF. Message-ID: <2AE7EB3FF3B9E14D9559582C5BA1E1A0013719@Development.LAMBENT.COM> Hi all, I am trying to access openLDAP server from a python script inside CMF site of Zope. I have python-ldap module installed on a linux machine. My final intention is to Add an LDAP entry in to LDAP server. Following code i have written in a python script just to get started by connecting to LDAP server and accessing the existing contents. Script starts: import ldap ldapCon = ldap.open("localhost") ldapCon.simple_bind_s("cn=Manager,o=Lambent","secret"); print ldapCon.search_s("ou=HR,o=Lambent",ldap.SCOPE_SUBTREE,"objectclass=*") return printed Script ends. I am clueless as to what is causing this problem. Following error i have encountered : An error was encountered while publishing this resource. Error Type: Unauthorized Error Value: You are not allowed to access open in this context Troubleshooting Suggestions The URL may be incorrect. The parameters passed to this resource may be incorrect. A resource that this resource relies on may be encountering an error. For more detailed information about the error, please refer to the HTML source for this page. If the error persists please contact the site maintainer. Thank you for your patience. Traceback (innermost last): File /usr/local/Zope2.5.1/lib/python/ZPublisher/Publish.py, line 150, in publish_module File /usr/local/Zope2.5.1/lib/python/ZPublisher/Publish.py, line 114, in publish File /usr/local/Zope2.5.1/lib/python/Zope/__init__.py, line 159, in zpublisher_exception_hook (Object: testsite) File /usr/local/Zope2.5.1/lib/python/ZPublisher/Publish.py, line 98, in publish File /usr/local/Zope2.5.1/lib/python/ZPublisher/mapply.py, line 88, in mapply (Object: ldap) File /usr/local/Zope2.5.1/lib/python/ZPublisher/Publish.py, line 39, in call_object (Object: ldap) File /usr/local/Zope2.5.1/lib/python/Shared/DC/Scripts/Bindings.py, line 252, in __call__ (Object: ldap) File /usr/local/Zope2.5.1/lib/python/Shared/DC/Scripts/Bindings.py, line 283, in _bindAndExec (Object: ldap) File /usr/local/Zope2.5.1/lib/python/Products/PythonScripts/PythonScript.py, line 302, in _exec (Object: ldap) (Info: ({'script': , 'context': , 'container': , 'traverse_subpath': []}, (), {}, None)) File Script (Python), line 7, in ldap File /usr/local/Zope2.5.1/lib/python/AccessControl/ZopeGuards.py, line 60, in guarded_getattr (Object: ldap) File /usr/local/Zope2.5.1/lib/python/AccessControl/SecurityManager.py, line 83, in validate File /usr/local/Zope2.5.1/lib/python/AccessControl/ZopeSecurityPolicy.py, line 145, in validate Unauthorized: (see above) Plz reply ASAP, Regards Ashish. From jens at zope.com Tue Jul 16 13:54:07 2002 From: jens at zope.com (Jens Vagelpohl) Date: Tue, 16 Jul 2002 07:54:07 -0400 Subject: Accessing openLDAP Server from Python Script inside a Zope CMF. In-Reply-To: <2AE7EB3FF3B9E14D9559582C5BA1E1A0013719@Development.LAMBENT.COM> Message-ID: this is a Zope question, not a python-ldap question. the simple solution: put the code into an external method instead of a python script. the hard solution: look into the documentation for the pythonscript product itself to find out how to enable access to outside modules. zope security is doing its job here. you cannot just willy-nilly import stuff in a script that can be edited through the web, it's a security disaster waiting to happen. that's why zope disallows what you are trying to do by default. jens On Tuesday, July 16, 2002, at 04:42 , Ashish Gautam wrote: > Hi all, > I am trying to access openLDAP server from a python script inside > CMF site > of Zope. > I have python-ldap module installed on a linux machine. > My final intention is to Add an LDAP entry in to LDAP server. > Following code i have written in a python script just to get > started by > connecting to LDAP server and accessing the existing contents. > > Script starts: > > import ldap > > ldapCon = ldap.open("localhost") > > ldapCon.simple_bind_s("cn=Manager,o=Lambent","secret"); > > print > ldapCon.search_s("ou=HR,o=Lambent",ldap.SCOPE_SUBTREE,"objectclass=*") > > return printed > > Script ends. > > I am clueless as to what is causing this problem. > > Following error i have encountered : > > > An error was encountered while publishing this resource. > > Error Type: Unauthorized > Error Value: You are not allowed to access open in this context > > > > Troubleshooting Suggestions > > The URL may be incorrect. > The parameters passed to this resource may be incorrect. > A resource that this resource relies on may be encountering an error. > > For more detailed information about the error, please refer to the HTML > source for this page. > > If the error persists please contact the site maintainer. Thank you > for your > patience. > > Traceback (innermost last): > File /usr/local/Zope2.5.1/lib/python/ZPublisher/Publish.py, line > 150, in > publish_module > File /usr/local/Zope2.5.1/lib/python/ZPublisher/Publish.py, line > 114, in > publish > File /usr/local/Zope2.5.1/lib/python/Zope/__init__.py, line 159, in > zpublisher_exception_hook > (Object: testsite) > File /usr/local/Zope2.5.1/lib/python/ZPublisher/Publish.py, line > 98, in > publish > File /usr/local/Zope2.5.1/lib/python/ZPublisher/mapply.py, line > 88, in > mapply > (Object: ldap) > File /usr/local/Zope2.5.1/lib/python/ZPublisher/Publish.py, line > 39, in > call_object > (Object: ldap) > File > /usr/local/Zope2.5.1/lib/python/Shared/DC/Scripts/Bindings.py, line > 252, in __call__ > (Object: ldap) > File > /usr/local/Zope2.5.1/lib/python/Shared/DC/Scripts/Bindings.py, line > 283, in _bindAndExec > (Object: ldap) > File > /usr/local/Zope2.5.1/lib/python/Products/PythonScripts/PythonScript.py, > line > 302, in _exec > (Object: ldap) > (Info: ({'script': , 'context': > , 'container': 8b10098>, > 'traverse_subpath': []}, (), {}, None)) > File Script (Python), line 7, in ldap > File /usr/local/Zope2.5.1/lib/python/AccessControl/ZopeGuards.py, > line 60, > in guarded_getattr > (Object: ldap) > File > /usr/local/Zope2.5.1/lib/python/AccessControl/SecurityManager.py, > line 83, in validate > File > /usr/local/Zope2.5.1/lib/python/AccessControl/ZopeSecurityPolicy.py, > line 145, in validate > Unauthorized: (see above) > > > Plz reply ASAP, > > Regards > Ashish. > > > > > From rferr at voicenet.com Tue Jul 16 17:00:10 2002 From: rferr at voicenet.com (rferr at voicenet.com) Date: Tue, 16 Jul 2002 11:00:10 -0400 (EDT) Subject: (no subject) Message-ID: <200207161500.LAA16189@email.voicenet.com> Hi ! I'm new to python and need a connection to our ldap via python. I have downloaded the win32 version, _ldap.pyd and ldap.py. The readme file for win32 says that is "NOT SAFE" for multi-threading, but the file itself has a date mark of 1996. Is this the version I should use or has it been updated to a version that is safe ? I don't see any real install instructions (other than the readme) and I don't see any actual examples of how the calls s/b done. Does anyone know of anywhere I can get some real-life examples of binds, searches, modifies ? The included help files don't have install instructions. Thanks, Richard Ferry From mcicogni at siosistemi.it Wed Jul 17 12:02:06 2002 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Wed, 17 Jul 2002 12:02:06 +0200 Subject: (no subject) References: <200207161500.LAA16189@email.voicenet.com> Message-ID: <3D35409E.7020004@siosistemi.it> rferr at voicenet.com wrote: >Hi ! > >I'm new to python and need a connection to our ldap via python. I have downloaded the win32 version, _ldap.pyd and ldap.py. > >The readme file for win32 says that is "NOT SAFE" for multi-threading, but the file itself has a date mark of 1996. > >Is this the version I should use or has it been updated to a version that is safe ? > >I don't see any real install instructions (other than the readme) and I don't see any actual examples of how the calls s/b done. Does anyone know of anywhere I can get some real-life examples of binds, searches, modifies ? The included help files don't have install instructions. > >Thanks, >Richard Ferry > > The multithreading part is not there yet. It's a newish development in the main tree; I haven't got the time to do it now for the Win32 part. I hope it will get there in the next few weeks. However, there is indeed a newer version under Win32, linked against OpenLDAP 2.0.23 instead of the old UMich libraries. It seems to work, but it's still in an experimental phase; if you wish to test it I may send the installer to you. Mind though that it's for Python 2.2. You also need to have the SASL DLL on your path. I may provide that if necessary. Mauro -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2926 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Wed Jul 17 17:01:15 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Wed, 17 Jul 2002 17:01:15 +0200 Subject: Caching-related DEFINE's Message-ID: <3D3586BB.3000500@stroeder.com> HI! Anyone here in favor of caching features in OpenLDAP2 libs? This feature is considered to be broken/experimental. Therefore I'd like to comment out the cache-related defines in setup.py. Comments? Ciao, Michael. From k.boehm at ewt.de Wed Jul 17 15:10:22 2002 From: k.boehm at ewt.de (Klaus Boehm) Date: Wed, 17 Jul 2002 15:10:22 +0200 Subject: newbie Message-ID: <3D356CBE.461C04F2@ewt.de> can anyone tell me how i can obtain the value from an attributetype(uid) from a user profile in ldap? this is my code: import ldap l = ldap.initialize("ldap://ldap.dmg.ewt.de:389") l.simple_bind_s("cn=admin, o=xxx", "xxxxxx") x = l.search_s("ou=People, o=xxx", ldap.SCOPE_ONELEVEL, "gecos=xxxxxx", attrlist=['uid'], attrsonly=0) print x or print x[0] ('cn=klausboehm, ou=People, o=xxx', {'uid': ['value']}) the output is a list with one index. how can i extract the value from the attribute uid? thanks for help klaus -- ewt gmbh data management group tel: ++49 821 3106 319 fax: ++49 821 3106 399 url: www.ewt.de From jens at zope.com Wed Jul 17 15:36:34 2002 From: jens at zope.com (Jens Vagelpohl) Date: Wed, 17 Jul 2002 09:36:34 -0400 Subject: newbie In-Reply-To: <3D356CBE.461C04F2@ewt.de> Message-ID: <365028FC-998A-11D6-93AB-0003939EFEBC@zope.com> "Learning Python" is a very good book that can help you deal with simple python data types... ;) print x[1]['uid'] jens On Wednesday, July 17, 2002, at 09:10 , Klaus Boehm wrote: > can anyone tell me how i can obtain the value from an attributetype(uid) > > from a user profile in ldap? > > this is my code: > > import ldap > l = ldap.initialize("ldap://ldap.dmg.ewt.de:389") > > l.simple_bind_s("cn=admin, o=xxx", "xxxxxx") > x = l.search_s("ou=People, o=xxx", ldap.SCOPE_ONELEVEL, "gecos=xxxxxx", > attrlist=['uid'], attrsonly=0) > print x > or > print x[0] > > ('cn=klausboehm, ou=People, o=xxx', {'uid': ['value']}) > > the output is a list with one index. > how can i extract the value from the attribute uid? > > > thanks for help > > klaus > > -- > > ewt gmbh > data management group > tel: ++49 821 3106 319 > fax: ++49 821 3106 399 > url: www.ewt.de > > > > > > From mcicogni at siosistemi.it Thu Jul 18 09:34:04 2002 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Thu, 18 Jul 2002 09:34:04 +0200 Subject: python-LDAP on Win32 References: <200207161500.LAA16189@email.voicenet.com> <3D35409E.7020004@siosistemi.it> <001901c22df1$bb017b80$293947d1@rferr> Message-ID: <3D366F6C.1070904@siosistemi.it> Richard Ferry wrote: >This is going to be put into a production environment, so I am hesitant to play w/ something experimental. What is your experience with it? > Well, the new version appears to work fine on my system; but I have no time to thoroughly test every feature. Mind that it's just a straightforward compilation of the same codebase everybody else's using, only done with MSVC++ (Win32, Intel). There are some quirks to the build process, but other than that, it compiles quite smoothly. >Re: the UMich libraries, are there any install instructions for this on a Win32 system? > > You just have to put the DLLs on your PATH. There's two of them, if I remember correctly, and both are needed; they were usually found (already compiled) on the UMich website. I may send you working (albeit old) binaries, if you have problems finding them. BR, Mauro -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2926 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Thu Jul 18 14:50:21 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 18 Jul 2002 14:50:21 +0200 Subject: [Fwd: libldap_r: undefined symbol: ldap_first_reference (ITS#1922)] References: Message-ID: <3D36B98D.3040000@stroeder.com> Joe Little wrote: > I did note the new 2.1.3 update too, and saw the libldap_r > build fix. Did you get a separate email from Kurt saying that it was > going to be addressed in a 2.0.x release as well? The fix appeared in the REL_ENG_2 either. ---------------------------- revision 1.57 date: 2002/07/08 22:34:41; author: kurt; state: Exp; lines: +8 -7 ITS#1922: add references.lo ---------------------------- No release yet. Ciao, Michael. From jens at zope.com Fri Jul 19 16:28:43 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 19 Jul 2002 10:28:43 -0400 Subject: FYI: ldaptor In-Reply-To: <3D270F4F.3050300@stroeder.com> Message-ID: hi michael et al, i was thinking of dropping support for python-ldap < 2.0 in new releases of some of my python products. the problem that came to mind was that people might be reluctant to switch to the latest python-ldap version because the current release name, "2.0.0pre4", makes it sound like it's not a finished release. i would be much more comfortable to tell people "get python-ldap 2.0.0" instead of "get python-ldap 2.0.0pre4". here's my question: since we all have been using 2.0.0pre4 very successfully (at least i have), would it be too much work to roll a 2.0.0 release either from 2.0.0pre4 or a later CVS-state? jens From michael at stroeder.com Fri Jul 19 16:51:01 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 19 Jul 2002 16:51:01 +0200 Subject: FYI: ldaptor References: Message-ID: <3D382755.4060709@stroeder.com> Jens Vagelpohl wrote: > > i was thinking of dropping support for python-ldap < 2.0 in new releases > of some of my python products. the problem that came to mind was that > people might be reluctant to switch to the latest python-ldap version > because the current release name, "2.0.0pre4", makes it sound like it's > not a finished release. Indeed it's not finished yet. Hence "pre". I would be willing to release a "2.0.0pre05" soon. > here's my question: since we all have been using 2.0.0pre4 very > successfully (at least i have), would it be too much work to roll a > 2.0.0 release either from 2.0.0pre4 or a later CVS-state? We did not use 2.0.0pre4 "very successfully". Remember the issues with performance fixed in current CVS? Remember open issues with libldap_r and thread-locking? I don't yet have much feedback of tests done with current CVS version. I usually don't get much feedback if I ask questions like "any objections against removing xyz...". Ciao, Michael. From michael at stroeder.com Fri Jul 19 16:52:26 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 19 Jul 2002 16:52:26 +0200 Subject: FYI: ldaptor References: Message-ID: <3D3827AA.2010706@stroeder.com> Jens Vagelpohl wrote: > > i was thinking of dropping support for python-ldap < 2.0 in new releases > of some of my python products. the problem that came to mind was that > people might be reluctant to switch to the latest python-ldap version > because the current release name, "2.0.0pre4", makes it sound like it's > not a finished release. BTW: Everybody use 1.10alpha3. How does that sound to you...? Ciao, Michael. From jens at zope.com Fri Jul 19 17:59:09 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 19 Jul 2002 11:59:09 -0400 Subject: FYI: ldaptor In-Reply-To: <3D3827AA.2010706@stroeder.com> Message-ID: <76098124-9B30-11D6-9BD0-0003939EFEBC@zope.com> that sounds even worse. however, i was hoping that the "this software is never at any finished state" from the "olden days" would be over soon :) veryone has a different philosophy about release frequency, i tend to release more often myself. jens On Friday, July 19, 2002, at 10:52 , Michael Str?der wrote: > Jens Vagelpohl wrote: >> i was thinking of dropping support for python-ldap < 2.0 in new releases >> of some of my python products. the problem that came to mind was that >> people might be reluctant to switch to the latest python-ldap version >> because the current release name, "2.0.0pre4", makes it sound like it's >> not a finished release. > > BTW: Everybody use 1.10alpha3. How does that sound to you...? > > Ciao, Michael. From michael at stroeder.com Fri Jul 19 18:30:40 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 19 Jul 2002 18:30:40 +0200 Subject: release versions (was: FYI: ldaptor) References: <76098124-9B30-11D6-9BD0-0003939EFEBC@zope.com> Message-ID: <3D383EB0.9020705@stroeder.com> Jens Vagelpohl wrote: > that sounds even worse. however, i was hoping that the "this software is > never at any finished state" from the "olden days" would be over soon :) As long as people are requesting new features appearing in OpenLDAP all the time but refuse to test thoroughly CVS versions on different platforms with different (build) configuration this piece of software won't make any significant progress to a non-beta release. > veryone has a different philosophy about release frequency, i tend to > release more often myself. 1. This does not say anything about software quality. 2. If you have full control without many users you can do almost everything you want. But people will blame me if their old code using python-ldap does not work anymore. Well, you did... The message is: python-ldap is community work. Progress is reached by at least testing it. And yes, despite the impression some of you might have my spare time is tight either. Ciao, Michael. From Hans.Aschauer at Physik.uni-muenchen.de Sat Jul 20 10:47:28 2002 From: Hans.Aschauer at Physik.uni-muenchen.de (Hans Aschauer) Date: Sat, 20 Jul 2002 10:47:28 +0200 Subject: Caching-related DEFINE's In-Reply-To: <3D3586BB.3000500@stroeder.com> References: <3D3586BB.3000500@stroeder.com> Message-ID: <200207201047.28271.Hans.Aschauer@Physik.uni-muenchen.de> On Mittwoch, 17. Juli 2002 17:01, Michael Str?der wrote: > HI! > > Anyone here in favor of caching features in OpenLDAP2 libs? This > feature is considered to be broken/experimental. Therefore I'd > like to comment out the cache-related defines in setup.py. > > Comments? Do it! Just my 2 Cents. Hans -- Hans.Aschauer at Physik.uni-muenchen.de From michael at stroeder.com Sat Jul 20 12:02:04 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Sat, 20 Jul 2002 12:02:04 +0200 Subject: Caching-related DEFINE's and mem leaks References: <3D3586BB.3000500@stroeder.com> <200207201047.28271.Hans.Aschauer@Physik.uni-muenchen.de> Message-ID: <3D39351C.6040605@stroeder.com> Hans Aschauer wrote: > On Mittwoch, 17. Juli 2002 17:01, Michael Str?der wrote: > >>Anyone here in favor of caching features in OpenLDAP2 libs? This >>feature is considered to be broken/experimental. Therefore I'd >>like to comment out the cache-related defines in setup.py. >> >>Comments? > > Do it! /bin/done Regarding the mem leaks: I can't observe them anymore with recent CVS version. Hmm, strange. I did experience mem leaks. That's why I wrote the script attached. Ciao, Michael. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: memleak.py URL: From jens at zope.com Sat Jul 20 15:51:35 2002 From: jens at zope.com (Jens Vagelpohl) Date: Sat, 20 Jul 2002 09:51:35 -0400 Subject: python-ldap 2.0.0pre05 In-Reply-To: <3D393AAA.8090607@stroeder.com> Message-ID: thanks michael. as far as you asking questions to the list concerning development decisions and not getting a lot of responses, at least in my own case most that you have asked about so far was about functionalities and parts of the code that i have never used myself (and sometimes never even heard about). that's why i can't really give too much meaningful feedback. my own products don't exercise python-ldap beyond very standard method calls. :( jens On Sat, 20 Jul 2002 12:25:46 +0200 =?ISO-8859-15?Q?Michael_Str=F6der?= wrote: > HI! > > Find a new pre-release of python-ldap: > > http://python-ldap.sf.net/download.shtml > > Ciao, Michael. > From jlittle at open-it.org Sun Jul 21 00:14:37 2002 From: jlittle at open-it.org (Joe Little) Date: Sat, 20 Jul 2002 15:14:37 -0700 Subject: python-ldap 2.0.0pre05 In-Reply-To: <3D393AAA.8090607@stroeder.com> Message-ID: <13F7DB04-9C2E-11D6-A1D2-0003930B38C0@open-it.org> Michael, can you adjust the freshmeat RPM link to point to www.open-it.org/download/ (since pre04 is in redhat 7.2 and pre05 will shortly be in at least 7.3) -- currently it points to 7.1 where the 1.10alpha3 RPMs are. On Saturday, July 20, 2002, at 03:25 AM, Michael Str?der wrote: > HI! > > Find a new pre-release of python-ldap: > > http://python-ldap.sf.net/download.shtml > > Ciao, Michael. > > > > From k.boehm at ewt.de Mon Jul 22 13:43:15 2002 From: k.boehm at ewt.de (Klaus Boehm) Date: Mon, 22 Jul 2002 13:43:15 +0200 Subject: parameter problem Message-ID: <3D3BEFD3.88A9F791@ewt.de> I have this line in my sourcecode. s = l.search_s("ou=xxxxx, o=xxx", ldap.SCOPE_SUBTREE, gecos, attrlist=['uidnumber','gidnumber','uid'], attrsonly=0) and i want pass the parameter filterstring as a variable(gecos) from another programm(Website). But i get an error: "ldap.FILTER_ERROR: {'desc': 'Bad search filter'}" What can i do to avoid this error? Thanks for help. Klaus -- ewt gmbh data management group tel: ++49 821 3106 319 fax: ++49 821 3106 399 url: www.ewt.de From Hans.Aschauer at Physik.uni-muenchen.de Mon Jul 22 14:12:49 2002 From: Hans.Aschauer at Physik.uni-muenchen.de (Hans Aschauer) Date: Mon, 22 Jul 2002 14:12:49 +0200 Subject: parameter problem In-Reply-To: <3D3BEFD3.88A9F791@ewt.de> References: <3D3BEFD3.88A9F791@ewt.de> Message-ID: <200207221412.49475.Hans.Aschauer@Physik.uni-muenchen.de> On Montag, 22. Juli 2002 13:43, Klaus Boehm wrote: > I have this line in my sourcecode. > > > s = l.search_s("ou=xxxxx, o=xxx", ldap.SCOPE_SUBTREE, gecos, > attrlist=['uidnumber','gidnumber','uid'], attrsonly=0) > > and i want pass the parameter filterstring as a variable(gecos) from > another programm(Website). > But i get an error: "ldap.FILTER_ERROR: {'desc': 'Bad > search filter'}" > > What can i do to avoid this error? Could you please tell us the contents of the gecos variable? Since the error is a 'Bad search filter', it would be really helpful to know the search filter... Useful searchfilters look like '(objectclass=*)', or '(gecos=xyz)'. If xyz is in your gecos variable, you can build the search filter with '(gecos=%s)' % gecos HTH, Hans -- Hans.Aschauer at Physik.uni-muenchen.de From michael at stroeder.com Mon Jul 22 14:12:28 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 22 Jul 2002 14:12:28 +0200 Subject: parameter problem References: <3D3BEFD3.88A9F791@ewt.de> Message-ID: <3D3BF6AC.3080600@stroeder.com> Klaus Boehm wrote: > > s = l.search_s("ou=xxxxx, o=xxx", ldap.SCOPE_SUBTREE, gecos, > attrlist=['uidnumber','gidnumber','uid'], attrsonly=0) > > and i want pass the parameter filterstring as a variable(gecos) from > another programm(Website). > But i get an error: "ldap.FILTER_ERROR: {'desc': 'Bad search > filter'}" > > What can i do to avoid this error? Provide a correct search filter (see RFC2254). Example: '(gecos=*klaus*)' Ciao, Michael. From jlittle at cs.stanford.edu Mon Jul 22 22:22:19 2002 From: jlittle at cs.stanford.edu (Joe Little) Date: Mon, 22 Jul 2002 13:22:19 -0700 Subject: 2.0.0pre05 RPMs Message-ID: are now up and posted via ftp.open-it.org. There are both RH7.2 and RH7.3 versions, the former using Python 2.1, and the latter using Python 2.2. Michael: Freshmeat.net still points to the redhat7.1 directory for RPMs. Is this something that I can somehow change? From michael at stroeder.com Mon Jul 22 22:40:22 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 22 Jul 2002 22:40:22 +0200 Subject: 2.0.0pre05 RPMs References: Message-ID: <3D3C6DB6.7080203@stroeder.com> Joe Little wrote: > > Michael: Freshmeat.net still points to the redhat7.1 directory for RPMs. > Is this something that I can somehow change? Since you created the python-ldap project entry on Freshmeat.net you should be able to request modifications. I requested a change of the project description a couple of days ago. Ciao, Michael. From Guillaume.Wenger at socgen.com Thu Jul 25 09:29:10 2002 From: Guillaume.Wenger at socgen.com (WENGER G DsigTcs) Date: Thu, 25 Jul 2002 09:29:10 +0200 Subject: ldap, ldap_r and thread problem Message-ID: Hi, I'm using Zope. my index.html page has 4 frames. Before, my 4 frames appeared without problem. Then, I've installed LDAPUserFolder which uses python ldap. And now, I often have one (different each time) of my frames which causes in Internal Error of Apache (because of no answer from Zope). I've tried to launch Zope with -M and I've seen that there was 4 'Get' but only 3 answers. So, my conclusion it's that Zope catchs the 4 'simultaneous' requests but answers only to 3. I have a lot of difficulties to find the origin of my problem. I've installed python ldap 2.0.0pre05 (compiled with Lib: ldap_r ldap lber resolv) and OpenLDAP 2.0.25-2. Is it the fault of LDAPUserFolder for, perhaps, a thread reason? Or Is it a problem with python ldap? May you help me? What can I do? I am using : Zope 2.5.1 Pyhton 2.1.3 LDAPUserFolder 1.5beta1 Python ldap 2.0.0pre05 (compiled with ldap_r) OpenLDAP 2.0.25-2 Thanks, ************************************************************************* Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. ******** This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************************************************************************* From michael at stroeder.com Thu Jul 25 11:50:09 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 25 Jul 2002 11:50:09 +0200 Subject: ldap, ldap_r and thread problem References: Message-ID: <3D3FC9D1.302@stroeder.com> WENGER G DsigTcs wrote: > > python ldap 2.0.0pre05 > (compiled with Lib: ldap_r ldap lber resolv) Use either ldap or ldap_r as given in the examples in setup.cfg. Not both! In any case the proper locking should be done to serialize the calls according to the requirements of either ldap or ldap_r. > Is it the fault of LDAPUserFolder for, perhaps, a thread reason? Or Is it a > problem with python ldap? May you help me? What can I do? I'm sure Jens can give more detailed information here. But I guess it's not a thread problem. Ciao, Michael. From ml-it-python-ldap-dev at epigenomics.com Thu Jul 25 10:31:33 2002 From: ml-it-python-ldap-dev at epigenomics.com (Robert Sander) Date: Thu, 25 Jul 2002 08:31:33 +0000 (UTC) Subject: port of Net::LDAP::Entry Message-ID: Hi! We have been using the Perl Net::LDAP modules to access our directory server. Now we want to switch to Python. This is a first port of Net::LDAP::Entry class Entry: import ldap def __init__(self, dn, values = {}): self.distname = dn self.values = values self.chgtype = "add" self.changes = [] def __str__(self): return "%s[%s]: %s" % ( self.distname, self.chgtype, self.values ) def get_value(self, attr): try: return self.values[attr] except KeyError, er: return None def changetype(self, typ = None): if typ: self.chgtype = typ self.changes = [] else: return self.chgtype def dn(self, dn = None): if dn: self.distname = dn else: return self.distname def exists(self, attr): return self.values.has_key(attr) def add(self, attrs): if type(attrs) != type([]): attrs = [attrs] for typ, val in attrs: if type(val) != type([]): val = [val] if self.values.has_key(typ): self.values[typ].extend(val) if self.chgtype == "modify": self.changes.append((ldap.MOD_REPLACE, typ, self.values[typ])) else: self.values[typ] = val if self.chgtype == "modify": self.changes.append((ldap.MOD_ADD, typ, val)) def replace(self, attrs): if type(attrs) != type([]): attrs = [attrs] for typ, val in attrs: if type(val) != type([]): val = [val] self.values[typ] = val if self.chgtype == "modify": self.changes.append((ldap.MOD_REPLACE, typ, val)) def delete(self, attrs = None): if attrs: if type(attrs) != type([]): attrs = [attrs] for attr in attrs: if self.values.has_key(attr): del(self.values[attr]) if self.chgtype == "modify": self.changes.append((ldap.MOD_DELETE, attr, None)) def update(self, l): if self.chgtype == "add": import ldap.modlist return l.add_s(self.distname, ldap.modlist.addModlist(self.values)) elif self.chgtype == "delete": return l.delete_s(self.distname) elif self.chgtype == "modify": return l.modify_s(self.distname, self.changes) You may find it useful. We have a directory service set up with OpenLDAP extensively using referrals. It seems that python-ldap currently is not able to handle these. Is this correct? Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From michael at stroeder.com Thu Jul 25 12:09:06 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 25 Jul 2002 12:09:06 +0200 Subject: port of Net::LDAP::Entry References: Message-ID: <3D3FCE42.20404@stroeder.com> Robert Sander wrote: > This is a first port of > Net::LDAP::Entry I have to admit that I do not know Net::LDAP::Entry. Therefore I might not fully understand the rationale. Check out ldap.modlist.modifyModlist(). Simply copy your old entry tweak the new entry's dictionary and create a list you can directly pass to LDAPObject.modify()/modify_s(). In some cases that might not work since there's no smart schema handling of the LDAP syntaxes but most times it's pretty convenient. Ciao, Michael. From robert.sander at epigenomics.com Thu Jul 25 12:15:39 2002 From: robert.sander at epigenomics.com (Robert Sander) Date: Thu, 25 Jul 2002 12:15:39 +0200 Subject: port of Net::LDAP::Entry In-Reply-To: <3D3FCE42.20404@stroeder.com> References: <3D3FCE42.20404@stroeder.com> Message-ID: <20020725101539.GA708@epigenomics.de> On Thu, Jul 25, 2002 at 12:09:06PM +0200, Michael Str?der wrote: > Robert Sander wrote: > >This is a first port of > >Net::LDAP::Entry > > I have to admit that I do not know Net::LDAP::Entry. Therefore I > might not fully understand the rationale. As I wrote we are currently using these Perl modules in our scripts. I ported this class to make the transition easy. Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From gurubert-news at epigenomics.com Thu Jul 25 12:24:23 2002 From: gurubert-news at epigenomics.com (Robert Sander) Date: Thu, 25 Jul 2002 12:24:23 +0200 Subject: Referral support (was: port of Net::LDAP::Entry) In-Reply-To: <3D3FCBF9.30701@stroeder.com> References: <3D3FCBF9.30701@stroeder.com> Message-ID: <20020725102423.GB708@epigenomics.de> On Thu, Jul 25, 2002 at 11:59:21AM +0200, Michael Str?der wrote: > Robert Sander wrote: > >We have a directory service set up with OpenLDAP extensively using > >referrals. It seems that python-ldap currently is not able to handle > >these. Is this correct? > > Before I write a pile of postings about it I'd like to know what > your understanding of handling referrals is. The Perl modules in Net::LDAP return a entries array and a references array after a search when the parameter "deref" is set to 3. I think this is DEREF_ALWAYS. With the referrals you are able to search further in the tree. I admit that I haven't tried to use l.deref = ldap.DEREF_ALWAYS and look at the result. Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From michael at stroeder.com Thu Jul 25 12:42:30 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Thu, 25 Jul 2002 12:42:30 +0200 Subject: Referral support (was: port of Net::LDAP::Entry) References: <3D3FCBF9.30701@stroeder.com> <20020725102423.GB708@epigenomics.de> Message-ID: <3D3FD616.2090501@stroeder.com> Robert Sander wrote: > On Thu, Jul 25, 2002 at 11:59:21AM +0200, Michael Str?der wrote: > >>Before I write a pile of postings about it I'd like to know what >>your understanding of handling referrals is. > > The Perl modules in Net::LDAP return a entries array and a references > array after a search when the parameter "deref" is set to 3. I think > this is DEREF_ALWAYS. Option OPT_DEREF has nothing to do with referrals. It's for aliases. OPT_REFERRALS is the relevant option which defines whether the OpenLDAP library internally follows referrals or not. > With the referrals you are able to search further in the tree. If you switch off internal referral handling you will receive search continuations along with normal search results as tuples with None as first item and a string containing the LDAP URL as second item. (Note that it might block when python-ldap is using the OpenLDAP 2.1 libs. I did not have the possibility to track down this issue.) See example: http://sites.inka.de:8002/web2ldap?ldap://ldap.rediris.es/dc%3Des??one? (Please use [Disconnect] after use to quickly erase the LDAP connection. This demo runs on a restricted shell-account allowing only 24 file handles). Example code: From michael at stroeder.com Thu Jul 25 17:34:43 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Thu, 25 Jul 2002 17:34:43 +0200 Subject: Setting options via class attributes of LDAPObject Message-ID: <3D401A93.9050408@stroeder.com> HI! I'd like to remove the possibility to set/get LDAP options via class attributes of ldap.LDAPObject instances since it's error-prone and kludgy code. LDAPObject.set_option() and LDAPObject.get_option() is the complete solution. Although it might break existing code if I remove LDAPObject.__setattr__() and LDAPObject.__getattr__(). Therefore I'd like to ask who is setting LDAP options via class attributes? Ciao, Michael. From michael at stroeder.com Thu Jul 25 18:27:29 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Thu, 25 Jul 2002 18:27:29 +0200 Subject: Setting options via class attributes of LDAPObject References: <3D401A93.9050408@stroeder.com> Message-ID: <3D4026F1.8030508@stroeder.com> Michael Str?der wrote: > > I'd like to remove the possibility to set/get LDAP options via class > attributes of ldap.LDAPObject instances since it's error-prone and > kludgy code. > > LDAPObject.set_option() and LDAPObject.get_option() is the complete > solution. > > Although it might break existing code if I remove > LDAPObject.__setattr__() and LDAPObject.__getattr__(). Therefore I'd > like to ask who is setting LDAP options via class attributes? Hmm, I've checked in a much less complex implementation of LDAPObject.__setattr__() and LDAPObject.__getattr__(). But I'd really like to remove getattr() and setattr() in LDAPObject.c since it does not make sense to do this at the C level. But if I remove getattr() and setattr() the set_option() and get_option() method are also removed. David, can you please enlighten me how the stuff in options.c works? It seems somewhat overly complex to me. Ciao, Michael. From jens at zope.com Thu Jul 25 18:45:08 2002 From: jens at zope.com (Jens Vagelpohl) Date: Thu, 25 Jul 2002 12:45:08 -0400 Subject: Setting options via class attributes of LDAPObject In-Reply-To: <3D401A93.9050408@stroeder.com> Message-ID: +1 IMHO direct attribute access without going through methods is nasty jens On Thursday, July 25, 2002, at 11:34 , Michael Str?der wrote: > HI! > > I'd like to remove the possibility to set/get LDAP options via class > attributes of ldap.LDAPObject instances since it's error-prone and kludgy > code. > > LDAPObject.set_option() and LDAPObject.get_option() is the complete > solution. > > Although it might break existing code if I remove > LDAPObject.__setattr__() and LDAPObject.__getattr__(). Therefore I'd like > to ask who is setting LDAP options via class attributes? > > Ciao, Michael. From ml-it-python-ldap-dev at epigenomics.com Thu Jul 25 23:01:03 2002 From: ml-it-python-ldap-dev at epigenomics.com (Robert Sander) Date: Thu, 25 Jul 2002 21:01:03 +0000 (UTC) Subject: Referral support (was: port of Net::LDAP::Entry) References: <3D3FCBF9.30701@stroeder.com> <20020725102423.GB708@epigenomics.de> <3D3FD616.2090501@stroeder.com> Message-ID: On Thu, 25 Jul 2002 10:45:12 +0000 (UTC), Michael Str?der wrote: > import ldap > > l=ldap.initialize('ldap://ldap.rediris.es') > l.set_option(ldap.OPT_PROTOCOL_VERSION,ldap.VERSION3) > l.set_option(ldap.OPT_REFERRALS,0) > result = l.search_s('dc=es',ldap.SCOPE_ONELEVEL,'(objectClass=*)') > for i in result: > print i Thanks for the example code. That actually works! I think I have to check all these options and their meaning again. ;-) Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From michael at stroeder.com Thu Jul 25 23:21:17 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Thu, 25 Jul 2002 23:21:17 +0200 Subject: Referral support (was: port of Net::LDAP::Entry) References: <3D3FCBF9.30701@stroeder.com> <20020725102423.GB708@epigenomics.de> <3D3FD616.2090501@stroeder.com> Message-ID: <3D406BCD.9000607@stroeder.com> Michael Str?der wrote: > > If you switch off internal referral handling you will receive search > continuations along with normal search results as tuples with None as > first item and a string containing the LDAP URL as second item. I forgot something: If the search root is itself matched by a referral a ldap.REFERRAL exception is raised. You have to extract the referral's LDAP URL and matched field from the exception instance. Feel free to check out web2ldap's sources pylib/w2lapp/handler.py and pylib/w2lapp/referral.py. Your mileage may vary. Note that there are many issues to deal with either in your concept or your application when extensively using referrals. Ciao, Michael. From michael at stroeder.com Thu Jul 25 11:59:21 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 25 Jul 2002 11:59:21 +0200 Subject: Referral support (was: port of Net::LDAP::Entry) References: Message-ID: <3D3FCBF9.30701@stroeder.com> Robert Sander wrote: > We have a directory service set up with OpenLDAP extensively using > referrals. It seems that python-ldap currently is not able to handle > these. Is this correct? There is support for it. But it's a rather complex topic. Your mileage may vary. Before I write a pile of postings about it I'd like to know what your understanding of handling referrals is. Ciao, Michael. From michael at stroeder.com Fri Jul 26 01:09:36 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Fri, 26 Jul 2002 01:09:36 +0200 Subject: setting/getting ldap.OPT_TIMEOUT and ldap.OPT_NETWORK_TIMEOUT Message-ID: <3D408530.9050803@stroeder.com> HI! Hmm, I tried to implement setting/getting options LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT in Moduls/options.c. But it does not seem to work. No wonder because C makes my eyes hurt! Can somebody please dig into options.c and review the nonsense I added? ;-) Ciao, Michael. From gurubert-news at epigenomics.com Fri Jul 26 07:26:28 2002 From: gurubert-news at epigenomics.com (Robert Sander) Date: Fri, 26 Jul 2002 07:26:28 +0200 Subject: Referral support (was: port of Net::LDAP::Entry) In-Reply-To: <3D406BCD.9000607@stroeder.com> References: <3D3FCBF9.30701@stroeder.com> <20020725102423.GB708@epigenomics.de> <3D3FD616.2090501@stroeder.com> <3D406BCD.9000607@stroeder.com> Message-ID: <20020726052628.GA19238@epigenomics.com> On Thu, Jul 25, 2002 at 11:21:17PM +0200, Michael Str?der wrote: > I forgot something: If the search root is itself matched by a > referral a ldap.REFERRAL exception is raised. I already got that exception. > Note that there are many issues to deal with either in your > concept or your application when extensively using referrals. We have a "wrapper" search function that will deal with this. Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From michael at stroeder.com Fri Jul 26 12:41:45 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Fri, 26 Jul 2002 12:41:45 +0200 Subject: Referral support (was: port of Net::LDAP::Entry) References: <3D3FCBF9.30701@stroeder.com> <20020725102423.GB708@epigenomics.de> <3D3FD616.2090501@stroeder.com> <3D406BCD.9000607@stroeder.com> <20020726052628.GA19238@epigenomics.com> Message-ID: <3D412769.8050601@stroeder.com> Robert Sander wrote: > >>Note that there are many issues to deal with either in your >>concept or your application when extensively using referrals. > > We have a "wrapper" search function that will deal with this. This might be a nice inspiration for python-ldap. Ciao, Michael. From mbagepll at memphis.edu Fri Jul 26 17:39:38 2002 From: mbagepll at memphis.edu (mbagepll at memphis.edu) Date: Fri, 26 Jul 2002 10:39:38 -0500 Subject: python-ldap-2.0.0pre05 and zope Message-ID: Hi all, I am trying to install python-ldap module for zope 2.5.1 on solaris 8. I am using netscape LDAP C library (there was no problem compiling it). I built and installed python-ldap and there were no errors. But, when i try to start zope, I get the following error- ------ 2002-07-26T14:22:40 ERROR(200) Zope Could not import Products.LDAPUserFolder Traceback (innermost last): File /opt/local/web/zope/jed/lib/python/OFS/Application.py, line 531, in import_product File /opt/local/web/zope/jed/lib/python/Products/LDAPUserFolder/__init__ .py, line 13, in ? File /opt/local/web/zope/jed/lib/python/Products/LDAPUserFolder/LDAPUser Folder.py, line 11, in ? File /opt/local/web/zope/jed/lib/python/Products/LDAPUserFolder/LDAPUser .py, line 20, in ? (Object: aq_inner) File /opt/local/web/zope/jed/lib/python/Products/LDAPUserFolder/utils.py , line 32, in ? File /opt/local/web/zope/jed/lib/python2.1/site- packages/ldap/__init__.py, line 11, in ? ImportError: ld.so.1: /opt/local/web/zope/jed/bin/python: fatal: libgcc_s.so.1: open failed: No such file or directory And then, i invoked the zope python interpreter and tried to import _ldap module. The error it throws is - >>> import _ldap Traceback (most recent call last): File "", line 1, in ? ImportError: ld.so.1: /opt/local/web/zope/jed/bin/python: fatal: relocation error: file /opt/local/web/zope/jed/lib/python2.1/site- packages/_ldap.so: symbol ldap_start_tls_s: referenced symbol not found >>> Can anyone help me in this matter? --Madhavi -------------- next part -------------- A non-text attachment was scrubbed... Name: "mbagepll.vcf Type: text/x-vcard Size: 258 bytes Desc: Card for URL: From mcicogni at siosistemi.it Fri Jul 26 17:44:36 2002 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Fri, 26 Jul 2002 17:44:36 +0200 Subject: python-ldap-2.0.0pre05 and zope References: Message-ID: <3D416E64.9000102@siosistemi.it> mbagepll at memphis.edu wrote: >I am trying to install python-ldap module for zope 2.5.1 on solaris 8. >I am using netscape LDAP C library ... > Unfortunately the current version of Python-ldap uses only the OpenLDAP 2.x libraries. There's no more support for Netscape libs since the 1.x branch was abandoned. Mauro -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2926 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Fri Jul 26 17:52:26 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 26 Jul 2002 17:52:26 +0200 Subject: python-ldap-2.0.0pre05 and zope References: Message-ID: <3D41703A.2020908@stroeder.com> mbagepll at memphis.edu wrote: > > I am trying to install python-ldap module for zope 2.5.1 on solaris 8. > I am using netscape LDAP C library (there was no problem compiling it). Note that since LDAP C libs are diverging solely building against OpenLDAP 2.x libs is supported. > ImportError: ld.so.1: /opt/local/web/zope/jed/bin/python: fatal: > libgcc_s.so.1: open failed: No such file or directory No clue... > And then, i invoked the zope python interpreter and tried to import > _ldap module. The error it throws is - > >>>>import _ldap >>> > Traceback (most recent call last): > File "", line 1, in ? > ImportError: ld.so.1: /opt/local/web/zope/jed/bin/python: fatal: > relocation error: file /opt/local/web/zope/jed/lib/python2.1/site- > packages/_ldap.so: symbol ldap_start_tls_s: referenced symbol not found Although Netscape libs are not supported you could try to comment the line with HAVE_LDAP_START_TLS_S in setup.py. But don't waste too much time with it. I removed some code for old Netscape 3 API. => grab OpenLDAP 2.0.25 and compile the libs. Ciao, Michael. From mbagepll at memphis.edu Fri Jul 26 20:25:12 2002 From: mbagepll at memphis.edu (mbagepll at memphis.edu) Date: Fri, 26 Jul 2002 13:25:12 -0500 Subject: python-ldap-2.0.0pre05 and zope Message-ID: To compile openldap-2.0.25, I followed the INSTALL manual. I did the following: 1) ./configure --disable-slapd --disable-slurpd --with- python=/opt/local/web/zope/bin/python 2) make depend 3) make when run the make command, I get the following errors. ld: fatal: library -lsasl: not found ld: fatal: File processing errors. No output written to .libs/libldap.so.2.0.16 *** Error code 1 make: Fatal error: Command failed for target `libldap.la' Current working directory /opt/local/web/ldap/openldap- 2.0.25/libraries/libldap *** Error code 1 make: Fatal error: Command failed for target `all-common' Current working directory /opt/local/web/ldap/openldap-2.0.25/libraries *** Error code 1 make: Fatal error: Command failed for target `all-common' I checked the /opt/local/web/ldap/openldap-2.0.25/libraries/ for 'libldap.la' file and there was not one. Instead it has a libldap folder. I checked to see if the file exists there, but could not find one. Am i missing something here? --Madhavi -------------- next part -------------- A non-text attachment was scrubbed... Name: "mbagepll.vcf Type: text/x-vcard Size: 258 bytes Desc: Card for URL: From jlittle at open-it.org Fri Jul 26 20:29:55 2002 From: jlittle at open-it.org (Joe Little) Date: Fri, 26 Jul 2002 11:29:55 -0700 Subject: python-ldap-2.0.0pre05 and zope In-Reply-To: Message-ID: OpenLDAP depends on the cyrus-sasl package.. Though you can install OpenLDAP without it, the python-ldap API links to that package as well via OpenLDAP libs. On Friday, July 26, 2002, at 11:25 AM, wrote: > To compile openldap-2.0.25, I followed the INSTALL manual. > I did the following: > > 1) ./configure --disable-slapd --disable-slurpd --with- > python=/opt/local/web/zope/bin/python > > 2) make depend > > 3) make > when run the make command, I get the following errors. > > ld: fatal: library -lsasl: not found > ld: fatal: File processing errors. No output written > to .libs/libldap.so.2.0.16 > *** Error code 1 > make: Fatal error: Command failed for target `libldap.la' > Current working directory /opt/local/web/ldap/openldap- > 2.0.25/libraries/libldap > *** Error code 1 > make: Fatal error: Command failed for target `all-common' > Current working directory /opt/local/web/ldap/openldap-2.0.25/libraries > *** Error code 1 > make: Fatal error: Command failed for target `all-common' > > I checked the /opt/local/web/ldap/openldap-2.0.25/libraries/ > for 'libldap.la' file and there was not one. Instead it has a libldap > folder. I checked to see if the file exists there, but could not find > one. > > Am i missing something here? > > --Madhavi > > From mbagepll at memphis.edu Fri Jul 26 20:45:34 2002 From: mbagepll at memphis.edu (mbagepll at memphis.edu) Date: Fri, 26 Jul 2002 13:45:34 -0500 Subject: python-ldap-2.0.0pre05 and zope Message-ID: Hi, Even when I configure openldap-2.0.25 with cyrus-sasl, I get the same errors when I run the 'make' command. --Madhavi -------------- next part -------------- A non-text attachment was scrubbed... Name: "mbagepll.vcf Type: text/x-vcard Size: 258 bytes Desc: Card for URL: From michael at stroeder.com Fri Jul 26 20:51:31 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 26 Jul 2002 20:51:31 +0200 Subject: python-ldap-2.0.0pre05 and zope References: Message-ID: <3D419A33.7020908@stroeder.com> Joe Little wrote: > OpenLDAP depends on the cyrus-sasl package.. Though you can install > OpenLDAP without it, Yes, ./configure --without-cyrus-sasl is the solution if one does not need SASL support. > the python-ldap API links to that package as well > via OpenLDAP libs. Only if line "libs" in setup.cfg contains "sasl" which is not the way it is shipped in the download distribution. There are other dependencies like StartTLS support which needs OpenLDAP libs built with OpenSSL (--with-tls). One can switch that off by editing the DEFINEs in setup.py. Ciao, Michael. From jlittle at open-it.org Fri Jul 26 20:49:30 2002 From: jlittle at open-it.org (Joe Little) Date: Fri, 26 Jul 2002 11:49:30 -0700 Subject: python-ldap-2.0.0pre05 and zope In-Reply-To: Message-ID: <6B0B21F8-A0C8-11D6-9766-0003930B38C0@open-it.org> I can only guess that it cannot find the cyrus-sasl libs. Check the library path. On Friday, July 26, 2002, at 11:45 AM, wrote: > Hi, > > Even when I configure openldap-2.0.25 with cyrus-sasl, I get the same > errors when I run the 'make' command. > > --Madhavi > From poster at bitstream.net Fri Jul 26 20:58:35 2002 From: poster at bitstream.net (Jacob Behm) Date: Fri, 26 Jul 2002 13:58:35 -0500 Subject: ZLDAPAdapter problems In-Reply-To: Message-ID: <368D67626F94DC42890180F75B1E97C70DFA26@newman.bisinc.net> Hi, I'm new to this group so if I'm out line with any of my questions please let me know. I'm building an intra/extranet in Zope and as my company already has all the groups and users defined in a MS Active Directory system, I'm trying to link Zope to our AD server using LDAP. I've installed the LDAP module for python and the ZLDAPAdapter for Zope seems to be working. But when I try to use it I get the following Zope error: "Zope has encountered an error while publishing this resource. Error Type: DECODING_ERROR Error Value: {'desc': 'Decoding error'}" I understand that this means that python couldn't interpret the response it got from my AD server. Is there a way for me to see the response? Has anyone tried this before? I could use a little guidance. Thanks, Jacob Behm From michael at stroeder.com Fri Jul 26 21:11:52 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 26 Jul 2002 21:11:52 +0200 Subject: ZLDAPAdapter problems References: <368D67626F94DC42890180F75B1E97C70DFA26@newman.bisinc.net> Message-ID: <3D419EF8.4090503@stroeder.com> Jacob Behm wrote: > > Error Type: DECODING_ERROR > Error Value: {'desc': 'Decoding error'}" Which version of OpenLDAP? Which version of python-ldap? Ciao, Michael. From jens at zope.com Fri Jul 26 21:13:52 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 26 Jul 2002 15:13:52 -0400 Subject: ZLDAPAdapter problems In-Reply-To: <368D67626F94DC42890180F75B1E97C70DFA26@newman.bisinc.net> Message-ID: ZLDAPAdapter is a really old zope product. i don't think it is being actively maintained. the correct people to talk to are the maintainers of that particular product. jens On Friday, July 26, 2002, at 02:58 , Jacob Behm wrote: > Hi, > > I'm new to this group so if I'm out line with any of my questions please > let me know. > > I'm building an intra/extranet in Zope and as my company already has all > the groups and users defined in a MS Active Directory system, I'm trying > to link Zope to our AD server using LDAP. I've installed the LDAP > module for python and the ZLDAPAdapter for Zope seems to be working. > But when I try to use it I get the following Zope error: > > "Zope has encountered an error while publishing this resource. > > Error Type: DECODING_ERROR > Error Value: {'desc': 'Decoding error'}" > > I understand that this means that python couldn't interpret the response > it got from my AD server. Is there a way for me to see the response? > > Has anyone tried this before? I could use a little guidance. > > Thanks, > > Jacob Behm From poster at bitstream.net Fri Jul 26 22:16:33 2002 From: poster at bitstream.net (Jacob Behm) Date: Fri, 26 Jul 2002 15:16:33 -0500 Subject: ZLDAPAdapter problems In-Reply-To: <3D419EF8.4090503@stroeder.com> Message-ID: <368D67626F94DC42890180F75B1E97C70DFA27@newman.bisinc.net> I don't know that I'm using any OpenLDAP. Would that be my problem? This Zope is running on a win32 machine. The python LDAP module is v1.10a3. > -----Original Message----- > From: Michael Str?der [mailto:michael at stroeder.com] > Sent: Friday, July 26, 2002 2:12 PM > To: Jacob Behm > Cc: python-ldap-dev at lists.sourceforge.net > Subject: Re: ZLDAPAdapter problems > > Jacob Behm wrote: > > > > Error Type: DECODING_ERROR > > Error Value: {'desc': 'Decoding error'}" > > Which version of OpenLDAP? Which version of python-ldap? > > Ciao, Michael. From jens at zope.com Fri Jul 26 22:51:35 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 26 Jul 2002 16:51:35 -0400 Subject: ZLDAPAdapter problems In-Reply-To: <368D67626F94DC42890180F75B1E97C70DFA27@newman.bisinc.net> Message-ID: <792007CE-A0D9-11D6-A9E4-0003939EFEBC@zope.com> i think another problem is active directory itself. i have a few python-based software pieces that work with LDAP and i always explicitly tell people there is no guarantee it will work with the "wannabe LDAP server" M$ calls "active directory". in the best M$ tradition it follows its very own standards, not anyone else's. trying to code around all those nonstandard behaviors is a *pain*. jens On Friday, July 26, 2002, at 04:16 , Jacob Behm wrote: > I don't know that I'm using any OpenLDAP. Would that be my problem? > This Zope is running on a win32 machine. The python LDAP module is > v1.10a3. > > >> -----Original Message----- >> From: Michael Str?der [mailto:michael at stroeder.com] >> Sent: Friday, July 26, 2002 2:12 PM >> To: Jacob Behm >> Cc: python-ldap-dev at lists.sourceforge.net >> Subject: Re: ZLDAPAdapter problems >> >> Jacob Behm wrote: >>> >>> Error Type: DECODING_ERROR >>> Error Value: {'desc': 'Decoding error'}" >> >> Which version of OpenLDAP? Which version of python-ldap? >> >> Ciao, Michael. > From michael at stroeder.com Sat Jul 27 01:35:52 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 27 Jul 2002 01:35:52 +0200 Subject: ZLDAPAdapter problems References: <368D67626F94DC42890180F75B1E97C70DFA27@newman.bisinc.net> Message-ID: <3D41DCD8.9070808@stroeder.com> Jacob Behm wrote: > I don't know that I'm using any OpenLDAP. Would that be my problem? > This Zope is running on a win32 machine. The python LDAP module is > v1.10a3. Then your Win32 python-ldap binaries are using the old Umich LDAP libraries which can only do LDAPv2. This is probably the reason for your problems with MS AD. Also note that python-ldap 1.10a3 is pretty outdated and only supports LDAPv2. Ciao, Michael. From michael at stroeder.com Sat Jul 27 15:25:34 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Sat, 27 Jul 2002 15:25:34 +0200 Subject: Changes to setup.py and setup.cfg Message-ID: <3D429F4E.7070802@stroeder.com> HI! I've checked in some changes to setup.py and setup.cfg hopefully simplyfing this. 1. Renamed DEFINE name HAVE_LDAP_START_TLS_S to HAVE_TLS. 2. HAVE_TLS is set by looking at line libs in setup.cfg. If it contains ssl *and* crypto HAVE_TLS is set. Otherwise support for StartTLS extended operation and LDAP over SSL is turned off. 3. I dropped support for line class in section [_ldap] of setup.cfg since we won't have support for other LDAP C SDKs. Please test if these changes have any bad implications on various build platforms. Ciao, Michael. From michael at stroeder.com Sat Jul 27 22:38:35 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Sat, 27 Jul 2002 22:38:35 +0200 Subject: ldap.schema: str2objectclass() fails Message-ID: <3D4304CB.9070509@stroeder.com> HI! ldap.schema.str2objectclass() fails when parsing the following string (from Netscape DS 4.16SP1 sub schema sub entry): "( 2.5.6.1 NAME 'alias' DESC 'Standard ObjectClass' SUP 'top' MUST ( objectclass $ aliasedObjectName ) MAY ( aci ) )" This schema string does not look unusual to me but... >>> ldap.schema.str2objectclass("( 2.5.6.1 NAME 'alias' DESC 'Standard ObjectClass' SUP 'top' MUST ( objectclass $ aliasedObjectName ) MAY ( aci ) )") Error: 6: MUST ( objectclass $ aliasedObjectName ) MAY ( aci ) )Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/ldap/schema.py", line 43, in str2objectclass return ldap.functions._ldap_function_call(_ldap.str2objectclass,schema_element_str) File "/usr/lib/python2.2/site-packages/ldap/__init__.py", line 56, in _ldap_function_call result = apply(func,args,kwargs) SystemError: NULL result without error in PyObject_Call >>> Well, I'd like to see some better error reporting with the help of exceptions. Anyway, there is a debug output text "Error: 6: .." produced. Don't know whether by the OpenLDAP libs or some code in Modules/schema.c. Hans, before I ask on the OpenLDAP list what this error means can you please review your code and test with the string above? Make sure to bring your CVS working tree in sync! Ciao, Michael. From jens at zope.com Sun Jul 28 01:16:35 2002 From: jens at zope.com (Jens Vagelpohl) Date: Sat, 27 Jul 2002 19:16:35 -0400 Subject: Changes to setup.py and setup.cfg In-Reply-To: <3D429F4E.7070802@stroeder.com> Message-ID: a simplistic test connecting to and getting search results from a server works for me on mac OS X version 10.1.5, compiled against OpenLDAP 2.1.3 libs. i noticed that setup.cfg now has 2 uncommented "libs" lines, the "simple" one and the "full featured" one. since the full feature line is after the simple one it will get executed in this case. jens On Saturday, July 27, 2002, at 09:25 , Michael Str?der wrote: > HI! > > I've checked in some changes to setup.py and setup.cfg hopefully > simplyfing this. > > 1. Renamed DEFINE name HAVE_LDAP_START_TLS_S to HAVE_TLS. > > 2. HAVE_TLS is set by looking at line libs in setup.cfg. If it contains > ssl *and* crypto HAVE_TLS is set. Otherwise support for StartTLS extended > operation and LDAP over SSL is turned off. > > 3. I dropped support for line class in section [_ldap] of setup.cfg since > we won't have support for other LDAP C SDKs. > > Please test if these changes have any bad implications on various build > platforms. > > Ciao, Michael. From michael at stroeder.com Sun Jul 28 01:25:51 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 28 Jul 2002 01:25:51 +0200 Subject: Changes to setup.py and setup.cfg References: Message-ID: <3D432BFF.1090707@stroeder.com> Jens Vagelpohl wrote: > a simplistic test connecting to and getting search results from a server > works for me on mac OS X version 10.1.5, compiled against OpenLDAP 2.1.3 > libs. > > i noticed that setup.cfg now has 2 uncommented "libs" lines, the > "simple" one and the "full featured" one. since the full feature line is > after the simple one it will get executed in this case. Thanks for reporting that. I've corrected that to one line for the sparse build. Ciao, Michael. From jajcus at bnet.pl Sun Jul 28 11:06:37 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Sun, 28 Jul 2002 11:06:37 +0200 Subject: ldap.schema: str2objectclass() fails In-Reply-To: <3D4304CB.9070509@stroeder.com> References: <3D4304CB.9070509@stroeder.com> Message-ID: <20020728090636.GC20706@nic.nigdzie> On Sat, Jul 27, 2002 at 10:38:35PM +0200, Michael Str?der wrote: > Well, I'd like to see some better error reporting with the help of > exceptions. Anyway, there is a debug output text "Error: 6: .." > produced. Don't know whether by the OpenLDAP libs or some code in > Modules/schema.c. Here is a fragment of Modules/schema.c: o = ldap_str2objectclass( oc_string, &ret, &errp, flag); if (ret) { printf("Error: %d: %s", ret, errp); /* XXX Do error handling... */ return NULL; } It seems ldap_str2objectclass() fails, but no proper python-way error hadnling is done. The fix should be easy (just replace /* XXX Do error handling... */ with exception object initialization). Unfortunately I am not able to do it now (lack of time) :-( Greets, Jacek From david.leonard at itee.uq.edu.au Sun Jul 28 13:41:04 2002 From: david.leonard at itee.uq.edu.au (David Leonard) Date: Sun, 28 Jul 2002 21:41:04 +1000 (EST) Subject: ldap.schema: str2objectclass() fails In-Reply-To: <20020728090636.GC20706@nic.nigdzie> Message-ID: On Sun, 28 Jul 2002, Jacek Konieczny typed thusly: > On Sat, Jul 27, 2002 at 10:38:35PM +0200, Michael Str?der wrote: > It seems ldap_str2objectclass() fails, but no proper python-way error > hadnling is done. The fix should be easy (just replace > /* XXX Do error handling... */ with exception object initialization). > Unfortunately I am not able to do it now (lack of time) :-( is ret important? is a subclassed error the right thing to do? Index: schema.c =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Modules/schema.c,v retrieving revision 1.2 diff -u -r1.2 schema.c --- schema.c 4 May 2002 18:14:48 -0000 1.2 +++ schema.c 28 Jul 2002 11:39:00 -0000 @@ -8,6 +8,8 @@ #include "schema.h" #include "ldap_schema.h" +static PyObject *SchemaError; + /* This utility function takes a null delimited C array of (null delimited) C strings, creates its python equivalent and returns a @@ -91,8 +93,7 @@ return NULL; o = ldap_str2objectclass( oc_string, &ret, &errp, flag); if (ret) { - printf("Error: %d: %s", ret, errp); - /* XXX Do error handling... */ + PyErr_SetString(SchemaError, errp); return NULL; } @@ -139,8 +140,7 @@ return NULL; a = ldap_str2attributetype( at_string, &ret, &errp, flag); if (ret) { - printf("Error: %d: %s", ret, errp); - /* XXX Do error handling... */ + PyErr_SetString(SchemaError, errp); return NULL; } @@ -208,8 +208,7 @@ return NULL; s = ldap_str2syntax(syn_string, &ret, &errp, flag); if (ret) { - printf("Error: %d: %s", ret, errp); - /* XXX Do error handling... */ + PyErr_SetString(SchemaError, errp); return NULL; } py_ret = PyList_New(4); @@ -243,8 +242,7 @@ return NULL; m = ldap_str2matchingrule(mr_string, &ret, &errp, flag); if (ret) { - printf("Error: %d: %s", ret, errp); - /* XXX Do error handling... */ + PyErr_SetString(SchemaError, errp); return NULL; } py_ret = PyList_New(6); @@ -285,5 +283,8 @@ void LDAPinit_schema( PyObject* d ) { + SchemaError = PyErr_NewException("ldap.SchemaError", + LDAPexception_class, NULL); + PyDict_SetItemString(d, "SchemaError", SchemaError); LDAPadd_methods( d, methods ); } -- David Leonard David.Leonard at itee.uq.edu.au Dept of Inf. Tech. and Elec. Engg _ Ph:+61 404 844 850 The University of Queensland |+| http://www.itee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 From Hans.Aschauer at Physik.uni-muenchen.de Mon Jul 29 14:10:36 2002 From: Hans.Aschauer at Physik.uni-muenchen.de (Hans Aschauer) Date: Mon, 29 Jul 2002 14:10:36 +0200 Subject: ldap.schema: str2objectclass() fails In-Reply-To: <3D4304CB.9070509@stroeder.com> References: <3D4304CB.9070509@stroeder.com> Message-ID: <200207291410.36304.Hans.Aschauer@Physik.uni-muenchen.de> On Samstag, 27. Juli 2002 22:38, Michael Str?der wrote: > HI! > > ldap.schema.str2objectclass() fails when parsing the following > string (from Netscape DS 4.16SP1 sub schema sub entry): > > "( 2.5.6.1 NAME 'alias' DESC 'Standard ObjectClass' SUP 'top' MUST > ( objectclass $ aliasedObjectName ) MAY ( aci ) )" > > This schema string does not look unusual to me but... But it does to me. The "SUP 'top'" should be "SUP top" (as far as I understand RFC 2252, Chapter 4: the argument of sup is oids, which does not include the quotes...). Just tried it, and it worked. One way to solve this problem (if netscape DS always returns such 'wrong' sub schema sub entries) would be to expose the flags argument of the C function to the python API, which allows to be more liberal in parsing the strings. The flags are defined in ldap_schema.h: #define LDAP_SCHEMA_ALLOW_NONE 0x00 /* Strict parsing */ #define LDAP_SCHEMA_ALLOW_NO_OID 0x01 /* Allow missing oid */ #define LDAP_SCHEMA_ALLOW_QUOTED 0x02 /* Allow bogus extra quotes */ #define LDAP_SCHEMA_ALLOW_DESCR 0x04 /* Allow descr instead of OID */ #define LDAP_SCHEMA_ALLOW_DESCR_PREFIX 0x08 /* Allow descr as OID prefix */ #define LDAP_SCHEMA_ALLOW_OID_MACRO 0x10 /* Allow OID macros in slapd */ #define LDAP_SCHEMA_ALLOW_ALL 0x1f /* Be very liberal in parsing */ At present, the flags are set to 0x00... [incomplete and 'bad' python error] > Well, I'd like to see some better error reporting with the help of > exceptions. Anyway, there is a debug output text "Error: 6: .." > produced. Don't know whether by the OpenLDAP libs or some code in > Modules/schema.c. Sorry that I still have not implemented correct error handling... The return codes are (again from ldap_schema.h): /* Codes for parsing errors */ #define LDAP_SCHERR_OUTOFMEM 1 #define LDAP_SCHERR_UNEXPTOKEN 2 #define LDAP_SCHERR_NOLEFTPAREN 3 #define LDAP_SCHERR_NORIGHTPAREN 4 #define LDAP_SCHERR_NODIGIT 5 #define LDAP_SCHERR_BADNAME 6 #define LDAP_SCHERR_BADDESC 7 #define LDAP_SCHERR_BADSUP 8 #define LDAP_SCHERR_DUPOPT 9 #define LDAP_SCHERR_EMPTY 10 > Hans, before I ask on the OpenLDAP list what this error means can > you please review your code and test with the string above? Make > sure to bring your CVS working tree in sync! Ok, I can try to fix things along the lines of David's patch (but including the error code). It will however take me at least one week. Hans -- Hans.Aschauer at Physik.uni-muenchen.de From michael at stroeder.com Mon Jul 29 14:22:07 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Mon, 29 Jul 2002 14:22:07 +0200 Subject: ldap.schema: str2objectclass() fails References: <3D4304CB.9070509@stroeder.com> <200207291410.36304.Hans.Aschauer@Physik.uni-muenchen.de> Message-ID: <3D45336F.2020406@stroeder.com> Hans Aschauer wrote: > > One way to solve this problem (if netscape DS always returns such > 'wrong' sub schema sub entries) would be to expose the flags argument > of the C function to the python API, which allows to be more liberal in > parsing the strings. We definitely need this! > Ok, I can try to fix things along the lines of David's patch (but > including the error code). It will however take me at least one week. Go for it. Ciao, Michael. From mbagepll at memphis.edu Mon Jul 29 16:18:37 2002 From: mbagepll at memphis.edu (mbagepll at memphis.edu) Date: Mon, 29 Jul 2002 09:18:37 -0500 Subject: python-ldap-2.0.0pre05 and openldap-2.1.3 Message-ID: <13ddb013c026.13c02613ddb0@memphis.edu> Hi all, I am trying to install python-ldap for solaris 8 using openldap-2.1.3. The openldap configures fine without giving any errors, but gives a warning which says- " Could not locate TLS/SSL package. TLS data protection not supported." Do i have to have SSL package? And, when I try to configure python-ldap, it throws the following error - Modules/options.c: In function `LDAP_set_option': Modules/options.c:79: warning: return makes integer from pointer without a cast Modules/options.c:97: warning: return makes integer from pointer without a cast gcc -shared build/temp.solaris-2.8-sun4u-2.1/LDAPObject.o build/temp.solaris-2.8-sun4u-2.1/common.o build/temp.solaris-2.8-sun4u- 2.1/constants.o build/temp.solaris-2.8-sun4u-2.1/errors.o build/temp.solaris-2.8-sun4u-2.1/functions.o build/temp.solaris-2.8- sun4u-2.1/schema.o build/temp.solaris-2.8-sun4u-2.1/ldapmodule.o build/temp.solaris-2.8-sun4u-2.1/linkedlist.o build/temp.solaris-2.8- sun4u-2.1/message.o build/temp.solaris-2.8-sun4u-2.1/version.o build/temp.solaris-2.8-sun4u-2.1/options.o - L/opt/local/web/ldap/openldap-2.1.3/libraries -lldap -llber -o build/lib.solaris-2.8-sun4u-2.1/_ldap.so ld: fatal: library -llber: not found ld: fatal: File processing errors. No output written to build/lib.solaris-2.8-sun4u-2.1/_ldap.so collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 I have noticed that the openldap-2.0.25 (the previous version) had liblber.a in the libraries folder. Where as, in openldap-2.1.3 there is no such file (liblber.a) in the libraries folder. Is this related to the error? --Madhavi -------------- next part -------------- A non-text attachment was scrubbed... Name: "mbagepll.vcf Type: text/x-vcard Size: 258 bytes Desc: Card for URL: From jens at zope.com Mon Jul 29 16:30:39 2002 From: jens at zope.com (Jens Vagelpohl) Date: Mon, 29 Jul 2002 10:30:39 -0400 Subject: python-ldap-2.0.0pre05 and openldap-2.1.3 In-Reply-To: <13ddb013c026.13c02613ddb0@memphis.edu> Message-ID: > I am trying to install python-ldap for solaris 8 using openldap-2.1.3. > The openldap configures fine without giving any errors, but gives a > warning which says- " Could not locate TLS/SSL package. TLS data > protection not supported." Do i have to have SSL package? it's just a warning. warnings are not fatal errors. the warning tells you exactly what is happening: no SSL package, so you will not get ldap with TLS or ldap over SSL. > > And, when I try to configure python-ldap, it throws the following > error - > > Modules/options.c: In function `LDAP_set_option': > Modules/options.c:79: warning: return makes integer from pointer > without a cast > Modules/options.c:97: warning: return makes integer from pointer > without a cast > gcc -shared build/temp.solaris-2.8-sun4u-2.1/LDAPObject.o > build/temp.solaris-2.8-sun4u-2.1/common.o build/temp.solaris-2.8-sun4u- > 2.1/constants.o build/temp.solaris-2.8-sun4u-2.1/errors.o > build/temp.solaris-2.8-sun4u-2.1/functions.o build/temp.solaris-2.8- > sun4u-2.1/schema.o build/temp.solaris-2.8-sun4u-2.1/ldapmodule.o > build/temp.solaris-2.8-sun4u-2.1/linkedlist.o build/temp.solaris-2.8- > sun4u-2.1/message.o build/temp.solaris-2.8-sun4u-2.1/version.o > build/temp.solaris-2.8-sun4u-2.1/options.o - > L/opt/local/web/ldap/openldap-2.1.3/libraries -lldap -llber -o > build/lib.solaris-2.8-sun4u-2.1/_ldap.so > ld: fatal: library -llber: not found > ld: fatal: File processing errors. No output written to > build/lib.solaris-2.8-sun4u-2.1/_ldap.so > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > I have noticed that the openldap-2.0.25 (the previous version) had > liblber.a in the libraries folder. Where as, in openldap-2.1.3 there is > no such file (liblber.a) in the libraries folder. Is this related to > the error? obviously the error is caused by not finding liblber. liblber *is* part of a openldap build (at least on all the 2.1.x builds i have done on linux and mac os x), so either it was put in a place that the buildout does not know about or your openldap build went wrong. jens From poster at bitstream.net Mon Jul 29 16:58:33 2002 From: poster at bitstream.net (Jacob Behm) Date: Mon, 29 Jul 2002 09:58:33 -0500 Subject: ZLDAPAdapter problems In-Reply-To: <3D41DCD8.9070808@stroeder.com> Message-ID: <368D67626F94DC42890180F75B1E97C736AC72@newman.bisinc.net> > Jacob Behm wrote: > > I don't know that I'm using any OpenLDAP. Would that be my problem? > > This Zope is running on a win32 machine. The python LDAP module is > > v1.10a3. > > Then your Win32 python-ldap binaries are using the old Umich LDAP > libraries which can only do LDAPv2. This is probably the reason > for your problems with MS AD. > > Also note that python-ldap 1.10a3 is pretty outdated and only > supports LDAPv2. > > Ciao, Michael. Ah .. this is very helpful. Does anyone know if there are updated binaries/libraries available for win32 systems? I'm sure someone has tried to interface with Active Directory with LDAP before. Has anyone been successful? Is it even possible? Thanks Again, Jacob From mcicogni at siosistemi.it Mon Jul 29 17:08:07 2002 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Mon, 29 Jul 2002 17:08:07 +0200 Subject: ZLDAPAdapter problems References: <368D67626F94DC42890180F75B1E97C736AC72@newman.bisinc.net> Message-ID: <3D455A57.8020209@siosistemi.it> Jacob Behm wrote: >>Jacob Behm wrote: >> >> >>>I don't know that I'm using any OpenLDAP. Would that be my problem? >>>This Zope is running on a win32 machine. The python LDAP module is >>>v1.10a3. >>> >>> >>Then your Win32 python-ldap binaries are using the old Umich LDAP >>libraries which can only do LDAPv2. This is probably the reason >>for your problems with MS AD. >> >>Also note that python-ldap 1.10a3 is pretty outdated and only >>supports LDAPv2. >> >>Ciao, Michael. >> >> > >Ah .. this is very helpful. Does anyone know if there are updated binaries/libraries available for win32 systems? > > Yes, there are: I have recently done a build of the newer stuff, which does need testing. If you're interested, I may send it to you. It's still python-ldap2.0.0pre04 and OpenLDAP 2.0.23 (with cyrus-sasl-1.5.27) due to lack of time on my part to get up to the very latest versions. >I'm sure someone has tried to interface with Active Directory with LDAP before. Has anyone been successful? Is it even possible? > > It does work, but it takes a lot of guessing of what the search roots are... and after that, you may have to tweak code to interpret the results correctly. Not as much as Novell Directory Service, though. ;-) BR, Mauro -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2926 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Mon Jul 29 17:26:31 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Jul 2002 17:26:31 +0200 Subject: ZLDAPAdapter problems References: <368D67626F94DC42890180F75B1E97C736AC72@newman.bisinc.net> Message-ID: <3D455EA7.7080200@stroeder.com> Jacob Behm wrote: > > I'm sure someone has tried to interface with Active Directory with LDAP > before. Has anyone been successful? Is it even possible? It should be possible. As python-ldap is concerned: I browsed an Active Directory server but not tested it very thoroughly. What you get out of it also depends very much on the security configuration. Ciao, Michael. From michael at stroeder.com Mon Jul 29 17:30:50 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Jul 2002 17:30:50 +0200 Subject: ZLDAPAdapter problems References: <368D67626F94DC42890180F75B1E97C736AC72@newman.bisinc.net> <3D455A57.8020209@siosistemi.it> Message-ID: <3D455FAA.8050501@stroeder.com> Mauro Cicognini wrote: > > It does work, but it takes a lot of guessing of what the search roots > are... ??? Attribute namingContexts in RootDSE should help. There's also an attribute defaultNamingContext. Access control restriction could be in place and off course these attributes should be queried by name just like with OpenLDAP 2.x. > and after that, you may have to tweak code to interpret the > results correctly. Can you elaborate on that? Tweak which code? > Not as much as Novell Directory Service, though. ;-) Can you elaborate on that too? As long as you don't try to handle Novell/NDS specific attributes it's very easy to query Novell eDirectory. BTW: One can have a look at ldap://www.nldap.com, their public demo server. You can even register to get your own container with write acess (http://www.nldap.com). Ciao, Michael. From michael at stroeder.com Mon Jul 29 17:24:01 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Jul 2002 17:24:01 +0200 Subject: python-ldap-2.0.0pre05 and openldap-2.1.3 References: <13ddb013c026.13c02613ddb0@memphis.edu> Message-ID: <3D455E11.9010806@stroeder.com> mbagepll at memphis.edu wrote: > > I am trying to install python-ldap for solaris 8 using openldap-2.1.3. > The openldap configures fine without giving any errors, but gives a > warning which says- " Could not locate TLS/SSL package. TLS data > protection not supported." Do i have to have SSL package? If you don't want to use LDAP over SSL or StartTLS extended operation to encrypt the LDAP data traffic you don't need to install OpenSSL. > And, when I try to configure python-ldap, it throws the following > error - > > Modules/options.c: In function `LDAP_set_option': > Modules/options.c:79: warning: return makes integer from pointer > without a cast > Modules/options.c:97: warning: return makes integer from pointer > without a cast You can ignore that warning. > ld: fatal: library -llber: not found > ld: fatal: File processing errors. No output written to > build/lib.solaris-2.8-sun4u-2.1/_ldap.so > [..] > I have noticed that the openldap-2.0.25 (the previous version) had > liblber.a in the libraries folder. Where as, in openldap-2.1.3 there is > no such file (liblber.a) in the libraries folder. Is this related to > the error? I guess your OpenLDAP build was not complete. You should find liblber.a and/or liblber.so. But this whole topic is more related to OpenLDAP itself. You might find the OpenLDAP Admin Guide, the FAQ-O-MATIC and mailing lists (archives) helpful to track those things down. Check out http://www.openldap.org. Ciao, Michael. From michael at stroeder.com Mon Jul 29 18:46:31 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Mon, 29 Jul 2002 18:46:31 +0200 Subject: ldap.schema: str2objectclass() fails References: <3D4304CB.9070509@stroeder.com> <200207291410.36304.Hans.Aschauer@Physik.uni-muenchen.de> <3D45336F.2020406@stroeder.com> Message-ID: <3D457167.9030304@stroeder.com> Michael Str?der wrote: > Hans Aschauer wrote: > >> One way to solve this problem (if netscape DS always returns such >> 'wrong' sub schema sub entries) would be to expose the flags argument >> of the C function to the python API, which allows to be more liberal >> in parsing the strings. > > We definitely need this! I changed the API to pass around this flags integer. I did other changes. Please bring your CVS working tree in sync. Ciao, Michael. From mbagepll at memphis.edu Mon Jul 29 19:03:36 2002 From: mbagepll at memphis.edu (mbagepll at memphis.edu) Date: Mon, 29 Jul 2002 12:03:36 -0500 Subject: python-ldap-2.0.0pre05 and openldap-2.1.3 Message-ID: <15083f151896.15189615083f@memphis.edu> Hi, I have got openldap installed completely. I have checked for liblber.a (this time) and it was poperly installed. Now my problem here is - after changing setup.cfg (file in python-ldap-2.0.0pre05), such that the 'library_dir' and 'include_dir' point to the openldap 'libraries' directory and 'include' directoy respectively, I ran the command - 'python setup.py build', which gave the following error- /libraries/liblber.a(sockbuf.o) ber_int_sb_close 0x5c /opt/local/web/ldap/openldap-2.0.25/libraries/liblber.a (sockbuf.o) ber_pvt_sb_copy_out 0xe74 /opt/local/web/ldap/openldap-2.0.25/libraries/liblber.a (sockbuf.o) ber_pvt_sb_copy_out 0xf10 /opt/local/web/ldap/openldap-2.0.25/libraries/liblber.a (sockbuf.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 Does any one know what this error is? -------------- next part -------------- A non-text attachment was scrubbed... Name: "mbagepll.vcf Type: text/x-vcard Size: 258 bytes Desc: Card for URL: From michael at stroeder.com Mon Jul 29 20:11:40 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Jul 2002 20:11:40 +0200 Subject: python-ldap-2.0.0pre05 and openldap-2.1.3 References: <15083f151896.15189615083f@memphis.edu> Message-ID: <3D45855C.2030406@stroeder.com> mbagepll at memphis.edu wrote: > > I have got openldap installed completely. I have checked for liblber.a > (this time) and it was poperly installed. And the shared lib liblber.so? > ld: fatal: relocations remain against allocatable but non-writable > sections > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 No clue about Solaris here. Are you using the Solaris compiler/linker? Googling around I found this here: http://gcc.gnu.org/ml/gcc-help/2000-05/msg00002.html Hmm, but -fPIC is already used. Ciao, Michael. From mbagepll at memphis.edu Mon Jul 29 21:16:29 2002 From: mbagepll at memphis.edu (mbagepll at memphis.edu) Date: Mon, 29 Jul 2002 14:16:29 -0500 Subject: python-ldap-2.0.0pre05 and openldap-2.1.3 Message-ID: <166b93162921.162921166b93@memphis.edu> yes, the shared lib liblber.so is installed in openldap- 2.1.3/libraries/liblber/.libs directory. And i am using gcc compiler and not the solaris comiler/linker. I am not sure if the liblber.so is in the right place, as it is in a hidden directory (.libs). Do I have to copy this to the 'liblber' directory for the linker to see it? Madhavi -------------- next part -------------- A non-text attachment was scrubbed... Name: "mbagepll.vcf Type: text/x-vcard Size: 258 bytes Desc: Card for URL: From michael at stroeder.com Mon Jul 29 22:00:38 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Jul 2002 22:00:38 +0200 Subject: python-ldap-2.0.0pre05 and openldap-2.1.3 References: <166b93162921.162921166b93@memphis.edu> Message-ID: <3D459EE6.2080709@stroeder.com> mbagepll at memphis.edu wrote: > yes, the shared lib liblber.so is installed in openldap- > 2.1.3/libraries/liblber/.libs directory. ??? Are you trying to compile python-ldap with include's and libs directly from the OpenLDAP source tree? Didn't you invoke $ ./configure --prefix=/usr/local/openldap $ make # make install to build *and* install OpenLDAP? > I am not sure if the liblber.so is in the right place, as it is in a > hidden directory (.libs). Do I have to copy this to the 'liblber' > directory for the linker to see it? Why not just try out yourself? At least you are sitting in front of your machine, don't you. ;-) On Linux the liblber.so, libldap.so, etc. are in the directory where parameter library_dirs of setup.cfg is pointing to. Ciao, Michael. From Hans.Aschauer at Physik.uni-muenchen.de Tue Jul 30 09:13:01 2002 From: Hans.Aschauer at Physik.uni-muenchen.de (Hans Aschauer) Date: Tue, 30 Jul 2002 09:13:01 +0200 Subject: ldap.schema: str2objectclass() fails In-Reply-To: <3D457167.9030304@stroeder.com> References: <3D4304CB.9070509@stroeder.com> <3D45336F.2020406@stroeder.com> <3D457167.9030304@stroeder.com> Message-ID: <200207300913.01242.Hans.Aschauer@Physik.uni-muenchen.de> On Montag, 29. Juli 2002 18:46, Michael Str?der wrote: > I changed the API to pass around this flags integer. I did other > changes. I made changes to schema.c and schema.py in order to actually pass the flag to the C functions: >>> a = "( 2.5.6.1 NAME 'alias' DESC 'Standard ObjectClass' SUP 'top' MUST ( objectclass $ aliasedObjectName ) MAY ( aci ) )" >>> ldap.schema.str2objectclass(a,15) ['2.5.6.1', ['alias'], 'Standard ObjectClass', 0, ['top'], 1, ['objectclass', 'aliasedObjectName'], ['aci'], []] >>> ldap.schema.str2objectclass(a) Error: 6: MUST ( objectclass $ aliasedObjectName ) MAY ( aci ) )Traceback (most recent call last): [...] Seems to work. Please test. Hans -- Hans.Aschauer at Physik.uni-muenchen.de From michael at stroeder.com Tue Jul 30 11:42:58 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Tue, 30 Jul 2002 11:42:58 +0200 Subject: ldap.schema: str2objectclass() fails References: <3D4304CB.9070509@stroeder.com> <3D45336F.2020406@stroeder.com> <3D457167.9030304@stroeder.com> <200207300913.01242.Hans.Aschauer@Physik.uni-muenchen.de> Message-ID: <3D465FA2.4010909@stroeder.com> Hans Aschauer wrote: > On Montag, 29. Juli 2002 18:46, Michael Str?der wrote: > > I made changes to schema.c and schema.py in order to actually pass the > flag to the C functions: > [...] > Seems to work. Please test. Thanks. It gets further but still chokes with schema of Netscape DS 4.16SP1 on some object classes although called with schema_allow=31. Can you point me to where are the error codes described in OpenLDAP? You can check yourself by invoking recently checked in Demo/schema.py: $ python Demo/schema.py ldap://memberdir.netscape.com/ memberdir.netscape.com is a iPlanet-Directory/5.0 B2001.109.0903. Feel free to use web2ldap's [ConnInfo] feature to find out more about demo servers mentioned there. It also does not work with www.nldap.com (Novell eDirectory 8.7). $ python Demo/schema.py ldap://www.nldap.com/ *** Schema from 'cn=schema' Error: 5: ( smssmdrclass-oid NAME 'sMSSMDRClass' DESC 'Standard ObjectClass' SUP resource STRUCTURAL MAY ( status $ Version $ sAPName $ sMSRegisteredService $ sMSProtocolAddress ) X-NDS_NAME 'SMS SMDR Class' X-NDS_NOT_CONTAINER '1' )Traceback (most recent call last): File "Demo/schema.py", line 27, in ? schema = ldap.schema.subSchema(subschemasubentry_entry,schema_allow=31) File "/usr/lib/python2.2/site-packages/ldap/schema.py", line 154, in __init__ se = SCHEMA_CLASS_MAPPING[attr_type](attr_value,schema_allow) File "/usr/lib/python2.2/site-packages/ldap/schema.py", line 47, in __init__ ( File "/usr/lib/python2.2/site-packages/ldap/schema.py", line 20, in str2objectclass return ldap.functions._ldap_function_call(_ldap.str2objectclass,schema_element_str,schema_allow) File "/usr/lib/python2.2/site-packages/ldap/__init__.py", line 56, in _ldap_function_call result = apply(func,args,kwargs) SystemError: NULL result without error in PyObject_Call Ciao, Michael. From Hans.Aschauer at Physik.uni-muenchen.de Tue Jul 30 12:13:45 2002 From: Hans.Aschauer at Physik.uni-muenchen.de (Hans Aschauer) Date: Tue, 30 Jul 2002 12:13:45 +0200 Subject: ldap.schema: str2objectclass() fails In-Reply-To: <3D465FA2.4010909@stroeder.com> References: <3D4304CB.9070509@stroeder.com> <200207300913.01242.Hans.Aschauer@Physik.uni-muenchen.de> <3D465FA2.4010909@stroeder.com> Message-ID: <200207301213.46019.Hans.Aschauer@Physik.uni-muenchen.de> On Dienstag, 30. Juli 2002 11:42, Michael Str?der wrote: > Can you point me to where are the error codes described in OpenLDAP? In ldap_schema.h: ---------------------------------------------- /* Codes for parsing errors */ #define LDAP_SCHERR_OUTOFMEM 1 #define LDAP_SCHERR_UNEXPTOKEN 2 #define LDAP_SCHERR_NOLEFTPAREN 3 #define LDAP_SCHERR_NORIGHTPAREN 4 #define LDAP_SCHERR_NODIGIT 5 #define LDAP_SCHERR_BADNAME 6 #define LDAP_SCHERR_BADDESC 7 #define LDAP_SCHERR_BADSUP 8 #define LDAP_SCHERR_DUPOPT 9 #define LDAP_SCHERR_EMPTY 10 ---------------------------------------------- > You can check yourself by invoking recently checked in > Demo/schema.py: > > $ python Demo/schema.py ldap://memberdir.netscape.com/ The problem is that they do not provide OID's where there must be OID's: objectClasses: ( inetsubscriber-oid NAME 'inetSubscriber' SUP top AUXILIARY MAY ( inetSubscriberAccountId $ inetSubscriberChallenge $ inetSubscriberResponse ) X-ORIGIN 'Nortel subscriber interoperability') In this case, the offending item is "inetsubscriber-oid", which is expected to be a numeric OID. In this case, the openldap schema parser is not liberal enough to allow such a string. There's not much that we can do in this case (except for writing our own parser, or filing a "bug" report, and hoping the best...) Of course, if we already had better error handling, we could also use some heuristics after an exception is caught ;-) Hans -- Hans.Aschauer at Physik.uni-muenchen.de From michael at stroeder.com Tue Jul 30 13:59:47 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Tue, 30 Jul 2002 13:59:47 +0200 Subject: ldap.schema: str2objectclass() fails References: <3D4304CB.9070509@stroeder.com> <200207300913.01242.Hans.Aschauer@Physik.uni-muenchen.de> <3D465FA2.4010909@stroeder.com> <200207301213.46019.Hans.Aschauer@Physik.uni-muenchen.de> Message-ID: <3D467FB3.4040505@stroeder.com> Hans Aschauer wrote: > On Dienstag, 30. Juli 2002 11:42, Michael Str?der wrote: > >>You can check yourself by invoking recently checked in >>Demo/schema.py: >> >>$ python Demo/schema.py ldap://memberdir.netscape.com/ > > The problem is that they do not provide OID's where there must be OID's: > objectClasses: ( inetsubscriber-oid Yes, that's what i suspected too. But I thought one of #define LDAP_SCHEMA_ALLOW_DESCR 0x04 /* Allow descr instead of OID */ #define LDAP_SCHEMA_ALLOW_DESCR_PREFIX 0x08 /* Allow descr as OID prefix */ #define LDAP_SCHEMA_ALLOW_OID_MACRO 0x10 /* Allow OID macros in slapd */ would do the trick. > There's not much that we > can do in this case (except for writing our own parser, Jacek already has a pure-Python parser in his curses-based LDAP client... > or filing a > "bug" report, and hoping the best...) I suspect that Kurt will not accept that but I will try to file an issue report anyway. > Of course, if we already had better error handling, we could also use > some heuristics after an exception is caught ;-) No. Ciao, Michael. From mbagepll at memphis.edu Tue Jul 30 15:39:13 2002 From: mbagepll at memphis.edu (mbagepll at memphis.edu) Date: Tue, 30 Jul 2002 08:39:13 -0500 Subject: python-ldap-2.0.0pre05 and openldap-2.1.3 Message-ID: <195bdc19673c.19673c195bdc@memphis.edu> yes, i had built and installed openldap correctly. Anyway, I had to copy the files to the library_dir directory. Now, I have python-ldap working. Thank you for your help. --Madhavi -------------- next part -------------- A non-text attachment was scrubbed... Name: "mbagepll.vcf Type: text/x-vcard Size: 258 bytes Desc: Card for URL: From michael at stroeder.com Tue Jul 30 15:47:27 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Tue, 30 Jul 2002 15:47:27 +0200 Subject: ldap.schema: str2objectclass() fails References: Message-ID: <3D4698EF.7080100@stroeder.com> David Leonard wrote: > is ret important? Yes, I think so. > is a subclassed error the right thing to do? Frankly I'd prefer to check the numerical error code in ldap.schema.str2objectclass() and the other wrapper functions and raise Python-declared exceptions instead of create the exception instances in Modules/schema.c. This is much easier to maintain (at least for me) and the schema exception class can be sub-classed etc. Ciao, Michael. From michael at stroeder.com Tue Jul 30 22:20:44 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Tue, 30 Jul 2002 22:20:44 +0200 Subject: ldap.schema: str2objectclass() fails References: <3D4698EF.7080100@stroeder.com> Message-ID: <3D46F51C.8090306@stroeder.com> Michael Str?der wrote: > Frankly I'd prefer to check the numerical error code in > ldap.schema.str2objectclass() and the other wrapper functions and raise > Python-declared exceptions instead of create the exception instances in > Modules/schema.c. How about this approach assuming _ldap.str2objectclass() only returns a error code as integer in case of an error? ------------------------- snip ------------------------- class SchemaError(Exception): pass class SCHERR_OUTOFMEM(SchemaError): pass class SCHERR_UNEXPTOKEN(SchemaError): pass class SCHERR_NOLEFTPAREN(SchemaError): pass class SCHERR_NORIGHTPAREN(SchemaError): pass class SCHERR_NODIGIT(SchemaError): pass class SCHERR_BADNAME(SchemaError): pass class SCHERR_BADDESC(SchemaError): pass class SCHERR_BADSUP(SchemaError): pass class SCHERR_DUPOPT(SchemaError): pass class SCHERR_EMPTY(SchemaError): pass ERRCODE2SCHERR = { 1:SCHERR_OUTOFMEM 2:SCHERR_UNEXPTOKEN 3:SCHERR_NOLEFTPAREN 4:SCHERR_NORIGHTPAREN 5:SCHERR_NODIGIT 6:SCHERR_BADNAME 7:SCHERR_BADDESC 8:SCHERR_BADSUP 9:SCHERR_DUPOPT 10:SCHERR_EMPTY } # Wrapper functions to serialize calls into OpenLDAP libs with # a module-wide thread lock def str2objectclass(schema_element_str,schema_allow=0): r = ldap.functions._ldap_function_call( _ldap.str2objectclass,schema_element_str,schema_allow ) if type(res)==type(0): raise ERRCODE2SCHERR.get(r,SchemaError)( r,schema_element_str ) else: assert type(res)==type(()) return r ------------------------- snip ------------------------- Ciao, Michael. From michael at stroeder.com Wed Jul 31 00:37:30 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Wed, 31 Jul 2002 00:37:30 +0200 Subject: ldap.schema: str2objectclass() fails References: <3D4304CB.9070509@stroeder.com> <200207300913.01242.Hans.Aschauer@Physik.uni-muenchen.de> <3D465FA2.4010909@stroeder.com> <200207301213.46019.Hans.Aschauer@Physik.uni-muenchen.de> Message-ID: <3D47152A.8080504@stroeder.com> Hans Aschauer wrote: > On Dienstag, 30. Juli 2002 11:42, Michael Str?der wrote: > > The problem is that they do not provide OID's where there must be OID's: It should be accepted with schema_allow=31. See discussion for issue filed in OpenLDAP's ITS: http://www.OpenLDAP.org/its/index.cgi?findid=1996 Please cross-check that the client library ALLOW flags are "properly enabled". Ciao, Michael. From Hans.Aschauer at Physik.uni-muenchen.de Wed Jul 31 09:51:42 2002 From: Hans.Aschauer at Physik.uni-muenchen.de (Hans Aschauer) Date: Wed, 31 Jul 2002 09:51:42 +0200 Subject: ldap.schema: str2objectclass() fails In-Reply-To: <3D47152A.8080504@stroeder.com> References: <3D4304CB.9070509@stroeder.com> <200207301213.46019.Hans.Aschauer@Physik.uni-muenchen.de> <3D47152A.8080504@stroeder.com> Message-ID: <200207310951.42763.Hans.Aschauer@Physik.uni-muenchen.de> On Mittwoch, 31. Juli 2002 00:37, Michael Str?der wrote: > It should be accepted with schema_allow=31. > > See discussion for issue filed in OpenLDAP's ITS: > > http://www.OpenLDAP.org/its/index.cgi?findid=1996 > > Please cross-check that the client library ALLOW flags are > "properly enabled". I did some printf - debugging, and I think it is a real openldap bug: >>> ldap.schema.str2objectclass(b,31) Error: 5: ( nsHost-oid NAME 'nsHost' DESC 'iPlanet defined objectclass' SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLocation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'iPlanet' ). flag = 31 ^^^^^^^^^ The "flag = 31" is printf'ed by the C wrapper code, using the same variable that is passed to the openldap - function. This is a small C test code in order to exclude errors from the python side (maybe you could post it to the ITS): From Hans.Aschauer at Physik.uni-muenchen.de Wed Jul 31 16:23:33 2002 From: Hans.Aschauer at Physik.uni-muenchen.de (Hans Aschauer) Date: Wed, 31 Jul 2002 16:23:33 +0200 Subject: ldap.schema: str2objectclass() fails In-Reply-To: <3D46F51C.8090306@stroeder.com> References: <3D4698EF.7080100@stroeder.com> <3D46F51C.8090306@stroeder.com> Message-ID: <200207311623.33391.Hans.Aschauer@Physik.uni-muenchen.de> On Dienstag, 30. Juli 2002 22:20, Michael Str?der wrote: > Michael Str?der wrote: > > Frankly I'd prefer to check the numerical error code in > > ldap.schema.str2objectclass() and the other wrapper functions and > > raise Python-declared exceptions instead of create the exception > > instances in Modules/schema.c. > > How about this approach assuming _ldap.str2objectclass() only > returns a error code as integer in case of an error? [...] This a really easy approach to the problem. Should I commit that patch? Hans -- Hans.Aschauer at Physik.uni-muenchen.de From michael at stroeder.com Wed Jul 31 16:46:28 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Wed, 31 Jul 2002 16:46:28 +0200 Subject: ldap.schema: str2objectclass() fails References: <3D4698EF.7080100@stroeder.com> <3D46F51C.8090306@stroeder.com> <200207311623.33391.Hans.Aschauer@Physik.uni-muenchen.de> Message-ID: <3D47F844.70304@stroeder.com> Hans Aschauer wrote: > On Dienstag, 30. Juli 2002 22:20, Michael Str?der wrote: > >>Michael Str?der wrote: >> >>>Frankly I'd prefer to check the numerical error code in >>>ldap.schema.str2objectclass() and the other wrapper functions and >>>raise Python-declared exceptions instead of create the exception >>>instances in Modules/schema.c. >> >>How about this approach assuming _ldap.str2objectclass() only >>returns a error code as integer in case of an error? > > > [...] > > This a really easy approach to the problem. Should I commit that patch? Yes! Ciao, Michael. From Hans.Aschauer at Physik.uni-muenchen.de Thu Aug 1 11:09:17 2002 From: Hans.Aschauer at Physik.uni-muenchen.de (Hans Aschauer) Date: Thu, 1 Aug 2002 11:09:17 +0200 Subject: ldap.schema: str2objectclass() fails In-Reply-To: <3D47F844.70304@stroeder.com> References: <200207311623.33391.Hans.Aschauer@Physik.uni-muenchen.de> <3D47F844.70304@stroeder.com> Message-ID: <200208011109.17794.Hans.Aschauer@Physik.uni-muenchen.de> On Mittwoch, 31. Juli 2002 16:46, Michael Str?der wrote: > Hans Aschauer wrote: > > This a really easy approach to the problem. Should I commit that > > patch? > > Yes! Done. Including the patch for schema.py. It works for me, but, as always, please test it! Hans -- Hans.Aschauer at Physik.uni-muenchen.de From michael at stroeder.com Thu Aug 1 11:40:29 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Thu, 01 Aug 2002 11:40:29 +0200 Subject: ldap.schema: str2objectclass() fails References: <200207311623.33391.Hans.Aschauer@Physik.uni-muenchen.de> <3D47F844.70304@stroeder.com> <200208011109.17794.Hans.Aschauer@Physik.uni-muenchen.de> Message-ID: <3D49020D.1080501@stroeder.com> Hans Aschauer wrote: > On Mittwoch, 31. Juli 2002 16:46, Michael Str?der wrote: > >>Hans Aschauer wrote: >> >>>This a really easy approach to the problem. Should I commit that >>>patch? >> >>Yes! > > Done. Including the patch for schema.py. It works for me, but, as > always, please test it! Seems to work. The assertion assert res in ERRCODE2SCHERR.keys() is not necessary since we use ERRCODE2SCHERR.get(res,SchemaError) to use the base-class in case of unknown error code. I expect the OpenLDAP project to add new error codes without us keeping up with it. ;-) Ciao, Michael. From michael at stroeder.com Fri Aug 2 16:23:09 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Fri, 02 Aug 2002 16:23:09 +0200 Subject: Schema-API References: <200208011245.39537.Hans.Aschauer@Physik.uni-muenchen.de> <3D49156A.2070506@stroeder.com> <200208011606.42865.Hans.Aschauer@Physik.uni-muenchen.de> Message-ID: <3D4A95CD.9040105@stroeder.com> Dear list members, please review the schema API in Lib/ldap/schema.py. There's also a demo script Demo/schema.py. I've tested it with OpenLDAP 2.0.x and 2.1.x, an Innosoft server and some Siemens Dir/X servers I found. It still chokes on Netscape/iPlanet/Sun Directory Servers etc. with non-numeric "OID" but now with a nice exception. Up to now I only addressed the issues with finding the mandantory and optional attribute types to a given list of object classes. It's still far away from being a complete schema support. Please comment! Ciao, Michael. From ml-it-python-ldap-dev at epigenomics.com Sun Jul 28 19:48:44 2002 From: ml-it-python-ldap-dev at epigenomics.com (Robert Sander) Date: Sun, 28 Jul 2002 17:48:44 +0000 (UTC) Subject: Referral support (was: port of Net::LDAP::Entry) References: <3D3FCBF9.30701@stroeder.com> <20020725102423.GB708@epigenomics.de> <3D3FD616.2090501@stroeder.com> <3D406BCD.9000607@stroeder.com> <20020726052628.GA19238@epigenomics.com> <3D412769.8050601@stroeder.com> Message-ID: On Fri, 26 Jul 2002 10:43:28 +0000 (UTC), Michael Str?der wrote: >> We have a "wrapper" search function that will deal with this. > > This might be a nice inspiration for python-ldap. Good, I haven't tested it very well, but it seems to work. Here it is: import ldap, ldapurl def ldapsearch(self, server, base, scope = ldap.SCOPE_SUBTREE, filter, attrs = None, attrsonly = 0, binddn = None, bindpw = None, debug = None): if debug: print "%s [%s]: %s; %s" % (server, base, filter, attrs) l = ldap.open(server) l.set_option(ldap.OPT_PROTOCOL_VERSION, ldap.VERSION3) l.set_option(ldap.OPT_REFERRALS, 0) l.simple_bind_s(binddn, bindpw) hash = {} if self.debug: print " searching in %s for %s" % ( base, filter ) try: for entry, values in l.search_s(base, scope, filter, attrs, attrsonly): if entry: hash[entry] = values if debug: print " found %s" % entry else: for value in values: if debug: print " got reference to %s" % value url = ldapurl.LDAPUrl(value) hash.update(ldapsearch(server=url.hostport, base=url.dn, scope=scope, filter=filter, attrs=attrs, attrsonly=attrsonly, binddn=binddn, bindpw=bindpw, debug=debug)) except ldap.REFERRAL, er: if er.has_key('info'): url = ldapurl.LDAPUrl(er['info']) hash.update(ldapsearch(server=url.hostport, base=url.dn, scope=scope, filter=filter, attrs=attrs, attrsonly=attrsonly, binddn=binddn, bindpw=bindpw, debug=debug)) l.unbind() return hash It fills a hash indexed by the dn with the value of the dn. Currently it needs the same binddn on every server accessed. But you can easily integrate a method that returns a new binddn and bindpw depending on the server and/or the search base. Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From michael at stroeder.com Wed Aug 7 17:40:01 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Wed, 07 Aug 2002 17:40:01 +0200 Subject: Added class ldap.ldapobject.ReconnectLDAPObject Message-ID: <3D513F51.4070702@stroeder.com> HI! I've added the class ldap.ldapobject.ReconnectLDAPObject. See the __doc__ string of recently checked in source: """ In case of server failure (ldap.SERVER_DOWN) the implementations of all synchronous operation methods (search_s() etc.) are doing an automatic reconnect and rebind and will retry the very same operation. This is very handy for broken LDAP server implementations (e.g. in Lotus Domino) which drop connections very often making it impossible to have a long-lasting control flow in the application. """ See Demo/reconnect.py how to deploy it. Please bring your CVS working tree in sync, review and test. Your feedback is appreciated! Ciao, Michael. From jens at zope.com Wed Aug 7 21:27:38 2002 From: jens at zope.com (Jens Vagelpohl) Date: Wed, 7 Aug 2002 15:27:38 -0400 Subject: Added class ldap.ldapobject.ReconnectLDAPObject In-Reply-To: <3D513F51.4070702@stroeder.com> Message-ID: i just tried running the Demo/reconnect script and it errs out because in line 7 it tries to call a method named "applyDefaults" on the ldap_url object, which does not have such a method... jens On Wednesday, August 7, 2002, at 11:40 , Michael Str?der wrote: > HI! > > I've added the class ldap.ldapobject.ReconnectLDAPObject. See the > __doc__ string of recently checked in source: > > """ > In case of server failure (ldap.SERVER_DOWN) the implementations > of all synchronous operation methods (search_s() etc.) are doing > an automatic reconnect and rebind and will retry the very same > operation. > > This is very handy for broken LDAP server implementations > (e.g. in Lotus Domino) which drop connections very often making > it impossible to have a long-lasting control flow in the > application. > """ > > See Demo/reconnect.py how to deploy it. > > Please bring your CVS working tree in sync, review and test. > Your feedback is appreciated! > > Ciao, Michael. > > > > From michael at stroeder.com Wed Aug 7 21:40:18 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 07 Aug 2002 21:40:18 +0200 Subject: Added class ldap.ldapobject.ReconnectLDAPObject References: Message-ID: <3D5177A2.3080702@stroeder.com> Jens Vagelpohl wrote: > i just tried running the Demo/reconnect script and it errs out because > in line 7 it tries to call a method named "applyDefaults" on the > ldap_url object, which does not have such a method... Sorry, forgot to check in ldapurl.py... /bin/done Please try again. Ciao, Michael. From jens at zope.com Wed Aug 7 21:50:24 2002 From: jens at zope.com (Jens Vagelpohl) Date: Wed, 7 Aug 2002 15:50:24 -0400 Subject: Schema-API In-Reply-To: <3D4A95CD.9040105@stroeder.com> Message-ID: i'm trying to run the Demo/schema.py script and steppping through it with pdb there's an oddity i see, which prevents the script from running successfully: - ldapobject.py line 548 (in method search_subschemasubentry) a search is done on the passed-in DN to retrieve the value for the attribute "subschemaSubentry". the search is successful and returns... [('dc=vts,dc=zope,dc=com', {'subschemaSubentry': ['cn=Subschema']})] - in line 555 there is the following call: e = ldap.cidict.cidict(r[0][1]) (r is the result shown above) - at this point "e" has the following value: {'subschemasubentry': ['cn=Subschema']} (notice: "subschemasubentry" is all lowercase now) - now the problem is in line 556 in the call... search_subschemasubentry_dn = e.get('subschemaSubentry', [None])[] (notice: it expects camelcase again...) ... at this point the result is None and the script dies a little later. jens On Friday, August 2, 2002, at 10:23 , Michael Str?der wrote: > Dear list members, > > please review the schema API in Lib/ldap/schema.py. There's also a demo > script Demo/schema.py. > > I've tested it with OpenLDAP 2.0.x and 2.1.x, an Innosoft server and some > Siemens Dir/X servers I found. It still chokes on Netscape/iPlanet/Sun > Directory Servers etc. with non-numeric "OID" but now with a nice > exception. > > Up to now I only addressed the issues with finding the mandantory and > optional attribute types to a given list of object classes. It's still > far away from being a complete schema support. > > Please comment! > > Ciao, Michael. > > > > From michael at stroeder.com Wed Aug 7 22:03:51 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 07 Aug 2002 22:03:51 +0200 Subject: Schema-API References: Message-ID: <3D517D27.1070506@stroeder.com> Jens Vagelpohl wrote: > i'm trying to run the Demo/schema.py script and steppping through it > with pdb there's an oddity i see, which prevents the script from running > successfully: > > - ldapobject.py line 548 (in method search_subschemasubentry) a search > is done on the passed-in DN to retrieve the value for the attribute > "subschemaSubentry". the search is successful and returns... > > [('dc=vts,dc=zope,dc=com', {'subschemaSubentry': ['cn=Subschema']})] > > - in line 555 there is the following call: > > e = ldap.cidict.cidict(r[0][1]) (r is the result shown above) > > - at this point "e" has the following value: > > {'subschemasubentry': ['cn=Subschema']} (notice: "subschemasubentry" is > all lowercase now) > > - now the problem is in line 556 in the call... > > search_subschemasubentry_dn = e.get('subschemaSubentry', [None])[] Yes, no problem since ldap.cidict.cidict is used. I wouldn't claim that there is no bug. But I can't see a problem. > ... at this point the result is None and the script dies a little later. "Dies a little later" is a little bit unspecific. Can you please provide the traceback and mention which LDAP server you're using for testing? Ciao, Michael. From jens at zope.com Wed Aug 7 23:06:11 2002 From: jens at zope.com (Jens Vagelpohl) Date: Wed, 7 Aug 2002 17:06:11 -0400 Subject: Added class ldap.ldapobject.ReconnectLDAPObject In-Reply-To: <3D5177A2.3080702@stroeder.com> Message-ID: <800D934C-AA49-11D6-9225-0003939EFEBC@zope.com> ldapurl.py has an error: in the applyDefaults method you put "for k in defaults". you meant "for k in default.keys()", correct? jens On Wednesday, August 7, 2002, at 03:40 , Michael Str?der wrote: > Jens Vagelpohl wrote: >> i just tried running the Demo/reconnect script and it errs out because >> in line 7 it tries to call a method named "applyDefaults" on the >> ldap_url object, which does not have such a method... > > Sorry, forgot to check in ldapurl.py... > > /bin/done > > Please try again. > > Ciao, Michael. > > > > From jens at zope.com Wed Aug 7 23:14:36 2002 From: jens at zope.com (Jens Vagelpohl) Date: Wed, 7 Aug 2002 17:14:36 -0400 Subject: Schema-API In-Reply-To: <3D517D27.1070506@stroeder.com> Message-ID: here's the traceback:: [dhcp182:src/python-ldap-HEAD/Demo] jens% python2.1 schema.py ldap://waldorf.zope.com/dc=vts,dc=zope,dc=com Time elapsed search sub schema sub entry: 0.018 Traceback (most recent call last): File "schema.py", line 29, in ? subschemasubentry_entry = l.read_subschemasubentry_s( File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", line 584, in read_subschemasubentry_s attrs File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", line 422, in search_s return self.search_st(base,scope,filterstr,attrlist,attrsonly,timeout= -1) File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", line 425, in search_st msgid = self.search(base,scope,filterstr,attrlist,attrsonly) File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", line 419, in search return self._ldap_call(self._l.search,base,scope,filterstr,attrlist,attrsonly) File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", line 95, in _ldap_call result = apply(func,args,kwargs) TypeError: argument 1 must be string, not None [dhcp182:src/python-ldap-HEAD/Demo] jens% the "error" is that this call on ldapobject.py line 557 "e = ldap.cidict.cidict(r[0][1])" all of a sudden lowercases the key "subschemaSubentry" from the original search result. so when the code tries to determine the value of that key, and asks for the *camelcased* version, it will get None back: "e.get('subschemaSubentry',[None])[0]" because "e" only has a key "subschemasubentry". if "e" contains the original camelcased key then the script continues successfully. jens On Wednesday, August 7, 2002, at 04:03 , Michael Str?der wrote: > Jens Vagelpohl wrote: >> i'm trying to run the Demo/schema.py script and steppping through it >> with pdb there's an oddity i see, which prevents the script from running >> successfully: >> - ldapobject.py line 548 (in method search_subschemasubentry) a search >> is done on the passed-in DN to retrieve the value for the attribute >> "subschemaSubentry". the search is successful and returns... >> [('dc=vts,dc=zope,dc=com', {'subschemaSubentry': ['cn=Subschema']})] >> - in line 555 there is the following call: >> e = ldap.cidict.cidict(r[0][1]) (r is the result shown above) >> - at this point "e" has the following value: >> {'subschemasubentry': ['cn=Subschema']} (notice: "subschemasubentry" is >> all lowercase now) >> - now the problem is in line 556 in the call... >> search_subschemasubentry_dn = e.get('subschemaSubentry', [None])[] > > Yes, no problem since ldap.cidict.cidict is used. I wouldn't claim that > there is no bug. But I can't see a problem. > >> ... at this point the result is None and the script dies a little later. > > "Dies a little later" is a little bit unspecific. Can you please provide > the traceback and mention which LDAP server you're using for testing? > > Ciao, Michael. > From jens at zope.com Wed Aug 7 23:21:42 2002 From: jens at zope.com (Jens Vagelpohl) Date: Wed, 7 Aug 2002 17:21:42 -0400 Subject: Schema-API In-Reply-To: <3D517D27.1070506@stroeder.com> Message-ID: the problem is in the cidict class. when you call "get" then the method "get" on UserDict gets called - which has no lowercasing of the name you ask for. jens On Wednesday, August 7, 2002, at 04:03 , Michael Str?der wrote: > Jens Vagelpohl wrote: >> i'm trying to run the Demo/schema.py script and steppping through it >> with pdb there's an oddity i see, which prevents the script from running >> successfully: >> - ldapobject.py line 548 (in method search_subschemasubentry) a search >> is done on the passed-in DN to retrieve the value for the attribute >> "subschemaSubentry". the search is successful and returns... >> [('dc=vts,dc=zope,dc=com', {'subschemaSubentry': ['cn=Subschema']})] >> - in line 555 there is the following call: >> e = ldap.cidict.cidict(r[0][1]) (r is the result shown above) >> - at this point "e" has the following value: >> {'subschemasubentry': ['cn=Subschema']} (notice: "subschemasubentry" is >> all lowercase now) >> - now the problem is in line 556 in the call... >> search_subschemasubentry_dn = e.get('subschemaSubentry', [None])[] > > Yes, no problem since ldap.cidict.cidict is used. I wouldn't claim that > there is no bug. But I can't see a problem. > >> ... at this point the result is None and the script dies a little later. > > "Dies a little later" is a little bit unspecific. Can you please provide > the traceback and mention which LDAP server you're using for testing? > > Ciao, Michael. > > > > From michael at stroeder.com Thu Aug 8 09:23:58 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 08 Aug 2002 09:23:58 +0200 Subject: Schema-API References: Message-ID: <3D521C8E.7010101@stroeder.com> Jens Vagelpohl wrote: > the problem is in the cidict class. when you call "get" then the method > "get" on UserDict gets called - which has no lowercasing of the name you > ask for. Nothing wrong with that. See UserDict.py: def get(self, key, failobj=None): if not self.has_key(key): return failobj return self[key] Method UserDict.get() calls self.__getitem__(). I've added two test cases to ldap.cidict as proof that this works correctly. Ciao, Michael. From michael at stroeder.com Thu Aug 8 09:41:05 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 08 Aug 2002 09:41:05 +0200 Subject: Schema-API References: Message-ID: <3D522091.3040102@stroeder.com> Jens Vagelpohl wrote: > > [dhcp182:src/python-ldap-HEAD/Demo] jens% python2.1 schema.py > ldap://waldorf.zope.com/dc=vts,dc=zope,dc=com Does the entry dc=vts,dc=zope,dc=com exist? What LDAP server is running on waldorf.zope.com:389? Any niftly access control in place? Not sure how to handle ldap.NO_SUCH_OBJECT during first search in search_subschemasubentry_s(). I've checked in a version yesterday 2002/08/07 20:25:26 which handles that (and some weird servers returning ldap.UNDEFINED_TYPE) slightly different. > [dhcp182:src/python-ldap-HEAD/Demo] jens% python2.1 schema.py > ldap://waldorf.zope.com/dc=vts,dc=zope,dc=com > Time elapsed search sub schema sub entry: 0.018 > Traceback (most recent call last): > File "schema.py", line 29, in ? > subschemasubentry_entry = l.read_subschemasubentry_s( > [..] > TypeError: argument 1 must be string, not None Well, off course here the Demo script is flawed... ;-) l.read_subschemasubentry_s() should not be called if the result was None (=> sync CVS). Ciao, Michael. From michael at stroeder.com Thu Aug 8 12:23:52 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 08 Aug 2002 12:23:52 +0200 Subject: Schema handling with various LDAP servers (was: fetching the structure / obejctClass defs) References: <200205171145.53395.t.kloppenburg@billiton.de> <200206031308.11671.Hans.Aschauer@Physik.uni-muenchen.de> <3CFB51B0.9040807@stroeder.com> <200206031355.07170.Hans.Aschauer@Physik.uni-muenchen.de> Message-ID: <3D5246B8.4000004@stroeder.com> Hans Aschauer wrote: > >>I'd like to see a base class for a LDAP syntax with a method >>validate() which is called when setting the attribute value. > > So this would mean that we change the implementation from "syntaxes are > instances of the syntax class" to "syntaxes are subclasses an > (abstract) syntax base class". Which objects would then instanciate the > syntax classes? Maybe some kind of attribute class instances, through > multiple inheritance? This question really drives me nuts. After playing yesterday with kind of a hard-coded class-based syntax handling added to web2ldap I didn't came to a conclusion whether an attribute should simply be an instance of LDAPSyntax class or not. Well, think of matching rules. That really makes it complicated. Frankly, I don't think it's worth the effort. I looked into sub schema sub entries of various public LDAP servers (Netscape 4.x, iPlanet 5.0, Siemens Dir/X, OpenLDAP 1.x/2.x, Innosoft, etc.) and the declaration of syntaxes is so different that it really does not make much sense to read and use the syntax and attribute type declarations from most of the LDAP servers. It's a whole mess out there in the real world! > For objectClasses, inheritance seems to > make sense, since they inherit from each other, and I think it would be > possible (in python), to build a class hirachy from server information > "on the fly". There's not much you have to do with object classes. From my tests I noticed that e.g. declaration of inetOrgPerson differs on servers by various vendors (e.g. Dir/X declares inetOrgPerson as AUXILIARY class derived from top which violates RFC2798). SubSchema.all_attrs() solves all these issues by resolving all MAY and MUST classes for a given list of object classes. Note that you can limit retrieval of sub schema sub entry to object classes by parameter attrs which usually saves a lot of band-width. Ciao, Michael. From jens at dataflake.org Thu Aug 8 15:20:15 2002 From: jens at dataflake.org (Jens Vagelpohl) Date: Thu, 8 Aug 2002 09:20:15 -0400 Subject: cidict problems Message-ID: <93A8CFBE-AAD1-11D6-A2FA-0003939EFEBC@dataflake.org> michael, in your last mail you said that the UserDict.get method would turn around and use __getitem__. this is not true, it uses "get" itself. i am working on python 2.1.3, maybe this has changed in the version you are using. here is the relevant code:: 35 def get(self, key, failobj=None): 36 -> return self.data.get(key, failobj) at this point self.data is... (Pdb) p self.data {'subschemasubentry': ['cn=Subschema']} and key is... (Pdb) p key 'subschemaSubentry' ... and when the "get" is called this is the result:: (Pdb) p self.data.get(key, failobj) [None] maybe the cidict class should override the method "get" as well? jens From jens at dataflake.org Thu Aug 8 15:26:19 2002 From: jens at dataflake.org (Jens Vagelpohl) Date: Thu, 8 Aug 2002 09:26:19 -0400 Subject: cidict problems Message-ID: <6CA67672-AAD2-11D6-A2FA-0003939EFEBC@dataflake.org> this addition to the cidict class helps it and allows schema.py to run successfully: def get(self, name, default): return UserDict.get(self, lower(name), default) jens From michael at stroeder.com Thu Aug 8 15:42:02 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 08 Aug 2002 15:42:02 +0200 Subject: cidict problems References: <93A8CFBE-AAD1-11D6-A2FA-0003939EFEBC@dataflake.org> Message-ID: <3D52752A.4000801@stroeder.com> Jens Vagelpohl wrote: > > in your last mail you said that the UserDict.get method would turn > around and use __getitem__. this is not true, it uses "get" itself. i am > working on python 2.1.3, maybe this has changed in the version you are > using. I'm using 2.2.1. > here is the relevant code:: > > 35 def get(self, key, failobj=None): > 36 -> return self.data.get(key, failobj) Aaargh, that's flawed! > maybe the cidict class should override the method "get" as well? /bin/done I've also added .keys() and .items() with case-respecting handling including test cases. Everyone is encouraged to test with different Python versions (without using option -O off course)! $ python Lib/ldap/cidict.py Ciao, Michael. From jens at zope.com Thu Aug 8 15:47:42 2002 From: jens at zope.com (Jens Vagelpohl) Date: Thu, 8 Aug 2002 09:47:42 -0400 Subject: cidict problems In-Reply-To: <3D52752A.4000801@stroeder.com> Message-ID: <697288CF-AAD5-11D6-A2FA-0003939EFEBC@zope.com> just as a FYI: we're kind of "stuck" on 2.1.3 as far as zope goes right now, so that will be the version that people run who run a recent version of zope. the first version of zope to "officially" support 2.2.x will be 2.7, which is a few months away. jens On Thursday, August 8, 2002, at 09:42 , Michael Str?der wrote: > Jens Vagelpohl wrote: >> in your last mail you said that the UserDict.get method would turn >> around and use __getitem__. this is not true, it uses "get" itself. i am >> working on python 2.1.3, maybe this has changed in the version you are >> using. > > I'm using 2.2.1. > >> here is the relevant code:: >> 35 def get(self, key, failobj=None): >> 36 -> return self.data.get(key, failobj) > > Aaargh, that's flawed! > >> maybe the cidict class should override the method "get" as well? > > /bin/done > > I've also added .keys() and .items() with case-respecting handling > including test cases. > > Everyone is encouraged to test with different Python versions (without > using option -O off course)! > > $ python Lib/ldap/cidict.py > > Ciao, Michael. > > From ml-it-python-ldap-dev at epigenomics.com Fri Aug 9 09:39:25 2002 From: ml-it-python-ldap-dev at epigenomics.com (Robert Sander) Date: Fri, 9 Aug 2002 07:39:25 +0000 (UTC) Subject: asynchronous search does not find referrals Message-ID: Hi! I do not know if I make something wrong here, but it seems to me that asynchronous searching does not find referrals in the tree. The example code as follows: #!/usr/bin/python import ldap l=ldap.initialize('ldap://ldap-hm') l.set_option(ldap.OPT_PROTOCOL_VERSION,ldap.VERSION3) l.set_option(ldap.OPT_REFERRALS,0) result = l.search('o=epigenomics',ldap.SCOPE_ONELEVEL,'(objectClass=*)') while 1: result_type, result_data = l.result(result, 0) if result_type == ldap.RES_SEARCH_ENTRY: print result_data elif result_type == ldap.RES_SEARCH_RESULT: print result_data break print for i in l.search_s('o=epigenomics',ldap.SCOPE_ONELEVEL,'(objectClass=*)'): print i And the output is: defiant gurubert 43 (/tmp): ./test.py [('cn=admin,o=epigenomics', {'objectClass': ['person'], 'sn': ['admin'], 'cn': ['admin']})] [('cn=updated,o=epigenomics', {'objectClass': ['person'], 'sn': ['updated'], 'cn': ['updated']})] [('cn=readout,o=epigenomics', {'objectClass': ['person'], 'sn': ['readout'], 'cn': ['readout']})] [('c=de,o=epigenomics', {'c': ['de'], 'objectClass': ['country']})] [('c=us,o=epigenomics', {'c': ['us'], 'objectClass': ['country']})] [('ou=groups,o=epigenomics', {'ou': ['groups'], 'objectClass': ['organizationalUnit']})] [('ou=autofs,o=epigenomics', {'ou': ['autofs'], 'objectClass': ['organizationalUnit']})] [('cn=gchange,o=epigenomics', {'objectClass': ['person'], 'sn': ['GroupChange'], 'cn': ['gchange']})] [('ou=testtree,o=epigenomics', {'ou': ['testtree'], 'objectClass': ['organizationalUnit']})] None ('cn=admin,o=epigenomics', {'objectClass': ['person'], 'sn': ['admin'], 'cn': ['admin']}) ('cn=updated,o=epigenomics', {'objectClass': ['person'], 'sn': ['updated'], 'cn': ['updated']}) ('cn=readout,o=epigenomics', {'objectClass': ['person'], 'sn': ['readout'], 'cn': ['readout']}) ('c=de,o=epigenomics', {'c': ['de'], 'objectClass': ['country']}) ('c=us,o=epigenomics', {'c': ['us'], 'objectClass': ['country']}) ('ou=groups,o=epigenomics', {'ou': ['groups'], 'objectClass': ['organizationalUnit']}) ('ou=autofs,o=epigenomics', {'ou': ['autofs'], 'objectClass': ['organizationalUnit']}) ('cn=gchange,o=epigenomics', {'objectClass': ['person'], 'sn': ['GroupChange'], 'cn': ['gchange']}) (None, ['ldap://ldap-hm/ou=Inc,o=epigenomics']) ('ou=testtree,o=epigenomics', {'ou': ['testtree'], 'objectClass': ['organizationalUnit']}) This makes it impossible to use asynchronous searching on a tree with referrals implemented. Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From ml-it-python-ldap-dev at epigenomics.com Fri Aug 9 11:07:48 2002 From: ml-it-python-ldap-dev at epigenomics.com (Robert Sander) Date: Fri, 9 Aug 2002 09:07:48 +0000 (UTC) Subject: asynchronous search does not find referrals References: <3D538577.2010903@stroeder.com> Message-ID: On Fri, 9 Aug 2002 09:06:43 +0000 (UTC), Michael Str?der wrote: > Uuumh, there might be some issues with search continuations. I saw > some of my async demos even lock up completely. Which version are > you using? It's from the Debian package version 1.9.999.pre04-1 which is python-ldap version 2.0.0-pre04 I think. Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From michael at stroeder.com Fri Aug 9 11:03:51 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 09 Aug 2002 11:03:51 +0200 Subject: asynchronous search does not find referrals References: Message-ID: <3D538577.2010903@stroeder.com> Robert Sander wrote: > > I do not know if I make something wrong here, but it seems to me that > asynchronous searching does not find referrals in the tree. Uuumh, there might be some issues with search continuations. I saw some of my async demos even lock up completely. Which version are you using? But it seems it works for me. web2ldap does make extensive use of async search when browsing (for nice handling of partial results and such). Ciao, Michael. From michael at stroeder.com Fri Aug 9 11:16:30 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Fri, 09 Aug 2002 11:16:30 +0200 Subject: asynchronous search does not find referrals References: <3D538577.2010903@stroeder.com> Message-ID: <3D53886E.9040400@stroeder.com> Robert Sander wrote: > On Fri, 9 Aug 2002 09:06:43 +0000 (UTC), > Michael Str?der wrote: > >>Uuumh, there might be some issues with search continuations. I saw >>some of my async demos even lock up completely. Which version are >>you using? > > It's from the Debian package version 1.9.999.pre04-1 which is > python-ldap version 2.0.0-pre04 I think. There was a fix related to this. You should at least use 2.0.0-pre05. Ciao, Michael. From ml-it-python-ldap-dev at epigenomics.com Sat Aug 10 00:20:42 2002 From: ml-it-python-ldap-dev at epigenomics.com (Robert Sander) Date: Fri, 9 Aug 2002 22:20:42 +0000 (UTC) Subject: asynchronous search does not find referrals References: <3D538577.2010903@stroeder.com> <3D53886E.9040400@stroeder.com> Message-ID: On Fri, 9 Aug 2002 09:20:39 +0000 (UTC), Michael Str?der wrote: > There was a fix related to this. You should at least use 2.0.0-pre05. I tried 2.0.0-pre05 with the same result: import ldap print ldap.__version__ l=ldap.initialize('ldap://ldap-hm') l.set_option(ldap.OPT_PROTOCOL_VERSION,ldap.VERSION3) l.set_option(ldap.OPT_REFERRALS,0) result = l.search('o=epigenomics',ldap.SCOPE_ONELEVEL,'(objectClass=*)') while 1: result_type, result_data = l.result(result, 0) if result_type == ldap.RES_SEARCH_ENTRY: print result_data elif result_type == ldap.RES_SEARCH_RESULT: print result_data break print for i in l.search_s('o=epigenomics',ldap.SCOPE_ONELEVEL,'(objectClass=*)'): print i Output: 2.0.0pre05 [('cn=admin,o=epigenomics', {'objectClass': ['person'], 'sn': ['admin'], 'cn': ['admin']})] [('cn=updated,o=epigenomics', {'objectClass': ['person'], 'sn': ['updated'], 'cn': ['updated']})] [('cn=readout,o=epigenomics', {'objectClass': ['person'], 'sn': ['readout'], 'cn': ['readout']})] [('c=de,o=epigenomics', {'c': ['de'], 'objectClass': ['country']})] [('c=us,o=epigenomics', {'c': ['us'], 'objectClass': ['country']})] [('ou=groups,o=epigenomics', {'ou': ['groups'], 'objectClass': ['organizationalUnit']})] [('ou=autofs,o=epigenomics', {'ou': ['autofs'], 'objectClass': ['organizationalUnit']})] [('cn=gchange,o=epigenomics', {'objectClass': ['person'], 'sn': ['GroupChange'], 'cn': ['gchange']})] [('ou=testtree,o=epigenomics', {'ou': ['testtree'], 'objectClass': ['organizationalUnit']})] [] ('cn=admin,o=epigenomics', {'objectClass': ['person'], 'sn': ['admin'], 'cn': ['admin']}) ('cn=updated,o=epigenomics', {'objectClass': ['person'], 'sn': ['updated'], 'cn': ['updated']}) ('cn=readout,o=epigenomics', {'objectClass': ['person'], 'sn': ['readout'], 'cn': ['readout']}) ('c=de,o=epigenomics', {'c': ['de'], 'objectClass': ['country']}) ('c=us,o=epigenomics', {'c': ['us'], 'objectClass': ['country']}) ('ou=groups,o=epigenomics', {'ou': ['groups'], 'objectClass': ['organizationalUnit']}) ('ou=autofs,o=epigenomics', {'ou': ['autofs'], 'objectClass': ['organizationalUnit']}) ('cn=gchange,o=epigenomics', {'objectClass': ['person'], 'sn': ['GroupChange'], 'cn': ['gchange']}) ('ou=testtree,o=epigenomics', {'ou': ['testtree'], 'objectClass': ['organizationalUnit']}) (None, ['ldap://ldap-hm/ou=Inc,o=epigenomics']) Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From michael at stroeder.com Sat Aug 10 00:35:45 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Sat, 10 Aug 2002 00:35:45 +0200 Subject: asynchronous search does not find referrals References: <3D538577.2010903@stroeder.com> <3D53886E.9040400@stroeder.com> Message-ID: <3D5443C1.9080705@stroeder.com> Robert Sander wrote: > On Fri, 9 Aug 2002 09:20:39 +0000 (UTC), > Michael Str?der wrote: > >>There was a fix related to this. You should at least use 2.0.0-pre05. > > I tried 2.0.0-pre05 with the same result: Hmm, not sure when the fix was exactly. Can you please test also the recent CVS version? There's a temporary tar.gz of today's snapshot on http://web2ldap.de/download.html Ciao, Michael. From michael at stroeder.com Sat Aug 10 00:44:04 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Sat, 10 Aug 2002 00:44:04 +0200 Subject: asynchronous search does not find referrals References: <3D538577.2010903@stroeder.com> <3D53886E.9040400@stroeder.com> Message-ID: <3D5445B4.4070309@stroeder.com> Robert Sander wrote: > On Fri, 9 Aug 2002 09:20:39 +0000 (UTC), > Michael Str?der wrote: > >>There was a fix related to this. You should at least use 2.0.0-pre05. > > I tried 2.0.0-pre05 with the same result: Sometimes the solutions is too obvious. ;-) It definitely helps to display the search references. Add this line: elif result_type == ldap.RES_SEARCH_REFERENCE: print result_data Also I'd like to suggest to make use of the very handy parameter trace_level: l=ldap.initialize('ldap://ldap.rediris.es',trace_level=1) Ciao, Michael. From michael at stroeder.com Sat Aug 10 00:46:04 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Sat, 10 Aug 2002 00:46:04 +0200 Subject: asynchronous search does not find referrals References: <3D538577.2010903@stroeder.com> <3D53886E.9040400@stroeder.com> <3D5445B4.4070309@stroeder.com> Message-ID: <3D54462C.7020806@stroeder.com> Michael Str?der wrote: > Sometimes the solutions is too obvious. ;-) > > It definitely helps to display the search references. Add this line: > > elif result_type == ldap.RES_SEARCH_REFERENCE: > print result_data And did I mention ldap.async? That is a convenience module exactly to avoid having to deal with it yourself. Ciao, Michael. From t.kloppenburg at billiton.de Sat Aug 10 21:21:54 2002 From: t.kloppenburg at billiton.de (Tjabo Kloppenburg) Date: Sat, 10 Aug 2002 21:21:54 +0200 Subject: problem with filter Message-ID: <200208102121.54886.t.kloppenburg@billiton.de> hi, I'm writing a program in python wir python-ldap2.0.0.-pre04 (linux). I can do all sorts of things, like searching: L = myldap.search_s( base, ldap.SCOPE_SUBTREE, "uid=ma*" ) let's say I have found twenty results, and I let the user chose one of the DNs. Now I want to retrieve the data of the object of a given dn. The problem is how to tell ldap.search_s to get the data of a dn like "uid=freak,ou=staff,o=company". L = myldap.search_s( base, ldap.SCOPE_SUBTREE, dn ) gives an empty list. L = myldap.search_s( base, ldap.SCOPE_SUBTREE, "dn=" + dn ) gives an empty list, too. what's the right filter/function for this? thanks a lot, tk. From jens at zope.com Sun Aug 11 03:19:23 2002 From: jens at zope.com (Jens Vagelpohl) Date: Sat, 10 Aug 2002 21:19:23 -0400 Subject: problem with filter In-Reply-To: <200208102121.54886.t.kloppenburg@billiton.de> Message-ID: <5E87DA76-ACC8-11D6-B932-0003939EFEBC@zope.com> your scope is probably inappropriate. use ldap.SCOPE_BASE. jens On Saturday, August 10, 2002, at 03:21 , Tjabo Kloppenburg wrote: > hi, > > I'm writing a program in python wir python-ldap2.0.0.-pre04 (linux). > > I can do all sorts of things, like searching: > L = myldap.search_s( base, ldap.SCOPE_SUBTREE, "uid=ma*" ) > > let's say I have found twenty results, and I let the user chose one of > the DNs. > Now I want to retrieve the data of the object of a given dn. The problem > is how to tell > ldap.search_s to get the data of a dn like "uid=freak,ou=staff,o=company" > . > > L = myldap.search_s( base, ldap.SCOPE_SUBTREE, dn ) > gives an empty list. > > L = myldap.search_s( base, ldap.SCOPE_SUBTREE, "dn=" + dn ) > gives an empty list, too. > > what's the right filter/function for this? > > > thanks a lot, > tk. > From michael at stroeder.com Sun Aug 11 15:51:43 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 11 Aug 2002 15:51:43 +0200 Subject: problem with filter References: <200208102121.54886.t.kloppenburg@billiton.de> Message-ID: <3D566BEF.2000000@stroeder.com> Tjabo Kloppenburg wrote: > > I'm writing a program in python wir python-ldap2.0.0.-pre04 (linux). > > I can do all sorts of things, like searching: > L = myldap.search_s( base, ldap.SCOPE_SUBTREE, "uid=ma*" ) "uid=ma*" is not a valid search filter. Use "(uid=ma*)" instead. See RFC2254 as stated in the docs. > let's say I have found twenty results, and I let the user chose one of the DNs. > Now I want to retrieve the data of the object of a given dn. If you did not specify args attrlist and attrsonly the entry data is already in the search result above. > The problem is how to tell > ldap.search_s to get the data of a dn like "uid=freak,ou=staff,o=company". > > L = myldap.search_s( base, ldap.SCOPE_SUBTREE, dn ) > gives an empty list. This call is wrong. Should be: L = myldap.search_s( dn, ldap.SCOPE_BASE, "(objectClass=*)" ) Read the docs for search(). Ciao, Michael. From t.kloppenburg at billiton.de Mon Aug 12 17:53:53 2002 From: t.kloppenburg at billiton.de (Tjabo Kloppenburg) Date: Mon, 12 Aug 2002 17:53:53 +0200 Subject: problem with filter In-Reply-To: <5E87DA76-ACC8-11D6-B932-0003939EFEBC@zope.com> References: <5E87DA76-ACC8-11D6-B932-0003939EFEBC@zope.com> Message-ID: <200208121753.53239.t.kloppenburg@billiton.de> hi, > your scope is probably inappropriate. use ldap.SCOPE_BASE. s = self.ldap.search_s( dn, ldap.SCOPE_BASE, "objectClass=*" ) made it. tnx, tk. QUESTION: why doesn't the reply-to tag point to the list? From michael at stroeder.com Mon Aug 12 18:20:12 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 12 Aug 2002 18:20:12 +0200 Subject: problem with filter References: <5E87DA76-ACC8-11D6-B932-0003939EFEBC@zope.com> <200208121753.53239.t.kloppenburg@billiton.de> Message-ID: <3D57E03C.1080402@stroeder.com> Tjabo Kloppenburg wrote: > >>your scope is probably inappropriate. use ldap.SCOPE_BASE. > > s = self.ldap.search_s( dn, ldap.SCOPE_BASE, "objectClass=*" ) > made it. The filter is still not valid even though the LDAP server might accept it. Use "(objectClass=*)" instead and make sure that you fully understand RFC2254. > QUESTION: why doesn't the reply-to tag point to the list? To avoid flames intended to reach me to be sent to the list. ;-) Ciao, Michael. From michael at stroeder.com Mon Aug 12 22:42:34 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 12 Aug 2002 22:42:34 +0200 Subject: Own pure Python parser for LDAPv3 schema support Message-ID: <3D581DBA.4090207@stroeder.com> HI! Please take note of the following check-ins related to LDAPv3 schema support (see below). Tested on various servers: OpenLDAP 2.0/2.1 IBM SecureWay Lotus Domino/LDAP R5(?) Novell eDirectory 8.6.1/8.7 Novell Directory Server 4.16SP1, 5.0 Siemens Dir/X (various unknown versions) Innosoft's IDDS 4.5.1 There still might be some detailed issues. Reviews, profiling performance hot spots, testing, etc. is appreciated. If that code works reliably I will cvs remove schema support based on OpenLDAP's schema parser from C _ldap. Ciao, Michael. -------- Original Message -------- Subject: CVS: python-ldap Date: Mon, 12 Aug 2002 13:32:29 -0700 From: Michael Str?der Reply-To: python-ldap-dev at lists.sourceforge.net To: python-ldap-commits at lists.sourceforge.net CVSROOT: /cvsroot/python-ldap Module name: python-ldap Changes by: stroeder 2002/08/12 13:32:29 Modified files: Demo : schema.py schema_tree.py Lib/ldap : schema.py Log message: Abandoned use of OpenLDAP's schema parser. Implemented own parsing with ldap.schema.split_tokens() and ldap.schema.extract_tokens(). Probably bad performance and robustness => peer review needed. SubSchema.name2oid is now nested dictionary separated by schema element classes. This was needed since schema element names are reused for attribute types and object classes on e.g. Novell eDirectory. From jens at zope.com Tue Aug 13 00:11:17 2002 From: jens at zope.com (Jens Vagelpohl) Date: Mon, 12 Aug 2002 18:11:17 -0400 Subject: Own pure Python parser for LDAPv3 schema support In-Reply-To: <3D581DBA.4090207@stroeder.com> Message-ID: <6CC017C1-AE40-11D6-992F-0003939EFEBC@zope.com> well, for what it's worth, the schema.py and schema_tree.py demos in the Demo folder work very nicely against my test server (OpenLDAP 2.1.3). as far as performance goes, the subjective performance seems to be the same as it was with the other implementation. not sure if that's any kind of useful indicator, though. i think this is great stuff. thanks michael!!! i plan on using this to offer select widgets in places where i had to rely on people typing objectClass names into text boxes before... jens On Monday, August 12, 2002, at 04:42 , Michael Str?der wrote: > HI! > > Please take note of the following check-ins related to LDAPv3 schema > support (see below). > > Tested on various servers: > OpenLDAP 2.0/2.1 > IBM SecureWay > Lotus Domino/LDAP R5(?) > Novell eDirectory 8.6.1/8.7 > Novell Directory Server 4.16SP1, 5.0 > Siemens Dir/X (various unknown versions) > Innosoft's IDDS 4.5.1 > > There still might be some detailed issues. > Reviews, profiling performance hot spots, testing, etc. is appreciated. > > If that code works reliably I will cvs remove schema support based on > OpenLDAP's schema parser from C _ldap. > > Ciao, Michael. > > > -------- Original Message -------- > Subject: CVS: python-ldap > Date: Mon, 12 Aug 2002 13:32:29 -0700 > From: Michael Str?der > Reply-To: python-ldap-dev at lists.sourceforge.net > To: python-ldap-commits at lists.sourceforge.net > > CVSROOT: /cvsroot/python-ldap > Module name: python-ldap > Changes by: stroeder 2002/08/12 13:32:29 > > Modified files: > Demo : schema.py schema_tree.py > Lib/ldap : schema.py > > Log message: > Abandoned use of OpenLDAP's schema parser. Implemented own parsing with > ldap.schema.split_tokens() and ldap.schema.extract_tokens(). Probably bad > performance and robustness => peer review needed. > > SubSchema.name2oid is now nested dictionary separated by schema element > classes. This was needed since schema element names are reused for > attribute > types and object classes on e.g. Novell eDirectory. > > From michael at stroeder.com Tue Aug 13 19:54:23 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 13 Aug 2002 19:54:23 +0200 Subject: Own pure Python parser for LDAPv3 schema support References: <6CC017C1-AE40-11D6-992F-0003939EFEBC@zope.com> Message-ID: <3D5947CF.50202@stroeder.com> Jens Vagelpohl wrote: > as far as performance goes, the subjective performance seems to > be the same as it was with the other implementation. not sure if > that's any kind of useful indicator, though. I hoped that someone bites the bullet and uses /usr/lib/python2.2/profile.py... ;-) Also the __init__() methods of the schema element classes need review to check whether they are consistent. > i plan on using this to > offer select widgets in places where i had to rely on people > typing objectClass names into text boxes before... This is rather simple: SubSchema.all_available(ldap.schema.ObjectClass) Be warned that the API still might be changed without prominent notification (there are some significant changes in the pipe not checked in). I developed the stuff while implementing schema support in web2ldap. Therefore it should contain almost everything needed by applications. Also be warned that there are many broken schemas out there in the wild. Test your application against other products than OpenLDAP! Ciao, Michael. From jens at zope.com Wed Aug 14 13:51:30 2002 From: jens at zope.com (Jens Vagelpohl) Date: Wed, 14 Aug 2002 07:51:30 -0400 Subject: Own pure Python parser for LDAPv3 schema support In-Reply-To: <3D5947CF.50202@stroeder.com> Message-ID: <2C1E6884-AF7C-11D6-BF58-0003939EFEBC@zope.com> > I hoped that someone bites the bullet and uses > /usr/lib/python2.2/profile.py... ;-) hey, i told you i don't use python2.2 yet ;) > Also the __init__() methods of the schema element classes need review to > check whether they are consistent. you mean the classes inside schema.py such os "ObjectClass", "AttributeType" etc? i am noticing that the __init__ for ObjectClass, unlike all others, does not just take the full schema_element_string, it also takes all attributes as separate keyword arguments. that seems a little redundant. all other classes only take the schema_element_string and extract the attributes from that. > Be warned that the API still might be changed without prominent > notification (there are some significant changes in the pipe not checked > in). I developed the stuff while implementing schema support in web2ldap. > Therefore it should contain almost everything needed by applications. i don't have time to implement it and throw it out right at this moment, anyway. i'm fully aware that something so "new" will change more frequently. > Also be warned that there are many broken schemas out there in the wild. > Test your application against other products than OpenLDAP! well, i would probably end up doing a widget that offers both a dropdown and a text input field, maybe depending on errors occurring during schema discovery. jens From michael at stroeder.com Wed Aug 14 18:47:26 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 14 Aug 2002 18:47:26 +0200 Subject: Own pure Python parser for LDAPv3 schema support References: <2C1E6884-AF7C-11D6-BF58-0003939EFEBC@zope.com> Message-ID: <3D5A899E.1030601@stroeder.com> Jens Vagelpohl wrote: >> I hoped that someone bites the bullet and uses >> /usr/lib/python2.2/profile.py... ;-) > > hey, i told you i don't use python2.2 yet ;) Hah, that's obviously no excuse... ;-) > i am noticing that the __init__ for ObjectClass, unlike all > others, does not just take the full schema_element_string, it > also takes all attributes as separate keyword arguments. that > seems a little redundant. Python 2.2.1 (#2, May 4 2002, 19:50:26) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ldap.schema >>> str(ldap.schema.ObjectClass(oid='1.23.456.78.0',names=['myClass','myClassAlias'],must=['myRequiredAttr1','myRequiredAttr2'],may=['myAllowed1'])) "( 1.23.456.78.0 NAME ( 'myClass' 'myClassAlias' ) STRUCTURAL MUST ( myRequiredAttr1 $ myRequiredAttr2 ) MAY myAllowed1 )" >>> Also works with Python 2.1.x! ;-) Got the message? It's meant for automated schema element creation. A schema editor comes to mind... > all other classes only take the schema_element_string and > extract the attributes from that. Yes, they are not complete yet. > well, i would probably end up doing a widget that offers both a > dropdown and a text input field, maybe depending on errors > occurring during schema discovery. Error handling is somewhat subtle. Ciao, Michael. From peter at hawkins.emu.id.au Fri Aug 16 12:26:45 2002 From: peter at hawkins.emu.id.au (Peter Hawkins) Date: Fri, 16 Aug 2002 20:26:45 +1000 Subject: Segfault in python-ldap Message-ID: <200208162026.50301.peter@hawkins.emu.id.au> Hi... I'm the current debian maintainer for the debian python-ldap package. This bug has been sitting in our BTS for a while: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=76722&repeatmerged=yes --- SNIP --- This piece of code might not be correct but it certainly should not make python segfault: import ldap class ldapObject: def __init__(self,dn=""): '''ldapObject constructor.''' self.dn=dn self.attr={} db=ldap.open("db.mors.wiggy.net",389) db.simple_bind("cn=admin,ou=People,dc=mors,dc=wiggy,dc=net", "12345") o=ldapObject("uid=tst,ou=People,dc=mors,dc=wiggy,dc=net") o.attr["objectClass"]="top" o.attr["uid"]="tst" db.add_s(o.dn, o) --- END SNIP --- I just checked and it still causes problems with 2.0.0-pre05. (though you may need to change db.mors.wiggy.net to something you can actually contact). A patch for this issue (against 2.0.0-pre04, but still applies correctly against 2.0.0-pre05), the correctness of which I am not totally certain, is attached. Could you please check it and apply it to your source tree? Thanks, Peter -- peter at hawkins.emu.id.au GPG key fingerprint: C746 38A9 D3E4 A171 FB6A 56D4 5E30 DFCC BE11 F437 -------------- next part -------------- A non-text attachment was scrubbed... Name: python-ldap.patch Type: text/x-diff Size: 435 bytes Desc: not available URL: From michael at stroeder.com Fri Aug 16 16:14:35 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 16 Aug 2002 16:14:35 +0200 Subject: Segfault in python-ldap References: <200208162026.50301.peter@hawkins.emu.id.au> Message-ID: <3D5D08CB.4060905@stroeder.com> Peter Hawkins wrote: > > This bug has been sitting in our BTS for a while: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=76722&repeatmerged=yes > > --- SNIP --- > This piece of code might not be correct but it certainly should not > make python segfault: Yepp, python-ldap should not crash. > --- python-ldap-2.0.0pre04/Modules/LDAPObject.c Sat Feb 2 22:47:00 2002 > +++ python-ldap-2.0.0pre04-new2/Modules/LDAPObject.c Tue Jul 2 22:09:26 2002 I've applied the patch you provided to my local working tree. It works. Thanks for submitting it. Well, this is not a complete solution for this kind of problems. Maybe assertion statements in each method of ldap.ldapobject.LDAPObject could be of better help here... Ciao, Michael. From michael at stroeder.com Mon Aug 19 20:12:55 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Mon, 19 Aug 2002 20:12:55 +0200 Subject: Preparing 2.0.0pre06 Message-ID: <3D613527.6010309@stroeder.com> HI! Please get your python-ldap working tree in sync since I'd like to release a 2.0.0pre06 real soon now. For those of your sitting behind a firewall or without CVS access there's a tar.gz temporarily available on: http://www.web2ldap.de/download.html I consider the LDAPv3 schema support to have a more or less stable API now. Please test and comment! Ciao, Michael. From michael at stroeder.com Mon Aug 19 20:20:34 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Mon, 19 Aug 2002 20:20:34 +0200 Subject: TODO until python-ldap 2.0.0 final release Message-ID: <3D6136F2.6080207@stroeder.com> HI! I'd like to bring your attention to the TODO file in python-ldap. For your convenience it's attached below. ;-) Any takers? Especially I'd like to see a general approach for extended controls and extended operations. Yeah, C illiterate I am I'm asking for help... Ciao, Michael. *** List of things to-do in no particular order *** General: - Define common license for all modules - Create a test script that exercises everything with a public server holding the BLITS 2.5 test data set Modules/ - Validating server's certificate when calling start_tls_s() or ldap.initialize('ldaps://..') - General support for controls - VLV control - server-side sorting control - Binding in DSA control mode (rewrite necessary) - Persistent search control - Wrap ldap_parse_reference() - Support for Win32 (and other platforms?) - Support Extended Operations by wrapping ldap_extended_operation() and ldap_parse_extended_result() - Set Password ext. op. - Whoami ext. op. Lib/ - Remove obsolete/unsupported modules - Caching of search requests for each LDAPObject instance - LDIF parser for replication logs - DSML support - Support for SASL mechanims GSS-API Tests/ Clean up and finish the mess of test scripts started. From michael at stroeder.com Tue Aug 20 11:20:22 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 20 Aug 2002 11:20:22 +0200 Subject: Preparing 2.0.0pre06 References: <3D613527.6010309@stroeder.com> <200208201041.57255.t.kloppenburg@billiton.de> Message-ID: <3D6209D6.5040603@stroeder.com> Tjabo Kloppenburg wrote: > > >>I consider the LDAPv3 schema support to have a more or less >>stable API now. > > are there any docs, Not yet. > examples ? Demo/schema.py and Demo/schema_tree.py Ciao, Michael. From jens at zope.com Mon Aug 19 23:53:20 2002 From: jens at zope.com (Jens Vagelpohl) Date: Mon, 19 Aug 2002 17:53:20 -0400 Subject: TODO until python-ldap 2.0.0 final release In-Reply-To: <3D6136F2.6080207@stroeder.com> Message-ID: <1362A90E-B3BE-11D6-AC66-0003939EFEBC@zope.com> talking about the common license, is there such a beast yet and you're just looking for someone to go through every file and make sure it's in there? or is it more about producing the legalese gibberish itself? :) jens On Monday, August 19, 2002, at 02:20 , Michael Str?der wrote: > HI! > > I'd like to bring your attention to the TODO file in python-ldap. For your > convenience it's attached below. ;-) > > Any takers? Especially I'd like to see a general approach for extended > controls and extended operations. Yeah, C illiterate I am I'm asking for > help... > > Ciao, Michael. > > *** List of things to-do in no particular order *** > > General: > - Define common license for all modules > - Create a test script that exercises everything with a public > server holding the BLITS 2.5 test data set > > Modules/ > - Validating server's certificate when calling start_tls_s() or > ldap.initialize('ldaps://..') > - General support for controls > - VLV control > - server-side sorting control > - Binding in DSA control mode (rewrite necessary) > - Persistent search control > - Wrap ldap_parse_reference() > - Support for Win32 (and other platforms?) > - Support Extended Operations by wrapping > ldap_extended_operation() and ldap_parse_extended_result() > - Set Password ext. op. > - Whoami ext. op. > > Lib/ > - Remove obsolete/unsupported modules > - Caching of search requests for each LDAPObject instance > - LDIF parser for replication logs > - DSML support > - Support for SASL mechanims GSS-API > > Tests/ > Clean up and finish the mess of test scripts started. > > > > From michael at stroeder.com Tue Aug 20 14:50:34 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 20 Aug 2002 14:50:34 +0200 Subject: TODO until python-ldap 2.0.0 final release References: <1362A90E-B3BE-11D6-AC66-0003939EFEBC@zope.com> Message-ID: <3D623B1A.20108@stroeder.com> Jens Vagelpohl wrote: > talking about the common license, is there such a beast yet and > you're just looking for someone to go through every file and > make sure it's in there? or is it more about producing the > legalese gibberish itself? :) Well, a little bit of both. Ciao, Michael. From jens at zope.com Tue Aug 20 16:24:52 2002 From: jens at zope.com (Jens Vagelpohl) Date: Tue, 20 Aug 2002 10:24:52 -0400 Subject: TODO until python-ldap 2.0.0 final release In-Reply-To: <3D623B1A.20108@stroeder.com> Message-ID: <976DF3B6-B448-11D6-92F5-0003939EFEBC@zope.com> where's the canonical "starting place", the "half-done" license? i'd be willing to finish that and make sure it appears wherever it is needed. jens On Tuesday, August 20, 2002, at 08:50 , Michael Str?der wrote: > Jens Vagelpohl wrote: > > talking about the common license, is there such a beast yet and > you're > just looking for someone to go through every file and > > make sure it's in there? or is it more about producing the > > legalese gibberish itself? :) > > Well, a little bit of both. > > Ciao, Michael. > From david.leonard at itee.uq.edu.au Wed Aug 21 07:20:51 2002 From: david.leonard at itee.uq.edu.au (David Leonard) Date: Wed, 21 Aug 2002 15:20:51 +1000 Subject: TODO until python-ldap 2.0.0 final release References: <1362A90E-B3BE-11D6-AC66-0003939EFEBC@zope.com> <3D623B1A.20108@stroeder.com> Message-ID: <029e01c248d2$862d4140$0d00640a@bovingdonst.fnarg.net.au> hi there python-ldap hackers! ahh ldap. although i don't do much with LDAP any more, i thought it would help i wrote something about the legal situation. the only necessary legalese to have in the distribution is a NOTICE that the software is provided AS IS and is not guranteed from exploding into small pieces. that is to cover our arses. this is a MINIMUM necessity in any software today. (It's because software engineering is generally of so abysmally low quality compared to any other human endeavour ... but that's another story!) as for the LICENCE.. i dunno. it is up to the primary authors of each 'contribution' to licence their work. i think the sourceforge project as a whole is declared publicly as "GPL" in the SF databases, but any BSD or PD licencing on individual files would still be compatible with that, so its not a problem to have individual contributions licenced differently. The LICENSE (sic) file is a bit of a dubious licence .. it's claims public domain release (ie destroyed copyright) but it then imposes conditions on use (ie acceptance of the disclaimer). i think that would collapse under scrutiny. Well at least there is a disclaimer there - ie the notice of user risk, which is the most important thing. The LICENSE file also appears to conflict with the explicit licencing in some files (gpl). Perhaps it could be changed to be more of a 'default' situation.. ie "Unless otherwise specified source files in this distribution are licenced for any use subject to acceptance of the following disclaimer, and may be otherwise treated as works in the public domain"... However, I do NOT want to see anyone FORCED into releasing their work or fixes into the public domain (although it would be nice). It's the primary author's right to restrict their work in any fashion that they desire (this ability stems from their natural copyright). But any contribution with a licence more restrictive than the GPL should not be allowed to be committed into the repository! that would be bad. Why? Because any packaging or distribution of python-ldap would have to comply with the strongest of licences. (GPL at the moment). And that wouldnt be fair. today, if someone wants to extract the non-GPLd code for their own evil corporate frankenstein product, then its up to them to manually go through and separate the files from each other.. and maybe even go through the CVS commits (which, depending on their relative size may not merit the status of a separately licencable 'contrbution'... mmm controversial) so, if someone wants to clean up the legalese mess, and clarify the situation, then go for it. But, adding more lines of text to all the files (as suggested) is a bit of overkill, in my opinion. another track is to ask all authors for permission to vary their licences to a common licence... like GPL or BSD... but you couldnt guarantee that everyone would agree! (or even be contactable!) d -- David Leonard ----- Original Message ----- From: "Michael Str?der" To: "Jens Vagelpohl" Cc: "Python Developer List" Sent: Tuesday, August 20, 2002 10:50 PM Subject: Re: TODO until python-ldap 2.0.0 final release > Jens Vagelpohl wrote: > > talking about the common license, is there such a beast yet and > > you're just looking for someone to go through every file and > > make sure it's in there? or is it more about producing the > > legalese gibberish itself? :) > > Well, a little bit of both. > > Ciao, Michael. > > > > From jens at zope.com Wed Aug 21 13:50:52 2002 From: jens at zope.com (Jens Vagelpohl) Date: Wed, 21 Aug 2002 07:50:52 -0400 Subject: License (was: Re: TODO until python-ldap 2.0.0 final release) In-Reply-To: <029e01c248d2$862d4140$0d00640a@bovingdonst.fnarg.net.au> Message-ID: <3E338C24-B4FC-11D6-87AD-0003939EFEBC@zope.com> just as a data point (this does not imply i want to follow the same route) , here at zope corp every contributor to our CVS must sign a document that allows us to put our ZPL (fully GPL-compatible) license onto anything they contribute. only after signing will they get CVS access. since we operate in commercial space doing custom zope applications this is an absolute "must", and a lot of customer contracts now have clauses to the effect that they never want to be the target of litigation because of any licensing issues in the underlying software. so we have to have very tight control over the license, and basically don't allow anything but ZPL-licensed software in our repository. i would suggest that the best way, for sanity's sake, is standardizing on a single license and trying to contact contributors to get their agreement. every single file in the python-ldap package would carry a short blurb at the top(1) that has the explicit "no warantees" assertion and a pointer to the main license which is stored in a central file such as LICENSE.txt or simply LICENSE (ZPL below, just as an example(2)). having a single license for python-ldap would also make python-ldap "usable" for paranoid companies/ individuals who actually read these licenses. unfortunately i am not sure what the legal situation is about wanting to change an existing license on a contribution if the original author cannot be contacted anymore... jens (1) sample we use at zope corp (obviously this would look a tad different for python-ldap):: """ ########################################################################## #### # # Copyright (c) 2001 Zope Corporation and Contributors. All Rights Reserved. # # This software is subject to the provisions of the Zope Public License, # Version 2.0 (ZPL). A copy of the ZPL should accompany this distribution. # THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED # WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED # WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS # FOR A PARTICULAR PURPOSE # ########################################################################## #### """ (2) the ZPL: """ Zope Public License (ZPL) Version 2.0 ----------------------------------------------- This software is Copyright (c) Zope Corporation (tm) and Contributors. All rights reserved. This license has been certified as open source. It has also been designated as GPL compatible by the Free Software Foundation (FSF). Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions in source code must retain the above copyright notice, this list of conditions, and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name Zope Corporation (tm) must not be used to endorse or promote products derived from this software without prior written permission from Zope Corporation. 4. The right to distribute this software or to use it for any purpose does not give you the right to use Servicemarks (sm) or Trademarks (tm) of Zope Corporation. Use of them is covered in a separate agreement (see http://www.zope.com/Marks). 5. If any files are modified, you must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. Disclaimer THIS SOFTWARE IS PROVIDED BY ZOPE CORPORATION ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ZOPE CORPORATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of contributions made by Zope Corporation and many individuals on behalf of Zope Corporation. Specific attributions are listed in the accompanying credits file. """ On Wednesday, August 21, 2002, at 01:20 , David Leonard wrote: > hi there python-ldap hackers! > > ahh ldap. although i don't do much with LDAP any more, i thought it would > help i wrote something about the legal situation. > > the only necessary legalese to have in the distribution is a NOTICE that > the > software is provided AS IS and is not guranteed from exploding into small > pieces. that is to cover our arses. this is a MINIMUM necessity in any > software today. (It's because software engineering is generally of so > abysmally low quality compared to any other human endeavour ... but that' > s > another story!) > > as for the LICENCE.. i dunno. it is up to the primary authors of each > 'contribution' to licence their work. i think the sourceforge project as > a > whole is declared publicly as "GPL" in the SF databases, but any BSD or PD > licencing on individual files would still be compatible with that, so its > not a problem to have individual contributions licenced differently. > > The LICENSE (sic) file is a bit of a dubious licence .. it's claims public > domain release (ie destroyed copyright) but it then imposes conditions on > use (ie acceptance of the disclaimer). i think that would collapse under > scrutiny. Well at least there is a disclaimer there - ie the notice of > user risk, which is the most important thing. > > The LICENSE file also appears to conflict with the explicit licencing in > some files (gpl). Perhaps it could be changed to be more of a 'default' > situation.. ie "Unless otherwise specified source files in this > distribution > are licenced for any use subject to acceptance of the following disclaimer, > and may be otherwise treated as works in the public domain"... > > However, I do NOT want to see anyone FORCED into releasing their work or > fixes into the public domain (although it would be nice). It's the primary > author's right to restrict their work in any fashion that they desire (this > ability stems from their natural copyright). > > But any contribution with a licence more restrictive than the GPL should > not > be allowed to be committed into the repository! that would be bad. > > Why? Because any packaging or distribution of python-ldap would have to > comply with the strongest of licences. (GPL at the moment). And that > wouldnt > be fair. today, if someone wants to extract the non-GPLd code for their own > evil corporate frankenstein product, then its up to them to manually go > through and separate the files from each other.. and maybe even go through > the CVS commits (which, depending on their relative size may not merit the > status of a separately licencable 'contrbution'... mmm controversial) > > so, if someone wants to clean up the legalese mess, and clarify the > situation, then go for it. But, adding more lines of text to all the files > (as suggested) is a bit of overkill, in my opinion. > > another track is to ask all authors for permission to vary their licences > to > a common licence... like GPL or BSD... but you couldnt guarantee that > everyone would agree! (or even be contactable!) > > d > -- > David Leonard > ----- Original Message ----- > From: "Michael Str?der" > To: "Jens Vagelpohl" > Cc: "Python Developer List" > Sent: Tuesday, August 20, 2002 10:50 PM > Subject: Re: TODO until python-ldap 2.0.0 final release > > >> Jens Vagelpohl wrote: >>> talking about the common license, is there such a beast yet and >>> you're just looking for someone to go through every file and >>> make sure it's in there? or is it more about producing the >>> legalese gibberish itself? :) >> >> Well, a little bit of both. >> >> Ciao, Michael. >> >> >> >> From Hans.Aschauer at Physik.uni-muenchen.de Wed Aug 21 12:04:56 2002 From: Hans.Aschauer at Physik.uni-muenchen.de (Hans Aschauer) Date: Wed, 21 Aug 2002 12:04:56 +0200 Subject: TODO until python-ldap 2.0.0 final release In-Reply-To: <3D6136F2.6080207@stroeder.com> References: <3D6136F2.6080207@stroeder.com> Message-ID: <200208211204.56871.Hans.Aschauer@Physik.uni-muenchen.de> On Montag, 19. August 2002 20:20, Michael Str?der wrote: > HI! > > I'd like to bring your attention to the TODO file in python-ldap. > For your convenience it's attached below. ;-) > > Any takers? Especially I'd like to see a general approach for > extended controls and extended operations. Yeah, C illiterate I am > I'm asking for help... [...] > Modules/ > - Validating server's certificate when calling start_tls_s() or > ldap.initialize('ldaps://..') Seems to be interesting. However, I have no idea how much work it is, and honestly, I don't know the pitfalls which one has to overcome in order to get it right, but I will look into it. > - General support for controls > - VLV control > - server-side sorting control > - Binding in DSA control mode (rewrite necessary) > - Persistent search control > - Wrap ldap_parse_reference() > - Support for Win32 (and other platforms?) > - Support Extended Operations by wrapping > ldap_extended_operation() and ldap_parse_extended_result() > - Set Password ext. op. > - Whoami ext. op. Maybe I find some free time to do these things (except for Win32). The C-API does not seem to be too complicated. Probably it would be a good idea to write wrappers for generic controls/extended operations only, and leave the details to python code. > Lib/ > - Remove obsolete/unsupported modules > - Caching of search requests for each LDAPObject instance > - LDIF parser for replication logs > - DSML support > - Support for SASL mechanims GSS-API Huh, does SASL GSS-API not work? I dont't have a working kerberos right now, but it used to work. Hans -- Hans.Aschauer at Physik.uni-muenchen.de From michael at stroeder.com Wed Aug 21 21:22:22 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Wed, 21 Aug 2002 21:22:22 +0200 Subject: TODO until python-ldap 2.0.0 final release References: <3D6136F2.6080207@stroeder.com> <200208211204.56871.Hans.Aschauer@Physik.uni-muenchen.de> Message-ID: <3D63E86E.3070504@stroeder.com> Hans Aschauer wrote: > On Montag, 19. August 2002 20:20, Michael Str?der wrote: > >>Modules/ >>- Validating server's certificate when calling start_tls_s() or >> ldap.initialize('ldaps://..') > > Seems to be interesting. However, I have no idea how much work it is, > and honestly, I don't know the pitfalls which one has to overcome in > order to get it right, but I will look into it. Frankly at the moment I have no clue whether this is more an issue of the OpenLDAP 2 lib itself or if we can do anything about it in python-ldap's C module part. Additionally there will be built-in support for CRL checking in OpenSSL 0.9.7 itself. > Probably it would be a good > idea to write wrappers for generic controls/extended operations only, > and leave the details to python code. Yepp! >>Lib/ >>- Remove obsolete/unsupported modules >>- Caching of search requests for each LDAPObject instance >>- LDIF parser for replication logs >>- DSML support >>- Support for SASL mechanims GSS-API > > Huh, does SASL GSS-API not work? Aah, sorry. I did not see and did not test this. > I dont't have a working kerberos right > now, but it used to work. Ok, then I will remove it from TODO. Ciao, Michael. From michael at stroeder.com Wed Aug 21 21:14:19 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 21 Aug 2002 21:14:19 +0200 Subject: TODO until python-ldap 2.0.0 final release References: <1362A90E-B3BE-11D6-AC66-0003939EFEBC@zope.com> <3D623B1A.20108@stroeder.com> <029e01c248d2$862d4140$0d00640a@bovingdonst.fnarg.net.au> Message-ID: <3D63E68B.4010007@stroeder.com> David Leonard wrote: > > as for the LICENCE.. i dunno. > [..] > The LICENSE (sic) file is a bit of a dubious licence .. $ diff LICENSE Modules/LICENCE 2c2 < The python-ldap package is in the PUBLIC DOMAIN. --- > The _ldap C module is in the PUBLIC DOMAIN. 15c15 < $Id: LICENSE,v 1.1 2002/07/25 21:43:25 stroeder Exp $ --- > $Id: LICENCE,v 1.1 2001/06/17 13:30:23 leonard Exp $ ;-) > The LICENSE file also appears to conflict with the explicit licencing in > some files (gpl). GPL? $ egrep -i "(gnu|gpl)" Lib/*.py Lib/ldap/*.py $ > Perhaps it could be changed to be more of a 'default' > situation.. ie "Unless otherwise specified source files in this distribution > are licenced for any use subject to acceptance of the following disclaimer, > and may be otherwise treated as works in the public domain"... I want to have exactly one file containing the license (or licence?) for all files distributed in the package. > However, I do NOT want to see anyone FORCED into releasing their work or > fixes into the public domain (although it would be nice). Agreed. > But any contribution with a licence more restrictive than the GPL should not > be allowed to be committed into the repository! that would be bad. Agreed. No doubt about that. > Why? Because any packaging or distribution of python-ldap would have to > comply with the strongest of licences. (GPL at the moment). No GPL anymore. Please bring your working tree in sync. I had the GPL in the header of some modules copied over from web2ldap. I just forgot to change that. Fixed that some time ago. > But, adding more lines of text to all the files > (as suggested) is a bit of overkill, in my opinion. Agreed. > another track is to ask all authors for permission to vary their licences to > a common licence... like GPL or BSD... but you couldnt guarantee that > everyone would agree! (or even be contactable!) I'd like to remove unmaintained and unpackaged code from the CVS anyway. This mainly affects Fog's Lib/perldap.py and ldaplib/*. The set of active authors boils down to Hans, David and me. The rest contributed patches and I'm pretty sure that the patched code is maintained in the python-ldap mainstream => for published fixes I would just assume the overall license we can agree on. Personally I have no problem to choose a very liberal one which allows commercial use. Ciao, Michael. From david.leonard at itee.uq.edu.au Thu Aug 22 03:35:29 2002 From: david.leonard at itee.uq.edu.au (David Leonard) Date: Thu, 22 Aug 2002 11:35:29 +1000 (EST) Subject: TODO until python-ldap 2.0.0 final release In-Reply-To: <3D63E68B.4010007@stroeder.com> Message-ID: On Wed, 21 Aug 2002, Michael Str?der typed thusly: > No GPL anymore. Please bring your working tree in sync. I had the > GPL in the header of some modules copied over from web2ldap. I > just forgot to change that. Fixed that some time ago. but fog's stuff in ldaplib/... has "GNU General Public License"(sic) in it. [just an english note: licence is a noun, and license is a verb... the mnemonic I use is that ICE is a noun.. ... [hey whats that crazy german dish with frozen pig trotters and saurkraut?]] > > another track is to ask all authors for permission to vary their licences to > > a common licence... like GPL or BSD... but you couldnt guarantee that > > everyone would agree! (or even be contactable!) > > I'd like to remove unmaintained and unpackaged code from the CVS > anyway. This mainly affects Fog's Lib/perldap.py and ldaplib/*. > The set of active authors boils down to Hans, David and me. The > rest contributed patches and I'm pretty sure that the patched code > is maintained in the python-ldap mainstream => for published fixes > I would just assume the overall license we can agree on. > Personally I have no problem to choose a very liberal one which > allows commercial use. so.. heres a plan for you, michael- 1) choose licence 2) mail the GPL authors asking if its okay to degrade/unify their code under the new licence 3) rm the files that are unmaintained? d -- David Leonard David.Leonard at itee.uq.edu.au School of Inf. Tech. and Elec. Engg _ Ph:+61 404 844 850 The University of Queensland |+| http://www.itee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ From michael at stroeder.com Thu Aug 22 14:27:39 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Thu, 22 Aug 2002 14:27:39 +0200 Subject: TODO until python-ldap 2.0.0 final release References: Message-ID: <3D64D8BB.7020003@stroeder.com> David Leonard wrote: > >No GPL anymore. Please bring your working tree in sync. > > but fog's stuff in ldaplib/... has "GNU General Public > License"(sic) in it. Ah, did not look at that. Fog's stuff is not part of the source distribution package generated with python setup.py sdist anyway. I'd like to also remove it from CVS tree. > [just an english note: licence is a noun, and license is a > verb... I found both "LICENSE" and "LICENCE" in the source packages of other projects. Maybe there's also a difference whether you speak American or British english? Examples for use of term "license": http://www.gnu.org/copyleft/gpl.html Personally I have no preference. Ciao, Michael. From michael at stroeder.com Thu Aug 22 20:46:46 2002 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Thu, 22 Aug 2002 20:46:46 +0200 Subject: TODO until python-ldap 2.0.0 final release References: <3D64D8BB.7020003@stroeder.com> Message-ID: <3D653196.9020103@stroeder.com> Michael Str?der wrote: > > Fog's stuff is not part of the source > distribution package generated with python setup.py sdist anyway. > > I'd like to also remove it from CVS tree. /bin/done Ciao, Michael. From davidma at eskimo.com Fri Aug 23 00:15:48 2002 From: davidma at eskimo.com (David Margrave) Date: Thu, 22 Aug 2002 15:15:48 -0700 (PDT) Subject: TLS Message-ID: I have finally taken a look atpython-ldap 2.0. Is there a way to do start_tls are are you restricted to ldap.initialize('ldaps://...')? Dave From michael at stroeder.com Fri Aug 23 09:58:14 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 23 Aug 2002 09:58:14 +0200 Subject: TLS References: Message-ID: <3D65EB16.50304@stroeder.com> David Margrave wrote: > I have finally taken a look atpython-ldap 2.0. Is there a way to do > start_tls are are you restricted to ldap.initialize('ldaps://...')? Use method start_tls_s(). Take a look at Demo/initialize.py. Ciao, Michael. From michael at stroeder.com Fri Aug 23 10:39:40 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 23 Aug 2002 10:39:40 +0200 Subject: License (was: Re: TODO until python-ldap 2.0.0 final release) References: <3E338C24-B4FC-11D6-87AD-0003939EFEBC@zope.com> Message-ID: <3D65F4CC.8090803@stroeder.com> HI! Now that I removed Fog's GPL-ed stuff from the CVS repository I think it shouldn't be too difficult to choose a common licen(c|s)e for all files. I have two requirements: - be as compatible to Python itself - be compatible to GPL http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses lists the newer Python license as GPL-compatible. How about using this one: http://www.python.org/2.0.1/license.html Ciao, Michael. From fog at debian.org Fri Aug 23 10:46:19 2002 From: fog at debian.org (Federico Di Gregorio) Date: 23 Aug 2002 10:46:19 +0200 Subject: License (was: Re: TODO until python-ldap 2.0.0 final release) In-Reply-To: <3D65F4CC.8090803@stroeder.com> References: <3E338C24-B4FC-11D6-87AD-0003939EFEBC@zope.com> <3D65F4CC.8090803@stroeder.com> Message-ID: <1030092379.1114.18.camel@momo> Il ven, 2002-08-23 alle 10:39, Michael Str?der ha scritto: > HI! > > Now that I removed Fog's GPL-ed stuff from the CVS repository I > think it shouldn't be too difficult to choose a common licen(c|s)e > for all files. > > I have two requirements: > - be as compatible to Python itself > - be compatible to GPL > > http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses > lists the newer Python license as GPL-compatible. > > How about using this one: http://www.python.org/2.0.1/license.html good enough for me. maybe my stuff should be kept ouside anyway, i am spanding almost all my hacking time in other projects nowdays and i don't know i i'll ever finish the ldap thingies. ciao, federico -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog at debian.org INIT.D Developer fog at initd.org God is real. Unless declared integer. -- Anonymous FORTRAN programmer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jens at zope.com Fri Aug 23 14:18:13 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 23 Aug 2002 08:18:13 -0400 Subject: License (was: Re: TODO until python-ldap 2.0.0 final release) In-Reply-To: <3D65F4CC.8090803@stroeder.com> Message-ID: <6564A842-B692-11D6-B4C9-0003939EFEBC@zope.com> > How about using this one: http://www.python.org/2.0.1/license.html > which one? there's *3* separate licenses in there ;) jens From michael at stroeder.com Fri Aug 23 14:54:47 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 23 Aug 2002 14:54:47 +0200 Subject: License (was: Re: TODO until python-ldap 2.0.0 final release) References: <6564A842-B692-11D6-B4C9-0003939EFEBC@zope.com> Message-ID: <3D663097.90707@stroeder.com> Jens Vagelpohl wrote: > >> How about using this one: http://www.python.org/2.0.1/license.html > > which one? there's *3* separate licenses in there ;) (Sigh!) Well, how about PSF LICENSE AGREEMENT FOR PYTHON 2.2.1 from http://www.python.org/2.2.1/license.html? I really wonder what module authors mean by writing "Python-style license". Ciao, Michael. From jens at zope.com Fri Aug 23 15:05:28 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 23 Aug 2002 09:05:28 -0400 Subject: License (was: Re: TODO until python-ldap 2.0.0 final release) In-Reply-To: <3D663097.90707@stroeder.com> Message-ID: that looks good. now, all of these licenses mention that they are between the end user and some tangible entity, like the python software foundation in case of the python license. what or who would that entity be for python-ldap? i have a feeling there must be some "licensor" explicitly named to make this beast enforceable at all. jens On Friday, August 23, 2002, at 08:54 , Michael Str?der wrote: > Jens Vagelpohl wrote: >>> How about using this one: http://www.python.org/2.0.1/license.html >> which one? there's *3* separate licenses in there ;) > > (Sigh!) Well, how about > > PSF LICENSE AGREEMENT FOR PYTHON 2.2.1 > > from http://www.python.org/2.2.1/license.html? > > I really wonder what module authors mean by > writing "Python-style license". > > Ciao, Michael. > From michael at stroeder.com Fri Aug 23 15:16:54 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 23 Aug 2002 15:16:54 +0200 Subject: License (was: Re: TODO until python-ldap 2.0.0 final release) References: Message-ID: <3D6635C6.40900@stroeder.com> Jens Vagelpohl wrote: > that looks good. > > now, all of these licenses mention that they are between the end user > and some tangible entity, like the python software foundation in case of > the python license. what or who would that entity be for python-ldap? i > have a feeling there must be some "licensor" explicitly named to make > this beast enforceable at all. Yes. How about asking Guido at Zope on how to grant the "licensor" role to the PSF? http://www.python.org/psf/mission.html sounds much like that. Maybe there's a separate PSF license available we can refer to? David? Ciao, Michael. From jens at zope.com Fri Aug 23 15:37:43 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 23 Aug 2002 09:37:43 -0400 Subject: License (was: Re: TODO until python-ldap 2.0.0 final release) In-Reply-To: <3D6635C6.40900@stroeder.com> Message-ID: <808F4071-B69D-11D6-A58B-0003939EFEBC@zope.com> from my read of those pages about the PSF i could not find anything that said the PSF licenses other software packages or offers to somehow be an umbrella for python-related software. i'll send a note to guido and ask him. jens On Friday, August 23, 2002, at 09:16 , Michael Str?der wrote: > Jens Vagelpohl wrote: >> that looks good. >> now, all of these licenses mention that they are between the end user and >> some tangible entity, like the python software foundation in case of the >> python license. what or who would that entity be for python-ldap? i have >> a feeling there must be some "licensor" explicitly named to make this >> beast enforceable at all. > > Yes. > > How about asking Guido at Zope on how to grant the "licensor" role to the PSF? > http://www.python.org/psf/mission.html sounds much like that. Maybe there' > s a separate PSF license available we can refer to? > > David? > > Ciao, Michael. > From jens at zope.com Fri Aug 23 15:43:02 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 23 Aug 2002 09:43:02 -0400 Subject: Fwd: License (was: Re: TODO until python-ldap 2.0.0 final release) Message-ID: <3E68BDA8-B69E-11D6-A58B-0003939EFEBC@zope.com> here's my message to guido... Begin forwarded message: > From: Jens Vagelpohl > Date: Fri Aug 23, 2002 09:41:37 US/Eastern > To: guido at zope.com > Subject: Fwd: License (was: Re: TODO until python-ldap 2.0.0 final release) > > guido, > > here's a non-technical question for you:: > > as part of preparing for the next python-ldap release michael str?der has > started a cleanup of all the various licenses that hang around in the > python-ldap repository. his goal is to unify everything under a single > license and the python/PSF license looks good to all those involved. > > now here's the hook: there is no entity that we could really name as the > licensor. michael asked me to ask you if there are any provisions under > which the python software foundation can assume the position of licensor > for any non-core python packages? > > jens > > > Begin forwarded message: > >> From: Jens Vagelpohl >> Date: Fri Aug 23, 2002 09:05:28 US/Eastern >> To: Michael Str?der >> Cc: Python Developer List >> Subject: Re: License (was: Re: TODO until python-ldap 2.0.0 final release) >> >> that looks good. >> >> now, all of these licenses mention that they are between the end user and >> some tangible entity, like the python software foundation in case of the >> python license. what or who would that entity be for python-ldap? i have >> a feeling there must be some "licensor" explicitly named to make this >> beast enforceable at all. >> >> jens >> >> >> On Friday, August 23, 2002, at 08:54 , Michael Str?der wrote: >> >>> Jens Vagelpohl wrote: >>>>> How about using this one: http://www.python.org/2.0.1/license.html >>>> which one? there's *3* separate licenses in there ;) >>> >>> (Sigh!) Well, how about >>> >>> PSF LICENSE AGREEMENT FOR PYTHON 2.2.1 >>> >>> from http://www.python.org/2.2.1/license.html? >>> >>> I really wonder what module authors mean by >>> writing "Python-style license". >>> >>> Ciao, Michael. >>> >> >> >> >> From michael at stroeder.com Fri Aug 23 15:58:36 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 23 Aug 2002 15:58:36 +0200 Subject: License (was: Re: TODO until python-ldap 2.0.0 final release) References: <808F4071-B69D-11D6-A58B-0003939EFEBC@zope.com> Message-ID: <3D663F8C.40602@stroeder.com> Jens Vagelpohl wrote: > Michael Str?der wrote: > > > http://www.python.org/psf/mission.html sounds much like that. > > from my read of those pages about the PSF i could not find anything that > said the PSF licenses other software packages or offers to somehow be an > umbrella for python-related software. My understanding of English is not perfect. That's for sure. Maybe I misunderstood these items on the PSF mission list: ----------------------------- snip ----------------------------- * Establishes PSF licenses, ensuring the rights of the public to freely obtain, use, redistribute, and modify intellectual property held by the PSF. [..] * Solicits and manages contributions to the Python codebase, and may perform these services on behalf of other open source Python-related codebases. ----------------------------- snip ----------------------------- Let's wait for what Guido and David will answer. Ciao, Michael. From jens at zope.com Fri Aug 23 17:36:38 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 23 Aug 2002 11:36:38 -0400 Subject: Fwd: License (was: Re: TODO until python-ldap 2.0.0 final release) Message-ID: <1D6557A6-B6AE-11D6-A58B-0003939EFEBC@zope.com> here's guido's answer... Begin forwarded message: > From: Guido van Rossum > Date: Fri Aug 23, 2002 11:00:57 US/Eastern > To: Jens Vagelpohl > Subject: Re: Fwd: License (was: Re: TODO until python-ldap 2.0.0 final > release) > >> guido, >> >> here's a non-technical question for you:: >> >> as part of preparing for the next python-ldap release michael str?der has >> started a cleanup of all the various licenses that hang around in the >> python-ldap repository. his goal is to unify everything under a single >> license and the python/PSF license looks good to all those involved. >> >> now here's the hook: there is no entity that we could really name as the >> licensor. michael asked me to ask you if there are any provisions under >> which the python software foundation can assume the position of licensor >> for any non-core python packages? >> >> jens > > If you transfer the copyright to the PSF, sure! We haven't quite > figured out the right way to do that, but draft forms are here: > > http://www.python.org/psf/psf-contributor-agreement.html > > There are some alternatives, like joint ownership, too. > > --Guido van Rossum (home page: http://www.python.org/~guido/) From david.leonard at itee.uq.edu.au Sun Aug 25 09:18:52 2002 From: david.leonard at itee.uq.edu.au (David Leonard) Date: Sun, 25 Aug 2002 17:18:52 +1000 (EST) Subject: License (was: Re: TODO until python-ldap 2.0.0 final release) In-Reply-To: <3D6635C6.40900@stroeder.com> Message-ID: hmm. for PSF licencing, I think we will have to 1) check with PSF - they may want us to sign a 'contributor agreement', a la Zope, to indemnify them against IP/ownership etc 2) assign copyright of all files to the PSF, ie add to each file: "Copyright (c) 2002 Python Software Foundation; All Rights Reserved" if you're going to give away ownership like that, then why not just go public domain? its the most 'open' of open source, imho. I'm happy either way, since I gave up copyright in all of my contributed files. As, long as you leave the notice/warning message in there somewhere. note also that previous file versions (extracted from cvs) would remain under their old licencing/copyright (if any).. which is normal, and desirable. d On Fri, 23 Aug 2002, Michael Str?der typed thusly: > Jens Vagelpohl wrote: > > that looks good. > > > > now, all of these licenses mention that they are between the end user > > and some tangible entity, like the python software foundation in case of > > the python license. what or who would that entity be for python-ldap? i > > have a feeling there must be some "licensor" explicitly named to make > > this beast enforceable at all. > > Yes. > > How about asking Guido at Zope on how to grant the "licensor" role to > the PSF? http://www.python.org/psf/mission.html sounds much like > that. Maybe there's a separate PSF license available we can refer to? > > David? > > Ciao, Michael. -- David Leonard David.Leonard at itee.uq.edu.au School of Inf. Tech. and Elec. Engg _ Ph:+61 404 844 850 The University of Queensland |+| http://www.itee.uq.edu.au/~leonard/ QLD 4072 AUSTRALIA ~` '~ From skaich at ontrackindia.com Fri Aug 30 12:55:32 2002 From: skaich at ontrackindia.com (skaich) Date: Fri, 30 Aug 2002 16:25:32 +0530 Subject: A Query Regarding Python Ldap Form Suman Message-ID: <000c01c25013$cb94c300$5b00a8c0@ontrackindia.com> Hello Sir I have recently downloded python-ldap-2.0.0pre05.tar.gz from source forge website. I insalled Python 2.1.2 and Openldap 2.1.4 but when I try to compile the following error message is coming : suse:/usr/local/zope/python-ldap-2.0.0pre05 # /usr/local/bin/python setup.py build running build running build_py warning: build_py: file Lib/ldap.py (for module ldap) not found not copying Lib/ldap/__init__.py (output up-to-date) not copying Lib/ldap/async.py (output up-to-date) not copying Lib/ldap/functions.py (output up-to-date) not copying Lib/ldap/sasl.py (output up-to-date) not copying Lib/ldap/schema.py (output up-to-date) not copying Lib/ldap/ldapobject.py (output up-to-date) not copying Lib/ldap/modlist.py (output up-to-date) not copying Lib/ldapurl.py (output up-to-date) not copying Lib/ldif.py (output up-to-date) warning: build_py: file Lib/ldap.py (for module ldap) not found running build_ext building '_ldap' extension skipping Modules/LDAPObject.c (build/temp.linux-i686-2.1/LDAPObject.o up-to-date) skipping Modules/common.c (build/temp.linux-i686-2.1/common.o up-to-date) gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -DHAVE_LDAP_START_TLS_S -DLDAPMODULE_VERSION=2.0.0pre05 -IModules -I/usr/local/openldap2/include -I/usr/local/include/python2.1 -c Modules/constants.c -o build/temp.linux-i686-2.1/constants.o Modules/constants.c: In function `LDAPinit_constants': Modules/constants.c:176: `LDAP_FILT_MAXSIZ' undeclared (first use in this function) Modules/constants.c:176: (Each undeclared identifier is reported only once Modules/constants.c:176: for each function it appears in.) error: command 'gcc' failed with exit status 1 I have installed openldap in /usr/local/openldap and I have the following changes the setup.cfg file [_ldap] class = OpenLDAP2 library_dirs = /usr/local/openldap2/lib include_dirs = /usr/local/openldap2/include -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Fri Aug 30 13:04:07 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 30 Aug 2002 13:04:07 +0200 Subject: A Query Regarding Python Ldap Form Suman References: <001a01c25013$ecae45c0$5b00a8c0@ontrackindia.com> Message-ID: <3D6F5127.8020605@stroeder.com> skaich wrote: > > I have recently downloded python-ldap-2.0.0pre05.tar.gz > from > source forge website. I insalled Python 2.1.2 and Openldap 2.1.4 but > when I try to compile the following error message is coming : > [..] > Modules/constants.c: In function `LDAPinit_constants': > Modules/constants.c:176: `LDAP_FILT_MAXSIZ' undeclared (first use in > this function) This has already been fixed in CVS version. See comment: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Modules/constants.c Or the diff http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Modules/constants.c.diff?r1=1.13&r2=1.14 Ciao, Michael. From michael at stroeder.com Sat Aug 31 20:48:27 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 31 Aug 2002 20:48:27 +0200 Subject: [Fwd: Re: Liberal parsing of schema elements (ITS#1996)] Message-ID: <3D710F7B.8000104@stroeder.com> HI! See final analysis below. Just for the records. Remind when doing error handling with wrapped OpenLDAP functions in future. Ciao, Michael. -------- Original Message -------- Subject: Re: Liberal parsing of schema elements (ITS#1996) Date: Thu, 29 Aug 2002 11:00:56 GMT From: Howard Chu To: michael at stroeder.com > Kurt D. Zeilenga wrote: >> I misunderstood the nature of the problem. The >> client library ALLOW flags, if properly enabled, >> should be able to parse these non-conformant >> values. If they aren't working, that's a bug. >> Patches welcomed. The code parses the string just fine and returns a valid LDAPObjectClass result. It just happens to leave a non-zero error code set as well, left over from its attempt to find a numeric OID. With the ALLOW flags set, that code is ignored and the parse continues. Since the return value is non-NULL Python should not be treating this as a failure. > > Any progress on this? > > Unfortunately I'm not a C programmer. I looked at the OpenLDAP > code and AFAICS there is code to allow non-numeric OIDs if the > proper ALLOW flag is set. > > The author of the relevant parts in python-ldap double-checked > that the ALLOW flags are properly passed to OpenLDAP's schema > parsing functions. > > But even with LDAP_SCHEMA_ALLOW_ALL the parsing chokes on e.g. > this line (Python exception instance displayed here): > > ldap.schema.SCHERR_NODIGIT: (5, "( pilotOrganization-OID NAME > 'pilotOrganization' DESC 'Standard ObjectClass' SUP 'top' MUST ( > objectclass $ ou $ o ) MAY ( aci $ buildingName $ > businessCategory $ description $ destinationIndicator $ > facsimileTelephoneNumber $ internationalIsdnNumber $ l $ > physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ > postalCode $ preferredDeliveryMethod $ registeredAddress $ > searchGuide $ seeAlso $ st $ street $ telephoneNumber $ > teletexTerminalIdentifier $ telexNumber $ userPassword $ > x121Address ) )") From vonceumern at rz.rwth-aachen.de Thu Sep 5 13:01:06 2002 From: vonceumern at rz.rwth-aachen.de (Ulf von Ceumern) Date: Thu, 05 Sep 2002 13:01:06 +0200 Subject: unable to build ldap.py Message-ID: <3D773972.BF0C5FD@rz.rwth-aachen.de> Hi. I have some trouble building and installing python-ldap-2.0.0pre04 or 5 on my system (dont know sys specs exactly. some sun solaris server). here is what i get: bash-2.03$ make python setup.py build running build running build_py warning: build_py: file Lib/ldap.py (for module ldap) not found not copying Lib/ldap/__init__.py (output up-to-date) not copying Lib/ldap/async.py (output up-to-date) not copying Lib/ldap/functions.py (output up-to-date) not copying Lib/ldap/sasl.py (output up-to-date) not copying Lib/ldap/schema.py (output up-to-date) not copying Lib/ldap/ldapobject.py (output up-to-date) not copying Lib/ldap/modlist.py (output up-to-date) not copying Lib/ldapurl.py (output up-to-date) not copying Lib/ldif.py (output up-to-date) warning: build_py: file Lib/ldap.py (for module ldap) not found running build_ext skipping '_ldap' extension (up-to-date) plus: i am installing this under a user dir and need to point python to use this version rather than the old version which is installed under the python lib dir somewhere. how do i do that? best regards, ulf v. ceumern From michael at stroeder.com Thu Sep 5 13:30:48 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 05 Sep 2002 13:30:48 +0200 Subject: unable to build ldap.py References: <3D773972.BF0C5FD@rz.rwth-aachen.de> Message-ID: <3D774068.6060008@stroeder.com> Ulf von Ceumern wrote: > > warning: build_py: file Lib/ldap.py (for module ldap) not found This is a warning caused by a deficiency of DistUtils. Just ignore it. > plus: i am installing this under a user dir and need to point python to > use this version rather than the old version which is installed under > the python lib dir somewhere. how do i do that? Use the executable of python which is in your user dir when invoking setup.py. Example: $ /home/ulf/bin/python setup.py build $ /home/ulf/bin/python setup.py install instead of $ python setup.py build $ python setup.py install Note that the build also has to be done with your locally installed version! Ciao, Michael. From vonceumern at rz.rwth-aachen.de Thu Sep 5 13:55:35 2002 From: vonceumern at rz.rwth-aachen.de (Ulf von Ceumern) Date: Thu, 05 Sep 2002 13:55:35 +0200 Subject: unable to build ldap.py References: <3D773972.BF0C5FD@rz.rwth-aachen.de> <3D774068.6060008@stroeder.com> Message-ID: <3D774637.9CBCCC5A@rz.rwth-aachen.de> Michael Str?der wrote: > > plus: i am installing this under a user dir and need to point python to > > use this version rather than the old version which is installed under > > the python lib dir somewhere. how do i do that? > > Use the executable of python which is in your user dir when invoking > setup.py. > > Example: > > $ /home/ulf/bin/python setup.py build > $ /home/ulf/bin/python setup.py install > > instead of > > $ python setup.py build > $ python setup.py install > > Note that the build also has to be done with your locally installed version! Hi Michael. Thanks for your help on the warning. But you got me wrong on the second problem: I want a python script to use the python-ldap version in my home dir rather than the one installed in the usual dir. I set export PYTHONPATH=/home/ceumern/ldap/python-ldap-2.0.0pre05/build/lib.solaris-2.8-sun4u-2.1/ and this is what i get: bash-2.03$ python -d /home/ceumern/ldap/ldap_test.py Traceback (most recent call last): File "/home/ceumern/ldap/ldap_test.py", line 6, in ? import ldap File "/home/ceumern/ldap/python-ldap-2.0.0pre05/build/lib.solaris-2.8-sun4u-2.1/ldap/__init__.py", line 11, in ? from _ldap import * ImportError: ld.so.1: python: fatal: libldap.so.2: open failed: No such file or directory when i unset the variable the skript uses the version installed under python2.1/site-packages/ldap and it works. there seems to be something wrong with my built version, but i cannot figure out what. regards, Ulf -------------- next part -------------- A non-text attachment was scrubbed... Name: vonceumern.vcf Type: text/x-vcard Size: 244 bytes Desc: Card for Ulf von Ceumern URL: From michael at stroeder.com Fri Sep 6 08:51:58 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 06 Sep 2002 08:51:58 +0200 Subject: unable to build ldap.py References: <3D773972.BF0C5FD@rz.rwth-aachen.de> <3D774068.6060008@stroeder.com> <3D774637.9CBCCC5A@rz.rwth-aachen.de> Message-ID: <3D78508E.8030007@stroeder.com> Ulf von Ceumern wrote: > from _ldap import * > ImportError: ld.so.1: python: fatal: libldap.so.2: open failed: No such file or > directory Hmm, on Linux I would start playing with editing /etc/ld.so.conf or setting LD_LIBRARY_PATH. No clue about Solaris though. Ciao, Michael. From michael at stroeder.com Fri Sep 6 20:27:04 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 06 Sep 2002 20:27:04 +0200 Subject: Very strange problem with module ldapurl Message-ID: <3D78F378.6020702@stroeder.com> HI! I have a very strange problem with ldapurl (my own source, sigh!) which can also be a security problem in case of passwords stored in LDAPUrlExtension instances. It drives me crazy! See this simple source: ------------------------ snip ------------------------ from ldapurl import LDAPUrl,LDAPUrlExtension l1=LDAPUrl() l1.hostport='host1' l1.who='cn=User1' l1.cred='passwd1' l1.extensions['dummyext1']=LDAPUrlExtension( extype='dummyext1',exvalue='dummyvalue1' ) print 'l1 before creation of l2:\n',str(l1) l2=LDAPUrl() l2.hostport='host2' l2.who='cn=User2' l2.cred='passwd2' l2.extensions['dummyext2']=LDAPUrlExtension( extype='dummyext2',exvalue='dummyvalue2' ) print 'l1 after creation of l2:\n',str(l1) print 'l2 itself:\n',str(l2) ------------------------ snip ------------------------ In theory l1 and l2 should be completely independent LDAPUrl instances. But it seems the LDAPUrl.extensions class attributes are tied by some means. The problem is the output (with Python 2.2.1): $ python Tests/ldapurl_instance_error.py ldap://host1/????dummyext2=dummyvalue2,dummyext1=dummyvalue1,bindname=cn=User2,X-BINDPW=passwd2 ldap://host2/????dummyext2=dummyvalue2,dummyext1=dummyvalue1,bindname=cn=User2,X-BINDPW=passwd2 Anybody here having a clue? Ciao, Michael. From jens at zope.com Fri Sep 6 21:51:07 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 6 Sep 2002 15:51:07 -0400 Subject: Very strange problem with module ldapurl In-Reply-To: <3D78F378.6020702@stroeder.com> Message-ID: i was stepping through the creation of l2 in the debugger, and to aid this i made the following change:: Index: ldapurl.py =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Lib/ldapurl.py,v retrieving revision 1.26 diff -r1.26 ldapurl.py 229c229 < extensions=LDAPUrlExtensions({}), --- > extensions=None, 238c238 < self.extensions=extensions --- > self.extensions=extensions or LDAPUrlExtensions({}) i basically moved the creation of that LDAPUrlExtensions object from the argument list into the function itself. that solved the problem for me it seems. here is my output now:: l1 before creation of l2: ldap://host1/????X- BINDPW=passwd1,dummyext1=dummyvalue1,bindname=cn=User1 l1 after creation of l2: ldap://host1/????X- BINDPW=passwd1,dummyext1=dummyvalue1,bindname=cn=User1 l2 itself: ldap://host2/????X- BINDPW=passwd2,dummyext2=dummyvalue2,bindname=cn=User2 hmmm.... :) jens On Friday, Sep 6, 2002, at 14:27 US/Eastern, Michael Str?der wrote: > HI! > > I have a very strange problem with ldapurl (my own source, sigh!) > which can also be a security problem in case of passwords stored in > LDAPUrlExtension instances. It drives me crazy! > > See this simple source: > > ------------------------ snip ------------------------ > from ldapurl import LDAPUrl,LDAPUrlExtension > > l1=LDAPUrl() > l1.hostport='host1' > l1.who='cn=User1' > l1.cred='passwd1' > l1.extensions['dummyext1']=LDAPUrlExtension( > extype='dummyext1',exvalue='dummyvalue1' > ) > > print 'l1 before creation of l2:\n',str(l1) > > l2=LDAPUrl() > l2.hostport='host2' > l2.who='cn=User2' > l2.cred='passwd2' > l2.extensions['dummyext2']=LDAPUrlExtension( > extype='dummyext2',exvalue='dummyvalue2' > ) > > print 'l1 after creation of l2:\n',str(l1) > print 'l2 itself:\n',str(l2) > ------------------------ snip ------------------------ > > In theory l1 and l2 should be completely independent LDAPUrl > instances. But it seems the LDAPUrl.extensions class attributes are > tied by some means. > > The problem is the output (with Python 2.2.1): > > $ python Tests/ldapurl_instance_error.py > ldap://host1/ > ????dummyext2=dummyvalue2,dummyext1=dummyvalue1,bindname=cn=User2,X- > BINDPW=passwd2 > ldap://host2/ > ????dummyext2=dummyvalue2,dummyext1=dummyvalue1,bindname=cn=User2,X- > BINDPW=passwd2 > > Anybody here having a clue? > > Ciao, Michael. > > > > From jens at zope.com Fri Sep 6 21:54:11 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 6 Sep 2002 15:54:11 -0400 Subject: Very strange problem with module ldapurl In-Reply-To: <3D78F378.6020702@stroeder.com> Message-ID: <69770CD2-C1D2-11D6-BAF7-0003939EFEBC@zope.com> i just got confirmation from someone here at zope corp who knows these things better that... - in general, it is better to avoid mutable default values in an argument list for a method - the fact that the LDAPUrlExtensions-constructor was part of the arguemnt list would actually give you the very same object every single time. jens On Friday, Sep 6, 2002, at 14:27 US/Eastern, Michael Str?der wrote: > HI! > > I have a very strange problem with ldapurl (my own source, sigh!) > which can also be a security problem in case of passwords stored in > LDAPUrlExtension instances. It drives me crazy! > > See this simple source: > > ------------------------ snip ------------------------ > from ldapurl import LDAPUrl,LDAPUrlExtension > > l1=LDAPUrl() > l1.hostport='host1' > l1.who='cn=User1' > l1.cred='passwd1' > l1.extensions['dummyext1']=LDAPUrlExtension( > extype='dummyext1',exvalue='dummyvalue1' > ) > > print 'l1 before creation of l2:\n',str(l1) > > l2=LDAPUrl() > l2.hostport='host2' > l2.who='cn=User2' > l2.cred='passwd2' > l2.extensions['dummyext2']=LDAPUrlExtension( > extype='dummyext2',exvalue='dummyvalue2' > ) > > print 'l1 after creation of l2:\n',str(l1) > print 'l2 itself:\n',str(l2) > ------------------------ snip ------------------------ > > In theory l1 and l2 should be completely independent LDAPUrl > instances. But it seems the LDAPUrl.extensions class attributes are > tied by some means. > > The problem is the output (with Python 2.2.1): > > $ python Tests/ldapurl_instance_error.py > ldap://host1/ > ????dummyext2=dummyvalue2,dummyext1=dummyvalue1,bindname=cn=User2,X- > BINDPW=passwd2 > ldap://host2/ > ????dummyext2=dummyvalue2,dummyext1=dummyvalue1,bindname=cn=User2,X- > BINDPW=passwd2 > > Anybody here having a clue? > > Ciao, Michael. From michael at stroeder.com Sat Sep 7 15:07:51 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 07 Sep 2002 15:07:51 +0200 Subject: Very strange problem with module ldapurl References: Message-ID: <3D79FA27.3060909@stroeder.com> David Leonard wrote: > > | 6.25. Why are default values sometimes shared between objects? > > I replaced all such fishy key-word arguments with mutable types and such. Please bring your working tree in sync and test. Ciao, Michael. From michael at stroeder.com Tue Sep 10 15:50:38 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 10 Sep 2002 15:50:38 +0200 Subject: 'valid' attribute in python-ldap 2.0.0pre05 References: <20020910065957.GA13563@pixar.com> Message-ID: <3D7DF8AE.1070905@stroeder.com> Lars, Cc:-ed python-ldap-dev at lists.sourceforge.net to receive comments by others. Lars Damerow wrote: > > I just built python-ldap 2.0.0pre05, and I can > no longer access the 'valid' attribute of LDAPObjects: Well, it is not supported at the moment. It would be fairly easy to reimplement it in the Python wrapper class (see Lib/ldap/ldapobject.c) if really needed for backward compability. Normally it's done within David's C code. Most times I'm not bothering with it. Frankly I would not rely on this flag at all. I'd suggest statements like: try: ..some LDAP operation.. except ldap.SERVER_DOWN: ..try to reconnect.. In current CVS version the new wrapper class ldap.ldapobject.ReconnectLDAPObject provides a convenient framework for this. Check it out. Ciao, Michael. From jlittle at open-it.org Tue Sep 10 21:00:25 2002 From: jlittle at open-it.org (Joe Little) Date: Tue, 10 Sep 2002 12:00:25 -0700 (PDT) Subject: updated 2.0.0pre05 RPM/SRPM Message-ID: Thanks to Kelly Roestel, a new set of RPMs for python-ldap have been created that use setup.py instead of the makefile, and use pythonapp in the spec file to indicate which python version to build against. I have posted python-ldap-2.0.0pre05-2.i386.rpm and its src rpm on ftp.open-it.org for RedHat 7.3 and python 2.2. You can use the spec file to match anything else. Michael: Can you adjust the rpm link again to point to the web page for downloads (its more informative and doesn't lose info from column truncation in ftp listings): http://kodama.open-it.org/openit/modules.php?op=modload&name=Downloads&file=index&req=viewdownload&cid=2 From jlittle at open-it.org Tue Sep 10 21:16:18 2002 From: jlittle at open-it.org (Joe Little) Date: Tue, 10 Sep 2002 12:16:18 -0700 Subject: updated 2.0.0pre05 RPM/SRPM In-Reply-To: Message-ID: And before anyone asks.. Its the same 2.0.0pre05 without patches. This was simply an RPM update that was submitted to me. Most people will want to be using the latest CVS version as per Michael's instructions.. On Tuesday, September 10, 2002, at 12:00 PM, Joe Little wrote: > > Thanks to Kelly Roestel, a new set of RPMs for python-ldap have been > created that use setup.py instead of the makefile, and use pythonapp in > the spec file to indicate which python version to build against. > > I have posted python-ldap-2.0.0pre05-2.i386.rpm and its src rpm on > ftp.open-it.org for RedHat 7.3 and python 2.2. You can use the spec > file > to match anything else. > > Michael: > > Can you adjust the rpm link again to point to the web page for > downloads > (its more informative and doesn't lose info from column truncation in > ftp listings): > > http://kodama.open-it.org/openit/ > modules.php?op=modload&name=Downloads&file=index&req=viewdownload&cid=2 > > > > > > From michael at stroeder.com Tue Sep 24 17:55:49 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 24 Sep 2002 17:55:49 +0200 Subject: ANN: python-ldap-2.0.0pre06 Message-ID: <3D908B05.4060708@stroeder.com> HI! Find a new pre-release of python-ldap: http://python-ldap.sourceforge.net/ python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). Download link: http://prdownloads.sourceforge.net/python-ldap/python-ldap-2.0.0pre06.tar.gz?download Changes since 2.0.0pre05: - Fine-grained locking when linking against libldap_r - New wrapper class ldap.ReconnectLDAPObject - Security fix to module ldapurl - Other fixes and improvements to whole package - LDAPv3 schema support (still somewhat premature and undocumented) Ciao, Michael. From peter at hawkins.emu.id.au Wed Sep 25 07:38:45 2002 From: peter at hawkins.emu.id.au (Peter Hawkins) Date: Wed, 25 Sep 2002 15:38:45 +1000 Subject: ANN: python-ldap-2.0.0pre06 In-Reply-To: <3D908B05.4060708@stroeder.com> References: <3D908B05.4060708@stroeder.com> Message-ID: <200209251538.49358.peter@hawkins.emu.id.au> Hi... On Wed, 25 Sep 2002 01:55 am, Michael Str?der wrote: > HI! > > Find a new pre-release of python-ldap: > ... > - Security fix to module ldapurl Can you explain this more clearly? How severe is it? Which versions does it affect? Do I need to issue an advisory against my package? > ... Also, pre06 doesn't appear to build against ldap_r (functions like ldap_first_reference don't exist in ldap_r). =) Peter -- peter at hawkins.emu.id.au GPG key fingerprint: C746 38A9 D3E4 A171 FB6A 56D4 5E30 DFCC BE11 F437 From michael at stroeder.com Wed Sep 25 10:12:32 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 25 Sep 2002 10:12:32 +0200 Subject: Security fix module ldapurl (was: ANN: python-ldap-2.0.0pre06) References: <3D908B05.4060708@stroeder.com> <200209251538.49358.peter@hawkins.emu.id.au> Message-ID: <3D916FF0.6080301@stroeder.com> Peter Hawkins wrote: >>- Security fix to module ldapurl > > Can you explain this more clearly? How severe is it? If an application used the LDAP URL extensions bindname and X-BINDPW in prior versions the key-word arg 'extensions' for LDAPUrl._init__() was not newly initialized each time. This could in some cases reveal login information elsewhere through LDAP URLs generated with this module. See also: http://www.geocrawler.com/lists/3/SourceForge/1568/0/9527098/ The follow-ups: http://www.geocrawler.com/lists/3/SourceForge/1568/0/9527860/ http://www.geocrawler.com/lists/3/SourceForge/1568/0/9527887/ http://www.geocrawler.com/lists/3/SourceForge/1568/0/9533130/ > Which versions does it affect? 2.0.0pre05 and prior versions which contain module ldapurl. > Do I need to issue an advisory against my package? Depends on your policy. Ciao, Michael. From Richard.Ferry at judiciary.state.nj.us Thu Sep 26 14:14:15 2002 From: Richard.Ferry at judiciary.state.nj.us (Richard.Ferry at judiciary.state.nj.us) Date: Thu, 26 Sep 2002 08:14:15 -0400 Subject: Search w/ win2000 Message-ID: I have version ldap-1.10a3 installed. I am running on a python 2.2 on a win2000 system. I have been unable to make the search work. Below are some of my unsuccessful tries. Can I use the "_s" option on the version that I am running and if not, can anyone tell me what format I would use for a basic search that returns the attributes I am looking for ? I assume that once I get this, the modify of the object would have the same format. Is this the version that would be used for win2000 ? Thanks, Richard Ferry ------------------------------------------- import ldap l = ldap.open("myserver.myorg:4444") l.simple_bind_s('uid=xxxxx,ou=myou,o=myorg','xxxxx') res = l.search_s('o=myorg', ldap.SCOPE_BASE, 'uid=xxxxx,ou=myou,o=myorg', ["ou", "l"]) When using the synchronous call I get this error: Traceback (most recent call last): File "C:\Python22\test_ld1.py", line 3, in ? l.simple_bind_s('uid=xxxxx,ou=myou,o=myorg','xxxxx') LOCAL_ERROR: {'desc': 'Local error'} ------------------------------------- import ldap l = ldap.open("myserver.myorg:4444") l.simple_bind('uid=xxxxx,ou=myou,o=myorg','xxxxx') res = l.search('o=myorg', ldap.SCOPE_BASE, 'uid=xxxxx,ou=myou,o=myorg', ["ou", "l"]) for entry in res: attrs=entry[1] ou=attrs["ou"] loc=attrs["l"] print loc print ou l.unbind() This code gives me this error msg: TypeError: iteration over non-sequence -------------------------------------------- import ldap l = ldap.open("myserver.myorg:4444") l.simple_bind('uid=xxxxx,ou=myou,o=myorg','xxxxx') res = l.search('o=myorg', ldap.SCOPE_BASE, 'uid=xxxxx,ou=myou,o=myorg', ["ou", "l"]) print res This code prints out res, which has a value of 2. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu Sep 26 14:39:41 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 26 Sep 2002 14:39:41 +0200 Subject: Search w/ win2000 References: Message-ID: <3D93000D.2030704@stroeder.com> Richard.Ferry at judiciary.state.nj.us wrote: > > I have version ldap-1.10a3 installed. I am running on a python 2.2 on > a win2000 system. Which LDAP server? Active Directory? Note that python-ldap 1.x cannot open an LDAPv3 connection. It's limited to LDAPv2 which is not allowed with Active Directory I suspect. There are other caveats of 1.x and LDAPv2. Unfortunately there's currently no Win32 build available of python-ldap 2.x which is based on OpenLDAP 2.x libs. > I have been unable to make the search work. Below are some of my > unsuccessful tries. Can I use the "_s" option on the version The synchronous method search_s() is what you probably like to use. It returns the search result als list of 2-tuples containing the distinguished name (string) and the entry (dictionary). > Traceback (most recent call last): > File "C:\Python22\test_ld1.py", line 3, in ? > l.simple_bind_s('uid=xxxxx,ou=myou,o=myorg','xxxxx') > LOCAL_ERROR: {'desc': 'Local error'} More information about your setup is needed. Which server? Is simple authentication enabled at the server at all? > l.simple_bind('uid=xxxxx,ou=myou,o=myorg','xxxxx') You should use the synchronous version for binding in any case. l.simple_bind_s('uid=xxxxx,ou=myou,o=myorg','xxxxx') > res = l.search('o=myorg', ldap.SCOPE_BASE, > 'uid=xxxxx,ou=myou,o=myorg', > ["ou", "l"]) > > for entry in res: > [..] > This code gives me this error msg: TypeError: iteration over > non-sequence search() in opposite to search_s() returns an integer representing the message ID of the started LDAP operation which is then used when calling result(). That's probably not what you want. Ciao, Michael. From michael at stroeder.com Wed Sep 25 10:12:32 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 25 Sep 2002 10:12:32 +0200 Subject: Security fix module ldapurl (was: ANN: python-ldap-2.0.0pre06) References: <3D908B05.4060708@stroeder.com> <200209251538.49358.peter@hawkins.emu.id.au> Message-ID: <3D916FF0.6080301@stroeder.com> Peter Hawkins wrote: >>- Security fix to module ldapurl > > Can you explain this more clearly? How severe is it? If an application used the LDAP URL extensions bindname and X-BINDPW in prior versions the key-word arg 'extensions' for LDAPUrl._init__() was not newly initialized each time. This could in some cases reveal login information elsewhere through LDAP URLs generated with this module. See also: http://www.geocrawler.com/lists/3/SourceForge/1568/0/9527098/ The follow-ups: http://www.geocrawler.com/lists/3/SourceForge/1568/0/9527860/ http://www.geocrawler.com/lists/3/SourceForge/1568/0/9527887/ http://www.geocrawler.com/lists/3/SourceForge/1568/0/9533130/ > Which versions does it affect? 2.0.0pre05 and prior versions which contain module ldapurl. > Do I need to issue an advisory against my package? Depends on your policy. Ciao, Michael. From Richard.Ferry at judiciary.state.nj.us Thu Sep 26 14:52:47 2002 From: Richard.Ferry at judiciary.state.nj.us (Richard.Ferry at judiciary.state.nj.us) Date: Thu, 26 Sep 2002 08:52:47 -0400 Subject: Search w/ win2000 Message-ID: I have Iplanet 5.0, which is ldapv.3 compliant. Simple authentication is our bind method. I am running win2000 on my deskpoint and my ldap resides on unix. Michael Str?der 09/26/2002 08:39 AM Please respond to michael To: Richard.Ferry at judiciary.state.nj.us cc: Python Developer List Subject: Re: Search w/ win2000 Richard.Ferry at judiciary.state.nj.us wrote: > > I have version ldap-1.10a3 installed. I am running on a python 2.2 on > a win2000 system. Which LDAP server? Active Directory? Note that python-ldap 1.x cannot open an LDAPv3 connection. It's limited to LDAPv2 which is not allowed with Active Directory I suspect. There are other caveats of 1.x and LDAPv2. Unfortunately there's currently no Win32 build available of python-ldap 2.x which is based on OpenLDAP 2.x libs. > I have been unable to make the search work. Below are some of my > unsuccessful tries. Can I use the "_s" option on the version The synchronous method search_s() is what you probably like to use. It returns the search result als list of 2-tuples containing the distinguished name (string) and the entry (dictionary). > Traceback (most recent call last): > File "C:\Python22\test_ld1.py", line 3, in ? > l.simple_bind_s('uid=xxxxx,ou=myou,o=myorg','xxxxx') > LOCAL_ERROR: {'desc': 'Local error'} More information about your setup is needed. Which server? Is simple authentication enabled at the server at all? > l.simple_bind('uid=xxxxx,ou=myou,o=myorg','xxxxx') You should use the synchronous version for binding in any case. l.simple_bind_s('uid=xxxxx,ou=myou,o=myorg','xxxxx') > res = l.search('o=myorg', ldap.SCOPE_BASE, > 'uid=xxxxx,ou=myou,o=myorg', > ["ou", "l"]) > > for entry in res: > [..] > This code gives me this error msg: TypeError: iteration over > non-sequence search() in opposite to search_s() returns an integer representing the message ID of the started LDAP operation which is then used when calling result(). That's probably not what you want. Ciao, Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu Sep 26 15:06:00 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 26 Sep 2002 15:06:00 +0200 Subject: Search w/ win2000 References: Message-ID: <3D930638.8050603@stroeder.com> Richard.Ferry at judiciary.state.nj.us wrote: > > I have Iplanet 5.0, which is ldapv.3 compliant. Simple authentication is > our bind method. This should normally work even if you're stuck with LDAPv2. > I am running win2000 on my deskpoint and my ldap resides on unix. Maybe there are even incompabilities of the old Umich DLLs used by Win32 version of python-ldap 1.x with W2K? How about also testing with python-ldap 2.x on your Unix box? Well, success might also depend on your Unix flavor. Another option would be using python-ldap 2.x based on OpenLDAP 2.x under cygwin (see http://www.geocrawler.com/archives/3/1568/2002/1/0/7452037/). The best option would be to ask whether somebody here (not me!) can provide a Win32 build of recent python-ldap. Ciao, Michael. From steffen.ries at sympatico.ca Fri Sep 27 02:30:47 2002 From: steffen.ries at sympatico.ca (Steffen Ries) Date: Thu, 26 Sep 2002 20:30:47 -0400 Subject: Search w/ win2000 In-Reply-To: Michael =?iso-8859-1?q?Str=F6der's?= message of "Thu, 26 Sep 2002 15:06:00 +0200" References: <3D930638.8050603@stroeder.com> Message-ID: <20020927003047.RLOC1398.tomts25-srv.bellnexxia.net@gondolin.beleriand> Michael Str?der writes: > Richard.Ferry at judiciary.state.nj.us wrote: > > I have Iplanet 5.0, which is ldapv.3 compliant. Simple > > authentication is our bind method. > > This should normally work even if you're stuck with LDAPv2. > > > I am running win2000 on my deskpoint and my ldap resides on unix. > > Maybe there are even incompabilities of the old Umich DLLs used by > Win32 version of python-ldap 1.x with W2K? I am using python-ldap 1.x with W2K and I can connect to iPlanet directories (and other LDAPv3 servers) without problems. > The best option would be to ask whether somebody here (not me!) can > provide a Win32 build of recent python-ldap. It would indeed be nice to have a recent python-ldap build for windows... :-) /steffen -- steffen.ries at sympatico.ca <> Gravity is a myth -- the Earth sucks! From michael at stroeder.com Fri Sep 27 14:05:52 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 27 Sep 2002 14:05:52 +0200 Subject: Wrapper above ADSI (was: Search w/ win2000) References: <3D930638.8050603@stroeder.com> <20020927003047.RLOC1398.tomts25-srv.bellnexxia.net@gondolin.beleriand> Message-ID: <3D9449A0.2030908@stroeder.com> Steffen Ries wrote: >>The best option would be to ask whether somebody here (not me!) can >>provide a Win32 build of recent python-ldap. > > It would indeed be nice to have a recent python-ldap build for > windows... :-) Hmm, just a wild idea: How about using Python Win32 to access ADSI via COM and set a python-ldap API-compatible wrapper module above? Ciao, Michael.