python-ldap-dev — discussion among developers

NULL result without error in call_object

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

HI!

I'm getting the following exception with recent CVS snapshot of
python-ldap (under Python 2.0 built against OpenLDAP 1.2.11 libs).

    result_type,result_data = ls.l.result(ldap_msgid,0)
SystemError: NULL result without error in call_object

Can anybody enlighten me what this means?

Ciao, Michael.

Re: python-ldap binary for Python 2.0 under Win32

[Brian <ca...@ru...>]

According to Michael Ströder:
> HI!
> 
> A quick note that there is a Win32 build of the python-ldap module
> available for download now which is e.g. needed for running web2ldap
> on Win32 platform:
> 
> http://localhost/inkasite/web2ldap/install.html#packages_win32

http://localhost/ ??

-- 
Failure is not an option. It comes bundled with your Microsoft product.
-- Ferenc Mantfeld

python-ldap binary for Python 2.0 under Win32

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

HI!

(Aargh! Wrong URL in my previous message!)

A quick note that there is a Win32 build of the python-ldap module
available for download now which is e.g. needed for running web2ldap
on Win32 platform:

http://www.web2ldap.de/install.html#packages_win32

Thanks to the contributor!

Any feedback is appreciated.

Ciao, Michael.

python-ldap binary for Python 2.0 under Win32

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

HI!

A quick note that there is a Win32 build of the python-ldap module
available for download now which is e.g. needed for running web2ldap
on Win32 platform:

http://localhost/inkasite/web2ldap/install.html#packages_win32

Thanks to the contributor!

Any feedback is appreciated.

Ciao, Michael.

Re: Cygwin Patch

[Jason T. <Jas...@do...>]

Michael,

On Wed, Dec 27, 2000 at 04:50:21PM +0100, Michael Str=F6der wrote:
> Jason Tishler wrote:
> >=20
> > python-ldap to build OOTB as a shared extension for Cygwin Python.
>=20
> Which leads to the question whether you can provide pre-compiled
> Win32 binaries of python-ldap for download.

I was going to offer to provide pre-built binaries in my previous email,
but I thought that it would be considered presumptuous without waiting
to see if the patch would be accepted.

There are also other issues regarding the usefulness of the pre-built
binary:

    1. Cygwin python-ldap is *not* a Mingw (i.e., straight Win32) binary
       and requires Cygwin's cygwin1.dll to run
    2. Cygwin python-ldap requires Cygwin Python to be built with a DLL c=
ore
       (similar to Win32 Python)

Additionally, I was hoping to store the pre-built binary on

    http://python-ldap.sourceforge.net/release.php

since my public web space is currently very limited.

Nevertheless, I can provide the following packages that are installable
with Cygwin's setup.exe:

    python-ldap-1.10alpha3-1.tar.gz: Cygwin python-ldap
    python-20001116-1.tar.gz:        Cygwin Python 2.0 with DLL core
    openldap-1.2.11-1.tar.gz:        Cygwin OpenLDAP 1.2.11 clients and l=
ibs

Only the first one above is required.  The other two are offered for
convenience only -- it makes more sense for them to be contributed to
the Cygwin project instead.

Jason

--=20
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jas...@do...
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

Re: Cygwin Patch

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

Jason Tishler wrote:
> 
> python-ldap to build OOTB as a shared extension for Cygwin Python.

Which leads to the question whether you can provide pre-compiled
Win32 binaries of python-ldap for download.

Ciao, Michael.

Cygwin Patch

[Jason T. <Jas...@do...>]

On Sun, 10 Dec 2000 23:27:49 +0100, David Leonard wrote:
> 	* python-ldap-1.10 will be tidied up, with just the memory-leak
> 	  patches applied, and a proper documentation build. (ie no v3
> 	  changes will be applied as it breaks v2 builds.) A final release
> 	  will be made.

Hopefully, the attached patch (against python-ldap-1.10alpha3) can
still be considered for inclusion in the 1.10 final release.  It enables
python-ldap to build OOTB as a shared extension for Cygwin Python.

Cygwin is an open-source POSIX emulation layer that enables many
GNU and UNIX tools to port to Windows without any source code changes.
If interested, please see http://www.cygwin.com for more information.

