python-ldap-dev — discussion among developers

Newbie Question

[Nader K. <nad...@ba...>]

Hello
I'm trying to install python ldap module on my machine.
my machine is solaris 7. with gcc 2.8.1 and python 1.5.2.
I have openldap 1.2.11.
I have tried python-ldap-1.10alpha3-src.tar.gz
when i ran the configure script it ran without problems. but once i ran make
i got this error.

ld -G  LDAPObject.o common.o constants.o errors.o functions.o ldapmodule.o
message.o version.o linkedlist.o template.o
CIDict.o  -lldap -llber -lsocket -lnsl -lm -lkrb -o _ldapmodule.so
ld: fatal: library -llber: not found
ld: fatal: File processing errors. No output written to _ldapmodule.so
make[1]: *** [_ldapmodule.so] Error 1
make[1]: Leaving directory `/opt/sa/python-ldap-1.10alpha3/Modules'
make: *** [_ldapmodule-build] Error 2

although when i ran the configure script it found it :

checking for library containing ber_free... (cached) -llber
checking for library containing ldap_open... (cached) -lldap

please help
Nader

P.S. attached is the full output of the configure and make

Re: new style getargs format but argument is not a tuple

[Michael <mi...@st...>]

David Leonard wrote:
> 
> I've added a check now and will eventually commit it.  The error you
> would get after the patch would be:
> 
>   TypeError: ("expected a tuple", 2)
> 
> which would probably not help, unless you knew that MOD_REPLACE = 2.

It might be a better choice to check that the modify list parameter
is really a Python list object because most beginners will forget to
create a list containing the tuples.

The misleading exception

SystemError: new style getargs format but argument is not a tuple

is raised because of a tuple passed to the method instead of a list.

Ciao, Michael.

Re: new style getargs format but argument is not a tuple

[Michael <mi...@st...>]

mike wrote:
> 
> tmp = _ldap.MOD_REPLACE, "favoritecolor", "red"

Has to be a list of tuples.

tmp = [(_ldap.MOD_REPLACE, "favoritecolor", "red")]

would be correct.

>     l.modify_s("cn=mike, ou=People, dc=foo, dc=com",tmp)
> SystemError: new style getargs format but argument is not a tuple

Your variable tmp seems to be treated as a sequence (the modify
list). tmp[0] is not a tuple which raises this Exception.

Ciao, Michael.

Re: new style getargs format but argument is not a tuple

[David L. <dav...@cs...>]

On Thu, 7 Sep 2000, mike typed thusly:

> My apoligies, the following two questions are pretty simple but I
> couldn't figure either of them out. 

actually, neither are simple!

> First, the .tex files in the Doc/_ldap directory are giving me errors
> when I try to view them(using latex or tex), is anyone else having this
> problem?  

yes... currently they need the tex support files from the recent
betas of python 1.6.. I have been able to build the documentation,
but want to do so in an automated/reliable way on the sourceforge boxes.
Eventually it will be put on the web site.

> Second, the reason I needed to look at the docs was to see what
> paramaters are supposed to be supplied to modify_s.  I did use vi to
> look at the raw .tex file and found my answer but it still doesn't seem

You can look at the __doc__ members on the functions. They are 
generally up to date.

> to be working.  Below is a test file that I am using along with the
> error it generates.
>
> Once again my apologies for the simple questions, the error is probably
> some bad syntax on my part, but I can't tell for sure because I can't
> read the docs.  Thanks again for any help!
> 
> [Contents of file test.py]
> 
> #!/usr/bin/env python
> 
> import _ldap
> 
> l = _ldap.open("localhost")
> l.simple_bind_s("","")
> tmp = _ldap.MOD_REPLACE, "favoritecolor", "red"
> l.modify_s("cn=mike, ou=People, dc=foo, dc=com",tmp)
> l.unbind()
> 
> 
> [Results when I run it]
> 
> [mike@apache mike]$ ./test.py
> Traceback (innermost last):
>   File "./test.py", line 8, in ?
>     l.modify_s("cn=mike, ou=People, dc=foo, dc=com",tmp)
> SystemError: new style getargs format but argument is not a tuple

that's a strange error! what you needed was a list of tuples:

  l.modify_s("cn=mike, ou=People, dc=foo, dc=com", [tmp])

Also, you ought to be using 'ldap', instead of '_ldap' :)

By the way, for other people reading, the SystemError came from
the Tuple_to_LDAPMod() function; its because I was lazy and used
PyArg_ParseTuple to split up the 'tuple' without checking that it
actually was a tuple.

I've added a check now and will eventually commit it.  The error you 
would get after the patch would be:

  TypeError: ("expected a tuple", 2)

which would probably not help, unless you knew that MOD_REPLACE = 2.

> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/python-ldap-dev
> 

-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

No horse gets anywhere until he is harnessed. No stream or gas drives anything
until it is confined. No Niagara is ever turned into light and power until
it is tunneled. No life ever grows great until it is focused, dedicated,
disciplined.  -Harry Emerson Fosdick

new style getargs format but argument is not a tuple

[mike <mi...@tg...>]

My apoligies, the following two questions are pretty simple but I
couldn't figure either of them out. 

First, the .tex files in the Doc/_ldap directory are giving me errors
when I try to view them(using latex or tex), is anyone else having this
problem?  

Second, the reason I needed to look at the docs was to see what
paramaters are supposed to be supplied to modify_s.  I did use vi to
look at the raw .tex file and found my answer but it still doesn't seem
to be working.  Below is a test file that I am using along with the
error it generates.

Once again my apologies for the simple questions, the error is probably
some bad syntax on my part, but I can't tell for sure because I can't
read the docs.  Thanks again for any help!

[Contents of file test.py]

#!/usr/bin/env python

import _ldap

l = _ldap.open("localhost")
l.simple_bind_s("","")
tmp = _ldap.MOD_REPLACE, "favoritecolor", "red"
l.modify_s("cn=mike, ou=People, dc=foo, dc=com",tmp)
l.unbind()


[Results when I run it]

[mike@apache mike]$ ./test.py
Traceback (innermost last):
  File "./test.py", line 8, in ?
    l.modify_s("cn=mike, ou=People, dc=foo, dc=com",tmp)
SystemError: new style getargs format but argument is not a tuple

Re: 1.10alpha 'release'

[<fo...@mi...>]

Scavenging the mail folder uncovered David Leonard's letter:
> 
> so far, all that the package has is whats in Lib and the _ldapmodule.
> fog, or whoever, if you want the rest to be installed sensibly, please
> link it into the root Makefile.in.

just returned from holydays and slowly crawling through 4000 emails...
i will update _ldapmodule and move the stable stuff in the right place
asap.

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
                           Don't dream it. Be it. -- Dr. Frank'n'further

Re: another leak fixed

[Michael <mi...@st...>]

David Leonard wrote:
> 
> [replying to oneself is a sign of madness]
> 
> On Fri, 18 Aug 2000, David Leonard typed thusly:
> > hooray! the result of ldap_get_dn() wasn't being freed.
> > patches committed into cvs, but i havent built a new release yet..
> 
> just had a thought - if/when blits is finished, it could be put into
> a endless loop and then memory-footprint-watchers like davidma and
> dr lazarus can do their top-watching thing :)

Yes. The test functions will all be separated and can be imported
into other test programs. Note: Some are destructive on the data
set.

Ciao, Michael.

Re: another leak fixed

[David L. <dav...@cs...>]

[replying to oneself is a sign of madness]

On Fri, 18 Aug 2000, David Leonard typed thusly:
> hooray! the result of ldap_get_dn() wasn't being freed.
> patches committed into cvs, but i havent built a new release yet..

just had a thought - if/when blits is finished, it could be put into 
a endless loop and then memory-footprint-watchers like davidma and 
dr lazarus can do their top-watching thing :)

-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

another leak fixed

[David L. <dav...@cs...>]

hooray! the result of ldap_get_dn() wasn't being freed.
patches committed into cvs, but i havent built a new release yet..

is anyone else running their eye over the code?

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

---------- Forwarded message ----------
Date: Fri, 18 Aug 2000 10:47:42 +1000
From: Dr. Ross Lazarus <ro...@me...>
To: David Leonard <dav...@cs...>
Subject: Re: search_s leaks in tiny amounts

bingo. 15000 cycles and the memory footprint hasn't shifted.

Is it worth exercising a few more functions this way? It's a really dumb
python test script!
Could be automated by doing a system call to free and parsing the
results.

Oh yes, forgot. Thesis due soon.... {O-:)

Thanks !

David Leonard wrote:
> 
> On Fri, 18 Aug 2000, Dr. Ross Lazarus typed thusly:
> 
> > Thanks for the suggestion - hmmmnn - patch failed on all hunks but I cut
> > and pasted from a windoze mail reader to a unix box...
> > So I did it by hand -
> > Minor syntax problemo -
> 
> yeah should have moved it into the bottom of the block instead :)
> i did that after i emailed you.  its the leak for sure...
> 
>          entrytuple = Py_BuildValue("(sO)", dn, attrdict);
>          Py_DECREF(attrdict);
>          PyList_Append(result, entrytuple);
>          Py_DECREF(entrytuple);
>          free(dn);
>      }
>      ldap_msgfree( m );
>      return result;

Python-backend for OpenLDAP 2.0

[Michael <mi...@st...>]

HI!

For pushing Python in the LDAP world it would be nice if somebody
could embedd the Python interpreter as backend in OpenLDAP 2.0. My C
knowledge is near zero but I'm willing to test and provide knowledge
about LDAP.

There are already Perl and TCL backends which could be used as
examples.

Ciao, Michael.

Re: BLITS

[Michael <mi...@st...>]

David Leonard wrote:
> 
> if you can create stub
> functions for every test (ie do-nothing stubs) then more people can
> systematically work through them

That's exactly what I did. I still have to check out if there are
dependencies between the tests but will try to work around them.

During the next days I will organize the stuff and write some
functions as example and check my coding guide-lines.

Ciao, Michael.

Re: rpm alpha release

[Michael <mi...@st...>]

David Leonard wrote:
> 
> well i finally managed to get an rpm created with jeff's help ...

Great!

> [..]
> could someone try this out please?

Works smoothly on my S.u.S.E. 6.4 system.

Ciao, Michael.

BLITS

[Michael <mi...@st...>]

HI!

I'm in the process of implementing the BLITS test suite because I
think there's a strong need for a well-defined test script. Testing
the current and future releases is somewhat difficult because one
can't be sure that all aspects are covered.

I have a function framework derived from

  http://www.opennc.org/directory/mats/blits24/index.htm

but the (simple) test functions itself have to be impemented now.

Well, there are ~ 200(!) tests defined and I won't be able to
implement them in a reasonable time frame myself.

Here's the deal: For every function another person is willing to
contribute I will implement one either. Before you're going to write
your own test scripts spend a few minutes on writing a test function
for blits.py and get one test function for free! ;-)

We will get a nice test script for the Demo/ section of python-ldap.

If you have some time send me an e-mail and I will organize who's
going to develop which test function. The read-only functions are
easy to implement if you have permanent Internet access to the test
data set on ldap://nldap.com/O=IMC,C=US (X.500 name set).

The test functions which need write access need the test data set
uploaded to a LDAPv3 server like OpenLDAP 2.0 (for most tests
OpenLDAP 1.2.x will be sufficient, too).

Ciao, Michael.

Re: rpm alpha release

[Jeffrey C. O. <je...@ol...>]

On Wed, Aug 16, 2000 at 11:42:01PM +1000, David Leonard wrote:
> 
> could someone try this out please? if it doesn't install and you think you 
> know how to fix it, please modify Build/build-linux.sh and Build/template.spec 
> then mail me.  thanks

The RPM installed and worked fine on a couple of small tests.

> what i really need now is someone who can build a win32 distribution.

I might give this a try since I really need a newer version of the
win32 distribution. This might take me a while since I've never used
Visual Studio before and I need to track down a win32 binary of
OpenLDAP (or build my own) as well as set up a machine to compile on.
Don't count on me finishing anything soon, since I have a lot of my
plate with the start of the fall semester a couple of weeks from now.

Jeff

rpm alpha release

[David L. <dav...@cs...>]

well i finally managed to get an rpm created with jeff's help ... 

ftp://python-ldap.sourceforge.net/pub/python-ldap/python-ldap-1.10alpha3-1.i386.rpm                             

could someone try this out please? if it doesn't install and you think you 
know how to fix it, please modify Build/build-linux.sh and Build/template.spec 
then mail me.  thanks

what i really need now is someone who can build a win32 distribution.

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Curses! - Mojo Jojo

fyi (zope & _ldap/ldap hacking)

[David L. <dav...@cs...>]

---------- Forwarded message ----------
Date: Wed, 16 Aug 2000 21:39:20 +1000
From: Dr. Ross Lazarus <ro...@me...>
To: David Leonard <dav...@cs...>
Subject: Re: Update - it's the search_s in ldapmodule which leaks when 
    usingldapmodule

I inherited some of the setup here so I didn't even try to grok why
"import ldap" worked when ldapmodule.so was available - it was always
called that - not _ldapmodule.so - I suspect the initial setup.

Anyhoo, it works as intended now. 

I don't use the cache so I'll turn it off - I didn't realise it affected
the client libraries - thanks. I'll let you know if it leaks differently
(!).

<a few minutes later>

Nope, no apparent difference.

I reverted to a fresh copy of the original tar and compiled with that
one mod. to the Makefile.in - that tarball appears fit for human
consumption.

May I suggest you might add to the readme, something along the lines of
your reply below 
"
the init function is usually called init_ldap() so the module
is called _ldap. when installed properly theres a ldap.py file that
wraps it.
"

Note for zope users: After the configure and make steps, put the output
(Modules/_ldapmodule.so) and Lib/ldap.py into your [zope]/lib/python
directory where it will be found by external methods and products.


for future generations of grateful end users.....

David Leonard wrote:
> 
> On Wed, 16 Aug 2000, Dr. Ross Lazarus typed thusly:
> 
> > ah, well.
> > I've always produced an ldapmodule.so and the _ldapmodule.so didn't drop
> > in to place correctly (and broke when renamed...).
> > > > breaks. I had to hack the ldapmodule.c file to use ldap instead of _ldap
> > > > and also the Setup file in Modules to generate ldap instead of _ldap and
> > > > the Makefile ditto..
> 
> the init function is usually called init_ldap() so the module
> is called _ldap. when installed properly theres a ldap.py file that
> wraps it.
> 
> > Whatever, I somehow got something called ldapmodule.so which works!!
> >
> > > > Still leaking about 112 bytes per 1000 calls to ldap_search_s
> > > >
> > > > Why or how it's less than 1 byte per call beats me!!!! - but it's MUCH
> > Why less than 1 byte per call?
> 
> no idea. could be the ldap library itself. do you disable the cache?
> 
> good to hear that its working for you though
> 
> --
> David Leonard                           Dav...@cs...
> Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
> The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
> QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401
> 
> Curses! - Mojo Jojo

-- 

Dr Ross Lazarus
Associate Professor and Sub-Dean for Information Technology
Faculty of Medicine, Room 126A, A27, University of Sydney,
Camperdown, NSW 2006, Australia
Tel: (+61 2) 93514429   Mobile: +61414872482  
Fax: (+61 2) 93516646   Email: ro...@me...

Re: 1.10alpha 'release'

[Michael <mi...@st...>]

Johannes Stezenbach wrote:
> 
> Don't be too perfectionistic, Michael.

Yeah, yeah. But I take it as a compliment to hear that from you...

Ciao, Michael.

Re: 1.10alpha 'release'

[Johannes S. <ya...@gm...>]

Michael Ströder wrote:
> 
> I did add a "from _ldap import __version__" myself in ldap.py before
> but what about __symbols__ added in the future? We need robust and
> consistent behaviour for all future modifications.

Use Guido's time machine?

But seriously, ldap.py and _ldapmodule.so must match, but that
should be no problem. Don't be too perfectionistic, Michael.

Johannes

Re: 1.10alpha 'release'

[Michael <mi...@st...>]

David Leonard wrote:
> 
> On Mon, 14 Aug 2000, Johannes Stezenbach typed thusly:
> 
> > Michael Ströder wrote:
> > But Michael's right: You *MUST* include a warning about deleting
> > the old ldapmodule.so (or ldap.dll) in the INSTALL/README
> > document. It may even be a good idea to add a micro-FAQ to the
> > distribution.
> 
> Perhaps the configure script could detect this and emit a warning?

Do you think people will ever percept it? Well, let's try.

>  import ldap; if string.find(ldap.__file__, "ldapmodule") != -1: ...
> 
> > > And I know that there's "from _ldap import *" in ldap.py but this
> > > does not import _ldap.__version__ and using "from module import *"
> > > is bad behaviour anyway.
> 
> just for you, michael i've gotten ldap.py to import __version__ :)

I did add a "from _ldap import __version__" myself in ldap.py before
but what about __symbols__ added in the future? We need robust and
consistent behaviour for all future modifications.

Ciao, Michael.

Re: rpm building

[Jeffrey C. O. <je...@ol...>]

On Tue, Aug 15, 2000 at 11:58:00AM +1000, David Leonard wrote:
> 
> I just commited Build/template.spec which could help someone doing the 
> rpm packaging.
> 
> I not sure how to build the package without having to first properly
> install things. You see, I don't have root access to a linux box so I
> can't actually install anything. I thought maybe with RPM I could do this: 
> 
> 	Prefix: /tmp/myroot/usr
> 	%install
> 	mkdir -p /tmp/myroot/usr
> 	make install DESTDIR=/tmp/myroot/usr
> 
> but then, that would be a confusing default.
> 
> The BSD packaging system allows you to build packages without modifying the
> ultimate target directories.

RPM has a similar mechanism:

Prefix:    /usr
BuildRoot: %{_tmp}/%{name}-%{version}-root

%install
rm -rf %{buildroot}
mkdir -p %{buildroot}
make install DESTDIR=%{buildroot}

Note: the %{buildroot} macro only works in more recent versions of
RPM. $RPM_BUILD_ROOT is the equivalent (but deprecated) variable to
use in older versions of RPM.

Jeff

rpm building

[David L. <dav...@cs...>]

I just commited Build/template.spec which could help someone doing the 
rpm packaging.

I not sure how to build the package without having to first properly
install things. You see, I don't have root access to a linux box so I
can't actually install anything. I thought maybe with RPM I could do this: 

	Prefix: /tmp/myroot/usr
	%install
	mkdir -p /tmp/myroot/usr
	make install DESTDIR=/tmp/myroot/usr

but then, that would be a confusing default.

The BSD packaging system allows you to build packages without modifying the
ultimate target directories.

Also, there is a filelist target in the top-level Makefile which may need
to be updated in the future.

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Re: 1.10alpha 'release'

[Johannes S. <ya...@gm...>]

Michael Ströder wrote:
> 
> But different versions of ldap.py will be necessary when
> distributing C ldap-module and ldaplib separately.

Python has a mechanism for handling optional modules: Catch
ImportError. But this doesn't work here because of ldap.py vs.
ldap package.

> It's ok if we
> rename Fog's stuff to ldaplib and keep ldap.py (small wrapper
> module) and _ldapmodule.so.

ACK.

> And due to start-up latency when doing "import ldap" with lots of
> stuff imported I want to keep both separated.

ACK.

> But what about the problem that _ldap.__version__ is not correctly
> imported by the wrapper module ldap.py with "from _ldap import *"?

Add "from _ldap import __version__".
Note that Python is smart enough to load _ldap only once, so this
second import is fast.

Johannes

Re: 1.10alpha 'release'

[David L. <dav...@cs...>]

On Mon, 14 Aug 2000, Johannes Stezenbach typed thusly:

> Michael Ströder wrote:
> But Michael's right: You *MUST* include a warning about deleting
> the old ldapmodule.so (or ldap.dll) in the INSTALL/README
> document. It may even be a good idea to add a micro-FAQ to the
> distribution.

Perhaps the configure script could detect this and emit a warning?

	import ldap; if string.find(ldap.__file__, "ldapmodule") != -1: ...

> > And I know that there's "from _ldap import *" in ldap.py but this
> > does not import _ldap.__version__ and using "from module import *"
> > is bad behaviour anyway.

just for you, michael i've gotten ldap.py to import __version__ :)

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Re: 1.10alpha 'release'

[David L. <dav...@cs...>]

On Mon, 14 Aug 2000, Johannes Stezenbach typed thusly:

> David Leonard wrote:
> > 
> > if you have CVS access, please check out the new Build directory. 
> 
> Sorry, I didn't look at Build, but compilation from the top level
> directory is broken:
> 
> $ ~/devel/ldapmodule/python-ldap-1.10a > make
> cd Modules && make srcdir=./Modules VPATH=./Modules
> make[1]: Entering directory
> `/home/joe/devel/ldapmodule/python-ldap-1.10a/Modules'
> make[1]: *** No rule to make target `Modules/LDAPObject.c',
> needed by `LDAPObject.o'.  Stop.

oops, yes that shouldn't be ./Modules but `pwd`/Modules
will fix

-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Re: 1.10alpha 'release'

[Michael <mi...@st...>]

Johannes Stezenbach wrote:
> 
> Please also test error conditions/exceptions. It would be nasty
> if a missing INCREF/surplus DECREF would make it dump core on
> error conditions.

When using web2ldap a lot of exceptions are caught. Up to now it
looks stable. Yeah, this is not 100% sure.

Anyway a BLITS test trys to address all cases. 
See: http://www.opennc.org/directory/mats/blits24/index.htm

Ciao, Michael.