python-ldap-dev — discussion among developers

Why does writing STDOUT affect my Python LDAP performance?

[Leif H. <le...@pr...>]

Hi,

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:

#!/usr/bin/python2

import ldap

l = ldap.open("localhost")
l.simple_bind_s("", "")

loop = 1000
while loop:
    loop = loop - 1
    print "Going into LDAP, loop is ", loop
    res = l.search_s(
        "dc=propel,dc=com",
        ldap.SCOPE_SUBTREE,
        "cn=Manager"
        )
    print "Done with search"

l.unbind()


(I added the print statements to show my problem). Here are the time 
resusts from two test runs:

269% time test.py
.
.
.
Done with search
2.180u 0.480s 0:06.85 38.8%     0+0k 0+0io 656pf+0w

loki 270% time /tmp/simple.py > /dev/null
115.770u 32.230s 2:31.46 97.7%  0+0k 0+0io 651pf+0w

Without redirecting STDOUT (lots of spam on the display), it takes about 
6 secs, when I do redirect STDOUT to devnull it takes 150 seconds (25x 
slower). This makes no sense to me at all... Also, this simple script 
leaks memory, not sure where yet.

Any ideas where to look? I'm using Python 2.1.2, OpenLDAP 2.0.22 and 
latest Python LDAP source from the CVS server.

Thanks,

-- leif

Re: cygwin and python-ldap

[Jason T. <ja...@ti...>]

Tony,

On Mon, Feb 11, 2002 at 01:51:08PM +0000, Tony Goodwin wrote:
> Next problem is that I get a lot of ber_printf (and ber_scanf ..) symbols
> not found from openldap origins
> I ain't no expert, but it seems to be building a shared library, and
> complaining about symbols not found in
> openldap (which has built OK .. though untested yet)
> 
> Any help appreciated
> 
> gcc -shared -Wl,--enable-auto-image-base ...
> [snip]
> /usr/local/src/openldap-2.0.21/libraries/libldap.a(search.o): In function
> `ldap_build_search_req':
> /usr/local/src/openldap-2.0.21/libraries/libldap/search.c:300: undefined
> reference to `ber_printf'
> /usr/local/src/openldap-2.0.21/libraries/libldap/search.c:326: undefined
> referen

Please try the setup.cfg mentioned in:

    http://www.geocrawler.com/archives/3/1568/2002/1/0/7452037/

and report back as to whether or not this solves your problem.  I think
you are having a library ordering problem.  I certainly did when I used
the order of the (commented out) libraries in the default setup.cfg.

Thanks,
Jason

cygwin and python-ldap

[Tony G. <dan...@ya...>]

Trying to build pre04 on cygwin using openldap 2.0.21, python 2.2
First problem was not finding lib resolv, though removing it from setup.cfg
doesn't seem to affect anything

Next problem is that I get a lot of ber_printf (and ber_scanf ..) symbols
not found from openldap origins
I ain't no expert, but it seems to be building a shared library, and
complaining about symbols not found in
openldap (which has built OK .. though untested yet)

Any help appreciated

Tony
<snip>

gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.3.9-i686-2.2/LDAPOb
ject.o build/temp.cygwin-1.3.9-i686-2.2/common.o
build/temp.cygwin-1.3.9-i686-2.
2/constants.o build/temp.cygwin-1.3.9-i686-2.2/errors.o
build/temp.cygwin-1.3.9-
i686-2.2/functions.o build/temp.cygwin-1.3.9-i686-2.2/ldapmodule.o
build/temp.cy
gwin-1.3.9-i686-2.2/linkedlist.o build/temp.cygwin-1.3.9-i686-2.2/message.o
buil
d/temp.cygwin-1.3.9-i686-2.2/template.o
build/temp.cygwin-1.3.9-i686-2.2/version
.o
build/temp.cygwin-1.3.9-i686-2.2/options.o -L/usr/local/src/openldap-2.0.21/
l
ibraries -L/usr/local/lib/python2.2/config -llber -lldap -lpython2.2 -o
build/li
b.cygwin-1.3.9-i686-2.2/_ldap.dll
/usr/local/src/openldap-2.0.21/libraries/libldap.a(search.o): In function
`ldap_
build_search_req':
/usr/local/src/openldap-2.0.21/libraries/libldap/search.c:300: undefined
referen
ce to `ber_printf'
/usr/local/src/openldap-2.0.21/libraries/libldap/search.c:326: undefined
referen
<etc ...>
</snip>