Note that the patch has no functional changes -- it only enables the
code to compile cleanly with Cygwin gcc.  Specifically, the changes
are as follows:

    1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) 
       as described in http://www.python.org/doc/FAQ.html#3.24 
    2. added DL_EXPORT to init_ldap() 

I'm quite willing to redo the patch against python-ldap CVS if that
will facilitate its acceptance.

My original plan was to wait until the Cygwin Python DLL and Shared
Extension Patch:

    http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470

was accepted and committed into Python CVS before contacting the list.
However, due to the impending 1.10 final release, I realized that it
would be prudent to submit the patch sooner rather than later.

The procedure to apply the patch (to python-ldap-1.10alpha3) is as follows:

    $ cd python-ldap-1.10alpha3
    $ # save the attachment to the current directory
    $ patch -p1 <Cygwin-python-ldap-1.10alpha3.patch

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jas...@do...
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

Re: python-ldap-2.0

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

David Margrave wrote:
> 
> What would be cool is if python-ldap could not only accept unicode 
> strings, but also automatically apply the language tag when
> creating or modifying attributes (i.e. cn;lang-de).

I don't think that the C module should do high-level operations like
this. I can imagine that it's worth to write a Python class for it -
contributions and detailed suggestions welcome. But let's stick to
things found in OpenLDAP 2.0's ldap.h first.

> Also, I haven't seen any discussion of SSL support.  I for one would 
> like
> the module to be able to do an SSL handshake to port 636 (or whatever it
> is) to protect the credentials when simple auth is being used.

OpenLDAP 2 has support for LDAP via SSL (URL scheme ldaps:// -> port
636) and LDAP with STARTTLS.

> It would also be cool to get the Kerberos V5 GSS-API SASL mechanism 
> going.

OpenLDAP supports SASL (not only Kerberos) if build with the Cyrus
SASL lib.

> I'm interested in doing the work to add these features.

Great! Please take a closer look at OpenLDAP 2.0.x.

Ciao, Michael.

Re: python-ldap-2.0

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

On Mon, 18 Dec 2000, David Margrave typed thusly:

> Also, I haven't seen any discussion of SSL support.

yes this is an important thing. i'm hoping that it will be more
or less transparent to the api user. perhaps it will be done by just by
providing set/get/check-certiciate hooks to the user like the python socket
module does for those who really care :)

> It would also be cool to get the Kerberos V5 GSS-API SASL mechanism going.

I'm not overly familiar with this, i'm afraid

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

Cassette tapes have an almost unlimited capacity for data.
  - Commodore 64 Programmer's Reference Guide (1983)

Re: python-ldap-2.0

[David M. <da...@es...>]

Hello,

I haven't been following the list too closely, so forgive me if some of
this has already been discussed.

I think unicode support is a great thing to add.  I have already played
with language tags a bit, but still being on python 1.5.2 for the most
part, haven't had a convenient way to do the unicode conversions.  What
would be cool is if python-ldap could not only accept unicode strings, but
also automatically apply the language tag when creating or modifying
attributes (i.e. cn;lang-de).  Of course, I can also imagine situations
where you wouldn't want the module making assumptions like this.

Also, I haven't seen any discussion of SSL support.  I for one would like
the module to be able to do an SSL handshake to port 636 (or whatever it
is) to protect the credentials when simple auth is being used.  I have to
admit I haven't looked into whether open LDAP supports this, or whether it
is something that would have to be cobbled in.  If open LDAP doesn't have
this, and doesn't provide for socket callbacks, then it could be tricky.

It would also be cool to get the Kerberos V5 GSS-API SASL mechanism going.
I'm interested in doing the work to add these features.


Dave



On Sun, 10 Dec 2000, David Leonard wrote:

