From Jun.Ding at microfocus.com Fri Oct 18 23:33:34 2002 From: Jun.Ding at microfocus.com (Jun Ding) Date: Fri, 18 Oct 2002 14:33:34 -0700 Subject: example of python-ldap module Message-ID: <75C025AE395F374B81F6416B1D4BDEFBB577B2@MTV-CORPMAIL> Could some body give me a short python exmple of how to use this module? I can't find any doc for how to use it, all docs I can find is C example. I installed a Windows 2k active direction ldap server on 10.20.30.100, and I can do that: >>> import ldap >>> l = ldap.open("10.20.30.100") >>> l.simple_bind("test","test") 1 >>> Then what? like how can I get the value of "test" user's Last name? or how can I set some values back to my ldap server? Thanks. From davidma at eskimo.com Fri Oct 18 23:45:23 2002 From: davidma at eskimo.com (David Margrave) Date: Fri, 18 Oct 2002 14:45:23 -0700 (PDT) Subject: example of python-ldap module In-Reply-To: <75C025AE395F374B81F6416B1D4BDEFBB577B2@MTV-CORPMAIL> Message-ID: something like: results = l.search_s('o=search_base',ldap.SCOPE_SUBTREE,'uid=user') the module actually has on-line docs as I recall. Lok at l.search_s.__doc__ for example. Dave On Fri, 18 Oct 2002, Jun Ding wrote: > Could some body give me a short python exmple of how to use this module? I > can't find any doc for how to use it, all docs I can find is C example. I > installed a Windows 2k active direction ldap server on 10.20.30.100, and I > can do that: > >>> import ldap > >>> l = ldap.open("10.20.30.100") > >>> l.simple_bind("test","test") > 1 > >>> > Then what? like how can I get the value of "test" user's Last name? or how > can I set some values back to my ldap server? Thanks. > > > From scholtes at fh-aachen.de Fri Oct 25 13:38:55 2002 From: scholtes at fh-aachen.de (J. Scholtes) Date: Fri, 25 Oct 2002 13:38:55 +0200 Subject: compile python-ldap on macosx Message-ID: <57EF3978-E80E-11D6-892B-003065E254D8@fh-aachen.de> Hi. I'm new to the list. In the list-archive I didn't find much about macosx, so here is my post. I'm trying to set up ZOPE with the LDAPuserFolder on a macosx-system and therefor I need python-ldap. But I#m not able to compile it on MacOsX 10.2 Is anyone on the List who did it successfull ? thanks Juergen Scholtes From michael at stroeder.com Fri Oct 25 13:51:38 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 25 Oct 2002 13:51:38 +0200 Subject: compile python-ldap on macosx References: <57EF3978-E80E-11D6-892B-003065E254D8@fh-aachen.de> Message-ID: <3DB9304A.20500@stroeder.com> J. Scholtes wrote: > > I'm trying to set up ZOPE with the LDAPuserFolder on a macosx-system and > therefor I need python-ldap. But I#m not able to compile it on MacOsX 10.2 > Is anyone on the List who did it successfull ? It's more likely that you get help if you provide more information about what you're trying to do and what went wrong. - OpenLDAP libs, version - python-ldap version - log of build with error messages Ciao, Michael. From scholtes at fh-aachen.de Fri Oct 25 14:21:03 2002 From: scholtes at fh-aachen.de (J. Scholtes) Date: Fri, 25 Oct 2002 14:21:03 +0200 Subject: compile python-ldap on macosx In-Reply-To: <3DB9304A.20500@stroeder.com> Message-ID: <3AC53414-E814-11D6-BCFD-000A27920D92@fh-aachen.de> Am Freitag, 25.10.02, um 13:51 Uhr (Europe/Budapest) schrieb Michael Str?der: > J. Scholtes wrote: >> I'm trying to set up ZOPE with the LDAPuserFolder on a macosx-system >> and therefor I need python-ldap. But I#m not able to compile it on >> MacOsX 10.2 >> Is anyone on the List who did it successfull ? > > It's more likely that you get help if you provide more information > about what you're trying to do and what went wrong. > > - OpenLDAP libs, version > - python-ldap version > - log of build with error messages > - I installed an OpenLDAP-Package distributed by Apple. I'ts based on openldap-2.0.18. - python-ldap version: python-ldap-2.0.0pre06 log of build: ################### [Tour1:~/python-ldap-2.0.0pre06] zope% python setup.py build running build running build_py warning: build_py: file Lib/ldap.py (for module ldap) not found warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) 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/cidict.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/__init__.py (output up-to-date) not copying Lib/ldap/schema/tokenizer.py (output up-to-date) not copying Lib/ldap/schema/models.py (output up-to-date) not copying Lib/ldap/schema/subentry.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 warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) not found running build_ext building '_ldap' extension skipping Modules/LDAPObject.c (build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o up-to-date) skipping Modules/common.c (build/temp.darwin-6.1-Power Macintosh-2.2/common.o up-to-date) skipping Modules/constants.c (build/temp.darwin-6.1-Power Macintosh-2.2/constants.o up-to-date) skipping Modules/errors.c (build/temp.darwin-6.1-Power Macintosh-2.2/errors.o up-to-date) skipping Modules/functions.c (build/temp.darwin-6.1-Power Macintosh-2.2/functions.o up-to-date) skipping Modules/schema.c (build/temp.darwin-6.1-Power Macintosh-2.2/schema.o up-to-date) skipping Modules/ldapmodule.c (build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o up-to-date) skipping Modules/linkedlist.c (build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o up-to-date) skipping Modules/message.c (build/temp.darwin-6.1-Power Macintosh-2.2/message.o up-to-date) skipping Modules/version.c (build/temp.darwin-6.1-Power Macintosh-2.2/version.o up-to-date) skipping Modules/options.c (build/temp.darwin-6.1-Power Macintosh-2.2/options.o up-to-date) gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o build/temp.darwin-6.1-Power Macintosh-2.2/common.o build/temp.darwin-6.1-Power Macintosh-2.2/constants.o build/temp.darwin-6.1-Power Macintosh-2.2/errors.o build/temp.darwin-6.1-Power Macintosh-2.2/functions.o build/temp.darwin-6.1-Power Macintosh-2.2/schema.o build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o build/temp.darwin-6.1-Power Macintosh-2.2/message.o build/temp.darwin-6.1-Power Macintosh-2.2/version.o build/temp.darwin-6.1-Power Macintosh-2.2/options.o -L/Library/OpenLDAP/lib -Wl,-R/Library/OpenLDAP/lib -lldap -llber -lresolv -o build/lib.darwin-6.1-Power Macintosh-2.2/_ldap.so ld: for architecture i386 ld: unknown flag: -R/Library/OpenLDAP/lib error: command 'gcc' failed with exit status 1 ##################################### I did a 'man ld' , but cannot find something about a flag or option -R ! Please be kind with me if I did something very stupid. I'm not a "kernel-hacker" but more like one of those script-kiddies ;) From jens at zope.com Fri Oct 25 14:31:20 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 25 Oct 2002 08:31:20 -0400 Subject: compile python-ldap on macosx In-Reply-To: <3AC53414-E814-11D6-BCFD-000A27920D92@fh-aachen.de> Message-ID: that error message always shows up for me as well (probably a typo somewhere in the build code), but it never made the build process fail for me. as far as OpenLDAP goes, i never use pre-packaged stuff. i use the source distribution and build it myself. never had a problem building python-ldap with that. jens > - I installed an OpenLDAP-Package distributed by Apple. I'ts based on > openldap-2.0.18. > - python-ldap version: python-ldap-2.0.0pre06 > > log of build: > ################### > [Tour1:~/python-ldap-2.0.0pre06] zope% python setup.py build > running build > running build_py > warning: build_py: file Lib/ldap.py (for module ldap) not found > warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) > 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/cidict.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/__init__.py (output up-to-date) > not copying Lib/ldap/schema/tokenizer.py (output up-to-date) > not copying Lib/ldap/schema/models.py (output up-to-date) > not copying Lib/ldap/schema/subentry.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 > warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) > not found > running build_ext > building '_ldap' extension > skipping Modules/LDAPObject.c (build/temp.darwin-6.1-Power > Macintosh-2.2/LDAPObject.o up-to-date) > skipping Modules/common.c (build/temp.darwin-6.1-Power > Macintosh-2.2/common.o up-to-date) > skipping Modules/constants.c (build/temp.darwin-6.1-Power > Macintosh-2.2/constants.o up-to-date) > skipping Modules/errors.c (build/temp.darwin-6.1-Power > Macintosh-2.2/errors.o up-to-date) > skipping Modules/functions.c (build/temp.darwin-6.1-Power > Macintosh-2.2/functions.o up-to-date) > skipping Modules/schema.c (build/temp.darwin-6.1-Power > Macintosh-2.2/schema.o up-to-date) > skipping Modules/ldapmodule.c (build/temp.darwin-6.1-Power > Macintosh-2.2/ldapmodule.o up-to-date) > skipping Modules/linkedlist.c (build/temp.darwin-6.1-Power > Macintosh-2.2/linkedlist.o up-to-date) > skipping Modules/message.c (build/temp.darwin-6.1-Power > Macintosh-2.2/message.o up-to-date) > skipping Modules/version.c (build/temp.darwin-6.1-Power > Macintosh-2.2/version.o up-to-date) > skipping Modules/options.c (build/temp.darwin-6.1-Power > Macintosh-2.2/options.o up-to-date) > gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress > build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o > build/temp.darwin-6.1-Power Macintosh-2.2/common.o > build/temp.darwin-6.1-Power Macintosh-2.2/constants.o > build/temp.darwin-6.1-Power Macintosh-2.2/errors.o > build/temp.darwin-6.1-Power Macintosh-2.2/functions.o > build/temp.darwin-6.1-Power Macintosh-2.2/schema.o > build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o > build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o > build/temp.darwin-6.1-Power Macintosh-2.2/message.o > build/temp.darwin-6.1-Power Macintosh-2.2/version.o > build/temp.darwin-6.1-Power Macintosh-2.2/options.o > -L/Library/OpenLDAP/lib -Wl,-R/Library/OpenLDAP/lib -lldap -llber > -lresolv -o build/lib.darwin-6.1-Power Macintosh-2.2/_ldap.so > ld: for architecture i386 > ld: unknown flag: -R/Library/OpenLDAP/lib > error: command 'gcc' failed with exit status 1 > ##################################### > > I did a 'man ld' , but cannot find something about a flag or option -R > ! > > Please be kind with me if I did something very stupid. I'm not a > "kernel-hacker" but more like one of those script-kiddies ;) > > From jens at zope.com Fri Oct 25 14:39:49 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 25 Oct 2002 08:39:49 -0400 Subject: compile python-ldap on macosx In-Reply-To: <3AC53414-E814-11D6-BCFD-000A27920D92@fh-aachen.de> Message-ID: now that i am looking at it, why does it say something about building for the i386 architecture in the build output? something about your build is horribly wrong. jens On Friday, Oct 25, 2002, at 08:21 US/Eastern, J. Scholtes wrote: > gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress > build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o > build/temp.darwin-6.1-Power Macintosh-2.2/common.o > build/temp.darwin-6.1-Power Macintosh-2.2/constants.o > build/temp.darwin-6.1-Power Macintosh-2.2/errors.o > build/temp.darwin-6.1-Power Macintosh-2.2/functions.o > build/temp.darwin-6.1-Power Macintosh-2.2/schema.o > build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o > build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o > build/temp.darwin-6.1-Power Macintosh-2.2/message.o > build/temp.darwin-6.1-Power Macintosh-2.2/version.o > build/temp.darwin-6.1-Power Macintosh-2.2/options.o > -L/Library/OpenLDAP/lib -Wl,-R/Library/OpenLDAP/lib -lldap -llber > -lresolv -o build/lib.darwin-6.1-Power Macintosh-2.2/_ldap.so > ld: for architecture i386 > ld: unknown flag: -R/Library/OpenLDAP/lib > error: command 'gcc' failed with exit status 1 From scholtes at fh-aachen.de Fri Oct 25 15:00:22 2002 From: scholtes at fh-aachen.de (J. Scholtes) Date: Fri, 25 Oct 2002 15:00:22 +0200 Subject: compile python-ldap on macosx In-Reply-To: Message-ID: Am Freitag, 25.10.02, um 14:39 Uhr (Europe/Budapest) schrieb Jens Vagelpohl: > now that i am looking at it, why does it say something about building > for the i386 architecture in the build output? something about your > build is horribly wrong. > > jens > > > On Friday, Oct 25, 2002, at 08:21 US/Eastern, J. Scholtes wrote: >> gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress >> build/temp.darwin-6.1-Power Macintosh-2.2/ mmh. but the second switch (-arch ppc) is correct Juergen From jens at zope.com Fri Oct 25 17:58:11 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 25 Oct 2002 11:58:11 -0400 Subject: compile python-ldap on macosx In-Reply-To: Message-ID: <8FD449D5-E832-11D6-B262-0003939EFEBC@zope.com> well, something about your setup is strange. just to compare, here is the output from my own machine:: ************************** gcc -flat_namespace -bundle -undefined suppress build/temp.darwin-6.1-Power Macintosh-2.1/LDAPObject.o build/temp.darwin-6.1-Power Macintosh-2.1/common.o build/temp.darwin-6.1-Power Macintosh-2.1/constants.o build/temp.darwin-6.1-Power Macintosh-2.1/errors.o build/temp.darwin-6.1-Power Macintosh-2.1/functions.o build/temp.darwin-6.1-Power Macintosh-2.1/schema.o build/temp.darwin-6.1-Power Macintosh-2.1/ldapmodule.o build/temp.darwin-6.1-Power Macintosh-2.1/linkedlist.o build/temp.darwin-6.1-Power Macintosh-2.1/message.o build/temp.darwin-6.1-Power Macintosh-2.1/version.o build/temp.darwin-6.1-Power Macintosh-2.1/options.o -L/usr/local/lib -R/usr/local/lib -lldap_r -llber -lssl -lcrypto -o build/lib.darwin-6.1-Power Macintosh-2.1/_ldap.so gcc: unrecognized option `-R/usr/local/lib' [dhcp192:local/src/python-ldap-HEAD] jens% *************************** as you can see, no "arch" arguments whatsoever. by the way, my python is "hand-made" as well. it's a self-compiled python 2.1.3. i don't know much about compilers, but it seems strange that there are more than a single arch argument, anyway. or is it possible to build for two completely disparate architectures in one compile run? sounds unlikely to me. jens On Friday, Oct 25, 2002, at 09:00 US/Eastern, J. Scholtes wrote: > > Am Freitag, 25.10.02, um 14:39 Uhr (Europe/Budapest) schrieb Jens > Vagelpohl: > >> now that i am looking at it, why does it say something about building >> for the i386 architecture in the build output? something about your >> build is horribly wrong. >> >> jens >> >> >> On Friday, Oct 25, 2002, at 08:21 US/Eastern, J. Scholtes wrote: >>> gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress >>> build/temp.darwin-6.1-Power Macintosh-2.2/ > > mmh. > but the second switch (-arch ppc) is correct > > Juergen > > From jlittle at open-it.org Fri Oct 25 20:00:00 2002 From: jlittle at open-it.org (Joe Little) Date: Fri, 25 Oct 2002 11:00:00 -0700 Subject: compile python-ldap on macosx In-Reply-To: <8FD449D5-E832-11D6-B262-0003939EFEBC@zope.com> Message-ID: <9472E65C-E843-11D6-9475-0003930B38C0@open-it.org> MacOSX has two supported architectures, as does Darwin. Apple only sells one and mothballed the other architecture. With Darwin, you still have both. When compiling, you are build Mach-O binaries that can be "FAT" -- both intel and ppc. Many defaults for Darwin build for both architectures. Though you may build from source, it is probably wiser for distribution to depend on the now included LDAP release with Darwin and MacOSX Jaguar (which ties into OpenDirectory). It will lower the entropy of support and likely not cause the "which libldap library am I linking to today" problems :) On Friday, October 25, 2002, at 08:58 AM, Jens Vagelpohl wrote: > well, something about your setup is strange. just to compare, here is > the output from my own machine:: > > ************************** > gcc -flat_namespace -bundle -undefined suppress > build/temp.darwin-6.1-Power Macintosh-2.1/LDAPObject.o > build/temp.darwin-6.1-Power Macintosh-2.1/common.o > build/temp.darwin-6.1-Power Macintosh-2.1/constants.o > build/temp.darwin-6.1-Power Macintosh-2.1/errors.o > build/temp.darwin-6.1-Power Macintosh-2.1/functions.o > build/temp.darwin-6.1-Power Macintosh-2.1/schema.o > build/temp.darwin-6.1-Power Macintosh-2.1/ldapmodule.o > build/temp.darwin-6.1-Power Macintosh-2.1/linkedlist.o > build/temp.darwin-6.1-Power Macintosh-2.1/message.o > build/temp.darwin-6.1-Power Macintosh-2.1/version.o > build/temp.darwin-6.1-Power Macintosh-2.1/options.o -L/usr/local/lib > -R/usr/local/lib -lldap_r -llber -lssl -lcrypto -o > build/lib.darwin-6.1-Power Macintosh-2.1/_ldap.so > gcc: unrecognized option `-R/usr/local/lib' > [dhcp192:local/src/python-ldap-HEAD] jens% > *************************** > > as you can see, no "arch" arguments whatsoever. by the way, my python > is "hand-made" as well. it's a self-compiled python 2.1.3. > > i don't know much about compilers, but it seems strange that there are > more than a single arch argument, anyway. or is it possible to build > for two completely disparate architectures in one compile run? sounds > unlikely to me. > > jens > > On Friday, Oct 25, 2002, at 09:00 US/Eastern, J. Scholtes wrote: > >> >> Am Freitag, 25.10.02, um 14:39 Uhr (Europe/Budapest) schrieb Jens >> Vagelpohl: >> >>> now that i am looking at it, why does it say something about >>> building for the i386 architecture in the build output? something >>> about your build is horribly wrong. >>> >>> jens >>> >>> >>> On Friday, Oct 25, 2002, at 08:21 US/Eastern, J. Scholtes wrote: >>>> gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined >>>> suppress build/temp.darwin-6.1-Power Macintosh-2.2/ >> >> mmh. >> but the second switch (-arch ppc) is correct >> >> Juergen >> >> > > > > From michael at stroeder.com Fri Oct 25 21:04:19 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 25 Oct 2002 21:04:19 +0200 Subject: compile python-ldap on macosx References: <9472E65C-E843-11D6-9475-0003930B38C0@open-it.org> Message-ID: <3DB995B3.9040002@stroeder.com> Joe Little wrote: > Though you may build from source, it is probably wiser > for distribution to depend on the now included LDAP release with Darwin > and MacOSX Jaguar (which ties into OpenDirectory). Is it possible to build python-ldap against this LDAP release? Any information about whether that's OpenLDAP 2 or not? I have to admit that I do not have any clue about the buzz-word 'OpenDirectory' and all the Mac OSX stuff. Ciao, Michael. From jlittle at open-it.org Fri Oct 25 22:03:38 2002 From: jlittle at open-it.org (Joe Little) Date: Fri, 25 Oct 2002 13:03:38 -0700 Subject: compile python-ldap on macosx In-Reply-To: <3DB995B3.9040002@stroeder.com> Message-ID: My understanding is that they include the OpenLDAP server 2.1.x on their server product. That being said I assume the client side build and libraries is based on the same version. Let me take a stab at it.. Ok. the framework lists it as an OpenLDAP 2.0.21 based library. However, the LDAP binary is built with liblber and libldap version 2.1.x Let's look at the /usr/lib directory for the libraries themselves. Strings results in the same 2.1.x (no indication of the specific version. MacOSX uses .dylib extensions without major/minor numbers) Pulling python-ldap from CVS and building it... I get the same error with the "python setup.py build" approach, but it appears to correctly generate the files. I get further errors when simply using "make" -- a lot about the inability to generate i386 libraries. However, it completes and a subsequent make shows that everything is up to date and nothing is left to build. Thus, the nature of the beast is that the included setup.cfg doesn't know that MacOSX can build for multiple architectures and its platform (python setup.py --platform) is "UNKNOWN". Is this normally the case for packages using setup.py/distutils? I hope this helps out the discussion a bit. On Friday, October 25, 2002, at 12:04 PM, Michael Str?der wrote: > Joe Little wrote: >> Though you may build from source, it is probably wiser for >> distribution to depend on the now included LDAP release with Darwin >> and MacOSX Jaguar (which ties into OpenDirectory). > > Is it possible to build python-ldap against this LDAP release? Any > information about whether that's OpenLDAP 2 or not? > > I have to admit that I do not have any clue about the buzz-word > 'OpenDirectory' and all the Mac OSX stuff. > > Ciao, Michael. > > > > From mengelhart at katahdinsoftware.com Sat Oct 26 09:22:23 2002 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Sat, 26 Oct 2002 03:22:23 -0400 Subject: compile python-ldap on macosx In-Reply-To: <57EF3978-E80E-11D6-892B-003065E254D8@fh-aachen.de> Message-ID: Hello Juergen, I just recently installed python-ldap on a stock Mac OS 10.2 powerbook using the stock python 2.2 distribution that is installed. first - in setup.py do change the first 2 lines to: library_dirs = /usr/lib include_dirs = /usr/include I believe you'll get that same gcc error message but after you run python setup.py build, do a: sudo python setup.py install and it should install the libraries fine. I am new to OpenLDAP so I'm having lots of trouble modifying entries and will be posting here soon but want to make sure my OpenLDAP configuration is setup correctly before I do that. BTW, for those who were asking, OpenLDAP v 2.1.0 is what is installed by default on Mac OS X v 10.2 There may have been some minor changes in the latest System update but it's at least 2.1.x Cheers Mike On Friday, October 25, 2002, at 07:38 AM, J. Scholtes wrote: > Hi. > I'm new to the list. In the list-archive I didn't find much about > macosx, so here is my post. > > I'm trying to set up ZOPE with the LDAPuserFolder on a macosx-system > and therefor I need python-ldap. But I#m not able to compile it on > MacOsX 10.2 > Is anyone on the List who did it successfull ? > > thanks > Juergen Scholtes > > > > > From jens at zope.com Sat Oct 26 16:48:45 2002 From: jens at zope.com (Jens Vagelpohl) Date: Sat, 26 Oct 2002 10:48:45 -0400 Subject: compile python-ldap on macosx In-Reply-To: Message-ID: <074F5EB6-E8F2-11D6-A629-0003939EFEBC@zope.com> looking at the configuration files under /etc/openldap i suppose this "built-in" ldap server is designed to serve NetInfo data through LDAP. not sure what that is supposed to be good for on a normal OS X install. i'd be weary to try and use that server to serve out other stuff as well. i'm not sure Software Update would recognize changes and not just replace the files the next time there is an updated ldap bundle. jens On Saturday, Oct 26, 2002, at 03:22 US/Eastern, Michael Engelhart wrote: > Hello Juergen, > > I just recently installed python-ldap on a stock Mac OS 10.2 powerbook > using the stock python 2.2 distribution that is installed. > > first - in setup.py do change the first 2 lines to: > > library_dirs = /usr/lib > include_dirs = /usr/include > > I believe you'll get that same gcc error message but after you run > python setup.py build, do a: > sudo python setup.py install > > and it should install the libraries fine. > > I am new to OpenLDAP so I'm having lots of trouble modifying entries > and will be posting here soon but want to make sure my OpenLDAP > configuration is setup correctly before I do that. > > BTW, for those who were asking, OpenLDAP v 2.1.0 is what is installed > by default on Mac OS X v 10.2 There may have been some minor changes > in the latest System update but it's at least 2.1.x > > Cheers > Mike > On Friday, October 25, 2002, at 07:38 AM, J. Scholtes wrote: > >> Hi. >> I'm new to the list. In the list-archive I didn't find much about >> macosx, so here is my post. >> >> I'm trying to set up ZOPE with the LDAPuserFolder on a macosx-system >> and therefor I need python-ldap. But I#m not able to compile it on >> MacOsX 10.2 >> Is anyone on the List who did it successfull ? >> >> thanks >> Juergen Scholtes >> >> >> >> >> From jens at zope.com Sat Oct 26 18:26:15 2002 From: jens at zope.com (Jens Vagelpohl) Date: Sat, 26 Oct 2002 12:26:15 -0400 Subject: compile python-ldap on macosx In-Reply-To: Message-ID: i personally had no idea that ldap comes standard. so i poked around and sure enough if you go to /etc/hostconfig and add a line that says... LDAPSERVER=-YES- then the built-in server starts up on system start. i then went in and changed /System/Library/StartupItems/LDAP/LDAP to point to my self-compiled slapd instead. works wonderfully. i probably should make use of the built-in one instead. i just have to change the configuration and *hope* that it can deal with my already existing database files and my schemata... but at any rate, at least for folks who just want to use python-ldap as a client without running a LDAP server the mere existence of the libraries and header files will simplify building the module a lot. jens On Saturday, Oct 26, 2002, at 12:12 US/Eastern, Michael Engelhart wrote: > Well NetInfo is one of "many" things OpenLDAP can serve up. I doubt > that Software Update would change the slapd.conf file since it > basically just points to the apple.schema file. I'm guessing it is > safe and to be sure I just keep a copy of the configuration file. > BUt that's just me. > > > On Saturday, October 26, 2002, at 10:48 AM, Jens Vagelpohl wrote: > >> looking at the configuration files under /etc/openldap i suppose this >> "built-in" ldap server is designed to serve NetInfo data through >> LDAP. not sure what that is supposed to be good for on a normal OS X >> > install. >> >> i'd be weary to try and use that server to serve out other stuff as >> well. i'm not sure Software Update would recognize changes and not >> just replace the files the next time there is an updated ldap bundle. >> >> jens > From jlittle at open-it.org Sat Oct 26 20:20:19 2002 From: jlittle at open-it.org (Joe Little) Date: Sat, 26 Oct 2002 11:20:19 -0700 Subject: compile python-ldap on macosx In-Reply-To: <074F5EB6-E8F2-11D6-A629-0003939EFEBC@zope.com> Message-ID: <9544BB2C-E90F-11D6-9BE0-000393696C5A@open-it.org> its an openldap to Netinfo bridge, done by Luke Howard (padl.com). In other words.. its as clean as you can get. Its compliant and works fine. I'm already using it as such in one case. Anybody can modify the schema to be what not and it won't break anything, since by default the system uses Netinfo and not LDAP and some steps are required to activate the LDAP bridge. Software update won't modify the slapd.conf to my knowledge. That is generated one time with a mkslapdconf command from the netinfo sources (during activation). Its similar to what a .deb or .rpm would do with the default slapd.conf -- not change it unless its not there. On Saturday, October 26, 2002, at 07:48 AM, Jens Vagelpohl wrote: > looking at the configuration files under /etc/openldap i suppose this > "built-in" ldap server is designed to serve NetInfo data through LDAP. > not sure what that is supposed to be good for on a normal OS X > install. > > i'd be weary to try and use that server to serve out other stuff as > well. i'm not sure Software Update would recognize changes and not > just replace the files the next time there is an updated ldap bundle. > > jens > > > On Saturday, Oct 26, 2002, at 03:22 US/Eastern, Michael Engelhart > wrote: > >> Hello Juergen, >> >> I just recently installed python-ldap on a stock Mac OS 10.2 >> powerbook using the stock python 2.2 distribution that is installed. >> >> first - in setup.py do change the first 2 lines to: >> >> library_dirs = /usr/lib >> include_dirs = /usr/include >> >> I believe you'll get that same gcc error message but after you run >> python setup.py build, do a: >> sudo python setup.py install >> >> and it should install the libraries fine. >> >> I am new to OpenLDAP so I'm having lots of trouble modifying entries >> and will be posting here soon but want to make sure my OpenLDAP >> configuration is setup correctly before I do that. >> >> BTW, for those who were asking, OpenLDAP v 2.1.0 is what is installed >> by default on Mac OS X v 10.2 There may have been some minor >> changes in the latest System update but it's at least 2.1.x >> >> Cheers >> Mike >> On Friday, October 25, 2002, at 07:38 AM, J. Scholtes wrote: >> >>> Hi. >>> I'm new to the list. In the list-archive I didn't find much about >>> macosx, so here is my post. >>> >>> I'm trying to set up ZOPE with the LDAPuserFolder on a macosx-system >>> and therefor I need python-ldap. But I#m not able to compile it on >>> MacOsX 10.2 >>> Is anyone on the List who did it successfull ? >>> >>> thanks >>> Juergen Scholtes >>> >>> >>> >>> >>> From kvthan at wm.edu Sun Oct 27 18:46:07 2002 From: kvthan at wm.edu (kapil thangavelu) Date: Sun, 27 Oct 2002 10:46:07 -0700 Subject: compile python-ldap on macosx In-Reply-To: <074F5EB6-E8F2-11D6-A629-0003939EFEBC@zope.com> References: <074F5EB6-E8F2-11D6-A629-0003939EFEBC@zope.com> Message-ID: <200210270946.07134.kvthan@wm.edu> for those interested i found this presentation os osx and directory services http://conferences.oreillynet.com/cs/macosx2002/view/e_sess/3298 cheers from a recently converted linux user, -k From michael at stroeder.com Sun Oct 27 13:32:05 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 27 Oct 2002 13:32:05 +0100 Subject: compile python-ldap on macosx References: <074F5EB6-E8F2-11D6-A629-0003939EFEBC@zope.com> <200210270946.07134.kvthan@wm.edu> Message-ID: <3DBBDCC5.3050502@stroeder.com> HI! Sourceforge recently added Mac OS X to their compile farm: http://sourceforge.net/forum/forum.php?forum_id=113664 Anyone interested in using that for testing python-ldap? We maybe could request the OpenDirectory standard package to be added to the compile farm system. Ciao, Michael From mengelhart at katahdinsoftware.com Sun Oct 27 13:53:12 2002 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Sun, 27 Oct 2002 07:53:12 -0500 Subject: compile python-ldap on macosx In-Reply-To: <3DBBDCC5.3050502@stroeder.com> Message-ID: <0D3D6578-E9AB-11D6-8F0B-000393A48A3C@katahdinsoftware.com> OpenLDAP is part of the default OS X install. I guess the developers would need access to the slapd.conf file to set the direcotry manager name/password. Mike On Sunday, October 27, 2002, at 07:32 AM, Michael Str?der wrote: > HI! > > Sourceforge recently added Mac OS X to their compile farm: > > http://sourceforge.net/forum/forum.php?forum_id=113664 > > Anyone interested in using that for testing python-ldap? We maybe > could request the OpenDirectory standard package to be added to the > compile farm system. > > Ciao, Michael From michael at stroeder.com Sun Oct 27 14:12:56 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 27 Oct 2002 14:12:56 +0100 Subject: compile python-ldap on macosx References: <0D3D6578-E9AB-11D6-8F0B-000393A48A3C@katahdinsoftware.com> Message-ID: <3DBBE658.7000203@stroeder.com> Michael Engelhart wrote: > On Sunday, October 27, 2002, at 07:32 AM, Michael Str?der wrote: > >> Sourceforge recently added Mac OS X to their compile farm: >> http://sourceforge.net/forum/forum.php?forum_id=113664 >> Anyone interested in using that for testing python-ldap? We maybe >> could request the OpenDirectory standard package to be added to the >> compile farm system. > > OpenLDAP is part of the default OS X install. I guess the developers > would need access to the slapd.conf file to set the direcotry manager > name/password. Maybe my comment was misleading. I was only thinking about using Mac OS X's LDAP client libs to compile binaries of python-ldap for Mac OS X. Ciao, Michael. From jens at zope.com Sun Oct 27 16:34:05 2002 From: jens at zope.com (Jens Vagelpohl) Date: Sun, 27 Oct 2002 10:34:05 -0500 Subject: compile python-ldap on macosx In-Reply-To: <3DBBE658.7000203@stroeder.com> Message-ID: <870851E9-E9C1-11D6-82C3-0003939EFEBC@zope.com> as far as compiling python-ldap goes, here is the outcome of a couple experiments i did yesterday. all were done with the current CVS HEAD: - against self-compiled OpenLDAP 2.1.4 and self-compiled python 2.1.3: no problem. - against built-in OpenLDAP and self-compiled python 2.1.3: no problem. i specified "/usr/lib" as library_dirs and "/usr/include" as include_dirs. libs was "ldap_r lber ssl crypto" (sasl did not compile - could not find sasl.h, even though OS X has the library itself). - against built-in OpenLDAP and the built-in python 2.2: fails with the error message that started this whole thread. the _ldap.so shared module is not created because linking fails. it seems that the culprit might be the built-in python2.2. the python build flags, i assume, govern the build flags used when compiling these extension modules. jens On Sunday, Oct 27, 2002, at 08:12 US/Eastern, Michael Str?der wrote: > Michael Engelhart wrote: >> On Sunday, October 27, 2002, at 07:32 AM, Michael Str?der wrote: >>> Sourceforge recently added Mac OS X to their compile farm: >>> http://sourceforge.net/forum/forum.php?forum_id=113664 >>> Anyone interested in using that for testing python-ldap? We maybe >>> could request the OpenDirectory standard package to be added to the >>> compile farm system. > > > > OpenLDAP is part of the default OS X install. I guess the developers > > would need access to the slapd.conf file to set the direcotry manager > > name/password. > > Maybe my comment was misleading. I was only thinking about using Mac > OS X's LDAP client libs to compile binaries of python-ldap for Mac OS > X. > > Ciao, Michael. > From jens at zope.com Sun Oct 27 16:39:28 2002 From: jens at zope.com (Jens Vagelpohl) Date: Sun, 27 Oct 2002 10:39:28 -0500 Subject: compile python-ldap on macosx In-Reply-To: <9544BB2C-E90F-11D6-9BE0-000393696C5A@open-it.org> Message-ID: <47A6B942-E9C2-11D6-82C3-0003939EFEBC@zope.com> clean or not, it does not work out of the box ;) the slapd.conf points to a database that does not exist, at least on my own system. i assume you have to make some explicit gesture to build that database file. even if this database existed and some unsuspecting person started using it i wonder what kind of security hole you open by not explicitly disabling the serving of netinfo data... on my own system i have now switched to using the built-in OpenLDAP by adjusting the slapd.conf (and commenting out the pieces pertaining to the netinfo bridge) and use it without problems through python-ldap compiled against my self-built python 2.1.3. jens On Saturday, Oct 26, 2002, at 14:20 US/Eastern, Joe Little wrote: > > its an openldap to Netinfo bridge, done by Luke Howard (padl.com). In > other words.. its as clean as you can get. Its compliant and works > fine. I'm already using it as such in one case. Anybody can modify the > schema to be what not and it won't break anything, since by default > the system uses Netinfo and not LDAP and some steps are required to > activate the LDAP bridge. > > Software update won't modify the slapd.conf to my knowledge. That is > generated one time with a mkslapdconf command from the netinfo sources > (during activation). Its similar to what a .deb or .rpm would do with > the default slapd.conf -- not change it unless its not there. > > On Saturday, October 26, 2002, at 07:48 AM, Jens Vagelpohl wrote: > >> looking at the configuration files under /etc/openldap i suppose this >> "built-in" ldap server is designed to serve NetInfo data through >> LDAP. not sure what that is supposed to be good for on a normal OS X >> > install. >> >> i'd be weary to try and use that server to serve out other stuff as >> well. i'm not sure Software Update would recognize changes and not >> just replace the files the next time there is an updated ldap bundle. >> >> jens >> >> >> On Saturday, Oct 26, 2002, at 03:22 US/Eastern, Michael Engelhart >> wrote: >> >>> Hello Juergen, >>> >>> I just recently installed python-ldap on a stock Mac OS 10.2 >>> powerbook using the stock python 2.2 distribution that is installed. >>> >>> first - in setup.py do change the first 2 lines to: >>> >>> library_dirs = /usr/lib >>> include_dirs = /usr/include >>> >>> I believe you'll get that same gcc error message but after you run >>> python setup.py build, do a: >>> sudo python setup.py install >>> >>> and it should install the libraries fine. >>> >>> I am new to OpenLDAP so I'm having lots of trouble modifying >>> entries and will be posting here soon but want to make sure my >>> OpenLDAP configuration is setup correctly before I do that. >>> >>> BTW, for those who were asking, OpenLDAP v 2.1.0 is what is >>> installed by default on Mac OS X v 10.2 There may have been some >>> minor changes in the latest System update but it's at least 2.1.x >>> >>> Cheers >>> Mike >>> On Friday, October 25, 2002, at 07:38 AM, J. Scholtes wrote: >>> >>>> Hi. >>>> I'm new to the list. In the list-archive I didn't find much about >>>> macosx, so here is my post. >>>> >>>> I'm trying to set up ZOPE with the LDAPuserFolder on a >>>> macosx-system and therefor I need python-ldap. But I#m not able to >>>> compile it on MacOsX 10.2 >>>> Is anyone on the List who did it successfull ? >>>> >>>> thanks >>>> Juergen Scholtes >>>> >>>> >>>> >>>> >>>> From mengelhart at katahdinsoftware.com Sun Oct 27 18:29:27 2002 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Sun, 27 Oct 2002 12:29:27 -0500 Subject: compile python-ldap on macosx In-Reply-To: <47A6B942-E9C2-11D6-82C3-0003939EFEBC@zope.com> Message-ID: > clean or not, it does not work out of the box ;) Huh?? We're talking about Mac OS X desktop here right? Why does having to adjust a configuration file before you run slapd considered not working out of the box? How would you have them pre-configure it??? It's not any different than having to configure an email client to read email from your POP account. In my mind I would say that it totally works out of the box. All I had to do was add the following to /etc/openldap/slapd.conf (making changes to work within your needs --- I also commented out the netinfo stuff because I'm not using NetInfo) database ldbm suffix "o=mydomain.com" rootdn "cn=Directory Manager,o= mydomain.com" rootpw somepw directory /var/db/openldap/openldap-data/ cachesize 1000000 dbcachesize 10000000 index uid,cn,sn,givenName pres,eq,sub sizelimit 5000 -- I wouldn't expect Apple to guess for me what I wanted here :-) Then you can either set LDAP to run at startup (which has been discussed here) or type /usr/libexec/slapd and you're up and running. You of course need to add the entries (either with the command line ldapadd or via some GUI admin tool) you want to search on to it to make it do what you want but I assume that's true of any LDAP server. BTW, the database you're talking about not existing with the default slapd.conf is because you probably don't have anything in your netinfo setup. Try launching slapd and then going into Netinfo and adding users and see if it gets created. Mike On Sunday, October 27, 2002, at 10:39 AM, Jens Vagelpohl wrote: > clean or not, it does not work out of the box ;) the slapd.conf > points to a database that does not exist, at least on my own system. i > assume you have to make some explicit gesture to build that database > file. > > even if this database existed and some unsuspecting person started > using it i wonder what kind of security hole you open by not > explicitly disabling the serving of netinfo data... > > on my own system i have now switched to using the built-in OpenLDAP by > adjusting the slapd.conf (and commenting out the pieces pertaining to > the netinfo bridge) and use it without problems through python-ldap > compiled against my self-built python 2.1.3. > > jens From mengelhart at katahdinsoftware.com Sun Oct 27 18:39:06 2002 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Sun, 27 Oct 2002 12:39:06 -0500 Subject: compile python-ldap on macosx In-Reply-To: <870851E9-E9C1-11D6-82C3-0003939EFEBC@zope.com> Message-ID: I've been using python-ldap scenario below for a few weeks now: > > - against built-in OpenLDAP and the built-in python 2.2: fails with > the error message that started this whole thread. the _ldap.so shared > module is not created because linking fails. Even though it fails with an error the library is already built by that point so if you do a python setup.py install, it installs python ldap libraries which do work (at least partially - see below). I've only tested connecting to a server and doing searches which all work fine and provide correct results. BUT, when I try to do a delete or modify, I get an error message that says: {'info': 'modifications require authentication', 'desc': 'Operations error'} I'm connected (at least it seems like I am) with the rootdn and rootpw that I have configured in slapd.conf. From my understanding binding with that user/password should allow me to modify any entry in the database. On the other hand maybe this is happening because the python-ldap library isn't built correctly. I'm very new to LDAP in general so I can't tell. maybe someone else on this list can help decipher that error response? BTW, is there any way to determine how an ldap object is actually bound to the server (e.g., getBoundUserName type of method?) The code I"m using to do this is based on my own simple LDAPWrapper class which is this: import ldap class LDAPWrapper: def __init__(self, user="", password=""): self.server = ldap.open("127.0.0.1") self.server.simple_bind(user, password) def search(self, base, filter, scope=ldap.SCOPE_SUBTREE, retrieveAttributes=None, limit=10): try: ldap_result_id = self.server.search(base, scope, filter, retrieveAttributes) result_set = [] for i in range(limit): result_type, result_data = self.server.result(ldap_result_id, 0) if (result_data == []): return result_set else: if result_type == ldap.RES_SEARCH_ENTRY: result_set.append(result_data) return result_set except ldap.SIZELIMIT_EXCEEDED, e: print e def delete(self, dn): try: result_type, result_data = self.server.delete_s(dn) if (result_type == 'RES_DELETE'): return 1 # true else: return 0 # false except Exception, e: print e print "An error occurred during LDAPSearch.delete()" return None def close(self): self.server.unbind() Any help would be appreciated and I will gladly test builds of python-ldap on my OS X box since I need this to work for development purposes. Cheers Mike On Sunday, October 27, 2002, at 10:34 AM, Jens Vagelpohl wrote: > as far as compiling python-ldap goes, here is the outcome of a couple > experiments i did yesterday. all were done with the current CVS HEAD: > > - against self-compiled OpenLDAP 2.1.4 and self-compiled python 2.1.3: > no problem. > > - against built-in OpenLDAP and self-compiled python 2.1.3: no > problem. i specified "/usr/lib" as library_dirs and "/usr/include" as > include_dirs. libs was "ldap_r lber ssl crypto" (sasl did not compile > - could not find sasl.h, even though OS X has the library itself). > > - against built-in OpenLDAP and the built-in python 2.2: fails with > the error message that started this whole thread. the _ldap.so shared > module is not created because linking fails. > > it seems that the culprit might be the built-in python2.2. the python > build flags, i assume, govern the build flags used when compiling > these extension modules. > > jens From michael at stroeder.com Sun Oct 27 18:55:20 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 27 Oct 2002 18:55:20 +0100 Subject: compile python-ldap on macosx References: Message-ID: <3DBC2888.4070703@stroeder.com> Michael Engelhart wrote: >> clean or not, it does not work out of the box ;) > > Huh?? We're talking about Mac OS X desktop here right? Why does having > to adjust a configuration file before you run slapd considered not > working out of the box? How would you have them pre-configure it??? > It's not any different than having to configure an email client to read > email from your POP account. In my mind I would say that it totally > works out of the box. All I had to do was add the following to > /etc/openldap/slapd.conf (making changes to work within your needs --- > I also commented out the netinfo stuff because I'm not using NetInfo) As I understand it this thread is shifting off-topic at this point. Please let's stick to discussing python-ldap build problems on Max OS X here. And please take discussion about Open Directory installation/configuration to another more appropriate forum. Thanks. Ciao, Michael. From mengelhart at katahdinsoftware.com Tue Oct 29 16:08:02 2002 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Tue, 29 Oct 2002 10:08:02 -0500 Subject: delete_s() result Message-ID: <382AE301-EB50-11D6-983B-000393A48A3C@katahdinsoftware.com> Hi all - Does a succesful ldap.delete_s() call return an empty list? It seems to be the case but the documentation doesn't specify what the return value should be. On a related note, if this is the correct return value from that call, then searching, modifying and deleting all work properly on a Mac OS X build of python-ldap even though there is an error message at the end of the setup.py build script. Cheers Mike From michael at stroeder.com Tue Oct 29 16:28:30 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 29 Oct 2002 16:28:30 +0100 Subject: delete_s() result References: <382AE301-EB50-11D6-983B-000393A48A3C@katahdinsoftware.com> Message-ID: <3DBEA91E.6070706@stroeder.com> Michael Engelhart wrote: > Does a succesful ldap.delete_s() call return an empty list? Hmm, according to the ancient __doc__ string it should return None. But maybe this changed because of the new implementation of delete_s() in the Python wrapper class ldap.ldapobject.SimpleLDAPObject. Best bet is to ignore the result of delete_s(). It won't contain any useful information. In opposite delete() returns the msgid as usual for async methods. Ciao, Michael. From michael at stroeder.com Tue Oct 29 18:07:29 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 29 Oct 2002 18:07:29 +0100 Subject: delete_s() result References: Message-ID: <3DBEC051.4060209@stroeder.com> Michael Engelhart wrote: > The result of the operation is succesful either way in > that it deletes the dn passed to it which is really all I care about > anyway. I'll just ignore results from delete. Thanks to the early design decision of David you don't have to do error handling by checking result codes. If an error occurs during deletion of an entry an exception of class ldap.LDAPError or a derived error class is raised. You can safely ignore results of add_s(), bind_s(), delete_s(), modify_s(), modrdn_s(), rename_s() and unbind_s(). Ciao, Michael. From mengelhart at katahdinsoftware.com Tue Oct 29 18:13:41 2002 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Tue, 29 Oct 2002 12:13:41 -0500 Subject: delete_s() result In-Reply-To: <3DBEC051.4060209@stroeder.com> Message-ID: Very cool. That's the way it should be! maybe that little tidbit should be in the documentation somewhere? although now it's archived in the mailing list... :-) Mike On Tuesday, October 29, 2002, at 12:07 PM, Michael Str?der wrote: > > Thanks to the early design decision of David you don't have to do > error handling by checking result codes. If an error occurs during > deletion of an entry an exception of class ldap.LDAPError or a derived > error class is raised. > > You can safely ignore results of add_s(), bind_s(), delete_s(), > modify_s(), modrdn_s(), rename_s() and unbind_s(). > > Ciao, Michael. From michael at stroeder.com Tue Oct 29 18:28:41 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 29 Oct 2002 18:28:41 +0100 Subject: delete_s() result References: Message-ID: <3DBEC549.106@stroeder.com> Michael Engelhart wrote: >> Thanks to the early design decision of David you don't have to do >> error handling by checking result codes. If an error occurs during >> deletion of an entry an exception of class ldap.LDAPError or a derived >> error class is raised. > > maybe that little tidbit should be in the documentation somewhere? http://python-ldap.sourceforge.net/doc/python-ldap/node9.html Ciao, Michael. From mengelhart at katahdinsoftware.com Tue Oct 29 18:42:45 2002 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Tue, 29 Oct 2002 12:42:45 -0500 Subject: delete_s() result In-Reply-To: <3DBEC549.106@stroeder.com> Message-ID: right - I guess was thinking more along the lines of directly in the documentation on the ldap operations page, having a paragraph that says "For the following methods, x(), y(), z(), ldap.LDAPError exceptions are raised instead of returning error codes - click here for more information on the Exceptions that can occur." In my case, I read through the exception page and didn't "get" that delete_s doesn't return error codes because there is documentation like this mixed into the LDAP operations page for say the result() method: The result() method returns a tuple of the form (result-type, result-data). The first element, result-type is a string, being one of: 'RES_BIND', 'RES_SEARCH_ENTRY', 'RES_SEARCH_RESULT', 'RES_MODIFY', 'RES_ADD', 'RES_DELETE', 'RES_MODRDN', or 'RES_COMPARE'. (The module constants RES_* are set to these strings, for your convenience.) This method does return codes and it seems to me that based on that if it's not explicitly stated that other methods would as well. Personally I would like to see the documentation have examples for each function written in python but I doubt anyone has time for that. I'll start collecting mine and maybe put them up somewhere. Mike On Tuesday, October 29, 2002, at 12:28 PM, Michael Str?der wrote: > Michael Engelhart wrote: >>> Thanks to the early design decision of David you don't have to do >>> error handling by checking result codes. If an error occurs during >>> deletion of an entry an exception of class ldap.LDAPError or a >>> derived error class is raised. >> maybe that little tidbit should be in the documentation somewhere? > > http://python-ldap.sourceforge.net/doc/python-ldap/node9.html > > Ciao, Michael. > > > > From michael at stroeder.com Tue Oct 29 18:59:49 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 29 Oct 2002 18:59:49 +0100 Subject: delete_s() result References: Message-ID: <3DBECC95.7080706@stroeder.com> Michael Engelhart wrote: > right - I guess was thinking more along the lines of directly in the > documentation Documentation... (sigh!) There are even sub-modules completely undocumented... Ciao, Michael. From mengelhart at katahdinsoftware.com Sun Nov 3 18:06:59 2002 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Sun, 3 Nov 2002 12:06:59 -0500 Subject: sample code online Message-ID: hey all - I just put a very simple set of python-ldap sample code that shows searching a directory, binding to a directory, and deleting entries: http://homepage.mac.com/mengelhart/python-ldap-samples.html I'm going to be adding a modify and also use of modlist when I get around to it. This page would have greatly helped me when I started with python-ldap so I figured someone else may find it useful. It's kind of a mixup of sync and async examples. Hopefully I'll get around to doing examples of each. If anyone finds any bugs - please let me know Cheers Mike From michael at stroeder.com Sun Nov 3 18:35:38 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 03 Nov 2002 18:35:38 +0100 Subject: sample code online References: Message-ID: <3DC55E6A.4010005@stroeder.com> Michael Engelhart wrote: > > I just put a very simple set of python-ldap sample code that shows > searching a directory, binding to a directory, and deleting entries: > http://homepage.mac.com/mengelhart/python-ldap-samples.html Thanks for contributing that. I've added a link to this page to http://python-ldap.sourceforge.net/docs.shtml . Some comments: As default an LDAPv2 connection is made by the OpenLDAP client libs. Therefore you have to explicitly set the attribute protocol_version to use LDAPv3. Personally I prefer to use: l.set_option(ldap.OPT_PROTOCOL_VERSION,ldap.VERSION3) This is especially true in the search example: -------------------- snip ------------------ ## first you must open a connection to the server try: l = ldap.open("127.0.0.1") ## searching doesn't require a bind except ldap.LDAPError, e: print e # handle error however you like -------------------- snip ------------------ Here you state that a BindRequest is not needed before the SearchRequest. This is only true for LDAPv3! Most times an LDAPv2 server will give you back ldap.PROTOCOL_ERROR (or behave odd ;-). It should read: -------------------- snip ------------------ ## first you must open a connection to the server try: l = ldap.open("127.0.0.1") l.protocol_version = ldap.VERSION3 ## with LDAPv3 searching doesn't require a bind except ldap.LDAPError, e: print e # handle error however you like -------------------- snip ------------------ Unfortunately if LDAPv3 is not supported you will get an error at the point where you send the first LDAPRequest (the SearchRequest in your example). Now one might wonder how to properly "negotiate" the LDAP protocol version. Well, check out how it's done ldap.ldapobject.SmartLDAPObject. This is not ready for prime time yet but should give you some inspiration. Please test! Your async search example is a good starting point to lead over to deploying class ldap.async.List. ;-) Well, everybody is encouraged to dig into Demo/ anyway. Ciao, Michael. From scholtes at fh-aachen.de Mon Nov 4 13:13:57 2002 From: scholtes at fh-aachen.de (J.Scholtes) Date: Mon, 4 Nov 2002 13:13:57 +0100 Subject: still probs to compile python-ldap on macosx Message-ID: Hi Folks. I still have problems to compile python-ldap on macosx. When I took a closer look to the output of the build-script I might have found one Problem. Here is the line of the gcc-call: ## gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o build/temp.darwin-6.1-Power Macintosh-2.2/common.o build/temp.darwin-6.1-Power Macintosh-2.2/constants.o build/temp.darwin-6.1-Power Macintosh-2.2/errors.o build/temp.darwin-6.1-Power Macintosh-2.2/functions.o build/temp.darwin-6.1-Power Macintosh-2.2/schema.o build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o build/temp.darwin-6.1-Power Macintosh-2.2/message.o build/temp.darwin-6.1-Power Macintosh-2.2/version.o build/temp.darwin-6.1-Power Macintosh-2.2/options.o -L/usr/local/openldap-REL_ENG_2_1/lib -Wl,-R/usr/local/openldap-REL_ENG_2_1/lib -lldap -llber -o build/lib.darwin-6.1-Power Macintosh-2.2/_ldap.so ## I think the Problem is the space in the path: build/temp.darwin-6.1-Power Macintosh-2.2/xxxx ^^^^ Where can I find the gcc-call to modify the path to something without a space ? best regards juergen From scholtes at fh-aachen.de Mon Nov 4 13:48:10 2002 From: scholtes at fh-aachen.de (J.Scholtes) Date: Mon, 4 Nov 2002 13:48:10 +0100 Subject: still probs to compile python-ldap on macosx In-Reply-To: Message-ID: Am Montag, 04.11.02, um 13:27 Uhr (Europe/Budapest) schrieb Jens Vagelpohl: > what is the actual error that you get... ? > > Here is the complete output: ##### running build running build_py warning: build_py: file Lib/ldap.py (for module ldap) not found warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) 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/cidict.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/__init__.py (output up-to-date) not copying Lib/ldap/schema/tokenizer.py (output up-to-date) not copying Lib/ldap/schema/models.py (output up-to-date) not copying Lib/ldap/schema/subentry.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 warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) not found running build_ext building '_ldap' extension creating build/temp.darwin-6.1-Power Macintosh-2.2 gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include -I/usr/include/python2.2 -c Modules/LDAPObject.c -o build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include -I/usr/include/python2.2 -c Modules/common.c -o build/temp.darwin-6.1-Power Macintosh-2.2/common.o cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include -I/usr/include/python2.2 -c Modules/constants.c -o build/temp.darwin-6.1-Power Macintosh-2.2/constants.o cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include -I/usr/include/python2.2 -c Modules/errors.c -o build/temp.darwin-6.1-Power Macintosh-2.2/errors.o cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include -I/usr/include/python2.2 -c Modules/functions.c -o build/temp.darwin-6.1-Power Macintosh-2.2/functions.o cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include -I/usr/include/python2.2 -c Modules/schema.c -o build/temp.darwin-6.1-Power Macintosh-2.2/schema.o cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include -I/usr/include/python2.2 -c Modules/ldapmodule.c -o build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include -I/usr/include/python2.2 -c Modules/linkedlist.c -o build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include -I/usr/include/python2.2 -c Modules/message.c -o build/temp.darwin-6.1-Power Macintosh-2.2/message.o cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include -I/usr/include/python2.2 -c Modules/version.c -o build/temp.darwin-6.1-Power Macintosh-2.2/version.o cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include -I/usr/include/python2.2 -c Modules/options.c -o build/temp.darwin-6.1-Power Macintosh-2.2/options.o cc1: warning: changing search order for system directory "/usr/include" cc1: warning: as it has already been specified as a non-system directory Modules/options.c: In function `LDAP_get_option': Modules/options.c:151: warning: unused variable `doubleval' gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o build/temp.darwin-6.1-Power Macintosh-2.2/common.o build/temp.darwin-6.1-Power Macintosh-2.2/constants.o build/temp.darwin-6.1-Power Macintosh-2.2/errors.o build/temp.darwin-6.1-Power Macintosh-2.2/functions.o build/temp.darwin-6.1-Power Macintosh-2.2/schema.o build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o build/temp.darwin-6.1-Power Macintosh-2.2/message.o build/temp.darwin-6.1-Power Macintosh-2.2/version.o build/temp.darwin-6.1-Power Macintosh-2.2/options.o -L/usr/lib -Wl,-R/usr/lib -lldap -llber -o build/lib.darwin-6.1-Power Macintosh-2.2/_ldap.so ld: for architecture i386 ld: unknown flag: -R/usr/lib error: command 'gcc' failed with exit status 1 ####### after that, all xxx.o files are create in "build/temp.darwin-6.1-Power Macintosh-2.2/" but no _ldap.so is created in "build/lib.darwin-6.1-Power Macintosh-2.2/" nor somewhere else. cu Juergen From jens at zope.com Mon Nov 4 18:39:59 2002 From: jens at zope.com (Jens Vagelpohl) Date: Mon, 4 Nov 2002 12:39:59 -0500 Subject: still probs to compile python-ldap on macosx In-Reply-To: Message-ID: <70756F72-F01C-11D6-A55B-0003939EFEBC@zope.com> well, i saw the same error trying to compile with the built-in python2.2. some people claim they got it done, but i went back to a self-compiled python and it was fine for me after that. jens On Monday, Nov 4, 2002, at 07:48 US/Eastern, J.Scholtes wrote: > > Am Montag, 04.11.02, um 13:27 Uhr (Europe/Budapest) schrieb Jens > Vagelpohl: > >> what is the actual error that you get... ? >> >> > > Here is the complete output: > > ##### > running build > running build_py > warning: build_py: file Lib/ldap.py (for module ldap) not found > warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) > 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/cidict.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/__init__.py (output up-to-date) > not copying Lib/ldap/schema/tokenizer.py (output up-to-date) > not copying Lib/ldap/schema/models.py (output up-to-date) > not copying Lib/ldap/schema/subentry.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 > warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) > not found > running build_ext > building '_ldap' extension > creating build/temp.darwin-6.1-Power Macintosh-2.2 > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp > -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include > -I/usr/include/python2.2 -c Modules/LDAPObject.c -o > build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o > cc1: warning: changing search order for system directory "/usr/include" > cc1: warning: as it has already been specified as a non-system > directory > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp > -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include > -I/usr/include/python2.2 -c Modules/common.c -o > build/temp.darwin-6.1-Power Macintosh-2.2/common.o > cc1: warning: changing search order for system directory "/usr/include" > cc1: warning: as it has already been specified as a non-system > directory > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp > -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include > -I/usr/include/python2.2 -c Modules/constants.c -o > build/temp.darwin-6.1-Power Macintosh-2.2/constants.o > cc1: warning: changing search order for system directory "/usr/include" > cc1: warning: as it has already been specified as a non-system > directory > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp > -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include > -I/usr/include/python2.2 -c Modules/errors.c -o > build/temp.darwin-6.1-Power Macintosh-2.2/errors.o > cc1: warning: changing search order for system directory "/usr/include" > cc1: warning: as it has already been specified as a non-system > directory > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp > -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include > -I/usr/include/python2.2 -c Modules/functions.c -o > build/temp.darwin-6.1-Power Macintosh-2.2/functions.o > cc1: warning: changing search order for system directory "/usr/include" > cc1: warning: as it has already been specified as a non-system > directory > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp > -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include > -I/usr/include/python2.2 -c Modules/schema.c -o > build/temp.darwin-6.1-Power Macintosh-2.2/schema.o > cc1: warning: changing search order for system directory "/usr/include" > cc1: warning: as it has already been specified as a non-system > directory > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp > -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include > -I/usr/include/python2.2 -c Modules/ldapmodule.c -o > build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o > cc1: warning: changing search order for system directory "/usr/include" > cc1: warning: as it has already been specified as a non-system > directory > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp > -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include > -I/usr/include/python2.2 -c Modules/linkedlist.c -o > build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o > cc1: warning: changing search order for system directory "/usr/include" > cc1: warning: as it has already been specified as a non-system > directory > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp > -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include > -I/usr/include/python2.2 -c Modules/message.c -o > build/temp.darwin-6.1-Power Macintosh-2.2/message.o > cc1: warning: changing search order for system directory "/usr/include" > cc1: warning: as it has already been specified as a non-system > directory > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp > -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include > -I/usr/include/python2.2 -c Modules/version.c -o > build/temp.darwin-6.1-Power Macintosh-2.2/version.o > cc1: warning: changing search order for system directory "/usr/include" > cc1: warning: as it has already been specified as a non-system > directory > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp > -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include > -I/usr/include/python2.2 -c Modules/options.c -o > build/temp.darwin-6.1-Power Macintosh-2.2/options.o > cc1: warning: changing search order for system directory "/usr/include" > cc1: warning: as it has already been specified as a non-system > directory > Modules/options.c: In function `LDAP_get_option': > Modules/options.c:151: warning: unused variable `doubleval' > gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress > build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o > build/temp.darwin-6.1-Power Macintosh-2.2/common.o > build/temp.darwin-6.1-Power Macintosh-2.2/constants.o > build/temp.darwin-6.1-Power Macintosh-2.2/errors.o > build/temp.darwin-6.1-Power Macintosh-2.2/functions.o > build/temp.darwin-6.1-Power Macintosh-2.2/schema.o > build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o > build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o > build/temp.darwin-6.1-Power Macintosh-2.2/message.o > build/temp.darwin-6.1-Power Macintosh-2.2/version.o > build/temp.darwin-6.1-Power Macintosh-2.2/options.o -L/usr/lib > -Wl,-R/usr/lib -lldap -llber -o build/lib.darwin-6.1-Power > Macintosh-2.2/_ldap.so > ld: for architecture i386 > ld: unknown flag: -R/usr/lib > error: command 'gcc' failed with exit status 1 > ####### > > after that, all xxx.o files are create in "build/temp.darwin-6.1-Power > Macintosh-2.2/" > but no _ldap.so is created in "build/lib.darwin-6.1-Power > Macintosh-2.2/" nor somewhere else. > > cu Juergen From sgraham at wugaa.com Mon Nov 4 19:15:18 2002 From: sgraham at wugaa.com (Steven Graham) Date: Mon, 04 Nov 2002 10:15:18 -0800 Subject: still probs to compile python-ldap on macosx In-Reply-To: <70756F72-F01C-11D6-A55B-0003939EFEBC@zope.com> Message-ID: Running ld -R tells me its an invalid option...: 34% ld -R ld: unknown flag: -R I would suggest one of two things, find where this -Wl option is being defined and get rid of the -R/usr/lib option. Or try compiling the source without i386 support, but having not compiled this yet I don't know if this -R option is specific to the i386 architecture linker flags or not. On 11/4/02 9:39 AM, "Jens Vagelpohl" wrote: > well, i saw the same error trying to compile with the built-in > python2.2. some people claim they got it done, but i went back to a > self-compiled python and it was fine for me after that. > > jens > > > On Monday, Nov 4, 2002, at 07:48 US/Eastern, J.Scholtes wrote: > >> >> Am Montag, 04.11.02, um 13:27 Uhr (Europe/Budapest) schrieb Jens >> Vagelpohl: >> >>> what is the actual error that you get... ? >>> >>> >> >> Here is the complete output: >> >> ##### >> running build >> running build_py >> warning: build_py: file Lib/ldap.py (for module ldap) not found >> warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) >> 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/cidict.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/__init__.py (output up-to-date) >> not copying Lib/ldap/schema/tokenizer.py (output up-to-date) >> not copying Lib/ldap/schema/models.py (output up-to-date) >> not copying Lib/ldap/schema/subentry.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 >> warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) >> not found >> running build_ext >> building '_ldap' extension >> creating build/temp.darwin-6.1-Power Macintosh-2.2 >> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >> -I/usr/include/python2.2 -c Modules/LDAPObject.c -o >> build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o >> cc1: warning: changing search order for system directory "/usr/include" >> cc1: warning: as it has already been specified as a non-system >> directory >> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >> -I/usr/include/python2.2 -c Modules/common.c -o >> build/temp.darwin-6.1-Power Macintosh-2.2/common.o >> cc1: warning: changing search order for system directory "/usr/include" >> cc1: warning: as it has already been specified as a non-system >> directory >> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >> -I/usr/include/python2.2 -c Modules/constants.c -o >> build/temp.darwin-6.1-Power Macintosh-2.2/constants.o >> cc1: warning: changing search order for system directory "/usr/include" >> cc1: warning: as it has already been specified as a non-system >> directory >> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >> -I/usr/include/python2.2 -c Modules/errors.c -o >> build/temp.darwin-6.1-Power Macintosh-2.2/errors.o >> cc1: warning: changing search order for system directory "/usr/include" >> cc1: warning: as it has already been specified as a non-system >> directory >> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >> -I/usr/include/python2.2 -c Modules/functions.c -o >> build/temp.darwin-6.1-Power Macintosh-2.2/functions.o >> cc1: warning: changing search order for system directory "/usr/include" >> cc1: warning: as it has already been specified as a non-system >> directory >> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >> -I/usr/include/python2.2 -c Modules/schema.c -o >> build/temp.darwin-6.1-Power Macintosh-2.2/schema.o >> cc1: warning: changing search order for system directory "/usr/include" >> cc1: warning: as it has already been specified as a non-system >> directory >> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >> -I/usr/include/python2.2 -c Modules/ldapmodule.c -o >> build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o >> cc1: warning: changing search order for system directory "/usr/include" >> cc1: warning: as it has already been specified as a non-system >> directory >> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >> -I/usr/include/python2.2 -c Modules/linkedlist.c -o >> build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o >> cc1: warning: changing search order for system directory "/usr/include" >> cc1: warning: as it has already been specified as a non-system >> directory >> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >> -I/usr/include/python2.2 -c Modules/message.c -o >> build/temp.darwin-6.1-Power Macintosh-2.2/message.o >> cc1: warning: changing search order for system directory "/usr/include" >> cc1: warning: as it has already been specified as a non-system >> directory >> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >> -I/usr/include/python2.2 -c Modules/version.c -o >> build/temp.darwin-6.1-Power Macintosh-2.2/version.o >> cc1: warning: changing search order for system directory "/usr/include" >> cc1: warning: as it has already been specified as a non-system >> directory >> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >> -I/usr/include/python2.2 -c Modules/options.c -o >> build/temp.darwin-6.1-Power Macintosh-2.2/options.o >> cc1: warning: changing search order for system directory "/usr/include" >> cc1: warning: as it has already been specified as a non-system >> directory >> Modules/options.c: In function `LDAP_get_option': >> Modules/options.c:151: warning: unused variable `doubleval' >> gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress >> build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o >> build/temp.darwin-6.1-Power Macintosh-2.2/common.o >> build/temp.darwin-6.1-Power Macintosh-2.2/constants.o >> build/temp.darwin-6.1-Power Macintosh-2.2/errors.o >> build/temp.darwin-6.1-Power Macintosh-2.2/functions.o >> build/temp.darwin-6.1-Power Macintosh-2.2/schema.o >> build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o >> build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o >> build/temp.darwin-6.1-Power Macintosh-2.2/message.o >> build/temp.darwin-6.1-Power Macintosh-2.2/version.o >> build/temp.darwin-6.1-Power Macintosh-2.2/options.o -L/usr/lib >> -Wl,-R/usr/lib -lldap -llber -o build/lib.darwin-6.1-Power >> Macintosh-2.2/_ldap.so >> ld: for architecture i386 >> ld: unknown flag: -R/usr/lib >> error: command 'gcc' failed with exit status 1 >> ####### >> >> after that, all xxx.o files are create in "build/temp.darwin-6.1-Power >> Macintosh-2.2/" >> but no _ldap.so is created in "build/lib.darwin-6.1-Power >> Macintosh-2.2/" nor somewhere else. >> >> cu Juergen > > > > From jens at zope.com Tue Nov 5 03:06:24 2002 From: jens at zope.com (Jens Vagelpohl) Date: Mon, 4 Nov 2002 21:06:24 -0500 Subject: still probs to compile python-ldap on macosx In-Reply-To: Message-ID: <2FC5065A-F063-11D6-870E-0003939EFEBC@zope.com> the -R is not the problem. under normal operation all it does is generate a warning. the problem is with the built-in python2.1 jens On Monday, Nov 4, 2002, at 13:15 US/Eastern, Steven Graham wrote: > > Running ld -R tells me its an invalid option...: > 34% ld -R > ld: unknown flag: -R > > I would suggest one of two things, find where this -Wl option is being > defined and get rid of the -R/usr/lib option. Or try compiling the > source > without i386 support, but having not compiled this yet I don't know > if this > -R option is specific to the i386 architecture linker flags or not. > > > On 11/4/02 9:39 AM, "Jens Vagelpohl" wrote: > >> well, i saw the same error trying to compile with the built-in >> python2.2. some people claim they got it done, but i went back to a >> self-compiled python and it was fine for me after that. >> >> jens >> >> >> On Monday, Nov 4, 2002, at 07:48 US/Eastern, J.Scholtes wrote: >> >>> >>> Am Montag, 04.11.02, um 13:27 Uhr (Europe/Budapest) schrieb Jens >>> Vagelpohl: >>> >>>> what is the actual error that you get... ? >>>> >>>> >>> >>> Here is the complete output: >>> >>> ##### >>> running build >>> running build_py >>> warning: build_py: file Lib/ldap.py (for module ldap) not found >>> warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) >>> 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/cidict.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/__init__.py (output up-to-date) >>> not copying Lib/ldap/schema/tokenizer.py (output up-to-date) >>> not copying Lib/ldap/schema/models.py (output up-to-date) >>> not copying Lib/ldap/schema/subentry.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 >>> warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) >>> not found >>> running build_ext >>> building '_ldap' extension >>> creating build/temp.darwin-6.1-Power Macintosh-2.2 >>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>> -I/usr/include/python2.2 -c Modules/LDAPObject.c -o >>> build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o >>> cc1: warning: changing search order for system directory >>> "/usr/include" >>> cc1: warning: as it has already been specified as a non-system >>> directory >>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>> -I/usr/include/python2.2 -c Modules/common.c -o >>> build/temp.darwin-6.1-Power Macintosh-2.2/common.o >>> cc1: warning: changing search order for system directory >>> "/usr/include" >>> cc1: warning: as it has already been specified as a non-system >>> directory >>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>> -I/usr/include/python2.2 -c Modules/constants.c -o >>> build/temp.darwin-6.1-Power Macintosh-2.2/constants.o >>> cc1: warning: changing search order for system directory >>> "/usr/include" >>> cc1: warning: as it has already been specified as a non-system >>> directory >>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>> -I/usr/include/python2.2 -c Modules/errors.c -o >>> build/temp.darwin-6.1-Power Macintosh-2.2/errors.o >>> cc1: warning: changing search order for system directory >>> "/usr/include" >>> cc1: warning: as it has already been specified as a non-system >>> directory >>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>> -I/usr/include/python2.2 -c Modules/functions.c -o >>> build/temp.darwin-6.1-Power Macintosh-2.2/functions.o >>> cc1: warning: changing search order for system directory >>> "/usr/include" >>> cc1: warning: as it has already been specified as a non-system >>> directory >>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>> -I/usr/include/python2.2 -c Modules/schema.c -o >>> build/temp.darwin-6.1-Power Macintosh-2.2/schema.o >>> cc1: warning: changing search order for system directory >>> "/usr/include" >>> cc1: warning: as it has already been specified as a non-system >>> directory >>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>> -I/usr/include/python2.2 -c Modules/ldapmodule.c -o >>> build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o >>> cc1: warning: changing search order for system directory >>> "/usr/include" >>> cc1: warning: as it has already been specified as a non-system >>> directory >>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>> -I/usr/include/python2.2 -c Modules/linkedlist.c -o >>> build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o >>> cc1: warning: changing search order for system directory >>> "/usr/include" >>> cc1: warning: as it has already been specified as a non-system >>> directory >>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>> -I/usr/include/python2.2 -c Modules/message.c -o >>> build/temp.darwin-6.1-Power Macintosh-2.2/message.o >>> cc1: warning: changing search order for system directory >>> "/usr/include" >>> cc1: warning: as it has already been specified as a non-system >>> directory >>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>> -I/usr/include/python2.2 -c Modules/version.c -o >>> build/temp.darwin-6.1-Power Macintosh-2.2/version.o >>> cc1: warning: changing search order for system directory >>> "/usr/include" >>> cc1: warning: as it has already been specified as a non-system >>> directory >>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>> -I/usr/include/python2.2 -c Modules/options.c -o >>> build/temp.darwin-6.1-Power Macintosh-2.2/options.o >>> cc1: warning: changing search order for system directory >>> "/usr/include" >>> cc1: warning: as it has already been specified as a non-system >>> directory >>> Modules/options.c: In function `LDAP_get_option': >>> Modules/options.c:151: warning: unused variable `doubleval' >>> gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress >>> build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o >>> build/temp.darwin-6.1-Power Macintosh-2.2/common.o >>> build/temp.darwin-6.1-Power Macintosh-2.2/constants.o >>> build/temp.darwin-6.1-Power Macintosh-2.2/errors.o >>> build/temp.darwin-6.1-Power Macintosh-2.2/functions.o >>> build/temp.darwin-6.1-Power Macintosh-2.2/schema.o >>> build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o >>> build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o >>> build/temp.darwin-6.1-Power Macintosh-2.2/message.o >>> build/temp.darwin-6.1-Power Macintosh-2.2/version.o >>> build/temp.darwin-6.1-Power Macintosh-2.2/options.o -L/usr/lib >>> -Wl,-R/usr/lib -lldap -llber -o build/lib.darwin-6.1-Power >>> Macintosh-2.2/_ldap.so >>> ld: for architecture i386 >>> ld: unknown flag: -R/usr/lib >>> error: command 'gcc' failed with exit status 1 >>> ####### >>> >>> after that, all xxx.o files are create in >>> "build/temp.darwin-6.1-Power >>> Macintosh-2.2/" >>> but no _ldap.so is created in "build/lib.darwin-6.1-Power >>> Macintosh-2.2/" nor somewhere else. >>> >>> cu Juergen >> >> >> >> From sgraham at wugaa.com Tue Nov 5 04:28:06 2002 From: sgraham at wugaa.com (Steven Graham) Date: Mon, 04 Nov 2002 19:28:06 -0800 Subject: still probs to compile python-ldap on macosx In-Reply-To: <2FC5065A-F063-11D6-870E-0003939EFEBC@zope.com> Message-ID: I disagree, under normal operation the command is failing and exiting with a status of 1 (Under OS X) 31% ld -R; echo $? ld: unknown flag: -R 1 The compile process is failing at the linker phase which means that there is an error in the build script (specifically the -Wl,-R/usr/bin option) On 11/4/02 6:06 PM, "Jens Vagelpohl" wrote: > the -R is not the problem. under normal operation all it does is > generate a warning. the problem is with the built-in python2.1 > > jens > > On Monday, Nov 4, 2002, at 13:15 US/Eastern, Steven Graham wrote: > >> >> Running ld -R tells me its an invalid option...: >> 34% ld -R >> ld: unknown flag: -R >> >> I would suggest one of two things, find where this -Wl option is being >> defined and get rid of the -R/usr/lib option. Or try compiling the >> source >> without i386 support, but having not compiled this yet I don't know >> if this >> -R option is specific to the i386 architecture linker flags or not. >> >> >> On 11/4/02 9:39 AM, "Jens Vagelpohl" wrote: >> >>> well, i saw the same error trying to compile with the built-in >>> python2.2. some people claim they got it done, but i went back to a >>> self-compiled python and it was fine for me after that. >>> >>> jens >>> >>> >>> On Monday, Nov 4, 2002, at 07:48 US/Eastern, J.Scholtes wrote: >>> >>>> >>>> Am Montag, 04.11.02, um 13:27 Uhr (Europe/Budapest) schrieb Jens >>>> Vagelpohl: >>>> >>>>> what is the actual error that you get... ? >>>>> >>>>> >>>> >>>> Here is the complete output: >>>> >>>> ##### >>>> running build >>>> running build_py >>>> warning: build_py: file Lib/ldap.py (for module ldap) not found >>>> warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) >>>> 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/cidict.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/__init__.py (output up-to-date) >>>> not copying Lib/ldap/schema/tokenizer.py (output up-to-date) >>>> not copying Lib/ldap/schema/models.py (output up-to-date) >>>> not copying Lib/ldap/schema/subentry.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 >>>> warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) >>>> not found >>>> running build_ext >>>> building '_ldap' extension >>>> creating build/temp.darwin-6.1-Power Macintosh-2.2 >>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>> -I/usr/include/python2.2 -c Modules/LDAPObject.c -o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o >>>> cc1: warning: changing search order for system directory >>>> "/usr/include" >>>> cc1: warning: as it has already been specified as a non-system >>>> directory >>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>> -I/usr/include/python2.2 -c Modules/common.c -o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/common.o >>>> cc1: warning: changing search order for system directory >>>> "/usr/include" >>>> cc1: warning: as it has already been specified as a non-system >>>> directory >>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>> -I/usr/include/python2.2 -c Modules/constants.c -o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/constants.o >>>> cc1: warning: changing search order for system directory >>>> "/usr/include" >>>> cc1: warning: as it has already been specified as a non-system >>>> directory >>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>> -I/usr/include/python2.2 -c Modules/errors.c -o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/errors.o >>>> cc1: warning: changing search order for system directory >>>> "/usr/include" >>>> cc1: warning: as it has already been specified as a non-system >>>> directory >>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>> -I/usr/include/python2.2 -c Modules/functions.c -o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/functions.o >>>> cc1: warning: changing search order for system directory >>>> "/usr/include" >>>> cc1: warning: as it has already been specified as a non-system >>>> directory >>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>> -I/usr/include/python2.2 -c Modules/schema.c -o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/schema.o >>>> cc1: warning: changing search order for system directory >>>> "/usr/include" >>>> cc1: warning: as it has already been specified as a non-system >>>> directory >>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>> -I/usr/include/python2.2 -c Modules/ldapmodule.c -o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o >>>> cc1: warning: changing search order for system directory >>>> "/usr/include" >>>> cc1: warning: as it has already been specified as a non-system >>>> directory >>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>> -I/usr/include/python2.2 -c Modules/linkedlist.c -o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o >>>> cc1: warning: changing search order for system directory >>>> "/usr/include" >>>> cc1: warning: as it has already been specified as a non-system >>>> directory >>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>> -I/usr/include/python2.2 -c Modules/message.c -o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/message.o >>>> cc1: warning: changing search order for system directory >>>> "/usr/include" >>>> cc1: warning: as it has already been specified as a non-system >>>> directory >>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>> -I/usr/include/python2.2 -c Modules/version.c -o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/version.o >>>> cc1: warning: changing search order for system directory >>>> "/usr/include" >>>> cc1: warning: as it has already been specified as a non-system >>>> directory >>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>> -I/usr/include/python2.2 -c Modules/options.c -o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/options.o >>>> cc1: warning: changing search order for system directory >>>> "/usr/include" >>>> cc1: warning: as it has already been specified as a non-system >>>> directory >>>> Modules/options.c: In function `LDAP_get_option': >>>> Modules/options.c:151: warning: unused variable `doubleval' >>>> gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress >>>> build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/common.o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/constants.o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/errors.o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/functions.o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/schema.o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/message.o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/version.o >>>> build/temp.darwin-6.1-Power Macintosh-2.2/options.o -L/usr/lib >>>> -Wl,-R/usr/lib -lldap -llber -o build/lib.darwin-6.1-Power >>>> Macintosh-2.2/_ldap.so >>>> ld: for architecture i386 >>>> ld: unknown flag: -R/usr/lib >>>> error: command 'gcc' failed with exit status 1 >>>> ####### >>>> >>>> after that, all xxx.o files are create in >>>> "build/temp.darwin-6.1-Power >>>> Macintosh-2.2/" >>>> but no _ldap.so is created in "build/lib.darwin-6.1-Power >>>> Macintosh-2.2/" nor somewhere else. >>>> >>>> cu Juergen >>> >>> >>> >>> From jens at zope.com Tue Nov 5 06:48:22 2002 From: jens at zope.com (Jens Vagelpohl) Date: Tue, 5 Nov 2002 00:48:22 -0500 Subject: still probs to compile python-ldap on macosx In-Reply-To: Message-ID: <31CB98E0-F082-11D6-870E-0003939EFEBC@zope.com> well, the build script does not fail using a self-built python 2.1.3. it gives a warning but the extension is being built. it fails with the built-in python. you get the warning about -R as well. my conclusion: the -R is not the real problem. jens On Monday, Nov 4, 2002, at 22:28 US/Eastern, Steven Graham wrote: > > I disagree, under normal operation the command is failing and exiting > with a > status of 1 (Under OS X) > > 31% ld -R; echo $? > ld: unknown flag: -R > 1 > > The compile process is failing at the linker phase which means that > there is > an error in the build script (specifically the -Wl,-R/usr/bin option) > > On 11/4/02 6:06 PM, "Jens Vagelpohl" wrote: > >> the -R is not the problem. under normal operation all it does is >> generate a warning. the problem is with the built-in python2.1 >> >> jens >> >> On Monday, Nov 4, 2002, at 13:15 US/Eastern, Steven Graham wrote: >> >>> >>> Running ld -R tells me its an invalid option...: >>> 34% ld -R >>> ld: unknown flag: -R >>> >>> I would suggest one of two things, find where this -Wl option is >>> being >>> defined and get rid of the -R/usr/lib option. Or try compiling the >>> source >>> without i386 support, but having not compiled this yet I don't know >>> if this >>> -R option is specific to the i386 architecture linker flags or not. >>> >>> >>> On 11/4/02 9:39 AM, "Jens Vagelpohl" wrote: >>> >>>> well, i saw the same error trying to compile with the built-in >>>> python2.2. some people claim they got it done, but i went back to a >>>> self-compiled python and it was fine for me after that. >>>> >>>> jens >>>> >>>> >>>> On Monday, Nov 4, 2002, at 07:48 US/Eastern, J.Scholtes wrote: >>>> >>>>> >>>>> Am Montag, 04.11.02, um 13:27 Uhr (Europe/Budapest) schrieb Jens >>>>> Vagelpohl: >>>>> >>>>>> what is the actual error that you get... ? >>>>>> >>>>>> >>>>> >>>>> Here is the complete output: >>>>> >>>>> ##### >>>>> running build >>>>> running build_py >>>>> warning: build_py: file Lib/ldap.py (for module ldap) not found >>>>> warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) >>>>> 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/cidict.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/__init__.py (output up-to-date) >>>>> not copying Lib/ldap/schema/tokenizer.py (output up-to-date) >>>>> not copying Lib/ldap/schema/models.py (output up-to-date) >>>>> not copying Lib/ldap/schema/subentry.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 >>>>> warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) >>>>> not found >>>>> running build_ext >>>>> building '_ldap' extension >>>>> creating build/temp.darwin-6.1-Power Macintosh-2.2 >>>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>>> -I/usr/include/python2.2 -c Modules/LDAPObject.c -o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o >>>>> cc1: warning: changing search order for system directory >>>>> "/usr/include" >>>>> cc1: warning: as it has already been specified as a non-system >>>>> directory >>>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>>> -I/usr/include/python2.2 -c Modules/common.c -o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/common.o >>>>> cc1: warning: changing search order for system directory >>>>> "/usr/include" >>>>> cc1: warning: as it has already been specified as a non-system >>>>> directory >>>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>>> -I/usr/include/python2.2 -c Modules/constants.c -o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/constants.o >>>>> cc1: warning: changing search order for system directory >>>>> "/usr/include" >>>>> cc1: warning: as it has already been specified as a non-system >>>>> directory >>>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>>> -I/usr/include/python2.2 -c Modules/errors.c -o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/errors.o >>>>> cc1: warning: changing search order for system directory >>>>> "/usr/include" >>>>> cc1: warning: as it has already been specified as a non-system >>>>> directory >>>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>>> -I/usr/include/python2.2 -c Modules/functions.c -o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/functions.o >>>>> cc1: warning: changing search order for system directory >>>>> "/usr/include" >>>>> cc1: warning: as it has already been specified as a non-system >>>>> directory >>>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>>> -I/usr/include/python2.2 -c Modules/schema.c -o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/schema.o >>>>> cc1: warning: changing search order for system directory >>>>> "/usr/include" >>>>> cc1: warning: as it has already been specified as a non-system >>>>> directory >>>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>>> -I/usr/include/python2.2 -c Modules/ldapmodule.c -o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o >>>>> cc1: warning: changing search order for system directory >>>>> "/usr/include" >>>>> cc1: warning: as it has already been specified as a non-system >>>>> directory >>>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>>> -I/usr/include/python2.2 -c Modules/linkedlist.c -o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o >>>>> cc1: warning: changing search order for system directory >>>>> "/usr/include" >>>>> cc1: warning: as it has already been specified as a non-system >>>>> directory >>>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>>> -I/usr/include/python2.2 -c Modules/message.c -o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/message.o >>>>> cc1: warning: changing search order for system directory >>>>> "/usr/include" >>>>> cc1: warning: as it has already been specified as a non-system >>>>> directory >>>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>>> -I/usr/include/python2.2 -c Modules/version.c -o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/version.o >>>>> cc1: warning: changing search order for system directory >>>>> "/usr/include" >>>>> cc1: warning: as it has already been specified as a non-system >>>>> directory >>>>> gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp >>>>> -DLDAPMODULE_VERSION=2.0.0pre06 -IModules -I/usr/include >>>>> -I/usr/include/python2.2 -c Modules/options.c -o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/options.o >>>>> cc1: warning: changing search order for system directory >>>>> "/usr/include" >>>>> cc1: warning: as it has already been specified as a non-system >>>>> directory >>>>> Modules/options.c: In function `LDAP_get_option': >>>>> Modules/options.c:151: warning: unused variable `doubleval' >>>>> gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined >>>>> suppress >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/LDAPObject.o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/common.o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/constants.o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/errors.o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/functions.o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/schema.o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/ldapmodule.o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/linkedlist.o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/message.o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/version.o >>>>> build/temp.darwin-6.1-Power Macintosh-2.2/options.o -L/usr/lib >>>>> -Wl,-R/usr/lib -lldap -llber -o build/lib.darwin-6.1-Power >>>>> Macintosh-2.2/_ldap.so >>>>> ld: for architecture i386 >>>>> ld: unknown flag: -R/usr/lib >>>>> error: command 'gcc' failed with exit status 1 >>>>> ####### >>>>> >>>>> after that, all xxx.o files are create in >>>>> "build/temp.darwin-6.1-Power >>>>> Macintosh-2.2/" >>>>> but no _ldap.so is created in "build/lib.darwin-6.1-Power >>>>> Macintosh-2.2/" nor somewhere else. >>>>> >>>>> cu Juergen >>>> >>>> >>>> >>>> From peter at hawkins.emu.id.au Tue Nov 5 08:01:22 2002 From: peter at hawkins.emu.id.au (Peter Hawkins) Date: Tue, 5 Nov 2002 18:01:22 +1100 Subject: still probs to compile python-ldap on macosx In-Reply-To: References: Message-ID: <200211051801.24633.peter@hawkins.emu.id.au> Hi... On Tue, 5 Nov 2002 02:28 pm, Steven Graham wrote: > I disagree, under normal operation the command is failing and > exiting with a status of 1 (Under OS X) > > 31% ld -R; echo $? > ld: unknown flag: -R > 1 -R takes an argument on other UNIXes. , and you'd expect ld to fail on that command line anyway since you haven't given it any input files. On linux: peterh at warpcore:~$ ld -R; echo $? ld: unrecognized option '-R' ld: use the --help option for usage information 1 peterh at warpcore:~$ ld -R/tmp; echo $? ld: no input files 1 peterh at warpcore:~$ =) Peter -- peter at hawkins.emu.id.au aka peterh at debian.org GPG key fingerprint: C746 38A9 D3E4 A171 FB6A 56D4 5E30 DFCC BE11 F437 From sgraham at wugaa.com Tue Nov 5 10:55:05 2002 From: sgraham at wugaa.com (Steven Graham) Date: Tue, 05 Nov 2002 01:55:05 -0800 Subject: still probs to compile python-ldap on macosx In-Reply-To: <200211051801.24633.peter@hawkins.emu.id.au> Message-ID: ld -R/filename does error out also, and after finding what was wrong it only issued a warning as Jens said earlier. For some reason gcc doesn't like the space in the filename when linking. This might not be gcc, it could be the shell that gcc is calling to exec ld. In any case I modified util.py in the distutils package to strip out spaces in the machine name ('Power Macintosh-2.2') when the osname is 'darwin'. The patch is as follows: --- util.py Tue Nov 5 01:29:27 2002 +++ util.py.osx Tue Nov 5 01:26:22 2002 @@ -67,6 +67,8 @@ m = rel_re.match(release) if m: release = m.group() + elif osname[:6] == "darwin": + machine = machine.replace(' ','') return "%s-%s-%s" % (osname, release, machine) ----end patch (don't include this in file)---- You can patch util.py (after making a backup) like so: # cd /path/to/python/lib/distutils/ # cp util.py util.py.orig # patch -u -p0 < patch_filename Where patch_filename is the file you save the patch into. If you don't want to use patch you can add the two line fix by hand :) This will cause the output_dir variable to be set to 'build/temp.darwin-6.1-PowerMacintosh-2.2/' I'm sure there is an easier way to set the build directory through options in either setup.py or through the command line but I can't find any. This fix seemed to work for me. -Steve Note: I have python2.2 installed on my system but it was showing the same problems. On 11/4/02 11:01 PM, "Peter Hawkins" wrote: > Hi... > > > On Tue, 5 Nov 2002 02:28 pm, Steven Graham wrote: >> I disagree, under normal operation the command is failing and >> exiting with a status of 1 (Under OS X) >> >> 31% ld -R; echo $? >> ld: unknown flag: -R >> 1 > > -R takes an argument on other UNIXes. , and you'd expect ld to fail on > that command line anyway since you haven't given it any input files. > > On linux: > peterh at warpcore:~$ ld -R; echo $? > ld: unrecognized option '-R' > ld: use the --help option for usage information > 1 > peterh at warpcore:~$ ld -R/tmp; echo $? > ld: no input files > 1 > peterh at warpcore:~$ > > =) > Peter ---- Steven Graham sgraham at wugaa.com From mengelhart at katahdinsoftware.com Tue Nov 5 14:55:04 2002 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Tue, 5 Nov 2002 08:55:04 -0500 Subject: still probs to compile python-ldap on macosx In-Reply-To: Message-ID: <2F42FCC8-F0C6-11D6-8A0B-000393A48A3C@katahdinsoftware.com> Just curious, does this now build without any errors on the python2.2 that is installed by the developer tools? I'm one of the ones who was able to build the library with my stock 10.2 OS X and Dev Tools. It errored out during the build phase but build install still installed the library and it works fine. Mike On Tuesday, November 5, 2002, at 04:55 AM, Steven Graham wrote: > > > ld -R/filename does error out also, and after finding what was wrong > it only > issued a warning as Jens said earlier. > > For some reason gcc doesn't like the space in the filename when > linking. > This might not be gcc, it could be the shell that gcc is calling to > exec ld. > In any case I modified util.py in the distutils package to strip out > spaces > in the machine name ('Power Macintosh-2.2') when the osname is > 'darwin'. > > The patch is as follows: > --- util.py Tue Nov 5 01:29:27 2002 > +++ util.py.osx Tue Nov 5 01:26:22 2002 > @@ -67,6 +67,8 @@ > m = rel_re.match(release) > if m: > release = m.group() > + elif osname[:6] == "darwin": > + machine = machine.replace(' ','') > > return "%s-%s-%s" % (osname, release, machine) > ----end patch (don't include this in file)---- > > You can patch util.py (after making a backup) like so: > > # cd /path/to/python/lib/distutils/ > # cp util.py util.py.orig > # patch -u -p0 < patch_filename > > Where patch_filename is the file you save the patch into. > If you don't want to use patch you can add the two line fix by hand :) > > This will cause the output_dir variable to be set to > 'build/temp.darwin-6.1-PowerMacintosh-2.2/' > > I'm sure there is an easier way to set the build directory through > options > in either setup.py or through the command line but I can't find any. > This > fix seemed to work for me. > > -Steve > > Note: I have python2.2 installed on my system but it was showing the > same > problems. From scholtes at fh-aachen.de Tue Nov 12 20:42:19 2002 From: scholtes at fh-aachen.de (Juergen Scholtes) Date: Tue, 12 Nov 2002 20:42:19 +0100 Subject: still probs to compile python-ldap on macosx ##solved## References: Message-ID: <001401c28a83$9d2df9a0$b7c3fea9@toms> Hi. It works !!! Without the space in the path and compiled with the Zope-included Python 2.1 i'm able to use the LDAPuserfolder with Zope 2.5.1. Thanks to all for your help. Best Regards Juergen ----- Original Message ----- From: "Steven Graham" To: "Peter Hawkins" Cc: Sent: Tuesday, November 05, 2002 10:55 AM Subject: Re: still probs to compile python-ldap on macosx > > ld -R/filename does error out also, and after finding what was wrong it only > issued a warning as Jens said earlier. > > For some reason gcc doesn't like the space in the filename when linking. > This might not be gcc, it could be the shell that gcc is calling to exec ld. > In any case I modified util.py in the distutils package to strip out spaces > in the machine name ('Power Macintosh-2.2') when the osname is 'darwin'. > > The patch is as follows: > --- util.py Tue Nov 5 01:29:27 2002 > +++ util.py.osx Tue Nov 5 01:26:22 2002 > @@ -67,6 +67,8 @@ > m = rel_re.match(release) > if m: > release = m.group() > + elif osname[:6] == "darwin": > + machine = machine.replace(' ','') > > return "%s-%s-%s" % (osname, release, machine) > ----end patch (don't include this in file)---- > > You can patch util.py (after making a backup) like so: > > # cd /path/to/python/lib/distutils/ > # cp util.py util.py.orig > # patch -u -p0 < patch_filename > > Where patch_filename is the file you save the patch into. > If you don't want to use patch you can add the two line fix by hand :) > > This will cause the output_dir variable to be set to > 'build/temp.darwin-6.1-PowerMacintosh-2.2/' > > I'm sure there is an easier way to set the build directory through options > in either setup.py or through the command line but I can't find any. This > fix seemed to work for me. > > -Steve > > Note: I have python2.2 installed on my system but it was showing the same > problems. > > On 11/4/02 11:01 PM, "Peter Hawkins" wrote: > > > Hi... > > > > > > On Tue, 5 Nov 2002 02:28 pm, Steven Graham wrote: > >> I disagree, under normal operation the command is failing and > >> exiting with a status of 1 (Under OS X) > >> > >> 31% ld -R; echo $? > >> ld: unknown flag: -R > >> 1 > > > > -R takes an argument on other UNIXes. , and you'd expect ld to fail on > > that command line anyway since you haven't given it any input files. > > > > On linux: > > peterh at warpcore:~$ ld -R; echo $? > > ld: unrecognized option '-R' > > ld: use the --help option for usage information > > 1 > > peterh at warpcore:~$ ld -R/tmp; echo $? > > ld: no input files > > 1 > > peterh at warpcore:~$ > > > > =) > > Peter > > ---- > Steven Graham > sgraham at wugaa.com > > > > > > From mengelhart at katahdinsoftware.com Sat Nov 23 16:20:51 2002 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Sat, 23 Nov 2002 10:20:51 -0500 Subject: retrieving schema Message-ID: <26B640FC-FEF7-11D6-BC82-000393A48A3C@katahdinsoftware.com> Is there anyway in python-ldap to retrieve the schema or an allowed attribute list from a directory (possibly an empty directory - no entries yet added). Thanks Mike From michael at stroeder.com Sun Nov 24 00:26:02 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 24 Nov 2002 00:26:02 +0100 Subject: retrieving schema References: <26B640FC-FEF7-11D6-BC82-000393A48A3C@katahdinsoftware.com> Message-ID: <3DE00E8A.6020004@stroeder.com> Michael Engelhart wrote: > Is there anyway in python-ldap to retrieve the schema or an allowed > attribute list from a directory (possibly an empty directory - no > entries yet added). Yes, dig into ldap.schema added in python-ldap 2.0.0pre06 (not yet documented and possibly still subject to changes). See http://python-ldap.sourceforge.net/pydoc/ldap.schema.html and Demo/schema.py Ciao, Michael. From loureiro at dte.gov.br Sat Nov 30 01:09:32 2002 From: loureiro at dte.gov.br (Jorge Loureiro Dias) Date: Fri, 29 Nov 2002 21:09:32 -0300 Subject: Problems importing ldap in Zope Message-ID: <20021130000932.M59372@dte.gov.br> I?m using Linux RedHat 8, Zope 2.6 , python-ldap-2.0.0pre06-1(rpm version) and LDAPUserFolder. I also have Python 2.2 installed. In Python, I can 'import ldap' and connect to my LDAP server. Everything works fine. But when Zope starts and tries to import ldap, it fails and sends a message: "undefined symbol PyType_IsSubtype". With Zope 2.51 and another server the same error occurs. -- Jorge Loureiro Dias loureiro at dte.gov.br From jens at zope.com Sat Nov 30 02:12:57 2002 From: jens at zope.com (Jens Vagelpohl) Date: Fri, 29 Nov 2002 20:12:57 -0500 Subject: Problems importing ldap in Zope In-Reply-To: <20021130000932.M59372@dte.gov.br> Message-ID: this problem has nothing to do with zope. the ldap module zope is trying to import is messed up. the one zope is trying to import is most likely not the same one that gets imported if you run python itself from the command line. you need to locate the exact python binary zope uses and rebuild the python-ldap module with that binary. jens On Friday, Nov 29, 2002, at 19:09 US/Eastern, Jorge Loureiro Dias wrote: > I?m using Linux RedHat 8, Zope 2.6 , python-ldap-2.0.0pre06-1(rpm > version) > and LDAPUserFolder. > I also have Python 2.2 installed. > > In Python, I can 'import ldap' and connect to my LDAP server. > Everything > works fine. > > But when Zope starts and tries to import ldap, it fails and sends a > message: > > "undefined symbol PyType_IsSubtype". > > With Zope 2.51 and another server the same error occurs. > > -- > Jorge Loureiro Dias > loureiro at dte.gov.br > > > From michael at stroeder.com Wed Dec 11 23:32:20 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 11 Dec 2002 23:32:20 +0100 Subject: LDAPObject.search_ext() Message-ID: <3DF7BCF4.2040505@stroeder.com> HI! I've committed some changes to use OpenLDAP 2.x's ldap_search_ext() instead of ldap_search(). This enables the application to specify a client-side search limit when using method search_ext() or search_ext_s(). The latter is inconvenient since ldap.SIZE_LIMIT_EXCEEDED is raised when the search limit was exceeded. Use (still undocumented) class ldap.async.List instead. This change is hidden in a back-ward compatible way in wrapper class ldap.ldapobject.LDAPObject. Old code should still work. Please test! Ciao, Michael From michael at stroeder.com Wed Dec 11 23:32:20 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 11 Dec 2002 23:32:20 +0100 Subject: LDAPObject.search_ext() Message-ID: <3DF7BCF4.2040505@stroeder.com> HI! I've committed some changes to use OpenLDAP 2.x's ldap_search_ext() instead of ldap_search(). This enables the application to specify a client-side search limit when using method search_ext() or search_ext_s(). The latter is inconvenient since ldap.SIZE_LIMIT_EXCEEDED is raised when the search limit was exceeded. Use (still undocumented) class ldap.async.List instead. This change is hidden in a back-ward compatible way in wrapper class ldap.ldapobject.LDAPObject. Old code should still work. Please test! Ciao, Michael From michael at stroeder.com Mon Dec 16 07:30:48 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 16 Dec 2002 07:30:48 +0100 Subject: Remove code for set_rebind_proc() in LDAPObject.c? Message-ID: <3DFD7318.6050408@stroeder.com> HI! Anyone in favour of re-enabling method set_rebind_proc()? It has been disabled quite a while ago and I would like to remove the code from LDAPObject.c. Callbacks are pretty un-pythonic and the functionality can be better achieved in a Python wrapper class. If someone really needs it he/she should volunteer maintaining it according to changes which might have been made in recent versions of OpenLDAP 2.x. Ciao, Michael. From rnaidu at zeomega.com Tue Dec 17 10:19:07 2002 From: rnaidu at zeomega.com (Rakesh Naidu) Date: Tue, 17 Dec 2002 14:49:07 +0530 Subject: error installing ldapmodule1.8 Message-ID: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> hello all, I hear that ldapmodule-1.8.tar.gz is not installable on suse linux 7.x since it uses an API which was not standardised(it references a member mod_next in the LDAPMod structure which was present in UM LDAP and early OpenLDAP) can any one confirm this or comment on this.... i have been trying to get the sys admin of my customer's ...to install this.....and i get this reply that it is not compatible... Rakesh Naidu. _o _\<_ __(_)/(_) life's a journey not a destination.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Tue Dec 17 10:22:43 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 17 Dec 2002 10:22:43 +0100 Subject: error installing ldapmodule1.8 In-Reply-To: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> Message-ID: <3DFEECE3.2080903@stroeder.com> Rakesh Naidu wrote: > I hear that ldapmodule-1.8.tar.gz is not installable on suse linux 7.x Please go for python-ldap 2.0.0pre06 compiled against OpenLDAP 2.x libs. 1.8 is pretty ancient. Ciao, Michael. From rnaidu at zeomega.com Tue Dec 17 11:18:57 2002 From: rnaidu at zeomega.com (Rakesh Naidu) Date: Tue, 17 Dec 2002 15:48:57 +0530 Subject: error installing ldapmodule1.8 References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> Message-ID: <029b01c2a5b5$b5c20450$3b01a8c0@zeomega.org> thanks for the reply,michael, do you think python-ldap 2.0.0pre05...should work fine with openldap 2.0.12 and also will python-ldap 2.0.0pre06 work fine with openldap 2.0.12 coz as of now i have asked my client's sys admin to instal python-ldap 2.0.0pre05 with regards, Rakesh Naidu ----- Original Message ----- From: "Michael Str?der" To: "Rakesh Naidu" Cc: "python-ldap" Sent: Tuesday, December 17, 2002 2:52 PM Subject: Re: error installing ldapmodule1.8 > Rakesh Naidu wrote: > > I hear that ldapmodule-1.8.tar.gz is not installable on suse linux 7.x > > Please go for python-ldap 2.0.0pre06 compiled against OpenLDAP 2.x libs. 1.8 > is pretty ancient. > > Ciao, Michael. > > > > From rganesan at myrealbox.com Tue Dec 17 11:10:09 2002 From: rganesan at myrealbox.com (Ganesan R) Date: 17 Dec 2002 15:40:09 +0530 Subject: error installing ldapmodule1.8 In-Reply-To: <3DFEECE3.2080903@stroeder.com> References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> Message-ID: >>>>> "Michael" == Michael Str?der writes: > Rakesh Naidu wrote: >> I hear that ldapmodule-1.8.tar.gz is not installable on suse linux 7.x > Please go for python-ldap 2.0.0pre06 compiled against OpenLDAP 2.x > libs. 1.8 is pretty ancient. Is OpenLDAP 2.0 supported? I faced some problems compiling python-ldap with it. The problems went away when I used OpenLDAP 2.1. This may be due to a bug in the local environment, I was playing around with both OpenLDAP 2.0 and 2.1. Ganesan -- Ganesan R From michael at stroeder.com Tue Dec 17 11:29:01 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 17 Dec 2002 11:29:01 +0100 Subject: error installing ldapmodule1.8 In-Reply-To: <029b01c2a5b5$b5c20450$3b01a8c0@zeomega.org> References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <029b01c2a5b5$b5c20450$3b01a8c0@zeomega.org> Message-ID: <3DFEFC6D.40003@stroeder.com> Rakesh Naidu wrote: > > do you think python-ldap 2.0.0pre05...should work fine with openldap 2.0.12 > > and also will python-ldap 2.0.0pre06 work fine with openldap 2.0.12 > > coz as of now i have asked my client's sys admin to instal python-ldap > 2.0.0pre05 I'd strongly recommend 2.0.0pre06 with very recent OpenLDAP 2.0.x or 2.1.x libs. Try to convince your sys admin. Or try to compile it in your home directory and build an RPM with 'python setup bist_rpm'. Ciao, Michael. From rnaidu at zeomega.com Tue Dec 17 12:14:46 2002 From: rnaidu at zeomega.com (Rakesh Naidu) Date: Tue, 17 Dec 2002 16:44:46 +0530 Subject: error installing ldapmodule1.8 References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> Message-ID: <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> michael...can u throw some light on this error..... 2002-12-17T10:50:45 ERROR(200) Zope Could not import Products.LDAPUserFolder Traceback (innermost last): File /home/zeo/Zope-2.5.1-linux2-x86/lib/python/OFS/Application.py, line 531, in import_product File /home/zeo/zope/lib/python/Products/LDAPUserFolder/__init__.py, line 13, in ? File /home/zeo/zope/lib/python/Products/LDAPUserFolder/LDAPUserFolder.py, line 34, in ? File /home/zeo/zope/lib/python/Products/LDAPUserFolder/LDAPUser.py, line 19, in ? (Object: aq_inner) File /home/zeo/zope/lib/python/Products/LDAPUserFolder/utils.py, line 32, in ? ImportError: No module named ldap as of now python-ldap 2.0.0pre05 / OpenLDAP 2.0.12 /on SuSe Linux (on client machine)..... your suggestions are welcome.....please confirm if upgradation to OpenLDAP 2.0.13 is a must taking in to consideration the above conf. thanks, Rakesh Naidu. ----- Original Message ----- From: "Michael Str?der" To: "Ganesan R" Cc: "python-ldap" Sent: Tuesday, December 17, 2002 4:02 PM Subject: Re: error installing ldapmodule1.8 Ganesan R wrote: >>>>>>"Michael" == Michael Str?der writes: > >>Please go for python-ldap 2.0.0pre06 compiled against OpenLDAP 2.x >>libs. 1.8 is pretty ancient. > > Is OpenLDAP 2.0 supported? Not only supported. Since python-ldap 2.x OpenLDAP 2.x is REQUIRED. > I faced some problems compiling python-ldap with > it. Which version of python-ldap? Which version of OpenLDAP? AFAIK you need at least OpenLDAP 2.0.13 when building with TLS support. Ciao, Michael. From michael at stroeder.com Tue Dec 17 11:32:10 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 17 Dec 2002 11:32:10 +0100 Subject: error installing ldapmodule1.8 In-Reply-To: References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> Message-ID: <3DFEFD2A.30506@stroeder.com> Ganesan R wrote: >>>>>>"Michael" == Michael Str?der writes: > >>Please go for python-ldap 2.0.0pre06 compiled against OpenLDAP 2.x >>libs. 1.8 is pretty ancient. > > Is OpenLDAP 2.0 supported? Not only supported. Since python-ldap 2.x OpenLDAP 2.x is REQUIRED. > I faced some problems compiling python-ldap with > it. Which version of python-ldap? Which version of OpenLDAP? AFAIK you need at least OpenLDAP 2.0.13 when building with TLS support. Ciao, Michael. From rganesan at myrealbox.com Tue Dec 17 12:05:46 2002 From: rganesan at myrealbox.com (Ganesan R) Date: 17 Dec 2002 16:35:46 +0530 Subject: error installing ldapmodule1.8 In-Reply-To: <3DFEFD2A.30506@stroeder.com> References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> Message-ID: >>>>> "Michael" == Michael Str?der writes: > Ganesan R wrote: >> Is OpenLDAP 2.0 supported? > Not only supported. Since python-ldap 2.x OpenLDAP 2.x is REQUIRED. >> I faced some problems compiling python-ldap with >> it. > Which version of python-ldap? pre6. > Which version of OpenLDAP? AFAIK you need at least OpenLDAP 2.0.13 > when building with TLS support. OpenLDAP 2.0.25. The verified that the problem is still present with with the "full-featured" build. I checked the mailing list and found the reason for my problem - "full-featured" build uses ldap_r which appears to be broken with OpenLDAP 2.0.* versions (at least till 2.0.25). By the way, I had a funny experience dealing with this problem. The error message said cannot find symbol ldap_first_reference. For some reason, I assumed that python is complaining about not able to resolve the first reference in the LDAP library and went about debugging with ldd :-) :-). Finally, I realized that it's the name of an actual symbol! By the way, I am extremely pleased with python-ldap. I have always been reluctant to code to the C API and even when I started using python, I used initially the external tools like ldapsearch and ldapmodify. Then I found python-ldap. It has really made LDAP programming a breeze. Thanks a lot! Ganesan -- Ganesan R From rganesan at myrealbox.com Tue Dec 17 12:21:05 2002 From: rganesan at myrealbox.com (Ganesan R) Date: 17 Dec 2002 16:51:05 +0530 Subject: error installing ldapmodule1.8 In-Reply-To: Message-ID: Hi, 2.0.0pre6. First, the binary rpm depends on python-devel and openldap-devel which are not needed. python-devel and openldap-devel should be in BuildRequires, not in Requires or Prereq lines of the spec file. Second, I need SSL support which doesn't seem to be enabled by default. Is it possible to turn on SSL support by default? Thanks. Ganesan -- Ganesan R From michael at stroeder.com Tue Dec 17 12:22:46 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 17 Dec 2002 12:22:46 +0100 Subject: error installing ldapmodule1.8 In-Reply-To: <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> Message-ID: <3DFF0906.10900@stroeder.com> Rakesh Naidu wrote: > michael...can u throw some light on this error..... > > 2002-12-17T10:50:45 ERROR(200) Zope Could not import Products.LDAPUserFolder > Traceback (innermost last): > [..] > ImportError: No module named ldap This was recently discussed here. I've attached a posting by Jens before he has to repeat it. Furthermore you can search the mailing list archive for 'Zope'. Ciao, Michael -------- Original Message -------- Subject: Re: Problems importing ldap in Zope Date: Fri, 29 Nov 2002 20:12:57 -0500 From: Jens Vagelpohl To: Jorge Loureiro Dias CC: python-ldap-dev at lists.sourceforge.net this problem has nothing to do with zope. the ldap module zope is trying to import is messed up. the one zope is trying to import is most likely not the same one that gets imported if you run python itself from the command line. you need to locate the exact python binary zope uses and rebuild the python-ldap module with that binary. jens From michael at stroeder.com Tue Dec 17 12:35:33 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 17 Dec 2002 12:35:33 +0100 Subject: error installing ldapmodule1.8 In-Reply-To: References: Message-ID: <3DFF0C05.2000904@stroeder.com> Ganesan R wrote: > > 2.0.0pre6. First, the binary rpm depends on python-devel and openldap-devel > which are not needed. python-devel and openldap-devel should be in > BuildRequires, not in Requires or Prereq lines of the spec file. Note that you have to contact the package maintainer if you think something's wrong with dependencies of a particular package. > Second, I need SSL support which doesn't seem to be enabled by default. Is > it possible to turn on SSL support by default? What do you mean with "by default"? If you build python-ldap yourself you can tweak setup.cfg to reflect your needs and configuration. Note that OpenLDAP also has to be built and installed with option --with-tls before. When shipping python-ldap one cannot foresee your particular system configuration. Ciao, Michael. From rganesan at myrealbox.com Tue Dec 17 12:51:16 2002 From: rganesan at myrealbox.com (Ganesan R) Date: 17 Dec 2002 17:21:16 +0530 Subject: error installing ldapmodule1.8 In-Reply-To: <3DFF0C05.2000904@stroeder.com> References: <3DFF0C05.2000904@stroeder.com> Message-ID: >>>>> "Michael" == Michael Str?der writes: > Ganesan R wrote: >> 2.0.0pre6. First, the binary rpm depends on python-devel and >> openldap-devel which are not needed. python-devel and openldap-devel >> should be in BuildRequires, not in Requires or Prereq lines of the spec >> file. > Note that you have to contact the package maintainer if you think > something's wrong with dependencies of a particular package. Noted :-). I assumed that the maintainer will be reading the list. I remember seeing his mails in the archive. >> Second, I need SSL support which doesn't seem to be enabled by >> default. Is it possible to turn on SSL support by default? > What do you mean with "by default"? > If you build python-ldap yourself you can tweak setup.cfg to reflect > your needs and configuration. Note that OpenLDAP also has to be built > and installed with option --with-tls before. When shipping python-ldap > one cannot foresee your particular system configuration. I didn't mean python-ldap distribution to turn on SSL by default. Redhat 7.3 OpenLDAP libraries ship with SSL option compiled in. So it makes sense for the RPM to be built with the option turned on. Again, this is an issue for the package maintainer. -- Ganesan R From michael at stroeder.com Tue Dec 17 12:54:10 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 17 Dec 2002 12:54:10 +0100 Subject: error installing ldapmodule1.8 In-Reply-To: <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> Message-ID: <3DFF1062.7080002@stroeder.com> Rakesh Naidu wrote: > > please confirm if upgradation to OpenLDAP > 2.0.13 is a must taking in to consideration the above conf. I'd even recommend that you SHOULD use the latest and greatest of the OpenLDAP libs since the OpenLDAP project applied numerous bug fixes to the client libs since 2.0.13. Ciao, Michael. From rnaidu at zeomega.com Tue Dec 17 15:32:42 2002 From: rnaidu at zeomega.com (Rakesh Naidu) Date: Tue, 17 Dec 2002 20:02:42 +0530 Subject: error installing ldapmodule1.8 References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> <3DFF1062.7080002@stroeder.com> Message-ID: <046d01c2a5d9$28cb17c0$3b01a8c0@zeomega.org> michael, do you you if ldapmodule-1.8 confirms to teh RFC1823 standards.. thanks rakesh ----- Original Message ----- From: "Michael Str?der" To: "Rakesh Naidu" Cc: "python-ldap" Sent: Tuesday, December 17, 2002 5:24 PM Subject: Re: error installing ldapmodule1.8 > Rakesh Naidu wrote: > > > > please confirm if upgradation to OpenLDAP > > 2.0.13 is a must taking in to consideration the above conf. > > I'd even recommend that you SHOULD use the latest and greatest of the > OpenLDAP libs since the OpenLDAP project applied numerous bug fixes to the > client libs since 2.0.13. > > Ciao, Michael. > > From michael at stroeder.com Tue Dec 17 16:04:28 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 17 Dec 2002 16:04:28 +0100 Subject: error installing ldapmodule1.8 In-Reply-To: <046d01c2a5d9$28cb17c0$3b01a8c0@zeomega.org> References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> <3DFF1062.7080002@stroeder.com> <046d01c2a5d9$28cb17c0$3b01a8c0@zeomega.org> Message-ID: <3DFF3CFC.4010702@stroeder.com> Rakesh Naidu wrote: > do you you if ldapmodule-1.8 confirms to teh RFC1823 standards.. Since python-ldap is a Python module it cannot be compliant to RFC 1823 which specifies a LDAP C API. It can only be inspired by it. Also note that all LDAP C APIs available shifted away from RFC 1823 since it does not cover newer features. Most remarkable for python-ldap 2.0.x is that OpenLDAP 2.x implements draft-ietf-ldapext-ldap-c-api. This draft is expired though. Ciao, Michael. From steffen.ries at sympatico.ca Tue Dec 17 14:59:39 2002 From: steffen.ries at sympatico.ca (Steffen Ries) Date: Tue, 17 Dec 2002 08:59:39 -0500 Subject: Remove code for set_rebind_proc() in LDAPObject.c? In-Reply-To: Michael =?iso-8859-1?q?Str=F6der's?= message of "Mon, 16 Dec 2002 07:30:48 +0100" References: <3DFD7318.6050408@stroeder.com> Message-ID: <20021217135939.KQBP28091.tomts16-srv.bellnexxia.net@gondolin.beleriand> Michael Str?der writes: > HI! > > Anyone in favour of re-enabling method set_rebind_proc()? Well, I am. To be exact. I am interested in the functionality provided by set_rebind_proc, not necessarily in its implementation. > It has been disabled quite a while ago and I would like to remove > the code from LDAPObject.c. Callbacks are pretty un-pythonic and the > functionality can be better achieved in a Python wrapper class. The last time I looked into this issue, I did not see an easy way how to build a wrapper class which encapsulates the rebinding. Do you have more ideas in this direction? I'm not sure when I'll find the time to work on this, but I may be able to contribute an implementation. > If someone really needs it he/she should volunteer maintaining it > according to changes which might have been made in recent versions of > OpenLDAP 2.x. I currently use an implementation that is backward compatible with OpenLDAP 1.x. The main reason is my application works both on Unix and WinNT. Since I don't actively support WinNT (esp. I don't have the infrastructure to build C-Code on NT), I depend on pre-built packages. The last time I checked, I didn't find any python-ldap-2.x package for windows. /steffen -- steffen.ries at sympatico.ca <> Gravity is a myth -- the Earth sucks! From michael at stroeder.com Tue Dec 17 16:19:30 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 17 Dec 2002 16:19:30 +0100 Subject: Remove code for set_rebind_proc() in LDAPObject.c? In-Reply-To: <20021217135939.KQBP28091.tomts16-srv.bellnexxia.net@gondolin.beleriand> References: <3DFD7318.6050408@stroeder.com> <20021217135939.KQBP28091.tomts16-srv.bellnexxia.net@gondolin.beleriand> Message-ID: <3DFF4082.5040209@stroeder.com> Steffen Ries wrote: > Michael Str?der writes: > > >Anyone in favour of re-enabling method set_rebind_proc()? > > Well, I am. > > To be exact. I am interested in the functionality provided by > set_rebind_proc, not necessarily in its implementation. This translates to: No problem to remove the related code from LDAPObject.c. >>It has been disabled quite a while ago and I would like to remove >>the code from LDAPObject.c. Callbacks are pretty un-pythonic and the >>functionality can be better achieved in a Python wrapper class. > > The last time I looked into this issue, I did not see an easy way how > to build a wrapper class which encapsulates the rebinding. Do you > have more ideas in this direction? I'm not sure when I'll find the > time to work on this, but I may be able to contribute an > implementation. Derive from ldap.ldapobject.LDAPObject and override all the relevant methods. I have a bunch of ideas like this. But I have to make up my mind how to implement these without stacking to many classes above each other. Maybe some kind of mix-in classes would help. One could think of a registration dictionary for exception handlers. > I currently use an implementation that is backward compatible with > OpenLDAP 1.x. You're own your own with that. > I didn't find any python-ldap-2.x > package for windows. Contributions welcome. Ciao, Michael. From jlittle at open-it.org Tue Dec 17 16:54:33 2002 From: jlittle at open-it.org (Joe Little) Date: Tue, 17 Dec 2002 07:54:33 -0800 Subject: error installing ldapmodule1.8 In-Reply-To: Message-ID: The maintainer (perhaps me) does read this list, but generally sleeps at the hours being discussed :) A classify python-ldap as Group: Development/Library so I have it depend on openldap-devel and other -devel level packages. Among other things, it builds against dynamic libraries would I just saw are present in both the openldap base and openldap-devel packages. Either way, you can convince me that these should simply be build prereqs. I assume that you'd want to have all the .h files (and openldap drafts) around for reference when building ldap tools with python since at times the python documentation is not complete. You are right that python-devel is probably not needed anymore. On Tuesday, December 17, 2002, at 03:51 AM, Ganesan R wrote: >>>>>> "Michael" == Michael Str?der writes: > >> Ganesan R wrote: >>> 2.0.0pre6. First, the binary rpm depends on python-devel and >>> openldap-devel which are not needed. python-devel and openldap-devel >>> should be in BuildRequires, not in Requires or Prereq lines of the >>> spec >>> file. > >> Note that you have to contact the package maintainer if you think >> something's wrong with dependencies of a particular package. > > Noted :-). I assumed that the maintainer will be reading the list. I > remember seeing his mails in the archive. > >>> Second, I need SSL support which doesn't seem to be enabled by >>> default. Is it possible to turn on SSL support by default? > >> What do you mean with "by default"? > >> If you build python-ldap yourself you can tweak setup.cfg to reflect >> your needs and configuration. Note that OpenLDAP also has to be built >> and installed with option --with-tls before. When shipping python-ldap >> one cannot foresee your particular system configuration. > > I didn't mean python-ldap distribution to turn on SSL by default. > Redhat 7.3 > OpenLDAP libraries ship with SSL option compiled in. So it makes sense > for > the RPM to be built with the option turned on. Again, this is an issue > for > the package maintainer. > > -- > Ganesan R > > > From jlittle at open-it.org Tue Dec 17 17:18:34 2002 From: jlittle at open-it.org (Joe Little) Date: Tue, 17 Dec 2002 08:18:34 -0800 Subject: error installing ldapmodule1.8 In-Reply-To: Message-ID: <30F0851D-11DB-11D7-B045-0003935417AE@open-it.org> corrections in my english below (just woke up) On Tuesday, December 17, 2002, at 07:54 AM, Joe Little wrote: > The maintainer (perhaps me) does read this list, but generally sleeps > at the hours being discussed :) > > I classify python-ldap as Group: Development/Library so I have it > depend on openldap-devel and other -devel level packages. Among other > things, it builds against dynamic libraries which I just saw are > present in both the openldap base and openldap-devel packages. Either > way, you can convince me that these should simply be build prereqs. I > assume that you'd want to have all the .h files (and openldap drafts) > around for reference when building ldap tools with python since at > times the python documentation is not complete. You are right that > python-devel is probably not needed anymore. > > On Tuesday, December 17, 2002, at 03:51 AM, Ganesan R wrote: > >>>>>>> "Michael" == Michael Str?der writes: >> >>> Ganesan R wrote: >>>> 2.0.0pre6. First, the binary rpm depends on python-devel and >>>> openldap-devel which are not needed. python-devel and openldap-devel >>>> should be in BuildRequires, not in Requires or Prereq lines of the >>>> spec >>>> file. >> >>> Note that you have to contact the package maintainer if you think >>> something's wrong with dependencies of a particular package. >> >> Noted :-). I assumed that the maintainer will be reading the list. I >> remember seeing his mails in the archive. >> >>>> Second, I need SSL support which doesn't seem to be enabled by >>>> default. Is it possible to turn on SSL support by default? >> >>> What do you mean with "by default"? >> >>> If you build python-ldap yourself you can tweak setup.cfg to reflect >>> your needs and configuration. Note that OpenLDAP also has to be built >>> and installed with option --with-tls before. When shipping >>> python-ldap >>> one cannot foresee your particular system configuration. >> >> I didn't mean python-ldap distribution to turn on SSL by default. >> Redhat 7.3 >> OpenLDAP libraries ship with SSL option compiled in. So it makes >> sense for >> the RPM to be built with the option turned on. Again, this is an >> issue for >> the package maintainer. >> >> -- >> Ganesan R >> >> >> From rganesan at myrealbox.com Wed Dec 18 05:05:23 2002 From: rganesan at myrealbox.com (Ganesan R) Date: 18 Dec 2002 09:35:23 +0530 Subject: error installing ldapmodule1.8 In-Reply-To: <30F0851D-11DB-11D7-B045-0003935417AE@open-it.org> References: <30F0851D-11DB-11D7-B045-0003935417AE@open-it.org> Message-ID: >>>>> "Joe" == Joe Little writes: > The maintainer (perhaps me) does read this list, but generally > sleeps at the hours being discussed :) That's a problem we'll have to live with I guess :-). > I classify python-ldap as Group: Development/Library so I have it depend > on openldap-devel and other -devel level packages. Among other things, it > builds against dynamic libraries which I just saw are present in both the > openldap base and openldap-devel packages. Either way, you can convince > me that these should simply be build prereqs. I guess you need convincing only on the openldap-devel package :-). Let me try. For C libraries a "library" package (the openldap package in this case) and a "devel" package make sense. The devel package usually contains the needed headers and archive libraries in case applications need to link statically. End users, i.e. users who use applications linked to OpenLDAP do not need to install -devel packages. For python (and java), the distinction does not exist. As a developer, I obviously will install openldap-devel for looking at the documentation or for developing C applications. However, the end user installing my python-ldap application should not need to install openldap-devel. Thank you very much for packaging python-ldap rpm. I am a Debian developer but use Redhat at work. Your work saved me a lot of time :-). Ganesan -- Ganesan R From jlittle at open-it.org Wed Dec 18 06:17:05 2002 From: jlittle at open-it.org (Joe Little) Date: Tue, 17 Dec 2002 21:17:05 -0800 Subject: error installing ldapmodule1.8 In-Reply-To: Message-ID: Ok.. though I think having the c headers/docs around is a good thing for python-ldap developers, I have relaxed the dependencies and made a better distinction between dependencies and prereqs (the latter provides ordering, required for python site-packages) You'll find new python-ldap RPM/SRPMS for RedHat 7.3 and 8.0 on ftp.open-it.org Enjoy. On Tuesday, December 17, 2002, at 08:05 PM, Ganesan R wrote: >>>>>> "Joe" == Joe Little writes: > >> The maintainer (perhaps me) does read this list, but generally >> sleeps at the hours being discussed :) > > That's a problem we'll have to live with I guess :-). > >> I classify python-ldap as Group: Development/Library so I have it >> depend >> on openldap-devel and other -devel level packages. Among other >> things, it >> builds against dynamic libraries which I just saw are present in both >> the >> openldap base and openldap-devel packages. Either way, you can >> convince >> me that these should simply be build prereqs. > > I guess you need convincing only on the openldap-devel package :-). > Let me > try. For C libraries a "library" package (the openldap package in this > case) > and a "devel" package make sense. The devel package usually contains > the > needed headers and archive libraries in case applications need to link > statically. End users, i.e. users who use applications linked to > OpenLDAP do > not need to install -devel packages. > > For python (and java), the distinction does not exist. As a > developer, I > obviously will install openldap-devel for looking at the documentation > or > for developing C applications. However, the end user installing my > python-ldap application should not need to install openldap-devel. > > Thank you very much for packaging python-ldap rpm. I am a Debian > developer > but use Redhat at work. Your work saved me a lot of time :-). > > Ganesan > > -- > Ganesan R > > > > From rganesan at myrealbox.com Tue Dec 17 13:00:56 2002 From: rganesan at myrealbox.com (Ganesan R) Date: 17 Dec 2002 17:30:56 +0530 Subject: Comment on documentation In-Reply-To: <3DFD7318.6050408@stroeder.com> Message-ID: Hi, The documentation for the LDAP add operation reads (See http://python-ldap.sourceforge.net/doc/python-ldap/node11.html) ------ add(dn, modlist) add_s(dn, modlist) This function is similar to modify(), except that the operation integer is omitted from the tuples in modlist. You might want to like into sub-module ldap.modlist for generating modlist. ------ Apart from the typo there (like into sub-module instead of look into sub-module), the description seems to imply that add is a short cut for modify with LDAP_MOD_ADD. I'd change that to add(dn, modlist) add_s(dn, modlist) Performs an LDAP add operation on dn. The dn argument is the distinguished name (DN) of the entry to add, and addlist is a list of attributes to be added. The modlist is similar the one passed to modify(), except that the operation integer is omitted from the tuples in modlist. You might want to look into sub-module ldap.modlist for generating the modlist. Ganesan -- Ganesan R From michael at stroeder.com Wed Dec 18 16:53:19 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 18 Dec 2002 16:53:19 +0100 Subject: Comment on documentation In-Reply-To: References: Message-ID: <3E0099EF.9000103@stroeder.com> Ganesan R wrote: > add(dn, modlist) > add_s(dn, modlist) > > Performs an LDAP add operation on dn. The dn argument is the distinguished > name (DN) of the entry to add, and addlist is a list of attributes to be > added. The modlist is similar the one passed to modify(), except that the > operation integer is omitted from the tuples in modlist. You might want to > look into sub-module ldap.modlist for generating the modlist. Ok. Ciao, Michael. From michael at stroeder.com Wed Dec 18 16:53:19 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 18 Dec 2002 16:53:19 +0100 Subject: Comment on documentation In-Reply-To: References: Message-ID: <3E0099EF.9000103@stroeder.com> Ganesan R wrote: > add(dn, modlist) > add_s(dn, modlist) > > Performs an LDAP add operation on dn. The dn argument is the distinguished > name (DN) of the entry to add, and addlist is a list of attributes to be > added. The modlist is similar the one passed to modify(), except that the > operation integer is omitted from the tuples in modlist. You might want to > look into sub-module ldap.modlist for generating the modlist. Ok. Ciao, Michael. From rnaidu at zeomega.com Fri Dec 20 13:54:40 2002 From: rnaidu at zeomega.com (Rakesh Naidu) Date: Fri, 20 Dec 2002 18:24:40 +0530 Subject: ldap_ufn_setfilter References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> <3DFF0906.10900@stroeder.com> Message-ID: <068a01c2a826$f61c7940$3b01a8c0@zeomega.org> hi micheal, i am getting this error now... do you know why this is... ImportError: /home/zeo/zope/lib/python/Products/LDAPUserFolder/_ldapmodule.so: undefined symbol: ldap_ufn_setfilter regards, Rakesh. ----- Original Message ----- From: "Michael Str?der" To: "Rakesh Naidu" Cc: "python-ldap" Sent: Tuesday, December 17, 2002 4:52 PM Subject: Re: error installing ldapmodule1.8 > Rakesh Naidu wrote: > > michael...can u throw some light on this error..... > > > > 2002-12-17T10:50:45 ERROR(200) Zope Could not import Products.LDAPUserFolder > > Traceback (innermost last): > > [..] > > ImportError: No module named ldap > > This was recently discussed here. I've attached a posting by Jens before he > has to repeat it. > > Furthermore you can search the mailing list archive for 'Zope'. > > Ciao, Michael > > -------- Original Message -------- > Subject: Re: Problems importing ldap in Zope > Date: Fri, 29 Nov 2002 20:12:57 -0500 > From: Jens Vagelpohl > To: Jorge Loureiro Dias > CC: python-ldap-dev at lists.sourceforge.net > > this problem has nothing to do with zope. the ldap module zope is > trying to import is messed up. the one zope is trying to import is most > likely not the same one that gets imported if you run python itself > from the command line. > > you need to locate the exact python binary zope uses and rebuild the > python-ldap module with that binary. > > jens > > > > From michael at stroeder.com Fri Dec 20 16:37:47 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 20 Dec 2002 16:37:47 +0100 Subject: ldap_ufn_setfilter In-Reply-To: <068a01c2a826$f61c7940$3b01a8c0@zeomega.org> References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> <3DFF0906.10900@stroeder.com> <068a01c2a826$f61c7940$3b01a8c0@zeomega.org> Message-ID: <3E03394B.5060501@stroeder.com> Rakesh Naidu wrote: > ImportError: > /home/zeo/zope/lib/python/Products/LDAPUserFolder/_ldapmodule.so: undefined > symbol: ldap_ufn_setfilter Which version of python-ldap are you using and which LDAP lib? The filename _ldapmodule.so looks like 1.x but the UFN-related functions/methods were removed in 2.x. Ciao, Michael. From rnaidu at zeomega.com Fri Dec 20 17:31:51 2002 From: rnaidu at zeomega.com (Rakesh Naidu) Date: Fri, 20 Dec 2002 22:01:51 +0530 Subject: ldap_ufn_setfilter References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> <3DFF0906.10900@stroeder.com> <068a01c2a826$f61c7940$3b01a8c0@zeomega.org> <3E03394B.5060501@stroeder.com> Message-ID: <073501c2a845$4cf54f30$3b01a8c0@zeomega.org> python-ldap 2.0.0pre05 and libldap.so.2 ----- Original Message ----- From: "Michael Str?der" To: "Rakesh Naidu" Cc: "Python Developer List" Sent: Friday, December 20, 2002 9:07 PM Subject: Re: ldap_ufn_setfilter > Rakesh Naidu wrote: > > ImportError: > > /home/zeo/zope/lib/python/Products/LDAPUserFolder/_ldapmodule.so: undefined > > symbol: ldap_ufn_setfilter > > Which version of python-ldap are you using and which LDAP lib? > > The filename _ldapmodule.so looks like 1.x but the UFN-related > functions/methods were removed in 2.x. > > Ciao, Michael. > > > > From rnaidu at zeomega.com Fri Dec 20 17:42:32 2002 From: rnaidu at zeomega.com (Rakesh Naidu) Date: Fri, 20 Dec 2002 22:12:32 +0530 Subject: ldap_ufn_setfilter References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> <3DFF0906.10900@stroeder.com> <068a01c2a826$f61c7940$3b01a8c0@zeomega.org> <3E03394B.5060501@stroeder.com> <073501c2a845$4cf54f30$3b01a8c0@zeomega.org> <3E0345FC.6080705@stroeder.com> Message-ID: <075601c2a846$cb298c30$3b01a8c0@zeomega.org> libldap.so.2 => /usr/lib/libldap.so.2 (0x40020000) liblber.so.2 => /usr/lib/liblber.so.2 (0x40049000) libm.so.6 => /lib/libm.so.6 (0x40053000) libc.so.6 => /lib/libc.so.6 (0x40075000) libnsl.so.1 => /lib/libnsl.so.1 (0x4019b000) libresolv.so.2 => /lib/libresolv.so.2 (0x401b2000) libdl.so.2 => /lib/libdl.so.2 (0x401c4000) libsasl.so.7 => /usr/lib/libsasl.so.7 (0x401c8000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x401d3000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x40200000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) libdb-3.1.so => /usr/lib/libdb-3.1.so (0x402c9000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40346000) libpam.so.0 => /lib/libpam.so.0 (0x40374000) ----- Original Message ----- From: "Michael Str?der" To: "Rakesh Naidu" Cc: "Python Developer List" Sent: Friday, December 20, 2002 10:01 PM Subject: Re: ldap_ufn_setfilter > Rakesh Naidu wrote: > > python-ldap 2.0.0pre05 and libldap.so.2 > > Really strange. I don't believe the _ldapmodule.so is compiled from > python-ldap 2.0.0pre05 sources. > > Is there a library mixture? Maybe an old python-ldap 1.x installation? What does > > $ ldd home/zeo/zope/lib/python/Products/LDAPUserFolder/_ldapmodule.so > > say? > > Is there also a file called _ldap.so? > > Ciao, Michael. > > > > From michael at stroeder.com Fri Dec 20 17:31:56 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 20 Dec 2002 17:31:56 +0100 Subject: ldap_ufn_setfilter In-Reply-To: <073501c2a845$4cf54f30$3b01a8c0@zeomega.org> References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> <3DFF0906.10900@stroeder.com> <068a01c2a826$f61c7940$3b01a8c0@zeomega.org> <3E03394B.5060501@stroeder.com> <073501c2a845$4cf54f30$3b01a8c0@zeomega.org> Message-ID: <3E0345FC.6080705@stroeder.com> Rakesh Naidu wrote: > python-ldap 2.0.0pre05 and libldap.so.2 Really strange. I don't believe the _ldapmodule.so is compiled from python-ldap 2.0.0pre05 sources. Is there a library mixture? Maybe an old python-ldap 1.x installation? What does $ ldd home/zeo/zope/lib/python/Products/LDAPUserFolder/_ldapmodule.so say? Is there also a file called _ldap.so? Ciao, Michael. From michael at stroeder.com Fri Dec 20 17:50:36 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 20 Dec 2002 17:50:36 +0100 Subject: ldap_ufn_setfilter In-Reply-To: <3E0345FC.6080705@stroeder.com> References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> <3DFF0906.10900@stroeder.com> <068a01c2a826$f61c7940$3b01a8c0@zeomega.org> <3E03394B.5060501@stroeder.com> <073501c2a845$4cf54f30$3b01a8c0@zeomega.org> <3E0345FC.6080705@stroeder.com> Message-ID: <3E034A5C.7020409@stroeder.com> Michael Str?der wrote: > Rakesh Naidu wrote: > >> python-ldap 2.0.0pre05 and libldap.so.2 > > Really strange. I digged into the mailing list archive and it seems that this problem was solved quite a while ago. Please go for python-ldap 2.0.0pre06. Ciao, Michael. From rnaidu at zeomega.com Sat Dec 21 09:32:00 2002 From: rnaidu at zeomega.com (Rakesh Naidu) Date: Sat, 21 Dec 2002 14:02:00 +0530 Subject: ldap_ufn_setfilter References: <01f701c2a5ad$59f63c70$3b01a8c0@zeomega.org> <3DFEECE3.2080903@stroeder.com> <3DFEFD2A.30506@stroeder.com> <02dd01c2a5bd$81e27860$3b01a8c0@zeomega.org> <3DFF0906.10900@stroeder.com> <068a01c2a826$f61c7940$3b01a8c0@zeomega.org> <3E03394B.5060501@stroeder.com> Message-ID: <083201c2a8cb$6e87dba0$3b01a8c0@zeomega.org> well this was solved when i copied the /zope/lib/python2.1/site-packages folder with the /usr/lib/python2.1/site-packages which basically has the ldapmodule which is written when pythin-ldap is compiled..... thanks, michael.. ----- Original Message ----- From: "Michael Str?der" To: "Rakesh Naidu" Cc: "Python Developer List" Sent: Friday, December 20, 2002 9:07 PM Subject: Re: ldap_ufn_setfilter > Rakesh Naidu wrote: > > ImportError: > > /home/zeo/zope/lib/python/Products/LDAPUserFolder/_ldapmodule.so: undefined > > symbol: ldap_ufn_setfilter > > Which version of python-ldap are you using and which LDAP lib? > > The filename _ldapmodule.so looks like 1.x but the UFN-related > functions/methods were removed in 2.x. > > Ciao, Michael. > > > > From jens at zope.com Tue Dec 24 16:02:46 2002 From: jens at zope.com (Jens Vagelpohl) Date: Tue, 24 Dec 2002 10:02:46 -0500 Subject: python-ldap and updateref Message-ID: for one of my python-ldap-based applications i am trying to make it behave correctly in a situation where it is talking to a slave that wants to defer to a master for certain updates. i have done some testing by setting up a master and slave and using the "updateref" directive in the slave's slapd.conf. according to the OpenLDAP documentation that should cause the slave to hand back the URI designated in the updateref directive if someone attempts a write. however, it doesn't seem to work, at least from python-ldap. i can modify records on the slave all day long and it does not hand back the master's URI. at the python prompt, after binding with a suitable DN i also do... conn.set_option(ldap.OPT_DEREF, ldap.DEREF_ALWAYS) but this does not seem to make a change. does anyone have this working with python-ldap? is my slave server configured incorrectly? jens From michael at stroeder.com Tue Dec 24 16:11:22 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 24 Dec 2002 16:11:22 +0100 Subject: python-ldap and updateref In-Reply-To: References: Message-ID: <3E08791A.4020203@stroeder.com> Jens Vagelpohl wrote: > > i have done some testing by setting up a master and slave and using the > "updateref" directive in the slave's slapd.conf. according to the > OpenLDAP documentation that should cause the slave to hand back the URI > designated in the updateref directive if someone attempts a write. > [..] > conn.set_option(ldap.OPT_DEREF, ldap.DEREF_ALWAYS) This option is for setting alias dereferencing which is something different. > but this does not seem to make a change. Maybe the OpenLDAP lib handles the referral internally and already changes the entry on your master? If you don't want to let the OpenLDAP lib handle the referral you have to use: conn.set_option(ldap.OPT_REFERRALS,0) Ciao, Michael. From jens at zope.com Tue Dec 24 16:26:06 2002 From: jens at zope.com (Jens Vagelpohl) Date: Tue, 24 Dec 2002 10:26:06 -0500 Subject: python-ldap and updateref In-Reply-To: <3E08791A.4020203@stroeder.com> Message-ID: <0553DC37-1754-11D7-9DD0-0003939EFEBC@zope.com> michael, i know for a fact that the referral is not handled internally, the entry on the master never gets changed. at this point i am not entirely sure if my slave is indeed configured correctly. i did read in some unrelated documentation that how the referral is handled differs based on the type of authentication you use. at this moment i am using a simple bind. jens P.S.: frohe weihnachten ;) On Tuesday, Dec 24, 2002, at 10:11 US/Eastern, Michael Str?der wrote: > Jens Vagelpohl wrote: >> i have done some testing by setting up a master and slave and using >> the "updateref" directive in the slave's slapd.conf. according to the >> OpenLDAP documentation that should cause the slave to hand back the >> URI designated in the updateref directive if someone attempts a >> write. >> [..] >> conn.set_option(ldap.OPT_DEREF, ldap.DEREF_ALWAYS) > > This option is for setting alias dereferencing which is something > different. > >> but this does not seem to make a change. > > Maybe the OpenLDAP lib handles the referral internally and already > changes the entry on your master? > > If you don't want to let the OpenLDAP lib handle the referral you have > to use: > > conn.set_option(ldap.OPT_REFERRALS,0) > > Ciao, Michael. > From jens at zope.com Tue Dec 24 16:48:36 2002 From: jens at zope.com (Jens Vagelpohl) Date: Tue, 24 Dec 2002 10:48:36 -0500 Subject: python-ldap and updateref In-Reply-To: <3E087E8B.5090907@stroeder.com> Message-ID: <29FC4A83-1757-11D7-9DD0-0003939EFEBC@zope.com> thanks a bunch, i am now getting the correct ldap.REFERRAL exception :) jens On Tuesday, Dec 24, 2002, at 10:34 US/Eastern, Michael Str?der wrote: > Jens Vagelpohl wrote: >> i know for a fact that the referral is not handled internally, the >> entry on the master never gets changed. at this point i am not >> entirely sure if my slave is indeed configured correctly. > > If you use > > conn.set_option(ldap.OPT_REFERRALS,0) > conn.manage_dsa_it(0) # this is the default > > and your server is configured correctly you should get an exception of > class ldap.REFERRAL. > >> P.S.: frohe weihnachten ;) > > Ah, yes. :-) > > Merry Christmas to all the list members and a happy New Year. > > Ciao, Michael. > From michael at stroeder.com Tue Dec 24 16:34:35 2002 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 24 Dec 2002 16:34:35 +0100 Subject: python-ldap and updateref In-Reply-To: <0553DC37-1754-11D7-9DD0-0003939EFEBC@zope.com> References: <0553DC37-1754-11D7-9DD0-0003939EFEBC@zope.com> Message-ID: <3E087E8B.5090907@stroeder.com> Jens Vagelpohl wrote: > > i know for a fact that the referral is not handled internally, the entry > on the master never gets changed. at this point i am not entirely sure > if my slave is indeed configured correctly. If you use conn.set_option(ldap.OPT_REFERRALS,0) conn.manage_dsa_it(0) # this is the default and your server is configured correctly you should get an exception of class ldap.REFERRAL. > P.S.: frohe weihnachten ;) Ah, yes. :-) Merry Christmas to all the list members and a happy New Year. Ciao, Michael. From jlittle at open-it.org Mon Dec 30 23:22:38 2002 From: jlittle at open-it.org (Joe Little) Date: Mon, 30 Dec 2002 14:22:38 -0800 Subject: further python-ldap RPM updates Message-ID: <347BFE54-1C45-11D7-BB3A-0003935417AE@open-it.org> Another bug crept into the RPMs I built. A patch suggested by rread has been accepted for the 7.3 and 8.0 editions of the python-ldap RPM. It addresses incorrect permissions on the schema subdirectory. Updated RPMs and SRPMs have been posted to ftp.open-it.org. I'll also be looking at using "distutil install" shortly to make sure it can interact well with the spec file usage or pythondir (used to specify the version to build against). Also, as soon as I dig out of the post holiday mess, I'm going to fulfill a promise to start tracking again the latest OpenLDAP packages, with an RPM of OpenLDAP 2.1.10.