Re: Install problem [python-ldap-2.0.0pre04]

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

Jacek Konieczny wrote:
> 
> On Sun, Feb 10, 2002 at 07:04:46PM +0100, Michael Ströder wrote:
> > > or is the new standard to use LDAP URLs??
> >
> > It is the new standard. OpenLDAP 2's ldap.h marks ldap_open() as
> > deprecated.
> AFAIK it is pepreciated in favor of ldap_init() (which initializes
> connection object, but doesn't connect till the first operation).
> 
> ldap_initialize() is a quite different thing, IMHO much more usefull.

Hmm, what to do? I stripped the wrapping functions for ldap_open()
and ldap_init() from LDAPObject.c. Is anyone in favour of having
these wrapped directly?

I would rather vote for making ldap.initialize() more smart or
implement a smart separate function. E.g. trying to set the right
protocol version would be nice (try LDAPv3 first and correctly fall
back to LDAPv2).

Ciao, Michael.

Re: Install problem [python-ldap-2.0.0pre04]

[Jacek K. <ja...@bn...>]

On Sun, Feb 10, 2002 at 07:04:46PM +0100, Michael Str=F6der wrote:
> > or is the new standard to use LDAP URLs??
>=20
> It is the new standard. OpenLDAP 2's ldap.h marks ldap_open() as
> deprecated.=20
AFAIK it is pepreciated in favor of ldap_init() (which initializes=20
connection object, but doesn't connect till the first operation).

ldap_initialize() is a quite different thing, IMHO much more usefull.

Greets,
Jacek

Re: Install problem [python-ldap-2.0.0pre04]

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

Donal Hunt wrote:
> 
> Is ldap.open still usable?

Yes. Mainly ldap.open() generates a LDAP URL and calls
ldap.initialize(). This is implemented in Python code (see
Lib/ldap/functions.py).

> or is the new standard to use LDAP URLs??

It is the new standard. OpenLDAP 2's ldap.h marks ldap_open() as
deprecated. Well, this does not mean a lot but ldap.initialize()
also enables your application to use ldaps:// (LDAP over SSL to
separate port) and ldapi:// (LDAP over Unix domain socket).

Ciao, Michael.

Re: Install problem [python-ldap-2.0.0pre04]

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

Donal Hunt wrote:
> 
> >>> l = ldap.initialize("earth.dcu.ie:389")

In opposite to ldap.open() the function ldap.initialize() expects a
LDAP URL as stated in ldap.initialize.__doc__ and the updated docs
(see http://python-ldap.sourceforge.net/doc/python-ldap/node4.html).

Therefore your funtion call has to be:
>>> l = ldap.initialize("ldap://earth.dcu.ie:389")

> ldap.LDAPError: (2, 'No such file or directory')
> >>>

This error message is misleading I admit. It comes from the OpenLDAP
2 libs. Hmm, ldap.initialize() could check for LDAP URL format to
provide a better error message by raising a specific ValueError
exception.

Ciao, Michael.

Install problem [python-ldap-2.0.0pre04]

[Donal H. <don...@ma...>]

Hey...

Just upgraded to python-ldap-2.0.0pre04 today and tried the example in
the README and got the following error.

Have I setup something arseways?

Regards

Donal
DCU

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
----------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------
donal@linux28:~/mailman_proj > python
Python 2.2 (#3, Dec 27 2001, 01:35:33)
[GCC 2.95.2 19991024 (release)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ldap
>>> l = ldap.initialize("earth.dcu.ie:389")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/site-packages/ldap/functions.py", line
73, in initialize
    return LDAPObject(uri,trace_level,trace_file)
  File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
46, in __init__
    self._l = self._ldap_call(_ldap.initialize,uri)
  File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
59, in _ldap_call
    result = ldap._ldap_call(func,*args,**kwargs)
  File "/usr/local/lib/python2.2/site-packages/ldap/__init__.py", line
31, in _ldap_call
    result = apply(func,args,kwargs)
ldap.LDAPError: (2, 'No such file or directory')
>>>
----------------------------------------------------------------------------------------

TeX guru wanted for python-ldap docs

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

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.

ANN: python-ldap 2.0.0pre04

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

HI!

Another pre-release version of the python-ldap package is available
at

  http://sourceforge.net/project/showfiles.php?group_id=2072

Also the docs were slightly updated (but are still incomplete
though):

  http://python-ldap.sourceforge.net/download.shtml

Ciao, Michael.

Re: RedHat 7.2 + openldap security advisor => openldap 1.10alpha3 breaks down

[Joe L. <jl...@op...>]

I meant to say that python2 coexists with python (1.5.x).

On 2/4/02 9:16 AM, "Joe Little" <jl...@op...> wrote:

> 
> Actually, RedHat renamed python-2 to python2 so that it co-exists with
> python-ldap.
> 
> The issue with the libcrypt bit is that a newer version of openssl was used
> for OpenLDAP. You can get around this by rebuilding later OpenLDAP packages
> using the older openssl packages. I do not necessarily recommend this.
> 
> Separate from this, you can rebuild the python-ldap RPMS with python 1.5.x,
> by simply changing the python version string through the spec file.
> 
> On 2/4/02 6:51 AM, "Juha Ylitalo" <juh...@no...> wrote:
> 
>> We've been using Joe Little's old python-ldap 1.10alpha3 RPM packages
>> (and versions, which we have rebuilt from same source RPM). This
>> solution has worked beatifully all the way upto openldap 2.0.11.
>> Then we got that security advisory from RedHat
>> (http://www.redhat.com/support/errata/RHSA-2002-014.html)
>> 
>> Since then we've been in following kind of situation:
>> Python 1.5.2 (#1, Jul  5 2001, 03:02:19)  [GCC 2.96 20000731 (Red Hat
>> Linux 7.1
>> 2 on linux-i386
>> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>>> import ldap
>> Traceback (innermost last):
>> File "<stdin>", line 1, in ?
>> File "/usr/lib/python1.5/site-packages/python-ldap/ldap.py", line 2,
>> in ?
>>   from _ldap import __version__
>> ImportError: /lib/libcrypt.so`: shared object not open
>>>>> 
>> 
>> At first we tried to get around by rebuilding python-ldap package, but
>> that didn't seem to solve the problem. When we checked for new
>> python-ldap versions, they all seemed to require python 2.x, which is
>> understandable considering how long python 2.x versions have been out
>> and as such they won't solve our immediate problem. As far as I've
>> understood RedHat is planning to keep their default python version at
>> 1.5.2 until they come up with RedHat Linux 8.x box and for that reason,
>> we would like to avoid version upgrade as well.
>> 
>> So, if anyone has been able to get python-ldap to work in RedHat 7.2
>> Linux box with python 1.5.2 and openldap 2.0.21, I'd like to hear about
>> it. 
>> 
>> P.S. Yes, I know that python2 package exists, but if upgrade python-ldap
>> to depend on it, we would also have to upgrade py-gtk, py-gnome, ...
> 
> 
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: RedHat 7.2 + openldap security advisor => openldap 1.10alpha3 breaks down

[Joe L. <jl...@op...>]

Actually, RedHat renamed python-2 to python2 so that it co-exists with
python-ldap.

The issue with the libcrypt bit is that a newer version of openssl was used
for OpenLDAP. You can get around this by rebuilding later OpenLDAP packages
using the older openssl packages. I do not necessarily recommend this.

Separate from this, you can rebuild the python-ldap RPMS with python 1.5.x,
by simply changing the python version string through the spec file.

On 2/4/02 6:51 AM, "Juha Ylitalo" <juh...@no...> wrote:

> We've been using Joe Little's old python-ldap 1.10alpha3 RPM packages
> (and versions, which we have rebuilt from same source RPM). This
> solution has worked beatifully all the way upto openldap 2.0.11.
> Then we got that security advisory from RedHat
> (http://www.redhat.com/support/errata/RHSA-2002-014.html)
> 
> Since then we've been in following kind of situation:
> Python 1.5.2 (#1, Jul  5 2001, 03:02:19)  [GCC 2.96 20000731 (Red Hat
> Linux 7.1
> 2 on linux-i386
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>> import ldap
> Traceback (innermost last):
> File "<stdin>", line 1, in ?
> File "/usr/lib/python1.5/site-packages/python-ldap/ldap.py", line 2,
> in ?
>   from _ldap import __version__
> ImportError: /lib/libcrypt.so`: shared object not open
>>>> 
> 
> At first we tried to get around by rebuilding python-ldap package, but
> that didn't seem to solve the problem. When we checked for new
> python-ldap versions, they all seemed to require python 2.x, which is
> understandable considering how long python 2.x versions have been out
> and as such they won't solve our immediate problem. As far as I've
> understood RedHat is planning to keep their default python version at
> 1.5.2 until they come up with RedHat Linux 8.x box and for that reason,
> we would like to avoid version upgrade as well.
> 
> So, if anyone has been able to get python-ldap to work in RedHat 7.2
> Linux box with python 1.5.2 and openldap 2.0.21, I'd like to hear about
> it. 
> 
> P.S. Yes, I know that python2 package exists, but if upgrade python-ldap
> to depend on it, we would also have to upgrade py-gtk, py-gnome, ...

RedHat 7.2 + openldap security advisor => openldap 1.10alpha3 breaks down

[Juha Y. <juh...@no...>]

We've been using Joe Little's old python-ldap 1.10alpha3 RPM packages
(and versions, which we have rebuilt from same source RPM). This
solution has worked beatifully all the way upto openldap 2.0.11.
Then we got that security advisory from RedHat
(http://www.redhat.com/support/errata/RHSA-2002-014.html)

Since then we've been in following kind of situation:
Python 1.5.2 (#1, Jul  5 2001, 03:02:19)  [GCC 2.96 20000731 (Red Hat
Linux 7.1
2 on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import ldap
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python1.5/site-packages/python-ldap/ldap.py", line 2,
in ?
    from _ldap import __version__
ImportError: /lib/libcrypt.so`: shared object not open
>>>

At first we tried to get around by rebuilding python-ldap package, but
that didn't seem to solve the problem. When we checked for new
python-ldap versions, they all seemed to require python 2.x, which is
understandable considering how long python 2.x versions have been out
and as such they won't solve our immediate problem. As far as I've
understood RedHat is planning to keep their default python version at
1.5.2 until they come up with RedHat Linux 8.x box and for that reason,
we would like to avoid version upgrade as well.

So, if anyone has been able to get python-ldap to work in RedHat 7.2
Linux box with python 1.5.2 and openldap 2.0.21, I'd like to hear about
it. 

P.S. Yes, I know that python2 package exists, but if upgrade python-ldap
to depend on it, we would also have to upgrade py-gtk, py-gnome, ...

-- 
Juha Ylitalo         juh...@no...         <work e-mail>
+358 40 562 6152     juh...@ik...              <rest of e-mail>
"Some tools are used, because its policy, others because they are good."

Re: Importing LDIFs with Python-LDAP

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

Peter van Rensburg wrote:
> 
> The "dn: blabla" line is not preffered at the top of the ldif. Seems
> like specifying the dn to ldap.add_s is enough. Duh.
> 
> Somewhere between Python-LDAP and OpenLDAP it cannot handle multiple
> lists with the same attribute name (in this case objectclass). This does
> work with Netscape's directory server though.

You should check out the module ldif and the sub-module ldap.modlist
shipped with python-ldap for this kind of task. I have to admit that
there's currently no good documentation, only pydoc generated stuff
linked at http://python-ldap.sf.net/docs.html.

Note that you have to take care that your LDIF file contains the
entries in the right tree-like order. This is not necessarily true
if exporting LDIF via e.g. OpenLDAP's ldapsearch tool.

Ciao, Michael.

Re: Importing LDIFs with Python-LDAP

[Peter v. R. <pe...@sy...>]

Uhm okay. My bad. 

The "dn: blabla" line is not preffered at the top of the ldif. Seems
like specifying the dn to ldap.add_s is enough. Duh.

Somewhere between Python-LDAP and OpenLDAP it cannot handle multiple
lists with the same attribute name (in this case objectclass). This does
work with Netscape's directory server though. 

For those that care, I modified addLdif so it looks something like this,
please bear in mind my inexperience (blatantly obvious I'm sure) with
Python:

def addLdif(ldapConn, dn, fileName):
   print "Entering addLdif()"
   try:
      dataFile = open(fileName, 'r')
   except:
      print "Error opening ldif file '" + fileName + "'"
      print "Aborting installation!"
      sys.exit()

   fileData = dataFile.readlines()
   dataFile.close()

   ldapData = []
   ldapDataDictionary = {}

   for line in fileData:
      index = string.find(line, ':')
      attributeName = subString(line,0,index)
      attributeValue = string.strip(subString(line,index+1))
  
      if attributeName in ldapDataDictionary.keys():

         # make "deep" copy, reference copy gets screwed up somehow
         tempList = []
         for atr in ldapDataDictionary[attributeName]:
            tempList.append(atr)
         tempList.append(attributeValue)

         ldapDataDictionary[attributeName] = tempList
      else:
         ldapDataDictionary[attributeName] = [ attributeValue ]

   for key in ldapDataDictionary.keys():
      ldapData = ldapData + [( key, ldapDataDictionary[key]), ]

   try:
      ldapConn.add_s(dn, ldapData)
   except:
      raise


Cheers,
Peter

On Sat, 2002-02-02 at 11:18, Peter van Rensburg wrote:
> Hi 
> 
> I'm using openldap 2.0.22 and the latest Python-LDAP and python 2.2 (I
> also tried with a very old version of Python-LDAP and python 1.5.2 with
> the same results.)
> 
> I stop openldap, rm all the .db files, start openldap, so it's a "fresh"
> install. 
> 
> The LDIF I'm trying to import looks like this:
> 
> dn: o=DOTC
> objectclass: top
> objectclass: organization
> o: DOTC
> 
> Using ldapadd: 
> ~openldap/bin/ldapadd -x -D"cn=Directory Manager,o=DOTC" -w xx -f
> org2.ldif
> 
> works fine without any errors.
> 
> Using a basic python script, something like this:
> 
> import sys
> import os
> import ldap
> import string
> 
> def subString(strinput, begin, end=0):
>    if 0 == end:
>       end = len(strinput)
>    
>    result = ""
>    for i in range(begin,end):
>       result = result + strinput[i]
>    
>    return result
> 
> def addLdif(ldapConn, dn, fileName):
>    print "Entering addLdif()"
>    try:
>       dataFile = open(fileName, 'r')
>    except:
>       print "Error opening ldif file '" + fileName + "'"
>       print "Aborting installation!"
>       sys.exit()
> 
>    print "reading lines"
>    fileData = dataFile.readlines()
>    dataFile.close()
>    print "done reading lines"
> 
>    ldapData = []
> 
>    print "constructing _ldapData"
>    print 
>    for line in fileData:
>       print "looking at line: " + line
>       index = string.find(line, ':')
>       ldapData = ldapData + [(subString(line,0,index),
> [string.strip(subString(line,index+1))]), ]
> 
>    print "_ldapData = " 
>    print ldapData
>    
>    try:
>       ldapConn.add_s(dn, ldapData)
>    except:
>       raise
> 
> def main(argv):
>    try:
>       ldapObj = ldap.open("localhost", 389)
>       ldapObj.simple_bind_s("cn=Directory Manager,o=DOTC", "xx")
>    except:
>       print "[main] Ldap open or bind failed!!"
>       return 0
> 
>    #try:
>    addLdif(ldapObj, "o=DOTC", "org2.ldif")
>    #except:
>    #   print "[main] addLdif failed!!"
>    #   return 0
> 
>  
> if __name__ == '__main__':
>    sys.exit(main(sys.argv))
> 
> produces the following error:
> 
>   File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
> 121, in add_s
>     self.result(msgid)
>   File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
> 355, in result
>     ldap_result = self._ldap_call(self._l.result,msgid,0,0)
>   File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
> 59, in _ldap_call
>     result = ldap._ldap_call(func,*args,**kwargs)
>   File "/usr/local/lib/python2.2/site-packages/ldap/__init__.py", line
> 31, in _ldap_call
>     result = apply(func,args,kwargs)
> ldap.UNDEFINED_TYPE: {'info': 'dn: attribute type undefined', 'desc':
> 'Undefined attribute type'}
> 
> The first line in the LDIF being "dn: blabla" is specified in the RFC
> for LDIFs. If I remove that line (dn: o=DOTC) I get the following error:
> 
>   File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
> 121, in add_s
>     self.result(msgid)
>   File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
> 343, in result
>     ldap_result = self._ldap_call(self._l.result,msgid,0,0)
>   File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
> 59, in _ldap_call
>     result = ldap._ldap_call(func,*args,**kwargs)
>   File "/usr/local/lib/python2.2/site-packages/ldap/__init__.py", line
> 31, in _ldap_call
>     result = apply(func,args,kwargs)
> ldap.TYPE_OR_VALUE_EXISTS: {'info': 'attribute provided more than once',
> 'desc': 'Type or value exists'}
> 
> 
> This works fine (without the "dn: blabla" at the start of the ldif) with
> IPlanet/Netscape's directory server. 
> 
> Does anyone know what is going on here?
> 
> Many thanks,
> Peter
> 

Importing LDIFs with Python-LDAP

[Peter v. R. <pe...@sy...>]

Hi 

I'm using openldap 2.0.22 and the latest Python-LDAP and python 2.2 (I
also tried with a very old version of Python-LDAP and python 1.5.2 with
the same results.)

I stop openldap, rm all the .db files, start openldap, so it's a "fresh"
install. 

The LDIF I'm trying to import looks like this:

dn: o=DOTC
objectclass: top
objectclass: organization
o: DOTC

Using ldapadd: 
~openldap/bin/ldapadd -x -D"cn=Directory Manager,o=DOTC" -w xx -f
org2.ldif

works fine without any errors.

Using a basic python script, something like this:

import sys
import os
import ldap
import string

def subString(strinput, begin, end=0):
   if 0 == end:
      end = len(strinput)
   
   result = ""
   for i in range(begin,end):
      result = result + strinput[i]
   
   return result

def addLdif(ldapConn, dn, fileName):
   print "Entering addLdif()"
   try:
      dataFile = open(fileName, 'r')
   except:
      print "Error opening ldif file '" + fileName + "'"
      print "Aborting installation!"
      sys.exit()

   print "reading lines"
   fileData = dataFile.readlines()
   dataFile.close()
   print "done reading lines"

   ldapData = []

   print "constructing _ldapData"
   print 
   for line in fileData:
      print "looking at line: " + line
      index = string.find(line, ':')
      ldapData = ldapData + [(subString(line,0,index),
[string.strip(subString(line,index+1))]), ]

   print "_ldapData = " 
   print ldapData
   
   try:
      ldapConn.add_s(dn, ldapData)
   except:
      raise

def main(argv):
   try:
      ldapObj = ldap.open("localhost", 389)
      ldapObj.simple_bind_s("cn=Directory Manager,o=DOTC", "xx")
   except:
      print "[main] Ldap open or bind failed!!"
      return 0

   #try:
   addLdif(ldapObj, "o=DOTC", "org2.ldif")
   #except:
   #   print "[main] addLdif failed!!"
   #   return 0

 
if __name__ == '__main__':
   sys.exit(main(sys.argv))

produces the following error:

  File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
121, in add_s
    self.result(msgid)
  File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
355, in result
    ldap_result = self._ldap_call(self._l.result,msgid,0,0)
  File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
59, in _ldap_call
    result = ldap._ldap_call(func,*args,**kwargs)
  File "/usr/local/lib/python2.2/site-packages/ldap/__init__.py", line
31, in _ldap_call
    result = apply(func,args,kwargs)
ldap.UNDEFINED_TYPE: {'info': 'dn: attribute type undefined', 'desc':
'Undefined attribute type'}

The first line in the LDIF being "dn: blabla" is specified in the RFC
for LDIFs. If I remove that line (dn: o=DOTC) I get the following error:

  File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
121, in add_s
    self.result(msgid)
  File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
343, in result
    ldap_result = self._ldap_call(self._l.result,msgid,0,0)
  File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
59, in _ldap_call
    result = ldap._ldap_call(func,*args,**kwargs)
  File "/usr/local/lib/python2.2/site-packages/ldap/__init__.py", line
31, in _ldap_call
    result = apply(func,args,kwargs)
ldap.TYPE_OR_VALUE_EXISTS: {'info': 'attribute provided more than once',
'desc': 'Type or value exists'}


This works fine (without the "dn: blabla" at the start of the ldif) with
IPlanet/Netscape's directory server. 

Does anyone know what is going on here?

Many thanks,
Peter

Re: subtle breakage

[Joe L. <jl...@op...>]

I did use distutils. Until the 2.0.0pre series, including CVS, it called
itself "python-ldap".

On 2/2/02 3:17 AM, "Michael Str=F6der" <mi...@st...> wrote:

> Joe Little wrote:
>>=20
>> I noticed something subtle that changed with the pre- releases. RPM and =
most
>> unix packages are case sensitive just as their unix underpinnings are.
>>=20
>> So, Python-LDAP does not upgrade against python-ldap.. Currently, for my
>> next build, I will need to explicitly target source files and still gene=
rate
>> python-ldap-<blah>.rpm --- Do you want to
>=20
> IMHO David chose "Python-LDAP" for whatever reason. You didn't use
> DistUtils to build your RPM before, did you?
>=20
>> b) revert back to the original name
>=20
> No problem, I've commited setup.py with package name being set to
> "python-ldap". I'm also feeling more comfortable with this.
>=20
> Ciao, Michael.
>=20
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: subtle breakage

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

Joe Little wrote:
> 
> I noticed something subtle that changed with the pre- releases. RPM and most
> unix packages are case sensitive just as their unix underpinnings are.
> 
> So, Python-LDAP does not upgrade against python-ldap.. Currently, for my
> next build, I will need to explicitly target source files and still generate
> python-ldap-<blah>.rpm --- Do you want to

IMHO David chose "Python-LDAP" for whatever reason. You didn't use
DistUtils to build your RPM before, did you?

> b) revert back to the original name

No problem, I've commited setup.py with package name being set to
"python-ldap". I'm also feeling more comfortable with this.

Ciao, Michael.

cross-post: openldap 2.0.22 and python-ldap-2.0.0pre03 RPMS released

[Joe L. <jl...@op...>]

ftp://ftp.open-it.org/pub/redhat7.2

Both SRPMS and RPMS for python-ldap's latest pre-release w/ Michael's
updated docs in PDF format and the latest OpenLDAP build have been posted.
Enjoy.

core-devers: this is what I'll be building on (with expected updates on from
python-ldap)

subtle breakage

[Joe L. <jl...@op...>]

I noticed something subtle that changed with the pre- releases. RPM and mos=
t
unix packages are case sensitive just as their unix underpinnings are.

So, Python-LDAP does not upgrade against python-ldap.. Currently, for my
next build, I will need to explicitly target source files and still generat=
e
python-ldap-<blah>.rpm --- Do you want to

a) break upgrade paths and keep the new name
or
b) revert back to the original name


On 2/1/02 4:36 AM, "Michael Str=F6der" <mi...@st...> wrote:

> HI!
>=20
> Another pre-release version of python-ldap is available at
>=20
> http://sourceforge.net/project/showfiles.php?group_id=3D2072
>=20
> Please test!
>=20
> Ciao, Michael.
>=20
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Updated docs

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

HI!

I did some documentation updates. See 

  http://python-ldap.sourceforge.net/docs.shtml

Even more nice would be if someone jumps on in. See documentation
sources in Docs/lib*.tex of CVS tree.

Ciao, Michael.

Re: ANN: Python-LDAP 2.0.0pre02

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

Jens Vagelpohl wrote:
> 
> On Friday, February 1, 2002, at 08:40 , Michael Ströder wrote:
> >
> > Sorry, I ran into a hen-and-egg problem: I wanted to avoid having to
> > set the version number in two soures (setup.py and
> > Lib/ldap/__init__.py). But one cannot import module ldap without
> > installed _ldap before. :-(
>
> i don't quite follow you on this, it seemed to work fine on pre02... :)

It worked for you since you already had an installed python-ldap.
But keep testing anyway.

Ciao, Michael.

Re: signature of ldap.open changed?

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

Michael Ströder wrote:
> 
> I have to admit I've never used open() in that way. I've checked in
> a modified version compliant to the old docs.

Note that ldap.open() wraps ldap_open() which is noted as
deprecated in OpenLDAP 2's ldap.h. Try to use ldap.initialize()
which wraps ldap_initialize() whereever possible. I've updated
most code examples under Demo/.

Ciao, Michael.

Re: ANN: Python-LDAP 2.0.0pre02

[Jens V. <je...@zo...>]

i don't quite follow you on this, it seemed to work fine on pre02... :)

pre03 compiles and works fine, too. (running on RH7.2, OpenLDAP 2.0.21,=20=

python2.1.2)

jens


On Friday, February 1, 2002, at 08:40 , Michael Str=F6der wrote:
>
> Sorry, I ran into a hen-and-egg problem: I wanted to avoid having to
> set the version number in two soures (setup.py and
> Lib/ldap/__init__.py). But one cannot import module ldap without
> installed _ldap before. :-(
>
> Please, check out new Python-LDAP 2.0.0pre03 which does not have
> this problem. Might take a while before it shows up. Grr, SF's file
> release system really sucks.
>
> Ciao, Michael.
>
>

Re: ANN: Python-LDAP 2.0.0pre02

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

Jens Vagelpohl wrote:
> 
> i'm getting this:
> 
>  >>> import ldap
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>    File "/usr/local/lib/python2.1/site-packages/ldap/__init__.py", line 5,
> in ?
>      from _ldap import *
> ImportError: liblber.so.2: cannot load shared object file: No such file or
> directory
>  >>>
> 
> i'm on YellowDog linux 2.1 (a redhat 7 clone for mac) with OpenLDAP 2.0.18
> and Python2.1.2. the messages from setup.py build and setup.py compile did
> not contain any errors during compilation.

Sorry, I ran into a hen-and-egg problem: I wanted to avoid having to
set the version number in two soures (setup.py and
Lib/ldap/__init__.py). But one cannot import module ldap without
installed _ldap before. :-(

Please, check out new Python-LDAP 2.0.0pre03 which does not have
this problem. Might take a while before it shows up. Grr, SF's file
release system really sucks.

Ciao, Michael.