> On Sun, 10 Dec 2000, Michael Str=F6der typed thusly:
> > I think we should leave the 1.x stuff as is and start with
> > python-ldap-ext based on OpenLDAP 2.0.x...
>=20
> Okay, to keep everyone on the list informed:
>=20
> Michael, as a knowledgable Karlsruhe local, showed me all the local
> restaurants that have closed down and then we discussed the direction for
> python-ldap. After a few drinks, and a discussion on cats, we agreed on
> the following plan:
>=20
> =09* python-ldap-1.10 will be tidied up, with just the memory-leak
> =09  patches applied, and a proper documentation build. (ie no v3
> =09  changes will be applied as it breaks v2 builds.) A final release
> =09  will be made.
>=20
> =09* A new python-ldap-2.0 will be started, with an API that is likely
> =09  to be somewhat incompatible with that of p-l-1.10. In particular,
> =09  the following will be the major compatibility targets:
> =09=09+ Python-2.0 support (ie unicode)
> =09=09+ OpenLDAP-2.0 support (ie LDAPv3/LDAP-EXT)
>=20
> This means that people relying on v2 client/servers should be happy enoug=
h
> with a reasonably stable release.  And people wanting to live in the 3rd
> millenium should be happy with a version (relatively) free of legacy supp=
ort.
>=20
> Please, comment! Are there problems with the above plan?
>=20
> In addition, I seek more comment on any more changes that the _ldap libra=
ry
> may need to support LDAPv3 connections. (Remember that the purpose of thi=
s
> module is not to give an abstraction of X.500 directory services, but rat=
her
> to provide an abstraction of the LDAP C API.)
>=20
> d
> --=20
> 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                     B73CD65FBEF4C089B79A8EBADF1A932F1=
3EA0FC8
>=20
> I put my chin on my knee, and looked for flaws in the soft grain of my
> beige plastic monitor casing. - Julian Assange
>=20
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> http://lists.sourceforge.net/mailman/listinfo/python-ldap-dev
>=20

Python LDAP Documentation

[John D. <joh...@mn...>]

LaTeX, TeX, LyX, and tth all have problems with the documents in the
_ldap directory.  I admint I'm not TeX expert, but has anyone else had
this problem, and if so, how have they addressed it?

Re: python-ldap-2.0

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

