You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(34) |
Mar
(9) |
Apr
|
May
(2) |
Jun
(14) |
Jul
(67) |
Aug
(34) |
Sep
(5) |
Oct
(20) |
Nov
(22) |
Dec
(31) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(15) |
Feb
(16) |
Mar
(20) |
Apr
(13) |
May
(72) |
Jun
(42) |
Jul
(41) |
Aug
(11) |
Sep
(19) |
Oct
(67) |
Nov
(59) |
Dec
(57) |
| 2002 |
Jan
(74) |
Feb
(69) |
Mar
(34) |
Apr
(55) |
May
(47) |
Jun
(74) |
Jul
(116) |
Aug
(68) |
Sep
(25) |
Oct
(42) |
Nov
(28) |
Dec
(52) |
| 2003 |
Jan
(19) |
Feb
(18) |
Mar
(35) |
Apr
(49) |
May
(73) |
Jun
(39) |
Jul
(26) |
Aug
(59) |
Sep
(33) |
Oct
(56) |
Nov
(69) |
Dec
(137) |
| 2004 |
Jan
(276) |
Feb
(15) |
Mar
(18) |
Apr
(27) |
May
(25) |
Jun
(7) |
Jul
(13) |
Aug
(2) |
Sep
(2) |
Oct
(10) |
Nov
(27) |
Dec
(28) |
| 2005 |
Jan
(22) |
Feb
(25) |
Mar
(41) |
Apr
(17) |
May
(36) |
Jun
(13) |
Jul
(22) |
Aug
(12) |
Sep
(23) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2006 |
Jan
(11) |
Feb
(3) |
Mar
(5) |
Apr
(22) |
May
(1) |
Jun
(10) |
Jul
(19) |
Aug
(7) |
Sep
(25) |
Oct
(23) |
Nov
(5) |
Dec
(27) |
| 2007 |
Jan
(25) |
Feb
(17) |
Mar
(44) |
Apr
(8) |
May
(33) |
Jun
(31) |
Jul
(42) |
Aug
(16) |
Sep
(12) |
Oct
(16) |
Nov
(23) |
Dec
(73) |
| 2008 |
Jan
(26) |
Feb
(6) |
Mar
(46) |
Apr
(17) |
May
(1) |
Jun
(44) |
Jul
(9) |
Aug
(34) |
Sep
(20) |
Oct
(2) |
Nov
(4) |
Dec
(16) |
| 2009 |
Jan
(14) |
Feb
(3) |
Mar
(45) |
Apr
(52) |
May
(34) |
Jun
(32) |
Jul
(24) |
Aug
(52) |
Sep
(22) |
Oct
(23) |
Nov
(19) |
Dec
(10) |
| 2010 |
Jan
(10) |
Feb
(13) |
Mar
(22) |
Apr
(9) |
May
(1) |
Jun
(1) |
Jul
(8) |
Aug
(9) |
Sep
(10) |
Oct
(1) |
Nov
(2) |
Dec
(3) |
| 2011 |
Jan
|
Feb
(18) |
Mar
(39) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <mi...@st...> - 2002-02-25 23:30:09
|
Joe Little wrote:
>
> When it
> explodes the DN out of my entry, its string result is:
>
> "(cn=whois\+\+)"
> [..]
> However, even before I explode it, I already see the DN is stored in my res
> as whois\+\+.
This is perfectly right. See RFC2253, section 2.4. After reading BNF in
section 3. you might be convinced that you're best bet is to handle DNs
as opaque. "+" is used to form multi-valued RDNs.
> Searching on this DN results in an ldap.FILTER_ERROR: {'desc':
> 'Bad search filter', 'info': ''}
Special chars in search filters are a different thing, see RFC2254.
> whois++ has been in /etc/services for quite some time.
I remember that there was a discussion about this very topic on one of
the OpenLDAP lists.
> So one of two things
> has happened:
>
> 1) python-ldap has changed behavior in some way (whether first pull of data
> or search filter usage)
>
> 2) MigrationTools (used to load up NIS type data to LDAP) from padl.com,
> which fixed certain things associated with + and other symbols, can load
> data correctly into LDAP with Perl ala PerLDAP and PythonLDAP doesn't
> support the same.
3) The LDAP libs/server requires proper escaping/handling DNs which
translates to "+" need to be escaped nowadays. The application using
python-ldap has to be fixed.
Ciao, Michael.
|
|
From: Joe L. <jl...@op...> - 2002-02-25 22:59:16
|
Hello all,
In my latest project, I am exercising various parts of the Python-LDAP in my
wrapper API to see that everything works. Back in June, I had two methods,
an ldap entry refresh() and a commit(). These worked without a hitch, and
against data such as /etc/service entries in LDAP. Now, I do get an error,
and perhaps someone can enlighten me on what has changed and why.
Specifically, there is an entry in /etc/services for whois++. My refresh()
method calls ldap.explode_dn(leaf_entry) whereby leaf_entry is an attr
dictionary ala what python-ldap normally results as results. When it
explodes the DN out of my entry, its string result is:
"(cn=whois\+\+)"
However, even before I explode it, I already see the DN is stored in my res
as whois\+\+. Searching on this DN results in an ldap.FILTER_ERROR: {'desc':
'Bad search filter', 'info': ''}
whois++ has been in /etc/services for quite some time. So one of two things
has happened:
1) python-ldap has changed behavior in some way (whether first pull of data
or search filter usage)
2) MigrationTools (used to load up NIS type data to LDAP) from padl.com,
which fixed certain things associated with + and other symbols, can load
data correctly into LDAP with Perl ala PerLDAP and PythonLDAP doesn't
support the same.
Perhaps Leif knows best :)
|
|
From: <mi...@st...> - 2002-02-23 14:22:42
|
Christian Wiese wrote: > > Am Freitag, 22. Februar 2002 19:26 schrieben Sie: > >>Christian Wiese wrote: >> >>> is there a way to get all possible attributes of an >>> objectclass with python-ldap? >>> >>Normally it's returned in the results if you do a normal search >>operation. > > I'm looking for a way to get the schema definitions out of an OpenLDAP > server, Sorry, I obviously misread your question. No, there's currently no support for parsing the subschemaSubentry in python-ldap. It's in the TODO. Feel free to contribute. I know that Jacek did some work for parsing subschema in his curses-based LDAP client. Ciao, Michael. |
|
From: Christian W. <chr...@we...> - 2002-02-23 13:55:22
|
Hello Michael, thank you for your reply. I'm looking for a way to get the schema definitions out of an OpenLDAP server, because I've extended my schema for special services like qmail and qmailControl, and I want to have a mechanism to get all the possible attributes of an objectclass out of a schema definition. It should not depending on if I used this objectclass allready. Thank you for you support. Greetings Christian Am Freitag, 22. Februar 2002 19:26 schrieben Sie: > Christian Wiese wrote: > > is there a way to get all possible attributes of an objectclass with > > python-ldap? > > Normally it's returned in the results if you do a normal search > operation. > > If it's not present in the entry's dictionary some ACLs might be in > effect which is very unlikely for objectClass attribute though. > > Ciao, Michael. |
|
From: Michael <mi...@st...> - 2002-02-22 18:27:00
|
Christian Wiese wrote: > > is there a way to get all possible attributes of an objectclass with > python-ldap? Normally it's returned in the results if you do a normal search operation. If it's not present in the entry's dictionary some ACLs might be in effect which is very unlikely for objectClass attribute though. Ciao, Michael. |
|
From: Christian W. <chr...@we...> - 2002-02-21 19:16:54
|
Hi All, is there a way to get all possible attributes of an objectclass with python-ldap? Greetings Christian |
|
From: John E. M. <jma...@ya...> - 2002-02-21 05:18:19
|
Michael, Thanks for your help. I have been documenting the process of installation on a Red Hat 7.2 system. This is the second machine I have installed on. This really consolidates the documentation and lack thereof of the process of installing everything web2ldap relies on. It is not yet complete, obviously. I have a couple of questions / problems / issues: 1) When I run it in Apache with mod_fastcgi, the first screen comes up, and from the first screen, I can log in, but, if I click on a link, like, say, "Bind", I get the following error sent to the browser: Session ID not found. Redirecting... 2) This is silly. When I run it in standalone mode, it works wonderfully locally, but when I try to access it from another machine on my local network, I get a "The page cannot be displayed" message. Any ideas? Thanks, and I hope my efforts in documentation are helpful to the cause. John P.S. The file is actually in html now. My notes on installing web2ldap on RedHat 7.2. Certain assumptions are made when not specifically stated otherwise, such as: you are root, the base subdirectory for working is the directory to which the downloads are saved, and Netscape Directory Server is installed. This document was meant for a wider audience than just the uber-technical, so please forgive any obvious instructions. 1) Install RedHat Linux 7.2. If web2ldap will be using the mod_fastcgi module in Apache, exclude the web server from the install (Apache), as it will need to be recompiled to include mod_fastcgi. 2) Obtain the following and save to a directory: ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.0.23.tgz http://prdownloads.sourceforge.net/python-ldap/python-ldap-2.0.0pre04.tar.gz http://www.stroeder.com/pylib/PyWebLib/download/pyweblib-1.1.0.tar.gz http://web2ldap.de/download/web2ldap-0.10.3.tar.gz 2a) There are two modes of operation of web2ldap: standalone, and with mod_fastcgi in Apache. If web2ldap is to be used with mod_fastcgi in Apache, the following should be saved to a directory: http://www.apache.org/dist/httpd/apache_1.3.23.tar.gz http://www.fastcgi.com/dist/mod_fastcgi-2.2.12.tar.gz http://alldunn.com/python/fcgi.py 2b) Depending on the options selected, either only Python 1.52 or Python 1.52 and Python 2.1 will be installed. If /usr/bin does not contain python2 and python2.1, download the following: ftp://ftp.python.org/pyb/python/2.2/Python-2.2.tgz 3) If necessary (see 2b above), install Python 2.2 by doing the following: tar zxvf Python-2.2.tgz cd Python-2.2 ./configure make make test /* optional, but suggested */ make install 4) Install PyWebLib by doing the following: tar zxvf pyweblib-1.1.0.tar.gz cd pyweblib-1.1.0.tar.gz /usr/local/bin/python setup.py install -O2 /* That is a capital "o" for optimization level. The path to Python 2.x needs to be specified */ 5) Since the web2ldap documentation suggests for RedHat "OpenLDAP (is) included with their Linux distribution" (which, for RedHat 7.2 is OpenLDAP 2.0.11), and, at the same time, "You have to grab a recent pre-release 2.0.0pre03 and build it against OpenLDAP 2.0.13+ libs" (contradictory), I suggest installing OpenLDAP 2.0.23 by doing the following: tar zxvf openldap-2.0.23.tgz cd openldap-2.0.23 ./configure make depend make make test /* optional, but suggested. Be prepared to wait or take Lunch. */ make install 6) Install python-ldap by doing the following: tar zxvf python-ldap-2.0.0pre04 cd python-ldap-2.0.0pre04 vi setup.cfg Modify the paths to the paths shown below. It may be possible to compile python-ldap against the compiled, but pre-installed OpenLDAP lib and include directories, but I haven't gone there yet. -------------------------------------------------------------- # Section for compiling the C extension module # for wrapping OpenLDAP 2 libs [_ldap] class = OpenLDAP2 library_dirs = /usr/local/lib include_dirs = /usr/local/include libs = lber ldap resolv # Installation options [install] compile = 1 optimize = 1 -------------------------------------------------------------- then ... /usr/local/bin/python setup.py build /usr/local/bin/python setup.py install Afterwords, to test the functionality of python-ldap, the following script may be used (you can call it test.py) Modify lines two and four to comply with your machine configuration. Make sure that either Netscape Directory Server or OpenLDAP is running and that the 2.1+ version of Python with python-ldap is used. This script is modified from the one in the documentation only in that it provides output, rather that only generating an error message if it fails. -------------------------------------------------------------- import ldap l = ldap.open("localhost") l.simple_bind_s("","") res = l.search_s("dc=example,dc=com", ldap.SCOPE_SUBTREE, "objectclass=*") print res l.unbind() -------------------------------------------------------------- OpenLDAP won't run with the default slpad.conf file. To test the script out with OpenLDAP, do the following: vi /usr/local/etc/openldap/slapd.conf Change the following lines: From: suffix "dc=my-domain,dc=com" To: suffix "dc=example,dc=com" ..and from: rootdn "cn=Manager,dc=my-domain,dc=com" To: rootdn "cn=Manager,dc=example,dc=com" Then execute the following: /usr/local/libexec/slapd ...and finally run the script: /usr/local/bin/python test.py /* using the correct Python */ If it works, kill the main OpenLDAP slapd process by getting the pid from: cat /usr/local/var/slapd.pid Then kill it's process id, i.e.: kill 12286 7) There are two modes of operation of web2ldap: standalone, and with mod_fastcgi in Apache. For mod_fastcgi operation, skip to step nine. For standalone operation do the following: tar zxvf web2ldap-0.10.2.tar.gz mv web2ldap-0.10.2 /usr/local/web2ldap vi /usr/local/web2ldap/etc/web2ldap/web2ldapcnf/standalone.py search for "run_username" change to "nobody" /* or create a new account */ search for "access_allowed" uncomment the first "access_allowed" line comment the second "access_allowed" line /* to allow access to all */ save the document and quit vi Then edit the following file: vi /usr/local/web2ldap/sbin/standalone.py Change the path to the updated Python in the first line: #!/usr/local/bin/python Search for: 127.0.0.1 and change it to the IP address bound to the NIC you will be communicating with. Save the document and exit vi. 8) Compile the web2ldap and run it by doing the following: cd /usr/local/web2ldap /usr/local/bin/python sbin/compile.py /usr/local/web2ldap/sbin/web2ldap.py -u nobody -t off -d on web2ldap will respond with the following: Read MIME-type mapping from file /etc/mime.types. Accepted IP address ranges: 0.0.0.0/0.0.0.0 Running mode: multi-threaded SSL: disabled Changed to UID 99. Point your favourite browser to http://ldap.testserver.com:1760/web2ldap to access the web application. 9) Install fcgi.py into the Python library path. Determine the python path by typing the following: /usr/local/bin/python Which will produce the following. The text to input is in red. Python 2.2 (#1, Feb 21 2002, 06:55:12) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-098)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print sys.path ['', '/usr/local/lib/python2.2', '/usr/local/lib/python2.2/plat-linux2', '/usr/local/lib/python2.2/lib-tk', '/usr/local/lib/python2.2/lib-dynload', '/usr/local/lib/python2.2/site-packages'] >>> <Ctrl>D The <Ctrl>D is the end of file marker, which exits python. Install fcgi.py by copying it to a directory in the Python path: cp fcgi.py /usr/local/lib/python2.2 /* from the directory fcgi.py was downloaded to */ 10) Install mod_fastcgi into Apache with APACI by doing the following: tar zxvf apache_1.3.23.tar.gz tar zxvf mod_fastcgi-2.2.12.tar.gz mv mod_fastcgi-2.2.12.tar.gz apache_1.3.23/src/modules/fastcgi cd apache_1.3.23.tar.gz ./configure activate-module=src/modules/fastcgi/libfastcgi.a make make install vi /usr/local/apache/conf/httpd.conf /* Make the following changes */ Find the following line: ScriptAlias /cgi-bin/ /usr/local/apache/cgi-bin/ Add the following line, just below it: ScriptAlias /web2ldap-fcgi/ /usr/local/web2ldap/fcgi/ Find the following line: # End of browser customization directives Add the following lines below it: FastCgiServer /usr/local/web2ldap/fcgi/web2ldap.py <Location /usr/local/web2ldap.fcgi> AddHandler fastcgi-script .py </Location> Save the file and exit vi. 11) Copy the css directory to where the scripts will expect it: cp -rp /usr/local/web2ldap/htdocs/css /usr/local/apache/htdocs 12) Start the Apache server: /usr/local/apache/bin/apachectl start 13) Open a browser to the following URL: http://hostname/web2ldap-fastcgi/web2ldap.py Ströder <mi...@st...> wrote: "John E. Mayorga" wrote: > > RedHat 7.2 seems to have both Python 1.5.2 and 2.1.1 in the distribution. You might want to see http://python-ldap.sf.net/download.shtml for a link to Joe's Red Hat RPMs. > There is a /usr/bin/python, but I don't > even know how to determine the version of that, or of DistUtils for that matter. If you invoke the interpreter (e.g. /usr/bin/python) the version is printed in the interactive interpreter shell. Press ^D to exit the interpreter. > Each version of Python in /usr/lib has it's own distutils. Which Python version do you want to use? I'd suggest to go for Python 2.1.1. > At this point, I have to admit that, although I've worked with Linux > for years, this is my first experience with Python. Maybe it helps if you tell us what you want to do. Ciao, Michael. --------------------------------- Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games |
|
From: Joe L. <jl...@op...> - 2002-02-19 01:53:31
|
On ftp://ftp.open-it.org/pub/redhat7.2 is the latest python-ldap RPMs. I can report that they work against my current codebase of DirectoryAdministrator 2.0 (yeah!!) BTW, I am using ldap.init() -- which recently was indicated as the correct method and not ldap.open(). I ran into some issues with expected results from executing ldap.initialize. Perchance this is a work in progress, as ldap.init looked like it was just going to return with a URI and instead it returned a correct LDAP fd. Then again, I'm just trying to get my code to work and not looking at the python-ldap code base much. Once pre05 is available "official", I'll post that. |
|
From: Michael <mi...@st...> - 2002-02-17 12:00:55
|
Joe Little wrote: > > I'll be building python-ldap-2.0.0pre5 shortly. Which is just the CVS version. No pre-release yet of this number. But as usual I'd like to encourage everyone to test it. I also would appreciate if someone could do some reviews of LDAPObject.c to track down the memory leaks. Leaking is reproducable with very simple script just doing the same searches over and over again. Ciao, Michael. |
|
From: Joe L. <jl...@op...> - 2002-02-17 05:05:06
|
redhat 7.2 has python2 rpms that coincide with the python 1.x. You=B9ll need
to check for python2 with =B3rpm =ADq python2=B2 -- if its not there, grab it fro=
m
your local mirror.=20
As for Michael=B9s suggestion, my python-ldap is built against the same
python2 rpm that RedHat provides.
I=B9ll be building python-ldap-2.0.0pre5 shortly.
On 2/16/02 6:03 PM, "John E. Mayorga" <jma...@ya...> wrote:
> Michael,=20
>=20
> An "rpm -q python" coughs up "python-1.5.3-35"
>=20
> I guess I'll download, compile, and install the latest stable Python and =
get
> back to you.=20
>=20
> Thanks again.=20
>=20
> John=20
>=20
> =20
>=20
> Michael Str=F6der <mi...@st...> wrote:
>> "John E. Mayorga" wrote:
>>> >=20
>>> > I've read the mailing list archives, the docs, the FAQ, done
>>> > multiple searches with google, tried, and experimented, and now I
>>> > have to ask: what's wrong with this?
>>> >=20
>>> > I'm getting the following error when running make (or "python
>>> > setup.py build" for that matter):
>>> >=20
>>> > Traceback (innermost last):
>>> > File "setup.py", line 38, in ?
>>> > if cfg.has_option('_ldap', 'class'):
>>> > AttributeError: has_option
>>> > make: *** [build] Error 1
>>=20
>> Hmm, which version of Python and which version of DistUtils?
>>=20
>> Note that python-ldap2.0.0pre has not been tested on Python 1.5.x.
>> It should work (except module ldapurl).
>>=20
>> Ciao, Michael.
>=20
>=20
> Do You Yahoo!?
> Yahoo! Sports <http://sports.yahoo.com/oly> - Coverage of the 2002 Olymp=
ic
> Games
|
|
From: Michael <mi...@st...> - 2002-02-17 02:24:30
|
"John E. Mayorga" wrote: > > RedHat 7.2 seems to have both Python 1.5.2 and 2.1.1 in the distribution. You might want to see http://python-ldap.sf.net/download.shtml for a link to Joe's Red Hat RPMs. > There is a /usr/bin/python, but I don't > even know how to determine the version of that, or of DistUtils for that matter. If you invoke the interpreter (e.g. /usr/bin/python) the version is printed in the interactive interpreter shell. Press ^D to exit the interpreter. > Each version of Python in /usr/lib has it's own distutils. Which Python version do you want to use? I'd suggest to go for Python 2.1.1. > At this point, I have to admit that, although I've worked with Linux > for years, this is my first experience with Python. Maybe it helps if you tell us what you want to do. Ciao, Michael. |
|
From: John E. M. <jma...@ya...> - 2002-02-17 02:03:33
|
Michael,
An "rpm -q python" coughs up "python-1.5.3-35"
I guess I'll download, compile, and install the latest stable Python and get back to you.
Thanks again.
John
Michael Ströder <mi...@st...> wrote: "John E. Mayorga" wrote:
>
> I've read the mailing list archives, the docs, the FAQ, done
> multiple searches with google, tried, and experimented, and now I
> have to ask: what's wrong with this?
>
> I'm getting the following error when running make (or "python
> setup.py build" for that matter):
>
> Traceback (innermost last):
> File "setup.py", line 38, in ?
> if cfg.has_option('_ldap', 'class'):
> AttributeError: has_option
> make: *** [build] Error 1
Hmm, which version of Python and which version of DistUtils?
Note that python-ldap2.0.0pre has not been tested on Python 1.5.x.
It should work (except module ldapurl).
Ciao, Michael.
---------------------------------
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games |
|
From: John E. M. <jma...@ya...> - 2002-02-17 01:50:25
|
Micheal,
Thank you for your response.
RedHat 7.2 seems to have both Python 1.5.2 and 2.1.1 in the distribution. There is a /usr/bin/python, but I don't even know how to determine the version of that, or of DistUtils for that matter. Each version of Python in /usr/lib has it's own distutils.
At this point, I have to admit that, although I've worked with Linux for years, this is my first experience with Python.
I'll try to determine the versions, assuming that will fix the problem. Any help in doing so would be greatly appreciated.
Thank you,
John
Michael Ströder <mi...@st...> wrote: "John E. Mayorga" wrote:
>
> I've read the mailing list archives, the docs, the FAQ, done
> multiple searches with google, tried, and experimented, and now I
> have to ask: what's wrong with this?
>
> I'm getting the following error when running make (or "python
> setup.py build" for that matter):
>
> Traceback (innermost last):
> File "setup.py", line 38, in ?
> if cfg.has_option('_ldap', 'class'):
> AttributeError: has_option
> make: *** [build] Error 1
Hmm, which version of Python and which version of DistUtils?
Note that python-ldap2.0.0pre has not been tested on Python 1.5.x.
It should work (except module ldapurl).
Ciao, Michael.
---------------------------------
Do You Yahoo!?
Got something to say? Say it better with Yahoo! Video Mail |
|
From: Michael <mi...@st...> - 2002-02-16 23:22:00
|
"John E. Mayorga" wrote:
>
> I've read the mailing list archives, the docs, the FAQ, done
> multiple searches with google, tried, and experimented, and now I
> have to ask: what's wrong with this?
>
> I'm getting the following error when running make (or "python
> setup.py build" for that matter):
>
> Traceback (innermost last):
> File "setup.py", line 38, in ?
> if cfg.has_option('_ldap', 'class'):
> AttributeError: has_option
> make: *** [build] Error 1
Hmm, which version of Python and which version of DistUtils?
Note that python-ldap2.0.0pre has not been tested on Python 1.5.x.
It should work (except module ldapurl).
Ciao, Michael.
|
|
From: John E. M. <jma...@ya...> - 2002-02-16 22:30:38
|
I've read the mailing list archives, the docs, the FAQ, done multiple searches with google, tried, and experimented, and now I have to ask: what's wrong with this?
I'm getting the following error when running make (or "python setup.py build" for that matter):
Traceback (innermost last):
File "setup.py", line 38, in ?
if cfg.has_option('_ldap', 'class'):
AttributeError: has_option
make: *** [build] Error 1
Here is my setup.cfg:
------------------------------------------------------------------------------------
# Section for compiling the C extension module
# for wrapping OpenLDAP 2 libs
[_ldap]
class = OpenLDAP2
library_dirs = /usr/local/lib
include_dirs = /usr/local/include
libs = lber ldap resolv
# Installation options
[install]
compile = 1
optimize = 1
------------------------------------------------------------------------------------
I simply "tar zxvf python-ldap-2.0.0pre4.tar.gz", cd to the resulting directory, tweak the setup.cfg to the above, and run make.
I'm running a plain vanilla RedHat 7.2 with a fresh install of openldap-2.0.23 using the simple instructions for compiling, testing, and installing it. My goal is to get web2ldap running, and I've worked on this little problem for over a day.
Please embarass me by offering a simple solution. :-)
John
---------------------------------
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games |
|
From: Jason T. <ja...@ti...> - 2002-02-15 20:21:48
|
Michael, On Tue, Feb 12, 2002 at 03:21:56PM +0100, Michael Str=F6der wrote: > Tony Goodwin wrote: > > Thanks Jason, > > Reorder of ldap and lber libs in setup.cfg worked >=20 > I've checked in a new setup.cfg with reordered line libs and two > different examples. Please comment. The new setup.cfg looks good. Note that the extra libraries for Cygw= in are only necessary because Cygwin Python is currently built with a static _socket module to workaround a fork() problem. Once my rebase patch is accepted into Cygwin setup.exe, then I will re-release Cygwi= n Python with a shared _socket module (as normal). At that point, the Cygwin lines should be removed and Cygwin python-ldap should build wi= th the default setup.cfg. Thanks, Jason |
|
From: Michael <mi...@st...> - 2002-02-13 00:49:34
|
HI!
I've committed a method LDAPObject.supported_ldap_version() to
Lib/ldap/ldapobject.py in CVS.
See the code snippet below. Please comment whether you find it
useful or annoying. Personally I'm using this code in web2ldap for
quite some while now and it seems to work with LDAP servers from
several vendors.
Hmm, I also thought about placing something like this in
LDAPObject.bind() to avoid an extra BindRequest. But this might be
too much hidden magic.
Ciao, Michael.
--------------------------------------------------------------------------
def supported_ldap_version(self):
"""
supported_ldap_version() -> int
Tries to negotiate the highest supported protocol version.
First this method binds anonymously with LDAPv3. If
that fails with info field 'version not supported' the
connection is completely dropped and re-openend like described
in RFC2251.
Mainly this is useful when connecting to a LDAP server without
prior knowledge. If you know the highest protocol version
supported by your server you won't need this method.
Caveat is that it sends an extra BindRequest to the server and
it does not work if the server does not allow anonymous bind
or mandates SASL bind.
The result of this method is an integer containing
the negotiated protocol version.
"""
# Try to set protocol version
self.set_option(ldap.OPT_PROTOCOL_VERSION,ldap.VERSION3)
# first try LDAPv3 bind
try:
# Try to bind to provoke error reponse at this very time
# if protocol version is not supported
self.bind_s('','',ldap.AUTH_SIMPLE)
except ldap.PROTOCOL_ERROR,e:
# Make sure that error just happened because of wrong
# protocol version
if hasattr(e,'args') and \
type(e.args)==type(()) and \
type(e.args[0])==type({}) and \
e.args[0].get('info','').lower()=='version not supported':
# Drop connection completely
self.unbind_s() ; del self._l
# Reconnect to host
self._l = self._ldap_call(_ldap.initialize,self._uri)
# Switch to new connection to LDAPv2
self.set_option(ldap.OPT_PROTOCOL_VERSION,ldap.VERSION2)
else:
# Raise any other error exception
raise e
# Set currently determined protocol version
protocol_version = ldap.VERSION2
else:
protocol_version = ldap.VERSION3
return protocol_version
|
|
From: Jens V. <je...@zo...> - 2002-02-12 18:40:24
|
michael,
sorry, that was a false alarm. everything builds OK with the Makefile=20
(after correcting some paths), i just used the wrong tool (TeXShop on =
Mac=20
OS X) to do it and it stumbled over stuff that the Makefile was supposed=20=
to generate on the fly before processing the tex inputs.
i do see the issues that you mentioned with the triple sections. i'll =
see=20
if i can try to look at it with my limited experience... :)
jens
On Tuesday, February 12, 2002, at 01:23 , Michael Str=F6der wrote:
> Thanks for looking at it.
>
> Jens Vagelpohl wrote:
>>
>> i am looking at those tex files (from current HEAD checkout) right =
now=20
>> and
>> it complains about some missing files::
>>
>> - version.tex (included in python-ldap.tex at the top)
>> - modpython-ldap.ind (pops up when processing ldap.tex at the very =
end
>> where it says "\subsection{Example \label{ldap-example}}"
>
> Both files are generated on the fly.
>
> version.tex is generated in the Makefile. You have to start make in
> the Doc/ directory. Hmm, I corrected the Makefile to work on my
> platform. Not sure if that works on every system though.
>
> modpython-ldap.ind (the module index) is also generated correctly on
> my system and included in either the PDF and the HTML output. I'm
> using the necessary TeX packages shipped with my SuSE Linux 7.1
> installation.
>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
|
|
From: Michael <mi...@st...> - 2002-02-12 18:23:52
|
Thanks for looking at it.
Jens Vagelpohl wrote:
>
> i am looking at those tex files (from current HEAD checkout) right now and
> it complains about some missing files::
>
> - version.tex (included in python-ldap.tex at the top)
> - modpython-ldap.ind (pops up when processing ldap.tex at the very end
> where it says "\subsection{Example \label{ldap-example}}"
Both files are generated on the fly.
version.tex is generated in the Makefile. You have to start make in
the Doc/ directory. Hmm, I corrected the Makefile to work on my
platform. Not sure if that works on every system though.
modpython-ldap.ind (the module index) is also generated correctly on
my system and included in either the PDF and the HTML output. I'm
using the necessary TeX packages shipped with my SuSE Linux 7.1
installation.
Ciao, Michael.
|
|
From: Jens V. <je...@zo...> - 2002-02-12 18:03:07
|
michael,
i am looking at those tex files (from current HEAD checkout) right now =
and=20
it complains about some missing files::
- version.tex (included in python-ldap.tex at the top)
- modpython-ldap.ind (pops up when processing ldap.tex at the very end=20=
where it says "\subsection{Example \label{ldap-example}}"
mind you, i am not a tex guru myself. are there files that need to be=20
checked into the repository?
jens
On Saturday, February 9, 2002, at 01:20 , Michael Str=F6der wrote:
> Aaargh!
>
> Can someone please glance over the .tex sources in Doc/. I screwed
> up something but I'm completely lost.
>
> The \section{\module{ldap} --- LDAP library interface module}
> appears three times in the .pdf but not in the HTML output...
>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
|
|
From: Joe L. <jl...@op...> - 2002-02-12 17:51:40
|
I'm using the same RawHide kernel (rebuilt) for my builds of python-ldap an= d the like. RedHat was experimenting with Ingo Molnar's new scheduler, and this is likely the suspect difference. There is a new patch he has just release, which I may apply against the kernel and rebuild. If you want the best performing 2.4.9 kernel, I'd go with 2.4.9-21 (RedHat 7.2 proper) BTW -- Hiya. At a new company? On 2/12/02 9:33 AM, "Leif Hedstrom" <le...@pr...> wrote: > Michael Str=F6der wrote: >=20 >> I've added measuring the time to the script itself and can't >> reproduce your results (tested with python2.0, python2.1.1 and >> python2.2). In my case redirecting stdout to /dev/null was faster. >> How did you do time measuring? Maybe somebody screwed up /dev/null >> on your system? >>=20 >=20 > Well, the good news is that I've solved my problem, and it's not related > to Python LDAP at all. :-). >=20 > I wrote a small C-program that also reproduced the same problem. So, > this narrowed it down to a few things: C-compiler, glibc or kernel. I > hadn't touched the first two in quite a while, but I did upgrade the > kernel a week ago... So, I rolled back to 2.4.7 (from 2.4.17), and now > my problem is gone. Don't ask me what happend with the 2.4.17 kernel, I > hadn't noticed any problems or errors at all after the upgrade (RPM from > Rawhide), but something is not good... >=20 > The module still leaks memory though, I'll poke at that little later. > Thanks again for the help, so I could narrow things down to the real > problem. :-) >=20 > Thanks, >=20 > -- Leif >=20 >=20 > _______________________________________________ > Python-LDAP-dev mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev |
|
From: Leif H. <le...@pr...> - 2002-02-12 17:34:05
|
Michael Str=F6der wrote: >I've added measuring the time to the script itself and can't >reproduce your results (tested with python2.0, python2.1.1 and >python2.2). In my case redirecting stdout to /dev/null was faster. >How did you do time measuring? Maybe somebody screwed up /dev/null >on your system? > Well, the good news is that I've solved my problem, and it's not related=20 to Python LDAP at all. :-). I wrote a small C-program that also reproduced the same problem. So,=20 this narrowed it down to a few things: C-compiler, glibc or kernel. I=20 hadn't touched the first two in quite a while, but I did upgrade the=20 kernel a week ago... So, I rolled back to 2.4.7 (from 2.4.17), and now=20 my problem is gone. Don't ask me what happend with the 2.4.17 kernel, I=20 hadn't noticed any problems or errors at all after the upgrade (RPM from=20 Rawhide), but something is not good... The module still leaks memory though, I'll poke at that little later.=20 Thanks again for the help, so I could narrow things down to the real=20 problem. :-) Thanks, -- Leif |
|
From: Michael <mi...@st...> - 2002-02-12 14:22:09
|
Tony Goodwin wrote: > > Thanks Jason, > Reorder of ldap and lber libs in setup.cfg worked I've checked in a new setup.cfg with reordered line libs and two different examples. Please comment. Please check it out from CVS. Ciao, Michael. --------------------------- snip --------------------------- # Section for compiling the C extension module # for wrapping OpenLDAP 2 libs [_ldap] class = OpenLDAP2 library_dirs = /usr/local/openldap2/lib include_dirs = /usr/local/openldap2/include # Standard build libs = ldap lber # Some Linux systems might need explicitly linking with -lresolv #libs = ldap lber resolv # For building with cygwin #libs = ldap lber ssl crypto --------------------------- snip --------------------------- |
|
From: Michael <mi...@st...> - 2002-02-12 12:18:25
|
Leif Hedstrom wrote: > > I wanted to write a very small app to do some simple tests, and I got > some very, very strange results. I can't understand why the performance > is so abysmal unless I print on STDOUT... The script is something like: > [..test script snipped..] I've added measuring the time to the script itself and can't reproduce your results (tested with python2.0, python2.1.1 and python2.2). In my case redirecting stdout to /dev/null was faster. How did you do time measuring? Maybe somebody screwed up /dev/null on your system? BTW: Remember to use l.set_option(ldap.OPT_PROTOCOL_VERSION,ldap.VERSION3) to set protocol version to LDAPv3. > Also, this simple script leaks memory, not sure where yet. Hmm, interesting question. Any C hacker with a license of e.g. Purify willing to dig into this? Ciao, Michael. |
|
From: Tony G. <dan...@ya...> - 2002-02-11 23:14:08
|
Thanks Jason, Reorder of ldap and lber libs in setup.cfg worked |