python-ldap-dev — discussion among developers

Re: latest ldap.i UPDATE!

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

My only concern is your libraries. do an ldd on the ldapcmodule (there is
also the lbermodule.so). Make sure it sees the same ldap libraries you
built it with.

I'd then use the test ldapsearch in Sacha's test directory (with the
aforementioned changed in ldap.open instead of ldap.LDAP for opening a
connection.

On Wed, 30 May 2001, Michael Str=F6der wrote:

> HI!
>
> I've built the swig-ldap with Joe's ldap.i and lber.i. After
> modifications to lber.i import works now. But I still have some
> problems.
>
> Note: The module is built as ldapcmodule.so on my system.
>
> Python 2.1 (#8, Apr 20 2001, 19:22:23)
> [GCC 2.95.2 19991024 (release)] on linux2
> Type "copyright", "credits" or "license" for more information.
> >>> import ldapc
> >>> attrs=3Dldapc.string_array(1)
> >>> ldapc.string_set(attrs,0,'objectClass')
> 'objectClass'
> >>> l=3Dldapc.open('localhost',389)
> >>> resPtr=3Dldapc.makeLDAPMessagePtrPtr()
> >>> status=3Dldapc.search_s(l,'O=3DMICHAELS',ldapc.SCOPE_BASE,
> '(objectClass=3D*)',attrs,0,resPtr)
> Segmentation fault
>
> Am I doing something wrong?
>
> I have to admit that these kind of error messages endorse my
> prejudices about SWIG-produced modules...
>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: latest ldap.i UPDATE!

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

HI!

I've built the swig-ldap with Joe's ldap.i and lber.i. After
modifications to lber.i import works now. But I still have some
problems.

Note: The module is built as ldapcmodule.so on my system.

Python 2.1 (#8, Apr 20 2001, 19:22:23) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import ldapc
>>> attrs=ldapc.string_array(1)
>>> ldapc.string_set(attrs,0,'objectClass')
'objectClass'
>>> l=ldapc.open('localhost',389)
>>> resPtr=ldapc.makeLDAPMessagePtrPtr()
>>> status=ldapc.search_s(l,'O=MICHAELS',ldapc.SCOPE_BASE,
'(objectClass=*)',attrs,0,resPtr)
Segmentation fault

Am I doing something wrong?

I have to admit that these kind of error messages endorse my
prejudices about SWIG-produced modules...

Ciao, Michael.

Re: latest ldap.i UPDATE!

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

Ok.. stuck on windows box for network access, but here's the deal.

edit lber.i that I submitted, and comment out these function defs:

lber_debug
lber_pbrint
ber_dump

Next, edit Sascha's make file to explicitly include ldap50 and lber50 as
your included libraries. Last, make sure /opt/ldapsdk/lib or wherever
mozilla is in your LD_LIBRARY_PATH, and before any other ldap libs (like
Oracle, OpenLDAP, or the like)

I did a test ldapsearch with the test dir (its now ldap.open(host,port)!!=
)
with the libraries and ldap.py/lber.py files present, and it all worked
fine against my openldap 2.0.x server. Yeah

Kudos to Michael for catching my not testing my latest lber.i file before
submitting to the list :)



On Mon, 28 May 2001, Michael Str=F6der wrote:

> Joe Little wrote:
> >
> > I've sent this to Sascha. It now contains the extended LDAP v3 API, w=
ith
> > only the netscape quasi-specific v3 extensions (server side sorts, an=
d
> > other server or client side ops)
> >
> > build against Mozilla and openldap 2.x, but I need to check the openl=
dap
> > 2.x again for some things. Still working..
>
> I tried to compile it against Netscape/Mozilla LDAP C SDK 5.0
> (binaries from Sun's web site downloaded today). After some tweaking
> of the Makefile (see attachment) it was built.
>
> But during import of ldapc it chokes with:
>
> Traceback (most recent call last):
>   File "tests/ldapsearch.py", line 9, in ?
>     import ldap
>   File "/home/michael/src/swig-ldap-0.17-stable-13/ldap.py", line 2,
> in ?
>     import ldapc
> ImportError: undefined symbol: lber_debug
>
> Tried this again with OpenLDAP 2.0.11 libs. Same result.
>
> Ciao, Michael.

Re: problem using python-ldap with python 2.1 and OpenLDAP 2.0.11

[Daniel S. <da...@ma...>]

On Tue, May 29, 2001 at 05:18:51PM +0200, Daniel Schlenzig wrote:
> On Tue, May 29, 2001 at 02:43:33PM +0200, Michael Str=F6der wrote:
>=20
> > Daniel Schlenzig wrote:
> > >=20
> > > I patched python-ldap-1.10alpha3 to have a OpenLDAP 2.0.x conformin=
g
> > > constants.c. Then I tried to run configure.
> >=20
> > Probably your patch is incomplete. See:
> >=20
> > http://www.geocrawler.com/lists/3/SourceForge/1568/0/5834291/
> Ok, I=B4ve downloaded the source RPMs and compiled them on my system. I=
 got a=20
> lot of compiler warnings most of them in template.c. After the installa=
tion
> of the new modules I tried to run the little test program, but it still
> fails. Any Ideas?
I had an EBTE =3D|.=20

Now it works for me, too. I had a little problem with old binaries. After
removing them from lib/python2.1/site-packages and "make install" it work=
s
perfectly. I=B4m sorry, if I caused any confusion.

bye, Daniel

Re: latest ldap.i

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

I'll need to look into the lber libs and their build mechanism.

On Mon, 28 May 2001, Michael Str=F6der wrote:

> Joe Little wrote:
> >
> > I've sent this to Sascha. It now contains the extended LDAP v3 API, w=
ith
> > only the netscape quasi-specific v3 extensions (server side sorts, an=
d
> > other server or client side ops)
> >
> > build against Mozilla and openldap 2.x, but I need to check the openl=
dap
> > 2.x again for some things. Still working..
>
> I tried to compile it against Netscape/Mozilla LDAP C SDK 5.0
> (binaries from Sun's web site downloaded today). After some tweaking
> of the Makefile (see attachment) it was built.
>
> But during import of ldapc it chokes with:
>
> Traceback (most recent call last):
>   File "tests/ldapsearch.py", line 9, in ?
>     import ldap
>   File "/home/michael/src/swig-ldap-0.17-stable-13/ldap.py", line 2,
> in ?
>     import ldapc
> ImportError: undefined symbol: lber_debug
>
> Tried this again with OpenLDAP 2.0.11 libs. Same result.
>
> Ciao, Michael.

Re: problem using python-ldap with python 2.1 and OpenLDAP 2.0.11

[Daniel S. <da...@ma...>]

On Tue, May 29, 2001 at 02:43:33PM +0200, Michael Str=F6der wrote:

> Daniel Schlenzig wrote:
> >=20
> > I patched python-ldap-1.10alpha3 to have a OpenLDAP 2.0.x conforming
> > constants.c. Then I tried to run configure.
>=20
> Probably your patch is incomplete. See:
>=20
> http://www.geocrawler.com/lists/3/SourceForge/1568/0/5834291/
Ok, I=B4ve downloaded the source RPMs and compiled them on my system. I g=
ot a=20
lot of compiler warnings most of them in template.c. After the installati=
on
of the new modules I tried to run the little test program, but it still
fails. Any Ideas?

bye, Daniel

Re: problem using python-ldap with python 2.1 and OpenLDAP 2.0.11

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

Daniel Schlenzig wrote:
> =

> I patched python-ldap-1.10alpha3 to have a OpenLDAP 2.0.x conforming
> constants.c. Then I tried to run configure.

Probably your patch is incomplete. See:

http://www.geocrawler.com/lists/3/SourceForge/1568/0/5834291/

> ps. Currently I=B4m using utf8 encoded DNs but I testet it also with no=
rmal
>     US ASCII encoded DNs and it did not work either.

This does not matter for python-ldap. Both are simply strings and
passed through.

Ciao, Michael.

problem using python-ldap with python 2.1 and OpenLDAP 2.0.11

[Daniel S. <da...@ma...>]

Hi,

I=B4m using ActiveState Python 2.1 and OpenLDAP 2.0.11. Since I want to b=
e
able to access my LDAP tree using python, I came across the python ldap
web page. First of all it looks very fine, but I ran into a severe proble=
m=20
that I=B4m unable to solve by myself.

I patched python-ldap-1.10alpha3 to have a OpenLDAP 2.0.x conforming
constants.c. Then I tried to run configure.

First configure complained about a missing libldap.so, although it is in
the correct place (/usr/local/lib). I then patched configure to find it.

I built the module, but it could not load because of an symbol it could
not find. After some searching I found out, that I had to link the=20
module  with libresolv.=20

After the next build I tried to run a little test program:

--- cut ---

import sys
import _ldap
l =3D _ldap.open("localhost")
l.simple_bind_s("", "")
res =3D l.search_s("o=3DMastyx,c=3DDE", _ldap.SCOPE_SUBTREE, "objectClass=
=3D*" )
print res
l.unbind()
			=09
--- cut ---

And all it gives me is a:

Traceback (most recent call last):
File "tmp/foo.py", line 5, in ?
      "objectClass=3D*" )
SystemError: Objects/dictobject.c:471: bad argument to internal function
     =20
So I startet to strace the program.It connects to the server, sends a req=
uest
and gets back the first level unter the requested dn. Right after that it
bails out.

Does anyone of you have an idea what I can do to make it work?

bye, Daniel

ps. Currently I=B4m using utf8 encoded DNs but I testet it also with norm=
al
    US ASCII encoded DNs and it did not work either.

Re: latest ldap.i

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

Joe Little wrote:
> 
> I've sent this to Sascha. It now contains the extended LDAP v3 API, with
> only the netscape quasi-specific v3 extensions (server side sorts, and
> other server or client side ops)
> 
> build against Mozilla and openldap 2.x, but I need to check the openldap
> 2.x again for some things. Still working..

I tried to compile it against Netscape/Mozilla LDAP C SDK 5.0
(binaries from Sun's web site downloaded today). After some tweaking
of the Makefile (see attachment) it was built.

But during import of ldapc it chokes with:

Traceback (most recent call last):
  File "tests/ldapsearch.py", line 9, in ?
    import ldap
  File "/home/michael/src/swig-ldap-0.17-stable-13/ldap.py", line 2,
in ?
    import ldapc
ImportError: undefined symbol: lber_debug

Tried this again with OpenLDAP 2.0.11 libs. Same result.

Ciao, Michael.

konstantin's patches now in RPM

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

I've place my python-ldap-*-3 RPMs (i386 and src) for RedHat 7.1 on
Open-IT.org. Yes, they now include the full patches in all their glory.
Enjoy. Remember, these are built against python 1.5.2


On Fri, 25 May 2001, Joe Little wrote:

> included are ldap/lber swig files (uses swig 1.3a5 or whatever the late=
st
> snapshot is..). They _compile_ against both OpenLDAP 2.0.x and mozilla
> ldap sdk 5.0. They only match Sascha's current swig files and do not as
> yet address other API needs. It is a work in progress, but I wnated to
> post it. You can grap Sasha's swig-ldap package and replace the
> ldap/lber.i files (remember to erase *_swap.c!) and then "make" it.
>
> On Fri, 25 May 2001, Michael Str=F6der wrote:
>
> > Joe Little wrote:
> > >
> > > I do understand that openldap 1.x is being maintained by OpenLDAP, =
but the
> > > distribution sets no longer maintain such. Thus any software create=
d with
> > > the hope for inclusion in a distro (like my management software ide=
as)
> > > need to be on the current build set.
> >
> > I disagree. E.g. recent S.u.S.E. Linux 7.1 ships with both libs and
> > python-ldap 1.10a3. I think Red Hat does also. Not sure about
> > Debian.
> >
> > Believe me I have exactly the same problems with 1st-level-support
> > for web2ldap.
> >
> > > I'll need to look further into the 2.x thread-safe issues. It would=
 appear
> > > from various notes/code that OpenLDAP 2.0.7 and beyond is now threa=
d-safe.
> >
> > No, it isn't.
> >
> > > I saw your message from before. Is there anything more current that
> > > confirms/refutes that?
> >
> > This message by Kurt Zeilenga was at the time 2.0.7 was already out.
> > Please re-read it. Note that there are still significant changes
> > with the OpenLDAP 2.0.x releases. You can't stick to 2.0.7 (2.0.11
> > was released yesterday).
> >
> > Regarding re-entrant LDAP libs Kurt mentioned ldap_r which provides
> > sort of a re-entrant lib but not without taking special care in the
> > LDAP application's C code. It might be a solution to wrap this into
> > a low-level API and write a thread-safe wrapper class around it.
> >
> > > I also DLed the newly minted ldapsdk5.0 for mozilla, and will work =
on the
> > > SWIG stuff there.
> >
> > According to various messages by Kurt Zeilenga and others this is
> > the only thread-safe LDAP lib.
> >
> > -------- Original Message --------
> > Subject: Re: [ldap] LDAP C SDK's thread-safe?
> > Date: Tue, 08 May 2001 09:08:29 -0400
> > From: mc...@ne... (Mark C Smith)
> > Organization: iPlanet E-Commerce Solutions
> > To: mi...@st...
> >
> > Just found this in my overflowing inbox... the Netscape/Mozilla SDK
> > is
> > multithread safe, although in older versions you must write and
> > install
> > some callback functions to allow for safe sharing of one LDAP *
> > session
> > handle among multiple threads.  This is documented.
> >
> > -Mark
> > -----------------------------------
> >
> > > The OpenLDAP 2.x include files give swig indigestion. My
> > > current approach to this whole mess is the get a passable swig modu=
le for
> > > some LDAP v3 library working, and then work with python-ldap (ie yo=
u?) to
> > > build toward a stable solution.
> >
> > Feel free to send me code for testing. Please mention the SWIG
> > version it requires. I have currently installed swig-1.3a5.
> >
> > > Once we have a working v3 backend to
> > > python-ldap, it will be easier to code for the differences in each =
SDK.
> > > This is why I DLed the mozilla one, since it was one you felt was m=
ost
> > > complete. If we can move on that, we have something to work with.
> >
> > I'd suggest to write low-level SWIG-wrappers around each LDAP C SDK
> > and write a nice Python class API for common use above it. So you
> > don't have to deal with the dirty details at the C level. Just wrap
> > 1:1 *everything* in libldap and libber and let me do the
> > higher-level abstraction.
> >
> > > At the same time, I'll be using the current python-ldap w/ openldap=
 2.x
> > > patches to work on the ZopeLDAP adaptor and that code. I hope to ge=
t the
> > > sdk bit done this weekend, and devote a good week to the Zope code.
> >
> > I'm pretty sure Jens will catch up quickly and modify the ZopeLDAP
> > stuff if there's a new usable API. Leave that part up to him.
> >
> > > That is where I stand, and I hope its agreeable to you. My hand is
> > > "raised" on the maintenance issue, I am still just unsure of how be=
st to
> > > tackle the problem.
> >
> > Since you are able to produce the SWIG wrapper code simply stick to
> > that. Leave the Python part to me and the Zope part to Jens. Is that
> > clear enough?
> >
> > Ciao, Michael.
> >
>

Re: other things

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

included are ldap/lber swig files (uses swig 1.3a5 or whatever the latest
snapshot is..). They _compile_ against both OpenLDAP 2.0.x and mozilla
ldap sdk 5.0. They only match Sascha's current swig files and do not as
yet address other API needs. It is a work in progress, but I wnated to
post it. You can grap Sasha's swig-ldap package and replace the
ldap/lber.i files (remember to erase *_swap.c!) and then "make" it.

On Fri, 25 May 2001, Michael Str=F6der wrote:

> Joe Little wrote:
> >
> > I do understand that openldap 1.x is being maintained by OpenLDAP, bu=
t the
> > distribution sets no longer maintain such. Thus any software created =
with
> > the hope for inclusion in a distro (like my management software ideas=
)
> > need to be on the current build set.
>
> I disagree. E.g. recent S.u.S.E. Linux 7.1 ships with both libs and
> python-ldap 1.10a3. I think Red Hat does also. Not sure about
> Debian.
>
> Believe me I have exactly the same problems with 1st-level-support
> for web2ldap.
>
> > I'll need to look further into the 2.x thread-safe issues. It would a=
ppear
> > from various notes/code that OpenLDAP 2.0.7 and beyond is now thread-=
safe.
>
> No, it isn't.
>
> > I saw your message from before. Is there anything more current that
> > confirms/refutes that?
>
> This message by Kurt Zeilenga was at the time 2.0.7 was already out.
> Please re-read it. Note that there are still significant changes
> with the OpenLDAP 2.0.x releases. You can't stick to 2.0.7 (2.0.11
> was released yesterday).
>
> Regarding re-entrant LDAP libs Kurt mentioned ldap_r which provides
> sort of a re-entrant lib but not without taking special care in the
> LDAP application's C code. It might be a solution to wrap this into
> a low-level API and write a thread-safe wrapper class around it.
>
> > I also DLed the newly minted ldapsdk5.0 for mozilla, and will work on=
 the
> > SWIG stuff there.
>
> According to various messages by Kurt Zeilenga and others this is
> the only thread-safe LDAP lib.
>
> -------- Original Message --------
> Subject: Re: [ldap] LDAP C SDK's thread-safe?
> Date: Tue, 08 May 2001 09:08:29 -0400
> From: mc...@ne... (Mark C Smith)
> Organization: iPlanet E-Commerce Solutions
> To: mi...@st...
>
> Just found this in my overflowing inbox... the Netscape/Mozilla SDK
> is
> multithread safe, although in older versions you must write and
> install
> some callback functions to allow for safe sharing of one LDAP *
> session
> handle among multiple threads.  This is documented.
>
> -Mark
> -----------------------------------
>
> > The OpenLDAP 2.x include files give swig indigestion. My
> > current approach to this whole mess is the get a passable swig module=
 for
> > some LDAP v3 library working, and then work with python-ldap (ie you?=
) to
> > build toward a stable solution.
>
> Feel free to send me code for testing. Please mention the SWIG
> version it requires. I have currently installed swig-1.3a5.
>
> > Once we have a working v3 backend to
> > python-ldap, it will be easier to code for the differences in each SD=
K.
> > This is why I DLed the mozilla one, since it was one you felt was mos=
t
> > complete. If we can move on that, we have something to work with.
>
> I'd suggest to write low-level SWIG-wrappers around each LDAP C SDK
> and write a nice Python class API for common use above it. So you
> don't have to deal with the dirty details at the C level. Just wrap
> 1:1 *everything* in libldap and libber and let me do the
> higher-level abstraction.
>
> > At the same time, I'll be using the current python-ldap w/ openldap 2=
.x
> > patches to work on the ZopeLDAP adaptor and that code. I hope to get =
the
> > sdk bit done this weekend, and devote a good week to the Zope code.
>
> I'm pretty sure Jens will catch up quickly and modify the ZopeLDAP
> stuff if there's a new usable API. Leave that part up to him.
>
> > That is where I stand, and I hope its agreeable to you. My hand is
> > "raised" on the maintenance issue, I am still just unsure of how best=
 to
> > tackle the problem.
>
> Since you are able to produce the SWIG wrapper code simply stick to
> that. Leave the Python part to me and the Zope part to Jens. Is that
> clear enough?
>
> Ciao, Michael.
>

Re: compilation error

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

David Leonard wrote:
> 
> mmmm, release... everyone is eager to do an interim release.
> I think 1.10 could be "released" by just renaming 1.10a3 to 1.10 :)

No! That's not right. Review the CVS logs!

There were patches after 1.10a3 adressing proper handling of (error)
results of ldap_result (also by Konstantin) which slightly changes
the result returned by LDAPObject.result() method in case of no
result received. (Uuuh, did anybody of you understand this sentence?
;-)

AFAIK also another memory leak was fixed (if you didn't loose the
patch... ;-).

> 1.11 can also appear soon. it just needs a little more removing of
> non-openldapisms testing and then packaging.

No! Just leave it as it is. Please, please...

Call it 1.11 to avoid confusion because *it is* significantly
different from 1.10a3. But it's stable.

Ciao, Michael.

Re: compilation error

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

Joe Little wrote:
> 
> Does anyone out there have original copies of these? The mailing list
> softwre did a good munge job on it.

I've attached a tar.gz containing the diffs.

> To quickly answer your last message, the package did not use the setup.py
> component. I'm using hte non-CVS version of 1.10a3. Should ther be another
> "release" this stage just to seperate things? Maybe a4 or b1?

Yes. I'd also suggest to make a 1.11 release before doing anything
else. The CVS version without any OpenLDAP 2.0.x related stuff works
pretty well.

Ciao, Michael.

Re: compilation error

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

On Thu, 24 May 2001, Joe Little typed thusly:

> Does anyone out there have original copies of these? The mailing list
> softwre did a good munge job on it.

choose the 'Print' option at the top of the web page. you'll get a 'raw'
version of the message which you can save to a file, or pipe straight into
patch if you're keen.

> To quickly answer your last message, the package did not use the setup.py
> component. I'm using hte non-CVS version of 1.10a3. Should ther be another
> "release" this stage just to seperate things? Maybe a4 or b1?

mmmm, release... everyone is eager to do an interim release.
I think 1.10 could be "released" by just renaming 1.10a3 to 1.10 :)

1.11 can also appear soon. it just needs a little more removing of
non-openldapisms testing and then packaging.

d
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

I put my chin on my knee, and looked for flaws in the soft grain of my
beige plastic monitor casing. - Julian Assange

Re: compilation error

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

Does anyone out there have original copies of these? The mailing list
softwre did a good munge job on it.

For instance, in the errors.c patch it has a nonsensical:


     +#if defined(LDAP_API_VERSION)
     +               if (ldap_get_option(l, LDAP_OPT_MATCHED_DN, &matched)
>= 0
     +                       && matched != NULL) {
     +                   if (*matched != `f, name );
     +#endif /* defined(LDAP_API_VERSION) */
      }

      /* set attribute */
     @@ -1798,7 +1865,12 @@
      static int
      setattr( LDAPObject* self, char* name, PyObject* value )
      {
     +#if defined(LDAP_API_VERSION)

First, `f, name doesn't work. Second, I found out that the file being
edited was actually LDAPObject.c and not errors.c at that point. A whole
segment is thus missing and a 4th file should be in the MMIME encode. The
message is offically screwed :)

To quickly answer your last message, the package did not use the setup.py
component. I'm using hte non-CVS version of 1.10a3. Should ther be another
"release" this stage just to seperate things? Maybe a4 or b1?



On Fri, 25 May 2001, David Leonard wrote:

> On Thu, 24 May 2001, Joe Little typed thusly:
>
> > BTW -- can anyone post to the list the most recent patches (Konstanin's)
>
> shame on you! ;) go to the python-ldap web page, click on mailing list archive,
> type 'konstantin patch' in the search field... and the first result is:
>
> http://www.geocrawler.com/archives/3/1568/2000/11/0/4676963/
>
> d
>

Re: compilation error

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

thanks.. not good net acces

On Fri, 25 May 2001, David Leonard wrote:

> On Thu, 24 May 2001, Joe Little typed thusly:
>
> > BTW -- can anyone post to the list the most recent patches (Konstanin's)
>
> shame on you! ;) go to the python-ldap web page, click on mailing list archive,
> type 'konstantin patch' in the search field... and the first result is:
>
> http://www.geocrawler.com/archives/3/1568/2000/11/0/4676963/
>
> d
>

Re: compilation error

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

On Thu, 24 May 2001, Joe Little typed thusly:

> BTW -- can anyone post to the list the most recent patches (Konstanin's)

shame on you! ;) go to the python-ldap web page, click on mailing list archive,
type 'konstantin patch' in the search field... and the first result is:

http://www.geocrawler.com/archives/3/1568/2000/11/0/4676963/

d
-- 
David Leonard                           Dav...@ds...
DSTC                                    Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

I put my chin on my knee, and looked for flaws in the soft grain of my
beige plastic monitor casing. - Julian Assange

new Python-LDAP RPMs

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

I've posted new RPMS (and source RPMS) for redhat 7.1 of python-ldap. This
addresses a lack of functionality (missing a library), but does not change
the patch used. I'll await final details on what is the best patch and
hope to apply those soon. Time will tell what is the best solution to
supporting ldapv3

Re: compilation error

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

BTW -- can anyone post to the list the most recent patches (Konstanin's)

I'll grab them soon. I'll be connected to the net every other day for a
bit, and the connection is so slow.. no web surfeing for me.

As to the message, you have valid points. From my standpoint, the problem=
s
require further research, so any reply would be less than adequate at thi=
s
stage..


On Thu, 24 May 2001, Michael Str=F6der wrote:

> Joe Little wrote:
> >
> > you'll notice that 1.2.x will slowly be unsupported/unavailable.
>
> OpenLDAP 1.2.x is actively maintained. See the recent 1.2.12 release
> a couple of days ago.
>
> > If nothing else, the OpenLDAP 2.x patches should like become
> > proper to the source tree so that users can use any modern system.
>
> Unfortunately your patch for linking python-ldap against OpenLDAP
> 2.0.x breaks some existing python-ldap code (deref, alias options)
> without giving extra functionality. Look into Konstantin's patch
> which is a little bit more complete regarding LDAP options.
>
> We already had this discussion on-list and off-list several
> times. Up to now *nobody* raised his virtual hand saying "I will do
> it, maintain it for at least a couple of months and write
> documentation". David is not available for working on it at the
> moment.
>
> Although I personally don't like a SWIG approach I already made
> suggestions how I could contribute to a SWIG-based low-level LDAP
> API by writing a nice Python wrapper above it. This means I'm really
> willing to put my time into this. I'm still waiting for at least one
> serious response from the SWIG crowd saying "Yes, I will do it!". I
> had a short look at the swig-ldap code posted by Sascha but could
> not compile it on my box.
>
> The argument that OpenLDAP 2.x is more modern does not stand for its
> own.
> Solaris developers could argue that Solaris already ships with
> Netscape/Mozilla SDK which is quite incompatible to the OpenLDAP 2.x
> libs - but thread-safe. Which way to go? My question regarding which
> SDK to choose was not answered by anybody here yet. It was not even
> discussed at all!
>
> Just to show you one example how detailed problems are:
> Today I experienced that OpenLDAP 2.0.10 has a slightly different
> behaviour regarding referrals with Konstantin's python-ldap patches
> than OpenLDAP 2.0.7. If you actually don't have to deal with these
> kind of problems it's far less hassle to stick to the OpenLDAP 1.2.x
> libs until one of you really bites the bullet and does the heavy
> work.
>
> I repeat myself: A couple of patches will not fit the bill because
> otherwise people will complain that it's immature and unusable.
>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: compilation error

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

Joe Little wrote:
> 
> you'll notice that 1.2.x will slowly be unsupported/unavailable.

OpenLDAP 1.2.x is actively maintained. See the recent 1.2.12 release
a couple of days ago.

> If nothing else, the OpenLDAP 2.x patches should like become
> proper to the source tree so that users can use any modern system.

Unfortunately your patch for linking python-ldap against OpenLDAP
2.0.x breaks some existing python-ldap code (deref, alias options)
without giving extra functionality. Look into Konstantin's patch
which is a little bit more complete regarding LDAP options.

We already had this discussion on-list and off-list several
times. Up to now *nobody* raised his virtual hand saying "I will do
it, maintain it for at least a couple of months and write
documentation". David is not available for working on it at the
moment.

Although I personally don't like a SWIG approach I already made
suggestions how I could contribute to a SWIG-based low-level LDAP
API by writing a nice Python wrapper above it. This means I'm really
willing to put my time into this. I'm still waiting for at least one
serious response from the SWIG crowd saying "Yes, I will do it!". I
had a short look at the swig-ldap code posted by Sascha but could
not compile it on my box.

The argument that OpenLDAP 2.x is more modern does not stand for its
own.
Solaris developers could argue that Solaris already ships with
Netscape/Mozilla SDK which is quite incompatible to the OpenLDAP 2.x
libs - but thread-safe. Which way to go? My question regarding which
SDK to choose was not answered by anybody here yet. It was not even
discussed at all!

Just to show you one example how detailed problems are:
Today I experienced that OpenLDAP 2.0.10 has a slightly different
behaviour regarding referrals with Konstantin's python-ldap patches
than OpenLDAP 2.0.7. If you actually don't have to deal with these
kind of problems it's far less hassle to stick to the OpenLDAP 1.2.x
libs until one of you really bites the bullet and does the heavy
work.

I repeat myself: A couple of patches will not fit the bill because
otherwise people will complain that it's immature and unusable.

Ciao, Michael.

Re: compilation error

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

you'll notice that 1.2.x will slowly be unsupported/unavailable. If
nothing else, the OpenLDAP 2.x patches should like become proper to the
source tree so that users can use any modern system.

Also, there is a bug in my packages that I just noticed. The makefile for
python-ldap does not explicitly install _ldapmodule.so in the python path=
,
so an RPM actually doesn't see it (alternative build root). I've made a
new RPM but I'm stuck on a lousy windows box for my net connection at the
moment. Happily, I have Zope working with python-ldap as of this morning.

My current solution to the above problem is to install _ldapmodule.so int=
o
/usr/lib/py*/site-packages alogn with ldap.pth. This way, packagers will
get it with "make DESTDIR=3DALTROOT/blah/blah"

		-Joe

On Wed, 23 May 2001, Michael Str=F6der wrote:

> Peter Peltonen wrote:
> >
> > openldap-devel-2.0.7-14
> > openldap12-1.2.11-4
>
> I'd suggest that you try to grab OpenLDAP 1.2.12 sources and compile
> them yourself in a local directory for making sure that the OpenLDAP
> libs are not mixed up:
>
> In directory openldap-1.2.12/ invoke:
> ./configure
> make depend
> make
>
> Then go to the python-ldap source directory:
>
> ./configure --prefix=3D/usr --with-python=3D/usr/bin/python2.1
> --with-ldap-lib=3D/home/michael/src/openldap-1.2.12/libraries
> --with-ldap-inc=3D/home/michael/src/openldap-1.2.12/include
> make
> make install
>
> > krbafs-1.0.5-1 (from RH7.1 CD)
> > pam_krb5-1.31-1
> > krb5-libs-1.2.2-5 (from RH7.1 Updates)
> > krb5-workstation-1.2.2-5
> > krb5-devel-1.2.2-5
> > krb5-server-1.2.2-5
>
> Note: web2ldap is not Kerberos-aware yet.
>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: compilation error

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

Peter Peltonen wrote:
> 
> openldap-devel-2.0.7-14
> openldap12-1.2.11-4

I'd suggest that you try to grab OpenLDAP 1.2.12 sources and compile
them yourself in a local directory for making sure that the OpenLDAP
libs are not mixed up:

In directory openldap-1.2.12/ invoke:
./configure
make depend
make

Then go to the python-ldap source directory:

./configure --prefix=/usr --with-python=/usr/bin/python2.1
--with-ldap-lib=/home/michael/src/openldap-1.2.12/libraries
--with-ldap-inc=/home/michael/src/openldap-1.2.12/include
make
make install

> krbafs-1.0.5-1 (from RH7.1 CD)
> pam_krb5-1.31-1
> krb5-libs-1.2.2-5 (from RH7.1 Updates)
> krb5-workstation-1.2.2-5
> krb5-devel-1.2.2-5
> krb5-server-1.2.2-5

Note: web2ldap is not Kerberos-aware yet.

Ciao, Michael.

compilation error

[Peter P. <pet...@fi...>]

I am trying to install web2ldap software which requires python-ldap version
1.8 or higher. The author of web2ldap provided me with the package
python-ldap-CVS-20010510.tar.gz which I tried to install in my RH 7.1 system
which has the following packages installed:

--snip--
python2-2.1-4 (from python.org)
python2-tkinter-2.1-4
python2-devel-2.1-4
python2-tools-2.1-4

python-2.0-14 (from rpmfind.net, built for ConnectivaLinux)
python-devel-2.0-14

python-xmlrpc-1.4-1 (from RH7.1 CD)
rpm-python-4.0.2-8

openldap-2.0.7-14 (from RH7.1 CD)
openldap-servers-2.0.7-14
openldap-clients-2.0.7-14
openldap-devel-2.0.7-14
openldap12-1.2.11-4

krbafs-1.0.5-1 (from RH7.1 CD)
pam_krb5-1.31-1

krb5-libs-1.2.2-5 (from RH7.1 Updates)
krb5-workstation-1.2.2-5
krb5-devel-1.2.2-5
krb5-server-1.2.2-5
--snip--

I configured python-ldap:

--snip--
[root@jolo python-ldap]# ./configure --with-ldap-lib=/usr/lib
--with-ldap-inc=/usr/include --with-python=/usr/bin/python2.1 --with-kerberos
--with-kerberos-lib=/usr/kerberos/lib
--snip--

And then tried to run make:

--snip--
[root@jolo python-ldap]# make
cd Modules && make srcdir=/usr/src/python-ldap/Modules
VPATH=/usr/src/python-ldap/Modules
make[1]: Entering directory `/usr/src/python-ldap/Modules'
gcc -fPIC -g -O2 -Wall -Wstrict-prototypes -I/usr/include/python2.1
-I/usr/include/python2.1 -DHAVE_CONFIG_H  -I. -DLDAP_REFERRALS -I/usr/include
-c /usr/src/python-ldap/Modules/./constants.c -o ./constants.o
/usr/src/python-ldap/Modules/./constants.c: In function `LDAPinit_constants':
/usr/src/python-ldap/Modules/./constants.c:69: `LDAP_MAX_ATTR_LEN' undeclared
(first use in this function)
/usr/src/python-ldap/Modules/./constants.c:69: (Each undeclared identifier is
reported only once
/usr/src/python-ldap/Modules/./constants.c:69: for each function it appears
in.)
/usr/src/python-ldap/Modules/./constants.c:82: `LDAP_REQ_UNBIND_30' undeclared
(first use in this function)
/usr/src/python-ldap/Modules/./constants.c:83: `LDAP_REQ_DELETE_30' undeclared
(first use in this function)
/usr/src/python-ldap/Modules/./constants.c:84: `LDAP_REQ_ABANDON_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:109: `LDAP_AUTH_SIMPLE_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:110: `LDAP_AUTH_KRBV41_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:111: `LDAP_AUTH_KRBV42_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:121: `LDAP_FILTER_PRESENT_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:125: `LDAP_SUBSTRING_INITIAL_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:126: `LDAP_SUBSTRING_ANY_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:127: `LDAP_SUBSTRING_FINAL_30'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:138: `LDAP_DEFAULT_REFHOPLIMIT'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:164: `LDAP_URL_ERR_NOTLDAP'
undeclared (first use in this function)
/usr/src/python-ldap/Modules/./constants.c:165: `LDAP_URL_ERR_NODN' undeclared
(first use in this function)
make[1]: *** [constants.o] Error 1
make[1]: Leaving directory `/usr/src/python-ldap/Modules'
make: *** [_ldapmodule-build] Error 2
--snip--

I get the same error if I try to recompile the .src.rpm found at
http://www.webideal.de/ldap/.

Any help appreciated,

Peter

Re: the new python-ldap website

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

On Mon, 14 May 2001, Jens Vagelpohl typed thusly:

> i just noticed one thing that hasn't been moved to the new site yet: the
> instructions / login info for anonymous CVS access...

done

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

Why are apartments so close together?

Re: Compiling woes on Solaris

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

My first stab at this is pathing..

Its not finding lber correctly since I think getfilter is in that. No?=20=

I'm also concerned that there are two ldap libraries on this. for=20
instance, Solaris 8 already has a /usr/lib/libldap.so.4 provided. That=20=

is likely what is being linked in!!!


On Monday, May 14, 2001, at 07:44  AM, Michael Str=F6der wrote:

> Since Brian did not re-post his question here I'll do it.
>
> Ciao, Michael.
>
> -------- Original Message --------
> Subject: web2ldap feedback
> Date: Fri, 27 Apr 2001 14:18:14 -0700
> From: Brian Doherty <bdo...@ma...>
> To: fee...@we...
>
> [..]
>
> I have the Netscape SDK in /usr/local/mozilla and the openldap v2
> in /usr/local.  Neither worked, and the ./Misc/openldap.sh didn't
> either.  I downloaded openldap 1.2.11 myself and installed it in
> /usr/local/openldap1.  Then I tried to configure python-ldap with
> ./configure --with-ldap=3D/usr/local/openldap1
> This configured OK, but the make failed with the following:
>
> make[1]: Entering directory
> `/usr/local/src/LDAP/Web/python-ldap-1.10alpha3/Modules'
> gcc -shared  ./LDAPObject.o ./common.o ./constants.o ./errors.o
> ./functions.o ./ldapmodule.o ./message.o ./version.o ./linkedlist.o
> ./template.o ./CIDict.o  -L/usr/local/openldap1/lib -lldap -llber
> -lsocket -lnsl -lm  -o ./_ldapmodule.so
> Text relocation remains                         referenced
>     against symbol                  offset      in file
> <unknown>                           0x430
> /usr/local/openldap1/lib/libldap.a(getfilter.o)
> <unknown>                           0x434
> /usr/local/openldap1/lib/libldap.a(getfilter.o)
> <unknown>                           0x438
> /usr/local/openldap1/lib/libldap.a(getfilter.o)
>
> ... (many many many more lines like this)
>
> ld: fatal: relocations remain against allocatable but non-writable
> sections
> collect2: ld returned 1 exit status
> make[1]: *** [_ldapmodule.so] Error 1
> make[1]: Leaving directory
> `/usr/local/src/LDAP/Web/python-ldap-1.10alpha3/Modules'
> make: *** [_ldapmodule-build] Error 2
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>