Gregor Hoffleit wrote:
> 
> IIRC, quite a few services inside Debian are using python-ldap
> (http://db.debian.org/), e.g. for maintenance of the maintainer 
> database. I'm not sure which sorts of code are involved there,
> and if they were ready
> to switch to Python 2.0, but if I would prefer to provide them with a
> python-ldap package which works on both 2.0 as well as 1.5.2.

I think the old python-ldap package will still exist and bugfixed =>
the old applications have a properly working module to run with.
BTW: This module also works with Python 2.0 => no problem for
http://db.debian.org/ at all.

> But if that's not feasible, I can simply split the package
> and stick with the old legacy code as python-ldap for 1.5.2
> and provide the new code as python2-ldap.

Yes, I would prefer that everyone considers the new python-ldap-2.0
(or python-ldap-ext?) to be a completely separate package.

Ciao, Michael.

Re: python-ldap-2.0

[Gregor H. <gr...@ho...>]

On Sat, Dec 16, 2000 at 07:05:53PM +1000, David Leonard wrote:
> On Tue, 12 Dec 2000, Gregor Hoffleit typed thusly:
> > When you write 'Python 2.0 support' and 'free of legacy support', does this
> > mean that this new version won't work anymore with Python 1.5.2 ?
> 
> yes... is that a problem?

No fatal problem, just a sort of inconvenience: It's a longer story...

Due to the GPL problems with the new Python license, Debian will provide and
maintain both Python 1.5.2 and Python 2.0 packages. It's on the maintainer
of a package depending on Python to decide if the license of his package
allows to be used with Python 2.0, or if he has to stick with Python 1.5.2
if he doesn't want to infringe the license. Users of third-party Python code
will have to make the same decision.

IIRC, quite a few services inside Debian are using python-ldap
(http://db.debian.org/), e.g. for maintenance of the maintainer database.
I'm not sure which sorts of code are involved there, and if they were ready
to switch to Python 2.0, but if I would prefer to provide them with a
python-ldap package which works on both 2.0 as well as 1.5.2.

But if that's not feasible, I can simply split the package and stick with
the old legacy code as python-ldap for 1.5.2 and provide the new code as
python2-ldap.

    Gregor
    

Re: python-ldap-2.0

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

On Tue, 12 Dec 2000, Gregor Hoffleit typed thusly:

> David,
>
> >        * A new python-ldap-2.0 will be started, with an API that is lik=
ely
> >          to be somewhat incompatible with that of p-l-1.10. In particul=
ar,
> >          the following will be the major compatibility targets:
> >                + Python-2.0 support (ie unicode)
> >                + OpenLDAP-2.0 support (ie LDAPv3/LDAP-EXT)
> >
> > This means that people relying on v2 client/servers should be happy eno=
ugh
> >=A0with a reasonably stable release.  And people wanting to live in the =
3rd
> > millenium should be happy with a version (relatively) free of legacy
> > support.
>
> When you write 'Python 2.0 support' and 'free of legacy support', does th=
is
> mean that this new version won't work anymore with Python 1.5.2 ?

yes... is that a problem?

d
--=20
David Leonard                           Dav...@ds...
CRC For Distributed Systems Technology  Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13E=
A0FC8

Cassette tapes have an almost unlimited capacity for data.
  - Commodore 64 Programmer's Reference Guide (1983)

Re: Spec file

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

just a quick note on future packaging: python1.6 and above come with
a distribution/packaging system ... which can build RPMs, etc. (or, so
i have finally discoverred in the python documentation)

so... Begone! disparate and out-of-date packaging systems! :)
what i mean to say is that things will get better... i promise.. real soon
now... no new taxes

On Fri, 15 Dec 2000, Michael Str=F6der typed thusly:

> > I was wondering if someone could provide the SPEC file which was used t=
o
> > compile the RPM for RedHat.  I have a RedHat 6.2 SPARC box, but have an
> > interest in maintaining python-ldap as a package.
> >
> > I'd be happy to donate the SPARC RPM back to the development site.
>
> Have a look at what Mirko did so far: http://www.webideal.de/ldap/.
> He does not have the time to keep up with the new versions.
>
> > (PS - I'm not subscribed to the dev list; just an interested user...)
>
> Please subscribe. It's really low-traffic.

--=20
David Leonard                           Dav...@ds...
CRC For Distributed Systems Technology  Room:78-632  Ph:+61 7 336 58358
The University of Queensland            http://www.dstc.edu.au/
QLD 4072  AUSTRALIA                     B73CD65FBEF4C089B79A8EBADF1A932F13E=
A0FC8

Cassette tapes have an almost unlimited capacity for data.
  - Commodore 64 Programmer's Reference Guide (1983)

Re: Spec file

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

Les Barstow wrote:
> 
> I was wondering if someone could provide the SPEC file which was used to
> compile the RPM for RedHat.  I have a RedHat 6.2 SPARC box, but have an
> interest in maintaining python-ldap as a package.
> 
> I'd be happy to donate the SPARC RPM back to the development site.

Have a look at what Mirko did so far: http://www.webideal.de/ldap/.
He does not have the time to keep up with the new versions.

> (PS - I'm not subscribed to the dev list; just an interested user...)

Please subscribe. It's really low-traffic.

Ciao, Michael.

Spec file

[Les B. <lba...@vr...>]

I was wondering if someone could provide the SPEC file which was used to
compile the RPM for RedHat.  I have a RedHat 6.2 SPARC box, but have an
interest in maintaining python-ldap as a package.

I'd be happy to donate the SPARC RPM back to the development site.

Thanks,

(PS - I'm not subscribed to the dev list; just an interested user...)

-- 
Les Barstow           | e-mail: lba...@vr...
System Administrator  |
VR-1, Inc.            | The box said "Requires Windows 95 or better",
http://www.vr1.com    | so I installed Linux!

Re: python-ldap-2.0

[Federico Di G. <fo...@mi...>]

Scavenging the mail folder uncovered Michael Ströder's letter:
> Federico Di Gregorio wrote:
> > 
> > mmm... what are schema functions? some time ago i was trying to
> > code some v3 schema support in pure python (do you remember) but
> > i never tidied up the code to something really useable. (nobody
> > ever tried my code to... *grin*)
> 
> The schema functions are exposed in ldap_schema.h of OpenLDAP 2.0.x
> and are exactly what you started to write (off course I remember).

so, maybe, we dont need a pure python implementation. mmm... maybe
that'll make my job easier and i'll produce something useable in
shorter time... (cvs updating now...)

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology              fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
    God is real. Unless declared integer. -- Anonymous female programmer

Re: python-ldap-2.0

[Sascha G. <sa...@fr...>]

> 
> Before we all dive into it can you give a short description
> of what you think the main advantages are?
> 


+ interface file is smaller and hopefully easier to maintain
+ data structures convert to objects in a convenient way
+ support for ruby, perl, guile wont be to different

- limits hard core hacking of the interface
- swig does not currently parse every conceivable type of C declaration


See attachment for some more information.

%Sascha

-- 
/* Yeah  */

Re: python-ldap-2.0

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

Federico Di Gregorio wrote:
> 
> mmm... what are schema functions? some time ago i was trying to
> code some v3 schema support in pure python (do you remember) but
> i never tidied up the code to something really useable. (nobody
> ever tried my code to... *grin*)

The schema functions are exposed in ldap_schema.h of OpenLDAP 2.0.x
and are exactly what you started to write (off course I remember).

Ciao, Michael.

Re: python-ldap-2.0

[Federico Di G. <fo...@mi...>]

Scavenging the mail folder uncovered Michael Ströder's letter:

> > In addition, I seek more comment on any more changes that the _ldap library
> > may need to support LDAPv3 connections. (Remember that the purpose of this
> > module is not to give an abstraction of X.500 directory services, but rather
> > to provide an abstraction of the LDAP C API.)
> 
> I would like to stay as close as possible to the new LDAP-EXT API in
> OpenLDAP 2.0.x since this API already trys to give some level of
> abstraction (SASL for providing several authentication methods
> etc.).

i agree.

> Once again the things I would like to see:
> 
> - LDAPv3 binding
> - proper support for search continuations (LDAPv3 referrals)
> - SSL and STARTTLS support
> - Access to schema functions (would save lots of work in Python
> applications)

mmm... what are schema functions? some time ago i was trying to 
code some v3 schema support in pure python (do you remember) but
i never tidied up the code to something really useable. (nobody
ever tried my code to... *grin*)
  
ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology              fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
                      The number of the beast: vi vi vi. -- Delexa Jones

Re: python-ldap-2.0

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

Gregor Hoffleit wrote:
> 
> When you write 'Python 2.0 support' and 'free of legacy support',
> does this mean that this new version won't work anymore
> with Python 1.5.2 ?

Additional note:

The old python-ldap 1.10.x will be properly released. The new
python-ldap 2.0 will be incompatible to old applications anyway
(just like the new OpenLDAP 2.0.x API based on LDAP-EXT is not
compatible to the old OpenLDAP 1.2.x API based on RFC1823).

Ciao, Michael.

Re: python-ldap-2.0

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

Gregor Hoffleit wrote:
> 
> >                + Python-2.0 support (ie unicode)
> 
> When you write 'Python 2.0 support' and 'free of legacy support', does this
> mean that this new version won't work anymore with Python 1.5.2 ?

Not sure how David will comment.

My personal opinion is that python-ldap 2.0 should make direct use
of the new Unicode objects in Python 2.0 (I dropped Python 1.5.2 in
web2ldap because of this). If we can provide normal string support
and Unicode support at the same time without producing a code bloat
then we could keep Python 1.5.2 support. If it gets too messy
personally I would like to drop support for non-Unicode Python
versions since migrating to e.g. Python 2.0 isn't that hard anyway
and Unicode objects are so handy...

Ciao, Michael.

Re: python-ldap-2.0

[Gregor H. <gr...@me...>]

David,

>        * A new python-ldap-2.0 will be started, with an API that is likely
>          to be somewhat incompatible with that of p-l-1.10. In particular,
>          the following will be the major compatibility targets:
>                + Python-2.0 support (ie unicode)
>                + OpenLDAP-2.0 support (ie LDAPv3/LDAP-EXT)
>
> This means that people relying on v2 client/servers should be happy enough
> with a reasonably stable release.  And people wanting to live in the 3rd
> millenium should be happy with a version (relatively) free of legacy
> support.

When you write 'Python 2.0 support' and 'free of legacy support', does this
mean that this new version won't work anymore with Python 1.5.2 ?

    Gregor
    

Re: python-ldap-2.0

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

Sascha Gresk wrote:
> 
> Yes, have a look at http://www.free.de/homes/sascha/swig-ldap.
> [..]
> Maybe its not as complete as python-ldap but its used in a productive
> enviroment

Before we all dive into it can you give a short description
of what you think the main advantages are?

Ciao, Michael.