From christian_wiese at web.de  Tue Oct  2 13:09:30 2001
From: christian_wiese at web.de (Christian Wiese)
Date: Tue, 2 Oct 2001 13:09:30 +0200
Subject: Problems importing _ldap module
Message-ID: <m15oNRD-007q11C@smtp.web.de>

Hi,

I want to write some python apps for accessing our LDAP server (OpenLDAP 
2.0.15 on RedHat 7.1), but I've problems importing the _ldap module.
I'm using the latest module from Joe Little, which compiles well with 
OpenLDAP 2.0.15

This is the error message I get from python:



From michael at stroeder.com  Tue Oct  2 17:32:04 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 02 Oct 2001 17:32:04 +0200
Subject: Problems importing _ldap module
References: <m15oNRD-007q11C@smtp.web.de>
Message-ID: <3BB9DDF4.4B8B54CF@stroeder.com>

Christian Wiese wrote:
> 
> ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so: undefined
> symbol: ldap_ufn_setfilter
> >>>

What's the output of ldd
/usr/lib/python1.5/site-packages/_ldapmodule.so ? Is there also a
_ldap.so (patched for OpenLDAP 2 libs) around?

Ciao, Michael.



From jlittle at open-it.org  Tue Oct  2 18:40:51 2001
From: jlittle at open-it.org (Joe Little)
Date: Tue, 2 Oct 2001 09:40:51 -0700
Subject: _ldap problem and current resolution. -- found api change
In-Reply-To: <1AA84668-B753-11D5-B049-0003930B38C0@open-it.org>
Message-ID: <3DAEE524-B754-11D5-B049-0003930B38C0@open-it.org>

Sorry. I _will try_ to ascertain when this broke. I didn't mean to add 
the "not". Looking at the change log, it would appear that 2.0.12 is the 
likely culprit, as very extraneous files were removed. More 
specifically, one of the last lines is "Removed -lldap UFN search 
support".

Michael, does Python-LDAP expect this to be there? It might be in the 
headers still and so is included (since python-ldap is mostly an 
openldap 1.x beast).

Also, this could very well be my fault since I am not CVS-current. 
However, Christian has already attempted to build against such. Again, I 
suspect some lingering requirement/inclusion in the python-ldap code. 
Still searching..


On Tuesday, October 2, 2001, at 09:32 AM, Joe Little wrote:

> Early analysis of the problem:
>
> OpenLDAP 2.0.11 does not exhibit this problem. The only other newer 
> versions of OpenLDAP that have been packaged by Open-IT are 2.0.14 and 
> 2.0.15.
>
> This likely means an API change in OpenLDAP that is subtle. I rebuilt 
> my RPMs against 2.0.15 and I still see the problem Christian Wiese 
> noted. However, regardless of OpenLDAP built against, the python-ldap 
> module works as long as the openldap 2.0.11 libraries are present. I 
> will not ascertain when this broke post 2.0.11. Likely it means that 
> python-ldap itself needs to address this condition, as it _currently_ 
> appears to be unrelated to the packaging. I of course may still be 
> wrong on that note.
>
>
> On Tuesday, October 2, 2001, at 09:12 AM, Christian Wiese wrote:
>
>> Hi,
>>
>> thank you for your reply and support.
>> In the readme file the module is imported with
>>
>>>>> import _ldap
>>
>> but if I try
>>
>>>>> import ldap
>>
>> I get the a similar error message.
>>
>> -----------------------------------------------
>>
>>>>> 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: /usr/lib/python1.5/site-packages/_ldapmodule.so: 
>> undefined symbol: ldap_ufn_setfilter
>>>>>
>>
>> ------------------------------------------------
>>
>> Greetings,
>>
>> Christian
>>
>> Am Tuesday 02 October 2001 17:57 schrieb jmlittle at mac.com:
>>> I'll look into this immediately. I also hate to bring up a dead horse,
>>> but are we supposed to import ldap or _ldap?
>>>
>>> On Tuesday, October 2, 2001, at 04:09 AM, Christian Wiese wrote:
>>>> Hi,
>>>>
>>>> I want to write some python apps for accessing our LDAP server 
>>>> (OpenLDAP
>>>> 2.0.15 on RedHat 7.1), but I've problems importing the _ldap module.
>>>> I'm using the latest module from Joe Little, which compiles well with
>>>> OpenLDAP 2.0.15
>>>>
>>>> This is the error message I get from python:
>>>>
>>>> 

From michael at stroeder.com  Tue Oct  2 19:12:31 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 02 Oct 2001 19:12:31 +0200
Subject: _ldap problem and current resolution. -- found api change
References: <3DAEE524-B754-11D5-B049-0003930B38C0@open-it.org>
Message-ID: <3BB9F57F.51BF3F5E@stroeder.com>

Joe Little wrote:
> 
> "Removed -lldap UFN search support".
> 
> Michael, does Python-LDAP expect this to be there?

The ufn* methods are mentioned in
http://python-ldap.sourceforge.net/doc/lib/node9.html. But I suspect
that no serious LDAP application ever made use of this.

> It might be in the
> headers still and so is included (since python-ldap is mostly an
> openldap 1.x beast).

IMHO the *ufn* functions were already dropped in other OpenLDAP 2
patches for python-ldap.

Ciao, Michael.



From jlittle at open-it.org  Tue Oct  2 18:32:43 2001
From: jlittle at open-it.org (Joe Little)
Date: Tue, 2 Oct 2001 09:32:43 -0700
Subject: _ldap problem and current resolution.
In-Reply-To: <auto-000006596668@business.mail-gw.net>
Message-ID: <1AA84668-B753-11D5-B049-0003930B38C0@open-it.org>

Early analysis of the problem:

OpenLDAP 2.0.11 does not exhibit this problem. The only other newer 
versions of OpenLDAP that have been packaged by Open-IT are 2.0.14 and 
2.0.15.

This likely means an API change in OpenLDAP that is subtle. I rebuilt my 
RPMs against 2.0.15 and I still see the problem Christian Wiese noted. 
However, regardless of OpenLDAP built against, the python-ldap module 
works as long as the openldap 2.0.11 libraries are present. I will not 
ascertain when this broke post 2.0.11. Likely it means that python-ldap 
itself needs to address this condition, as it _currently_ appears to be 
unrelated to the packaging. I of course may still be wrong on that note.


On Tuesday, October 2, 2001, at 09:12 AM, Christian Wiese wrote:

> Hi,
>
> thank you for your reply and support.
> In the readme file the module is imported with
>
>>>> import _ldap
>
> but if I try
>
>>>> import ldap
>
> I get the a similar error message.
>
> -----------------------------------------------
>
>>>> 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: /usr/lib/python1.5/site-packages/_ldapmodule.so: undefined 
> symbol: ldap_ufn_setfilter
>>>>
>
> ------------------------------------------------
>
> Greetings,
>
> Christian
>
> Am Tuesday 02 October 2001 17:57 schrieb jmlittle at mac.com:
>> I'll look into this immediately. I also hate to bring up a dead horse,
>> but are we supposed to import ldap or _ldap?
>>
>> On Tuesday, October 2, 2001, at 04:09 AM, Christian Wiese wrote:
>>> Hi,
>>>
>>> I want to write some python apps for accessing our LDAP server 
>>> (OpenLDAP
>>> 2.0.15 on RedHat 7.1), but I've problems importing the _ldap module.
>>> I'm using the latest module from Joe Little, which compiles well with
>>> OpenLDAP 2.0.15
>>>
>>> This is the error message I get from python:
>>>
>>> 

From michael at stroeder.com  Tue Oct  2 19:00:00 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 02 Oct 2001 19:00:00 +0200
Subject: _ldap problem and current resolution.
References: <1AA84668-B753-11D5-B049-0003930B38C0@open-it.org>
Message-ID: <3BB9F290.2738F6A6@stroeder.com>

Joe Little wrote:
> 
> Early analysis of the problem:
> 
> OpenLDAP 2.0.11 does not exhibit this problem. The only other newer
> versions of OpenLDAP that have been packaged by Open-IT are 2.0.14 and
> 2.0.15.

See OpenLDAP 2's CHANGES:

------------------------- snip ---------------------------
OpenLDAP 2.0.12 Release
[..]
        Removed -lldap UFN search support
[..]
------------------------- snip ---------------------------

Ciao, Michael.



From christian_wiese at web.de  Tue Oct  2 17:53:14 2001
From: christian_wiese at web.de (Christian Wiese)
Date: Tue, 2 Oct 2001 17:53:14 +0200
Subject: Problems importing _ldap module
In-Reply-To: <3BB9DDF4.4B8B54CF@stroeder.com>
References: <m15oNRD-007q11C@smtp.web.de> <3BB9DDF4.4B8B54CF@stroeder.com>
Message-ID: <auto-000006596452@business.mail-gw.net>

Hi Michael,

thank you very much for your reply.

ldd produces following output:
------------------------------------------------------

# ldd /usr/lib/python1.5/site-packages/_ldapmodule.so
        libldap.so.2 => /usr/lib/libldap.so.2 (0x40029000)
        liblber.so.2 => /usr/lib/liblber.so.2 (0x40052000)
        libm.so.6 => /lib/i686/libm.so.6 (0x4005c000)
        libc.so.6 => /lib/i686/libc.so.6 (0x4007f000)
        libsasl.so.7 => /usr/lib/libsasl.so.7 (0x401ba000)
        libkrb4.so.2 => /usr/kerberos/lib/libkrb4.so.2 (0x401c4000)
        libdes425.so.3 => /usr/kerberos/lib/libdes425.so.3 (0x401d9000)
        libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x401dd000)
        libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x40235000)
        libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x40246000)
        libssl.so.2 => /lib/libssl.so.2 (0x40249000)
        libcrypto.so.2 => /lib/libcrypto.so.2 (0x40276000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
        libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4033a000)
        libdl.so.2 => /lib/libdl.so.2 (0x40342000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40346000)
        libpam.so.0 => /lib/libpam.so.0 (0x40373000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x4037b000)


From jmlittle at mac.com  Tue Oct  2 17:57:51 2001
From: jmlittle at mac.com (jmlittle at mac.com)
Date: Tue, 2 Oct 2001 08:57:51 -0700
Subject: Problems importing _ldap module
In-Reply-To: <m15oNRD-007q11C@smtp.web.de>
Message-ID: <3B844CC0-B74E-11D5-B049-0003930B38C0@mac.com>

I'll look into this immediately. I also hate to bring up a dead horse, 
but are we supposed to import ldap or _ldap?

On Tuesday, October 2, 2001, at 04:09 AM, Christian Wiese wrote:

> Hi,
>
> I want to write some python apps for accessing our LDAP server (OpenLDAP
> 2.0.15 on RedHat 7.1), but I've problems importing the _ldap module.
> I'm using the latest module from Joe Little, which compiles well with
> OpenLDAP 2.0.15
>
> This is the error message I get from python:
>
> 

From michael at stroeder.com  Tue Oct  2 18:09:06 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 02 Oct 2001 18:09:06 +0200
Subject: Problems importing _ldap module
References: <3B844CC0-B74E-11D5-B049-0003930B38C0@mac.com>
Message-ID: <3BB9E6A2.B069263C@stroeder.com>

jmlittle at mac.com wrote:
> 
> are we supposed to import ldap or _ldap?

Good question. I vote for "import ldap" although the docs and
demos say sometimes "import _ldap".

IMHO "ldap" should be a module package with a ldap/__init__.py
importing the symbols from module _ldap (as already done on Unix
platforms in [Python's lib path]/site-packages/python-ldap/ldap.py).

This makes it possible to add Python modules to module ldap.

Ciao, Michael.



From cw at 4ix.net  Tue Oct  2 18:12:27 2001
From: cw at 4ix.net (Christian Wiese)
Date: Tue, 2 Oct 2001 18:12:27 +0200
Subject: Problems importing _ldap module
In-Reply-To: <3B844CC0-B74E-11D5-B049-0003930B38C0@mac.com>
References: <3B844CC0-B74E-11D5-B049-0003930B38C0@mac.com>
Message-ID: <auto-000006596668@business.mail-gw.net>

Hi,

thank you for your reply and support.
In the readme file the module is imported with

>>>import _ldap

but if I try

>>>import ldap

I get the a similar error message.

-----------------------------------------------

>>> 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: /usr/lib/python1.5/site-packages/_ldapmodule.so: undefined symbol: ldap_ufn_setfilter
>>>

------------------------------------------------

Greetings,

Christian

Am Tuesday 02 October 2001 17:57 schrieb jmlittle at mac.com:
> I'll look into this immediately. I also hate to bring up a dead horse,
> but are we supposed to import ldap or _ldap?
>
> On Tuesday, October 2, 2001, at 04:09 AM, Christian Wiese wrote:
> > Hi,
> >
> > I want to write some python apps for accessing our LDAP server (OpenLDAP
> > 2.0.15 on RedHat 7.1), but I've problems importing the _ldap module.
> > I'm using the latest module from Joe Little, which compiles well with
> > OpenLDAP 2.0.15
> >
> > This is the error message I get from python:
> >
> > 

From michael at stroeder.com  Tue Oct  2 18:24:07 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 02 Oct 2001 18:24:07 +0200
Subject: Problems importing _ldap module
References: <3B844CC0-B74E-11D5-B049-0003930B38C0@mac.com> <auto-000006596668@business.mail-gw.net>
Message-ID: <3BB9EA27.A90B0B24@stroeder.com>

Christian Wiese wrote:
> 
> but if I try
> 
> >>>import ldap
> 
> I get the a similar error message.
> [..]
>     from _ldap import __version__
> ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so: undefined symbol: ldap_ufn_setfilter
> >>>

Yes, there is a import _ldap in ldap.py anyway. It's just a matter
of module packaging. 

The problem is that in the OpenLDAP 2 libs the support for the
mainly unused functions *ufn* was dropped. Your build of python-ldap
trys to import those old functions which makes me believe that your
_ldapmodule.so was built against OpenLDAP 1 libs.

Ciao, Michael.



From cw at 4ix.net  Tue Oct  2 18:36:42 2001
From: cw at 4ix.net (Christian Wiese)
Date: Tue, 2 Oct 2001 18:36:42 +0200
Subject: Problems importing _ldap module
In-Reply-To: <3BB9EA27.A90B0B24@stroeder.com>
References: <3B844CC0-B74E-11D5-B049-0003930B38C0@mac.com> <auto-000006596668@business.mail-gw.net> <3BB9EA27.A90B0B24@stroeder.com>
Message-ID: <auto-000006600023@business.mail-gw.net>

Ok, I understand, but I've never installed OpenLDAP 1.x on this system.

Then we should check "LDAPObject.c", regarding this functions.

Here are some greps, concerning my configuration:

---------------------------------------------------

# rpm -qa | grep openldap
openldap-devel-2.0.15-1
openldap-clients-2.0.15-1
openldap-servers-2.0.15-1
openldap-2.0.15-1

# rpm -qa | grep python
python-xmlrpc-1.4-1
python-docs-1.5.2-35
pythonlib-1.28-1
rpm-python-4.0.3-0.96
python-devel-1.5.2-35
python-tools-1.5.2-35
openssl-python-0.9.6-3
mod_python-2.7.3-1
python-1.5.2-35
python-ldap-python1.5-1.10alpha3-4

---------------------------------------------------

Am Tuesday 02 October 2001 18:24 schrieb Michael Str?der:
> Christian Wiese wrote:
> > but if I try
> >
> > >>>import ldap
> >
> > I get the a similar error message.
> > [..]
> >     from _ldap import __version__
> > ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so: undefined
> > symbol: ldap_ufn_setfilter
>
> Yes, there is a import _ldap in ldap.py anyway. It's just a matter
> of module packaging.
>
> The problem is that in the OpenLDAP 2 libs the support for the
> mainly unused functions *ufn* was dropped. Your build of python-ldap
> trys to import those old functions which makes me believe that your
> _ldapmodule.so was built against OpenLDAP 1 libs.
>
> Ciao, Michael.




From cw at 4ix.net  Tue Oct  2 17:58:15 2001
From: cw at 4ix.net (Christian Wiese)
Date: Tue, 2 Oct 2001 17:58:15 +0200
Subject: Problems importing _ldap module
In-Reply-To: <3BB893D200000A85@hawk.dcu.ie>
References: <3BB893D200000A85@hawk.dcu.ie>
Message-ID: <auto-000006596494@business.mail-gw.net>

Hi Donald,
thank you very much for your help, but everything seem to be on the right 
place. Also the permissions are correct.

As I wrote in a later email, I found some gcc warnings during compilation of 
the CVS source.
Then I compiled the "official" released sources, and I found the same 
warnings again.

Greetings from Berlin,

Christian

Am Tuesday 02 October 2001 17:24 schrieb donal.hunt2 at mail.dcu.ie:
> Christian,
>
> You need to make sure the python-ldap library is installed correctly.
> make sure it's in /usr/lib/python1.5/site-packages/
>
> I had a few problems getting it to be found when i started out and ended
> up with copies of it all over the place!! But if it's in the above location
> it should all be cool (check permissions too).
>
> Regards
>
> Donal
>
> >-- Original Message --
>
> From: Christian Wiese <christian_wiese at web.de>
>
> >To: python-ldap-dev at lists.sourceforge.net
> >Subject: Problems importing _ldap module
> >Date: Tue, 2 Oct 2001 13:09:30 +0200
> >
> >
> >Hi,
> >
> >I want to write some python apps for accessing our LDAP server (OpenLDAP
> >
> >2.0.15 on RedHat 7.1), but I've problems importing the _ldap module.
> >I'm using the latest module from Joe Little, which compiles well with
> >OpenLDAP 2.0.15
> >
> >This is the error message I get from python:
> >
> >

From michael at stroeder.com  Tue Oct  2 18:11:35 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 02 Oct 2001 18:11:35 +0200
Subject: Problems importing _ldap module
References: <3BB893D200000A85@hawk.dcu.ie> <auto-000006596494@business.mail-gw.net>
Message-ID: <3BB9E737.7D50E4F1@stroeder.com>

Christian Wiese wrote:
> 
> Then I compiled the "official" released sources, and I found the same
> warnings again.

Compiling the "official" released sources and OpenLDAP 2 libs:
See item 3 on: http://python-ldap.sf.net/faq.shtml

It's still up-to-date.

Ciao, Michael.



From cw at 4ix.net  Tue Oct  2 18:25:20 2001
From: cw at 4ix.net (Christian Wiese)
Date: Tue, 2 Oct 2001 18:25:20 +0200
Subject: Problems importing _ldap module
In-Reply-To: <3BB9E737.7D50E4F1@stroeder.com>
References: <3BB893D200000A85@hawk.dcu.ie> <auto-000006596494@business.mail-gw.net> <3BB9E737.7D50E4F1@stroeder.com>
Message-ID: <auto-000006596856@business.mail-gw.net>

you are right, and I read the faq before, but I found also a special rpm 
package from Joe, which is linked against OpenLDAP 2.x.x libs. There are also 
some patches in it.

see:

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

The CVS sources should also work with OpenLDAP 2.x.x libs.


Am Tuesday 02 October 2001 18:11 schrieb Michael Str?der:
> Christian Wiese wrote:
> > Then I compiled the "official" released sources, and I found the same
> > warnings again.
>
> Compiling the "official" released sources and OpenLDAP 2 libs:
> See item 3 on: http://python-ldap.sf.net/faq.shtml
>
> It's still up-to-date.
>
> Ciao, Michael.




From jlittle at open-it.org  Tue Oct  2 18:08:16 2001
From: jlittle at open-it.org (Joe Little)
Date: Tue, 2 Oct 2001 09:08:16 -0700
Subject: Problems importing _ldap module
In-Reply-To: <m15oNRD-007q11C@smtp.web.de>
Message-ID: <B078369A-B74F-11D5-B049-0003930B38C0@open-it.org>

Ok.. to make sure we are all on the the same page. You are using RedHat 
7.1 with Open-IT's openldap-2.0.15 RPMS, as well as the 
python-ldap-python1.5-1.10alpha3-4.i386.rpm, correct? I want to make 
sure I match your setup exactly.


On Tuesday, October 2, 2001, at 04:09 AM, Christian Wiese wrote:

> Hi,
>
> I want to write some python apps for accessing our LDAP server (OpenLDAP
> 2.0.15 on RedHat 7.1), but I've problems importing the _ldap module.
> I'm using the latest module from Joe Little, which compiles well with
> OpenLDAP 2.0.15
>
> This is the error message I get from python:
>
> 

From michael at stroeder.com  Tue Oct  2 18:26:36 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 02 Oct 2001 18:26:36 +0200
Subject: Problems importing _ldap module
References: <B078369A-B74F-11D5-B049-0003930B38C0@open-it.org>
Message-ID: <3BB9EABC.1A1D03D0@stroeder.com>

Joe Little wrote:
> 
> python-ldap-python1.5-1.10alpha3-4.i386.rpm, correct?
                        ^^^^^^^^^^

This version number is misleading since you patched python-ldap. And
any reasons why you're not using recent CVS tree for applying the
patches? There were important memory leak fixes since 1.10alpha3.

Ciao, Michael.



From cw at 4ix.net  Tue Oct  2 18:28:04 2001
From: cw at 4ix.net (Christian Wiese)
Date: Tue, 2 Oct 2001 18:28:04 +0200
Subject: Problems importing _ldap module
In-Reply-To: <B078369A-B74F-11D5-B049-0003930B38C0@open-it.org>
References: <B078369A-B74F-11D5-B049-0003930B38C0@open-it.org>
Message-ID: <auto-000006596895@business.mail-gw.net>

Yep, that's right ...


Am Tuesday 02 October 2001 18:08 schrieb Joe Little:
> Ok.. to make sure we are all on the the same page. You are using RedHat
> 7.1 with Open-IT's openldap-2.0.15 RPMS, as well as the
> python-ldap-python1.5-1.10alpha3-4.i386.rpm, correct? I want to make
> sure I match your setup exactly.
>
> On Tuesday, October 2, 2001, at 04:09 AM, Christian Wiese wrote:
> > Hi,
> >
> > I want to write some python apps for accessing our LDAP server (OpenLDAP
> > 2.0.15 on RedHat 7.1), but I've problems importing the _ldap module.
> > I'm using the latest module from Joe Little, which compiles well with
> > OpenLDAP 2.0.15
> >
> > This is the error message I get from python:
> >
> > 

From jlittle at open-it.org  Tue Oct  2 18:29:47 2001
From: jlittle at open-it.org (Joe Little)
Date: Tue, 2 Oct 2001 09:29:47 -0700
Subject: Problems importing _ldap module
In-Reply-To: <3BB9EABC.1A1D03D0@stroeder.com>
Message-ID: <B20FB230-B752-11D5-B049-0003930B38C0@open-it.org>

this is a new patching scheme provided to me. It allows for builds 
against python1.5, 2.0, and 2.1. As for the patches, have only taken the 
posted patches to date and have not yet used CVS since it was in flux. 
What would be the current ideal flags to CVS to pull out an OpenLDAP 2.0 
version. Is it HEAD?

On Tuesday, October 2, 2001, at 09:26 AM, Michael Str?der wrote:

> Joe Little wrote:
>>
>> python-ldap-python1.5-1.10alpha3-4.i386.rpm, correct?
>                         ^^^^^^^^^^
>
> This version number is misleading since you patched python-ldap. And
> any reasons why you're not using recent CVS tree for applying the
> patches? There were important memory leak fixes since 1.10alpha3.
>
> Ciao, Michael.
>





From jlittle at open-it.org  Tue Oct  2 19:17:31 2001
From: jlittle at open-it.org (Joe Little)
Date: Tue, 2 Oct 2001 10:17:31 -0700
Subject: Problems importing _ldap module
In-Reply-To: <auto-000006600023@business.mail-gw.net>
Message-ID: <5CC4C4A6-B759-11D5-B049-0003930B38C0@open-it.org>

This is getting interesting

Looks like LDAPObject.c in the Modules directory explicitly call ufn_* 
and these are in turn relied upon by the URL functions. I'm currently 
undergoing surgery on the code, removing the ugly bits AND hoping that 
it will still be functional.

This is not CVS.. just my latest edition.


On Tuesday, October 2, 2001, at 09:36 AM, Christian Wiese wrote:

> Ok, I understand, but I've never installed OpenLDAP 1.x on this system.
>
> Then we should check "LDAPObject.c", regarding this functions.
>
> Here are some greps, concerning my configuration:
>
> ---------------------------------------------------
>
> # rpm -qa | grep openldap
> openldap-devel-2.0.15-1
> openldap-clients-2.0.15-1
> openldap-servers-2.0.15-1
> openldap-2.0.15-1
>
> # rpm -qa | grep python
> python-xmlrpc-1.4-1
> python-docs-1.5.2-35
> pythonlib-1.28-1
> rpm-python-4.0.3-0.96
> python-devel-1.5.2-35
> python-tools-1.5.2-35
> openssl-python-0.9.6-3
> mod_python-2.7.3-1
> python-1.5.2-35
> python-ldap-python1.5-1.10alpha3-4
>
> ---------------------------------------------------
>
> Am Tuesday 02 October 2001 18:24 schrieb Michael Str?der:
>> Christian Wiese wrote:
>>> but if I try
>>>
>>>>>> import ldap
>>>
>>> I get the a similar error message.
>>> [..]
>>>     from _ldap import __version__
>>> ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so: 
>>> undefined
>>> symbol: ldap_ufn_setfilter
>>
>> Yes, there is a import _ldap in ldap.py anyway. It's just a matter
>> of module packaging.
>>
>> The problem is that in the OpenLDAP 2 libs the support for the
>> mainly unused functions *ufn* was dropped. Your build of python-ldap
>> trys to import those old functions which makes me believe that your
>> _ldapmodule.so was built against OpenLDAP 1 libs.
>>
>> Ciao, Michael.
>
> 

From cw at 4ix.net  Tue Oct  2 19:26:25 2001
From: cw at 4ix.net (Christian Wiese)
Date: Tue, 2 Oct 2001 19:26:25 +0200
Subject: Problems importing _ldap module
In-Reply-To: <5CC4C4A6-B759-11D5-B049-0003930B38C0@open-it.org>
References: <5CC4C4A6-B759-11D5-B049-0003930B38C0@open-it.org>
Message-ID: <auto-000006600494@business.mail-gw.net>


with my little experience in C, I removed the ufn functions in LDAPObject.c 
from the CVS source and now can import the ldap module and it seems to 
function.

greetings

Christian

Am Tuesday 02 October 2001 19:17 schrieb Joe Little:
> This is getting interesting
>
> Looks like LDAPObject.c in the Modules directory explicitly call ufn_*
> and these are in turn relied upon by the URL functions. I'm currently
> undergoing surgery on the code, removing the ugly bits AND hoping that
> it will still be functional.
>
> This is not CVS.. just my latest edition.
>
> On Tuesday, October 2, 2001, at 09:36 AM, Christian Wiese wrote:
> > Ok, I understand, but I've never installed OpenLDAP 1.x on this system.
> >
> > Then we should check "LDAPObject.c", regarding this functions.
> >
> > Here are some greps, concerning my configuration:
> >
> > ---------------------------------------------------
> >
> > # rpm -qa | grep openldap
> > openldap-devel-2.0.15-1
> > openldap-clients-2.0.15-1
> > openldap-servers-2.0.15-1
> > openldap-2.0.15-1
> >
> > # rpm -qa | grep python
> > python-xmlrpc-1.4-1
> > python-docs-1.5.2-35
> > pythonlib-1.28-1
> > rpm-python-4.0.3-0.96
> > python-devel-1.5.2-35
> > python-tools-1.5.2-35
> > openssl-python-0.9.6-3
> > mod_python-2.7.3-1
> > python-1.5.2-35
> > python-ldap-python1.5-1.10alpha3-4
> >
> > ---------------------------------------------------
> >
> > Am Tuesday 02 October 2001 18:24 schrieb Michael Str?der:
> >> Christian Wiese wrote:
> >>> but if I try
> >>>
> >>>>>> import ldap
> >>>
> >>> I get the a similar error message.
> >>> [..]
> >>>     from _ldap import __version__
> >>> ImportError: /usr/lib/python1.5/site-packages/_ldapmodule.so:
> >>> undefined
> >>> symbol: ldap_ufn_setfilter
> >>
> >> Yes, there is a import _ldap in ldap.py anyway. It's just a matter
> >> of module packaging.
> >>
> >> The problem is that in the OpenLDAP 2 libs the support for the
> >> mainly unused functions *ufn* was dropped. Your build of python-ldap
> >> trys to import those old functions which makes me believe that your
> >> _ldapmodule.so was built against OpenLDAP 1 libs.
> >>
> >> Ciao, Michael.
> >
> > 

From michael at stroeder.com  Tue Oct  2 19:57:27 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 02 Oct 2001 19:57:27 +0200
Subject: _ldap problem and current resolution. -- found api change
References: <3321D796-B75A-11D5-B049-0003930B38C0@open-it.org>
Message-ID: <3BBA0007.87D2B2EA@stroeder.com>

Joe Little wrote:
> 
> what is the openldap 2.x module name from cvs.. I just pulled
> "python-ldap" using the anonymous instructions, and it pulled a copy
> with all UFN/etc support still there. like Christian said, he built
> against the current CVS tree. Is this tree "the openldap 2.x" tree like
> I think it is. If so, it is littered with ufn/url support :)

OpenLDAP 2 support not yet there in CVS.

The most recent and complete OpenLDAP 2 patch I have is the one by
Steffen Ries <steffen.ries at sympatico.ca> who tried to come up with
something against CVS containing all the memory leak fixes applied,
Konstantin's patches, Stig's suggestions and his own STARTTLS
support. Not sure about the ufn* stuff though. I've built it against
OpenLDAP 2.0.16engineering from CVS. It works but still seg faults a
lot. Could be an issue with my local installation with OpenLDAP
1.2.13 hanging around in /usr/lib although
/usr/local/openldap2/lib/libldap.so.2 is used.

This patched module is used for running web2ldap's online-demo at
http://sites.inka.de:8002/web2ldap with Python 2.

Ciao, Michael.



From jlittle at open-it.org  Tue Oct  2 20:03:15 2001
From: jlittle at open-it.org (Joe Little)
Date: Tue, 2 Oct 2001 11:03:15 -0700 (PDT)
Subject: new RPMs/diff
Message-ID: <Pine.LNX.4.33.0110021059380.20693-100000@kodama.stanford.edu>


I've placed on open-it.org the latest release of my python-ldap package in
the redhat7.1 directory. Release 5 removes the UFN and URL support that
has caused a problem for post openldap 2.0.11 systems. The "final" patch
for this release simply removes the code. This may not be ideal. I hope to
incorporate the latest mem-leak patches against the cvs tree and release
yet another edition within a week if possible.

Here for posterity is the patch

--- python-ldap-1.10alpha3/Modules/LDAPObject.c.orig	Tue Oct  2 09:47:47 2001
+++ python-ldap-1.10alpha3/Modules/LDAPObject.c	Tue Oct  2 10:14:42 2001
@@ -1421,149 +1421,6 @@

 /* ldap_search_s == ldap_search_st */

-/* ldap_ufn_search_c */
-
-/* ldap_ufn_search_ct */
-
-/* ldap_ufn_search_s */
-
-static PyObject*
-l_ldap_ufn_search_s( LDAPObject* self, PyObject* args )
-{
-    char *ufn;
-    PyObject *attrlist;
-    char **attrs;
-    int attrsonly = 0;
-    LDAPMessage *resmsg = NULL;
-    int result;
-
-    if (!PyArg_ParseTuple( args, "sO|i",
-    	&ufn, &attrlist, &attrsonly)) return NULL;
-    if (not_valid(self)) return NULL;
-
-    if (!attrs_from_List( attrlist, &attrs ))
-   	 return NULL;
-
-    LDAP_BEGIN_ALLOW_THREADS( self );
-    result = ldap_ufn_search_s( self->ldap, ufn,
-                             attrs, attrsonly, &resmsg );
-    LDAP_END_ALLOW_THREADS( self );
-
-    free_attrs( &attrs );
-
-    if (result != LDAP_SUCCESS)
-    	return LDAPerror( self->ldap, "ldap_ufn_search_s" );
-
-    if (resmsg == NULL) {
-    	Py_INCREF( Py_None );
-	return Py_None;
-    } else {
-    	return LDAPmessage_to_python( self->ldap, resmsg );
-    }
-}
-
-
-/* ldap_ufn_setfilter */
-
-static PyObject*
-l_ldap_ufn_setfilter( LDAPObject* self, PyObject* args )
-{
-    char* filter;
-    LDAPFiltDesc* res;
-
-    if (!PyArg_ParseTuple( args, "s", &filter)) return NULL;
-    if (not_valid(self)) return NULL;
-    res = ldap_ufn_setfilter( self->ldap, filter );
-
-    if (res == NULL)
-	return LDAPerror(NULL, "ldap_ufn_setfilter");
-
-    Py_INCREF( Py_None );
-    return Py_None;
-}
-
-/* ldap_ufn_setprefix */
-
-static PyObject*
-l_ldap_ufn_setprefix( LDAPObject* self, PyObject* args )
-{
-    char* prefix;
-
-    if (!PyArg_ParseTuple( args, "s", &prefix)) return NULL;
-    if (not_valid(self)) return NULL;
-    ldap_ufn_setprefix( self->ldap, prefix );
-    Py_INCREF( Py_None );
-    return Py_None;
-}
-
-static char doc_ufn[] =
-"ufn_setfilter(filtername) -> None\n"
-"ufn_setprefix(prefix) -> None\n"
-"ufn_search_s(url [,attrsonly=0])\n"
-"ufn_search_st(url [,attrsonly=0 [,timeout=-1]])\n\n"
-"\tSee the LDAP library manual pages for more information on these\n"
-"\t`user-friendly name' functions.";
-
-/* ldap_sort_entries */
-
-/* ldap_url_search */
-
-/* ldap_url_search_s */
-
-/* ldap_url_search_st */
-
-static PyObject*
-l_ldap_url_search_st( LDAPObject* self, PyObject* args )
-{
-    char *url;
-    int attrsonly = 0;
-    LDAPMessage *resmsg;
-    int result;
-    double timeout = -1.0;
-    struct timeval tv, *tvp;
-
-    if (!PyArg_ParseTuple( args, "s|id", &url, &attrsonly, &timeout ))
-    	return NULL;
-    if (not_valid(self)) return NULL;
-
-    if (timeout>=0) {
-        tvp = &tv;
-	set_timeval_from_double( tvp, timeout );
-    } else {
-    	tvp = NULL;
-    }
-
-    LDAP_BEGIN_ALLOW_THREADS( self );
-    result = ldap_url_search_st( self->ldap, url, attrsonly, tvp, &resmsg );
-    LDAP_END_ALLOW_THREADS( self );
-
-    if (result != LDAP_SUCCESS)
-    	return LDAPerror( self->ldap, "ldap_ufn_search_st" );
-
-    if (resmsg == NULL) {
-    	Py_INCREF( Py_None );
-	return Py_None;
-    } else {
-    	return LDAPmessage_to_python( self->ldap, resmsg );
-    }
-}
-
-static char doc_url_search[] =
-"url_search_s(url [,attrsonly=0])\n"
-"url_search_s(url [,attrsonly=0 [,timeout=-1]])\n\n"
-"\tThese routine works much like search_s*, except that many\n"
-"\tsearch parameters are pulled out of the URL url.\n"
-"\n"
-"\tLDAP URLs look like this:\n"
-"\t    ldap://host[:port]/dn[?attributes[?scope[?filter]]]\n"
-"\n"
-"\twhere scope is one of 'base' (default), 'one' or 'sub',\n"
-"\tand attributes is a comma-separated list of attributes to\n"
-"\tbe retrieved.\n"
-"\n"
-"\tURLs wrapped in angle-brackets and/or preceded by 'URL:'\n"
-"\tare tolerated.";
-
 /* methods */

 static PyMethodDef methods[] = {
@@ -1631,11 +1488,6 @@
     {"search",		(PyCFunction)l_ldap_search,		METH_VARARGS,	doc_search},
     {"search_s",	(PyCFunction)l_ldap_search_st,		METH_VARARGS,	doc_search},
     {"search_st",	(PyCFunction)l_ldap_search_st,		METH_VARARGS,	doc_search},
-    {"ufn_search_s",	(PyCFunction)l_ldap_ufn_search_s,	METH_VARARGS,	doc_ufn},
-    {"ufn_setfilter",	(PyCFunction)l_ldap_ufn_setfilter,	METH_VARARGS,	doc_ufn},
-    {"ufn_setprefix",	(PyCFunction)l_ldap_ufn_setprefix,	METH_VARARGS,	doc_ufn},
-    {"url_search_s",	(PyCFunction)l_ldap_url_search_st,	METH_VARARGS,	doc_url_search},
-    {"url_search_st",	(PyCFunction)l_ldap_url_search_st,	METH_VARARGS,	doc_url_search},
     { NULL, NULL }
 };





From Konstantin.Chuguev at dante.org.uk  Wed Oct  3 11:03:36 2001
From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev)
Date: Wed, 03 Oct 2001 10:03:36 +0100
Subject: _ldap problem and current resolution. -- found api change
References: <3321D796-B75A-11D5-B049-0003930B38C0@open-it.org> <3BBA0007.87D2B2EA@stroeder.com> <auto-000006600822@business.mail-gw.net>
Message-ID: <3BBAD468.82E111F2@dante.org.uk>

Hi All,

A small update on what I'm doing:
I have merged Steffen Ries's and my patches and built python-ldap with
OpenLDAP-2.0.15. I then installed web2ldap-0.9.5 to do some tests.
For what I need it, it works fine. But there still may be problems in other
areas.

I think it's OK to commit the patches to the current branch of CVS. Your
suggestions?

And, yes, as there are no ldap_ufn_* functions in OpenLDAP-2.x, they are made
conditional (#if LDAP_API_VERSION < 2000) in the patches.
The other known issue is the ldap_rebind_proc callback function, which
incompatible in OpenLDAP-1.x and 2.x (both arguments, result and behaviour).
This requires more study.

Regards,
    Konstantin.

Christian Wiese wrote:

> Michael,
>
> where can I get the OpenLDAP 2.0.16engineering version ?
> I can test it on my machine because I don't run openldap 1.x
>
> Christian
>
> Am Tuesday 02 October 2001 19:57 schrieb Michael Str?der:
> > Joe Little wrote:
> > > what is the openldap 2.x module name from cvs.. I just pulled
> > > "python-ldap" using the anonymous instructions, and it pulled a copy
> > > with all UFN/etc support still there. like Christian said, he built
> > > against the current CVS tree. Is this tree "the openldap 2.x" tree like
> > > I think it is. If so, it is littered with ufn/url support :)
> >
> > OpenLDAP 2 support not yet there in CVS.
> >
> > The most recent and complete OpenLDAP 2 patch I have is the one by
> > Steffen Ries <steffen.ries at sympatico.ca> who tried to come up with
> > something against CVS containing all the memory leak fixes applied,
> > Konstantin's patches, Stig's suggestions and his own STARTTLS
> > support. Not sure about the ufn* stuff though. I've built it against
> > OpenLDAP 2.0.16engineering from CVS. It works but still seg faults a
> > lot. Could be an issue with my local installation with OpenLDAP
> > 1.2.13 hanging around in /usr/lib although
> > /usr/local/openldap2/lib/libldap.so.2 is used.
> >
> > This patched module is used for running web2ldap's online-demo at
> > http://sites.inka.de:8002/web2ldap with Python 2.
> >
> > Ciao, Michael.
> >
> > 

From jlittle at open-it.org  Wed Oct  3 17:32:27 2001
From: jlittle at open-it.org (Joe Little)
Date: Wed, 3 Oct 2001 08:32:27 -0700
Subject: _ldap problem and current resolution. -- found api change
In-Reply-To: <3BBAD468.82E111F2@dante.org.uk>
Message-ID: <DA12EDC2-B813-11D5-8508-0003930B38C0@open-it.org>

please do commit... the effort to get current CS to work with Steffen's 
patches has been problematic on my end. I'd like there to be concensus 
(ie CVS committed) on what is the ideal 2.x version. I also think that 
the version number should be officially increased to 1.11alpha or 
whatever.

On Wednesday, October 3, 2001, at 02:03 AM, Konstantin Chuguev wrote:

> Hi All,
>
> A small update on what I'm doing:
> I have merged Steffen Ries's and my patches and built python-ldap with
> OpenLDAP-2.0.15. I then installed web2ldap-0.9.5 to do some tests.
> For what I need it, it works fine. But there still may be problems in 
> other
> areas.
>
> I think it's OK to commit the patches to the current branch of CVS. Your
> suggestions?
>
> And, yes, as there are no ldap_ufn_* functions in OpenLDAP-2.x, they 
> are made
> conditional (#if LDAP_API_VERSION < 2000) in the patches.
> The other known issue is the ldap_rebind_proc callback function, which
> incompatible in OpenLDAP-1.x and 2.x (both arguments, result and 
> behaviour).
> This requires more study.
>
> Regards,
>     Konstantin.
>
> Christian Wiese wrote:
>
>> Michael,
>>
>> where can I get the OpenLDAP 2.0.16engineering version ?
>> I can test it on my machine because I don't run openldap 1.x
>>
>> Christian
>>
>> Am Tuesday 02 October 2001 19:57 schrieb Michael Str?der:
>>> Joe Little wrote:
>>>> what is the openldap 2.x module name from cvs.. I just pulled
>>>> "python-ldap" using the anonymous instructions, and it pulled a copy
>>>> with all UFN/etc support still there. like Christian said, he built
>>>> against the current CVS tree. Is this tree "the openldap 2.x" tree 
>>>> like
>>>> I think it is. If so, it is littered with ufn/url support :)
>>>
>>> OpenLDAP 2 support not yet there in CVS.
>>>
>>> The most recent and complete OpenLDAP 2 patch I have is the one by
>>> Steffen Ries <steffen.ries at sympatico.ca> who tried to come up with
>>> something against CVS containing all the memory leak fixes applied,
>>> Konstantin's patches, Stig's suggestions and his own STARTTLS
>>> support. Not sure about the ufn* stuff though. I've built it against
>>> OpenLDAP 2.0.16engineering from CVS. It works but still seg faults a
>>> lot. Could be an issue with my local installation with OpenLDAP
>>> 1.2.13 hanging around in /usr/lib although
>>> /usr/local/openldap2/lib/libldap.so.2 is used.
>>>
>>> This patched module is used for running web2ldap's online-demo at
>>> http://sites.inka.de:8002/web2ldap with Python 2.
>>>
>>> Ciao, Michael.
>>>
>>> 

From michael at stroeder.com  Wed Oct  3 17:47:00 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 03 Oct 2001 17:47:00 +0200
Subject: _ldap problem and current resolution. -- found api change
References: <DA12EDC2-B813-11D5-8508-0003930B38C0@open-it.org>
Message-ID: <3BBB32F4.933833A0@stroeder.com>

Joe Little wrote:
> 
> please do commit... the effort to get current CS to work with Steffen's
> patches has been problematic on my end. I'd like there to be concensus
> (ie CVS committed) on what is the ideal 2.x version. I also think that
> the version number should be officially increased to 1.11alpha or
> whatever.

The version number symbol is already 1.11 for the OpenLDAP 1.2.x
branch. It was decided ages ago that the OpenLDAP 2 based branch
should get version numbers 2.x.

Since we have a tagged CVS archive for the OpenLDAP 1.2.x branch
(label OPENLDAP_1_BRANCH) I see no problem with Konstantin commiting
his work now.

Ciao, Michael.



From steffen.ries at sympatico.ca  Tue Oct 16 14:05:05 2001
From: steffen.ries at sympatico.ca (Steffen Ries)
Date: 16 Oct 2001 08:05:05 -0400
Subject: patch for Internationalization support (iconv)
In-Reply-To: js9s@netscape.net's message of "Tue, 16 Oct 2001 06:44:24 -0400"
References: <1C7917E2.5923A124.0000408D@netscape.net>
Message-ID: <m3zo6rdc3y.fsf@gondolin.beleriand>

js9s at netscape.net writes:

> I have sent to Leonard the patch, but did not get any indication of
> its being received, so here I send the patch again, see if it is
> useful to other people.
> 
> I just worked out the python-ldap so that it will convert the local
> characters to utf8 or vice versa according to the user locale setup.
> This is done because OpenLdap currently only support utf8, one has
> to make the translation mannually getting in or out of openldap.  I
> tested on zh_CN.GB2312 (simplified Chinese), and it worked.  By no
> means it is a complete test, but it is a good start, and it worked
> for me.  The patch was generated against the CVS tree check out
> yesterday, so it is pretty recent.

I would be careful with this patch.

It looks to me that you are converting *every* ldap attribute from the
current locale encoding to UTF-8 (and vice versa). This takes care of
the most common attributes, but it affects binary attributes as well,
which it shouldn't.

IMHO a better approach would be to allow Python Unicode strings as
well as regular strings for writing attributes, then encode unicode
strings to UTF-8.

For reading from LDAP, I'm not sure what the best approach would
be. E.g. if the attribute type syntax is "Directory String", create a
unicode string, otherwise create a literal string. But how do you know
the attribute syntax? Maybe it is best to leave the attributes as they
are and leave the encoding to the user...

just my 0.02$

/steffen
-- 
steffen.ries at sympatico.ca	<> Gravity is a myth -- the Earth sucks!




From js9s at netscape.net  Tue Oct 16 12:44:24 2001
From: js9s at netscape.net (js9s at netscape.net)
Date: Tue, 16 Oct 2001 06:44:24 -0400
Subject: patch for Internationalization support (iconv)
Message-ID: <1C7917E2.5923A124.0000408D@netscape.net>

I have sent to Leonard  the patch, but did not get any indication of its being received, so here I send the patch again, see if it is useful to other people.

 I just worked out the python-ldap so that it will convert the local characters to utf8 or vice versa according to the user locale setup.   This is done because OpenLdap currently only support utf8, one has to make the  translation mannually getting in or out of openldap.   I tested on zh_CN.GB2312 (simplified Chinese), and it worked.  By no means it is a complete test, but it is a good start, and it worked for me.  The patch was generated against the CVS tree check out yesterday, so it is pretty recent.
Here is the patch in the attachment.


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop at Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pl.patch
Type: application/octet-stream
Size: 28064 bytes
Desc: pl.patch
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20011016/b5b2798b/attachment.obj>

From david.leonard at itee.uq.edu.au  Tue Oct 16 13:34:03 2001
From: david.leonard at itee.uq.edu.au (David Leonard)
Date: Tue, 16 Oct 2001 21:34:03 +1000 (EST)
Subject: Internationalization patch, i18n, iconv, ...
In-Reply-To: <50469213.2694AE01.0000408D@netscape.net>
Message-ID: <Pine.BSO.4.33.0110162124280.2167-100000@cathexis.bovingdon-st.fnarg.net.au>


On Sat, 13 Oct 2001, js9s at netscape.net typed thusly:
> I just worked out the python-ldap so that it will convert the
> local charactors to utf8 or vice versa according to the user locale
> setup.   This is done because OpenLdap currently only support utf8,
> so  one has to make the  translation.   I tested on zh_CN.GB2312
> (simplified Chinese), and it worked.  By no means it is a complete
> test, but it is a good start, and it worked for me.  The patch was
> generated against the CVS tree check out yesterday, so it is pretty
> recent.
> Here is the patch in the attachment.

hi

sorry i have been unable to respond to you - i had marked your
message important but have been busy of late. :(

i'm glad you send it to the list, because it will stand a better chance
of being reviewed there.. a better chance than just sitting in my mailbox.

here are my comments from a quick perusal of the diff

... the diff is reversed. (took me a moment to figure out what was
going on there!.. the order is 'diff <old> <new>')

... you're relying on an iconv.h header file, which isn't on every
system. (especially mine)

.. I think instead to use PyString_Decode() and PyString_Encode()..
that way you get python unicode string objects.

i'm not an expert on these things, but here is a cut and paste from
a python header file:

/* Create a string object by decoding the encoded string s of the
   given size. */

extern DL_IMPORT(PyObject*) PyString_Decode(
    const char *s,              /* encoded string */
    int size,                   /* size of buffer */
    const char *encoding,       /* encoding */
    const char *errors          /* error handling */
    );

/* Encodes a char buffer of the given size and returns a
   Python string object. */

extern DL_IMPORT(PyObject*) PyString_Encode(
    const char *s,              /* string char buffer */
    int size,                   /* number of chars to encode */
    const char *encoding,       /* encoding */
    const char *errors          /* error handling */
    );


d

-- 
David Leonard                           David.Leonard at itee.uq.edu.au
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Make sure that you have enough free memory in your temp directory.
	- Sun StarOffice README





From michael at stroeder.com  Tue Oct 16 18:10:41 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 16 Oct 2001 18:10:41 +0200
Subject: patch for Internationalization support (iconv)
References: <1C7917E2.5923A124.0000408D@netscape.net> <m3zo6rdc3y.fsf@gondolin.beleriand>
Message-ID: <3BCC5C01.CCD452FA@stroeder.com>

Steffen Ries wrote:
> 
> js9s at netscape.net writes:
> 
> > I just worked out the python-ldap so that it will convert the local
> > characters to utf8 or vice versa according to the user locale setup.
> > This is done because OpenLdap currently only support utf8, one has
> > to make the translation mannually getting in or out of openldap.
> 
> I would be careful with this patch.

Me too.

> It looks to me that you are converting *every* ldap attribute from the
> current locale encoding to UTF-8 (and vice versa). This takes care of
> the most common attributes, but it affects binary attributes as well,
> which it shouldn't.

Exactly. Without knowing the schema (syntax of attribute here) used
on the server a LDAP application should not simply assume UTF-8.
Also a really compliant application should look at the LDAP version
in use. LDAPv2 assumes T.61.

> IMHO a better approach would be to allow Python Unicode strings as
> well as regular strings for writing attributes, then encode unicode
> strings to UTF-8.

The application has to know the schema and therefore the application
is responsible for encoding before passing strings to python-ldap.
python-ldap is too low-level for that. I would even disallow passing
Unicode strings to python-ldap.

> For reading from LDAP, I'm not sure what the best approach would
> be. E.g. if the attribute type syntax is "Directory String", create a
> unicode string, otherwise create a literal string. But how do you know
> the attribute syntax?

Again: python-ldap is too low-level for that. Don't mess with
different string types! And rethink why default encoding in Python's
Unicode support is ASCII.

> Maybe it is best to leave the attributes as they
> are and leave the encoding to the user...

Definitely yes!

Ciao, Michael.



From js9s at netscape.net  Tue Oct 16 19:41:00 2001
From: js9s at netscape.net (js9s at netscape.net)
Date: Tue, 16 Oct 2001 13:41:00 -0400
Subject: Internationalization patch, i18n, iconv, ...
Message-ID: <66028D4C.51DFDB46.0000408D@netscape.net>

The iconv is part of glibc 2.2.2 and above, so iconv.h should be in any recent LINUX system if the C developement environment is configured. If older than glic 2.2.2, you might have to install the iconvlib seperately.

I did try to use PyString_(De/En)code, but it is not very well suited to openldap type of applications, especially if dn has mixed ascii and utf8 encodings.  But I will be happy if someone can prove I am wrong. 

Thanks.
J.


David Leonard <david.leonard at itee.uq.edu.au> wrote:

>
>On Sat, 13 Oct 2001, js9s at netscape.net typed thusly:
>> I just worked out the python-ldap so that it will convert the
>> local charactors to utf8 or vice versa according to the user locale
>> setup.   This is done because OpenLdap currently only support utf8,
>> so  one has to make the  translation.   I tested on zh_CN.GB2312
>> (simplified Chinese), and it worked.  By no means it is a complete
>> test, but it is a good start, and it worked for me.  The patch was
>> generated against the CVS tree check out yesterday, so it is pretty
>> recent.
>> Here is the patch in the attachment.
>
>hi
>
>sorry i have been unable to respond to you - i had marked your
>message important but have been busy of late. :(
>
>i'm glad you send it to the list, because it will stand a better chance
>of being reviewed there.. a better chance than just sitting in my mailbox.
>
>here are my comments from a quick perusal of the diff
>
>... the diff is reversed. (took me a moment to figure out what was
>going on there!.. the order is 'diff <old> <new>')
>
>... you're relying on an iconv.h header file, which isn't on every
>system. (especially mine)
>
>.. I think instead to use PyString_Decode() and PyString_Encode()..
>that way you get python unicode string objects.
>
>i'm not an expert on these things, but here is a cut and paste from
>a python header file:
>
>/* Create a string object by decoding the encoded string s of the
>   given size. */
>
>extern DL_IMPORT(PyObject*) PyString_Decode(
>    const char *s,              /* encoded string */
>    int size,                   /* size of buffer */
>    const char *encoding,       /* encoding */
>    const char *errors          /* error handling */
>    );
>
>/* Encodes a char buffer of the given size and returns a
>   Python string object. */
>
>extern DL_IMPORT(PyObject*) PyString_Encode(
>    const char *s,              /* string char buffer */
>    int size,                   /* number of chars to encode */
>    const char *encoding,       /* encoding */
>    const char *errors          /* error handling */
>    );
>
>
>d
>
>-- 
>David Leonard                           David.Leonard at itee.uq.edu.au
>Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
>The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
>QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8
>
>Make sure that you have enough free memory in your temp directory.
>    - Sun StarOffice README
>
>
>




From js9s at netscape.net  Wed Oct 17 07:18:34 2001
From: js9s at netscape.net (js9s at netscape.net)
Date: Wed, 17 Oct 2001 01:18:34 -0400
Subject: Internationalization patch, i18n, iconv, ...
Message-ID: <2DAAF59F.48D2D89D.0000408D@netscape.net>

UNIX(LINUX)  is the only OS I know that has the internationalization (i18n) concept. Windows, VMS and many other less known OS, such as milkyway etc., only have the concept of localization (L10?).  This patch may be used for localization purpose as well, but its main target is the i18n type of applications.  Don't know about mac, but since it is mainly a personal system, my guess is that it is just like windows, L10 only.

any way, I appreciate the good work in the free software community, and like to contribute something back.  I have no interest getting into the OS squabbling, especially with mac fans.

Thanks
J.
 

jmlittle at mac.com wrote:

>I wouldn't suggest that the audience here is 100% linux. Rather, a 
>majority likely is not
>
>On Tuesday, October 16, 2001, at 10:41 AM, js9s at netscape.net wrote:
>
>> The iconv is part of glibc 2.2.2 and above, so iconv.h should be in any 
>> recent LINUX system if the C developement environment is configured. If 
>> older than glic 2.2.2, you might have to install the iconvlib 
>> seperately.
>>
>> I did try to use PyString_(De/En)code, but it is not very well suited 
>> to openldap type of applications, especially if dn has mixed ascii and 
>> utf8 encodings.  But I will be happy if someone can prove I am wrong.
>>
>> Thanks.
>> J.
>>
>>
>> David Leonard <david.leonard at itee.uq.edu.au> wrote:
>>
>>>
>>> On Sat, 13 Oct 2001, js9s at netscape.net typed thusly:
>>>> I just worked out the python-ldap so that it will convert the
>>>> local charactors to utf8 or vice versa according to the user locale
>>>> setup.   This is done because OpenLdap currently only support utf8,
>>>> so  one has to make the  translation.   I tested on zh_CN.GB2312
>>>> (simplified Chinese), and it worked.  By no means it is a complete
>>>> test, but it is a good start, and it worked for me.  The patch was
>>>> generated against the CVS tree check out yesterday, so it is pretty
>>>> recent.
>>>> Here is the patch in the attachment.
>>>
>>> hi
>>>
>>> sorry i have been unable to respond to you - i had marked your
>>> message important but have been busy of late. :(
>>>
>>> i'm glad you send it to the list, because it will stand a better chance
>>> of being reviewed there.. a better chance than just sitting in my 
>>> mailbox.
>>>
>>> here are my comments from a quick perusal of the diff
>>>
>>> ... the diff is reversed. (took me a moment to figure out what was
>>> going on there!.. the order is 'diff <old> <new>')
>>>
>>> ... you're relying on an iconv.h header file, which isn't on every
>>> system. (especially mine)
>>>
>>> .. I think instead to use PyString_Decode() and PyString_Encode()..
>>> that way you get python unicode string objects.
>>>
>>> i'm not an expert on these things, but here is a cut and paste from
>>> a python header file:
>>>
>>> /* Create a string object by decoding the encoded string s of the
>>>   given size. */
>>>
>>> extern DL_IMPORT(PyObject*) PyString_Decode(
>>>    const char *s,              /* encoded string */
>>>    int size,                   /* size of buffer */
>>>    const char *encoding,       /* encoding */
>>>    const char *errors          /* error handling */
>>>    );
>>>
>>> /* Encodes a char buffer of the given size and returns a
>>>   Python string object. */
>>>
>>> extern DL_IMPORT(PyObject*) PyString_Encode(
>>>    const char *s,              /* string char buffer */
>>>    int size,                   /* number of chars to encode */
>>>    const char *encoding,       /* encoding */
>>>    const char *errors          /* error handling */
>>>    );
>>>
>>>
>>> d
>>>
>>> --
>>> David Leonard                           David.Leonard at itee.uq.edu.au
>>> Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
>>> The University of Queensland       |+|  
>>> http://www.itee.uq.edu.au/~leonard/
>>> QLD 4072  AUSTRALIA               ~` '~ 
>>> B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8
>>>
>>> Make sure that you have enough free memory in your temp directory.
>>>    - Sun StarOffice README
>>>
>>>
>>>
>>
>>
>> 

From david.leonard at itee.uq.edu.au  Wed Oct 17 07:25:41 2001
From: david.leonard at itee.uq.edu.au (David Leonard)
Date: Wed, 17 Oct 2001 15:25:41 +1000 (EST)
Subject: Internationalization patch, i18n, iconv, ...
In-Reply-To: <2DAAF59F.48D2D89D.0000408D@netscape.net>
Message-ID: <Pine.BSO.4.33.0110171522570.2167-100000@cathexis.bovingdon-st.fnarg.net.au>


to get this thread back on track, does anyone have objections to Michael's
solution?

i.e. leave the data as 'raw' strings, and use codecs.utf_8_decode() when you
know that it is UTF-8 encoded.

d

On Wed, 17 Oct 2001, js9s at netscape.net typed thusly:

> UNIX(LINUX)  is the only OS I know that has the internationalization (i18n) concept. Windows, VMS and many other less known OS, such as milkyway etc., only have the concept of localization (L10?).  This patch may be used for localization purpose as well, but its main target is the i18n type of applications.  Don't know about mac, but since it is mainly a personal system, my guess is that it is just like windows, L10 only.

-- 
David Leonard                           David.Leonard at itee.uq.edu.au
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Make sure that you have enough free memory in your temp directory.
	- Sun StarOffice README




From jlittle at open-it.org  Wed Oct 17 07:44:29 2001
From: jlittle at open-it.org (Joe Little)
Date: Tue, 16 Oct 2001 22:44:29 -0700
Subject: Internationalization patch, i18n, iconv, ...
In-Reply-To: <2DAAF59F.48D2D89D.0000408D@netscape.net>
Message-ID: <0876F554-C2C2-11D5-9E35-0003930B38C0@open-it.org>

well, mac is now UNIX, its also already I18N natively

Don't start a flame war without fuel :)....

I'm merely stating the the python-ldap module needs to maintain its 
ability to be os agnostic.

On Tuesday, October 16, 2001, at 10:18 PM, js9s at netscape.net wrote:

> UNIX(LINUX)  is the only OS I know that has the internationalization 
> (i18n) concept. Windows, VMS and many other less known OS, such as 
> milkyway etc., only have the concept of localization (L10?).  This 
> patch may be used for localization purpose as well, but its main target 
> is the i18n type of applications.  Don't know about mac, but since it 
> is mainly a personal system, my guess is that it is just like windows, 
> L10 only.
>
> any way, I appreciate the good work in the free software community, and 
> like to contribute something back.  I have no interest getting into the 
> OS squabbling, especially with mac fans.
>
> Thanks
> J.
>
>
> jmlittle at mac.com wrote:
>
>> I wouldn't suggest that the audience here is 100% linux. Rather, a
>> majority likely is not
>>
>> On Tuesday, October 16, 2001, at 10:41 AM, js9s at netscape.net wrote:
>>
>>> The iconv is part of glibc 2.2.2 and above, so iconv.h should be in 
>>> any
>>> recent LINUX system if the C developement environment is configured. 
>>> If
>>> older than glic 2.2.2, you might have to install the iconvlib
>>> seperately.
>>>
>>> I did try to use PyString_(De/En)code, but it is not very well suited
>>> to openldap type of applications, especially if dn has mixed ascii and
>>> utf8 encodings.  But I will be happy if someone can prove I am wrong.
>>>
>>> Thanks.
>>> J.
>>>
>>>
>>> David Leonard <david.leonard at itee.uq.edu.au> wrote:
>>>
>>>>
>>>> On Sat, 13 Oct 2001, js9s at netscape.net typed thusly:
>>>>> I just worked out the python-ldap so that it will convert the
>>>>> local charactors to utf8 or vice versa according to the user locale
>>>>> setup.   This is done because OpenLdap currently only support utf8,
>>>>> so  one has to make the  translation.   I tested on zh_CN.GB2312
>>>>> (simplified Chinese), and it worked.  By no means it is a complete
>>>>> test, but it is a good start, and it worked for me.  The patch was
>>>>> generated against the CVS tree check out yesterday, so it is pretty
>>>>> recent.
>>>>> Here is the patch in the attachment.
>>>>
>>>> hi
>>>>
>>>> sorry i have been unable to respond to you - i had marked your
>>>> message important but have been busy of late. :(
>>>>
>>>> i'm glad you send it to the list, because it will stand a better 
>>>> chance
>>>> of being reviewed there.. a better chance than just sitting in my
>>>> mailbox.
>>>>
>>>> here are my comments from a quick perusal of the diff
>>>>
>>>> ... the diff is reversed. (took me a moment to figure out what was
>>>> going on there!.. the order is 'diff <old> <new>')
>>>>
>>>> ... you're relying on an iconv.h header file, which isn't on every
>>>> system. (especially mine)
>>>>
>>>> .. I think instead to use PyString_Decode() and PyString_Encode()..
>>>> that way you get python unicode string objects.
>>>>
>>>> i'm not an expert on these things, but here is a cut and paste from
>>>> a python header file:
>>>>
>>>> /* Create a string object by decoding the encoded string s of the
>>>>   given size. */
>>>>
>>>> extern DL_IMPORT(PyObject*) PyString_Decode(
>>>>    const char *s,              /* encoded string */
>>>>    int size,                   /* size of buffer */
>>>>    const char *encoding,       /* encoding */
>>>>    const char *errors          /* error handling */
>>>>    );
>>>>
>>>> /* Encodes a char buffer of the given size and returns a
>>>>   Python string object. */
>>>>
>>>> extern DL_IMPORT(PyObject*) PyString_Encode(
>>>>    const char *s,              /* string char buffer */
>>>>    int size,                   /* number of chars to encode */
>>>>    const char *encoding,       /* encoding */
>>>>    const char *errors          /* error handling */
>>>>    );
>>>>
>>>>
>>>> d
>>>>
>>>> --
>>>> David Leonard                           David.Leonard at itee.uq.edu.au
>>>> Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
>>>> The University of Queensland       |+|
>>>> http://www.itee.uq.edu.au/~leonard/
>>>> QLD 4072  AUSTRALIA               ~` '~
>>>> B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8
>>>>
>>>> Make sure that you have enough free memory in your temp directory.
>>>>    - Sun StarOffice README
>>>>
>>>>
>>>>
>>>
>>>
>>> 

From michael at stroeder.com  Wed Oct 17 09:56:52 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 17 Oct 2001 09:56:52 +0200
Subject: Internationalization patch, i18n, iconv, ...
References: <66028D4C.51DFDB46.0000408D@netscape.net>
Message-ID: <3BCD39C4.6C5BE0D7@stroeder.com>

js9s at netscape.net wrote:
> 
> The iconv is part of glibc 2.2.2 and above, so iconv.h should be in
> any recent LINUX system

web2ldap based on python-ldap aims to run on Win32 platform too...

Anyway all character set translation should be based on Unicode
support introduced in Python 1.6 because the codec concept looks
very clean. There are Unicode codecs for Python based on iconv lib
if the built-in Python codecs are not sufficient.

> I did try to use PyString_(De/En)code, but it is not very well
> suited to openldap type of applications, especially if dn has mixed
> ascii and utf8 encodings.

I'm not sure what you mean with "mixed ascii and utf8 encodings".

UTF-8 is a variable length encoding of the ISO-10646 character set
which maps the page containing the ASCII characters directly to
ASCII.

Example with my last name:

>>> unicode('Str?der','iso-8859-1').encode('utf-8')
'Str\xc3\xb6der'

Ciao, Michael.



From michael at stroeder.com  Wed Oct 17 09:56:42 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 17 Oct 2001 09:56:42 +0200
Subject: Internationalization patch, i18n, iconv, ...
References: <0876F554-C2C2-11D5-9E35-0003930B38C0@open-it.org>
Message-ID: <3BCD39BA.62C753C0@stroeder.com>

Joe Little wrote:
> 
> I'm merely stating the the python-ldap module needs to maintain its
> ability to be os agnostic.

Yes. Although my personal preference is using Linux as OS it's an
important requirement that python-ldap should run on any platform
where Python has been ported to. If somebody needs special codecs
not part of the Python distribution he/she should look into the
iconv-based Python codec project.

Ciao, Michael.



From michael at stroeder.com  Wed Oct 17 20:00:17 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 17 Oct 2001 20:00:17 +0200
Subject: Using python-ldap with web2ldap
References: <3BCD9AAA.40803@rtv.AWOLart.com>
Message-ID: <3BCDC731.867C5F05@stroeder.com>

Art Vossberg wrote:
> [..]
> Traceback (most recent call last):
> [..]
> NameError: cannot set that field
> [..]
> Obviously, most of this data is environmental data, but the last several
> lines indicate a setoption or __setattr__ problem.

FYI: With web2ldap I already try to handle differences of
python-ldap built against different versions of the OpenLDAP libs.
This works fairly well with the patches exposing the "version"
attribute. I take the presence of the "version" attribute as
indicator that the OpenLDAP 2 libs are used.

However if the python-ldap was built against OpenLDAP 2 libs with
patches which does not expose the "version" attribute it is assumed
that the OpenLDAP 1 libs are in place and setting the LDAP
connection options via attribute "options" obviously fails.

For those of you interested in the gory details check out module
ldapsession.py shipped with web2ldap.

Ciao, Michael.



From art at rtv.AWOLart.com  Wed Oct 17 16:50:18 2001
From: art at rtv.AWOLart.com (Art Vossberg)
Date: Wed, 17 Oct 2001 10:50:18 -0400
Subject: Using python-ldap with web2ldap
Message-ID: <3BCD9AAA.40803@rtv.AWOLart.com>

Following the advice on the list to delete the references to 'ufn' in 
modules/LDAPObject.c I have been able to get the module to compile and 
it imports without criticism.  However, web2ldap (which is the only 
program presently using pytjon-ldap) no longer works.
 When a user tries to connect, the following error message is generated 
in the apache log:

[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: 


From michael at stroeder.com  Thu Oct 18 13:34:08 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 18 Oct 2001 13:34:08 +0200
Subject: Internationalization patch, i18n, iconv, ...
References: <15A46EDB.7C475F29.0000408D@netscape.net>
Message-ID: <3BCEBE30.B9417B70@stroeder.com>

js9s at netscape.net wrote:
> 
> I have something like uid=someone,ou=???,dc=domain,dc=org. The
> ou value is in gb2312 encoding.

It seems that your DNs are not compliant to RFC2253. All attribute
values should be UTF-8 encoded ISO-10646 Unicode. Check the
component which builds this DN.

Ciao, Michael.



From js9s at netscape.net  Wed Oct 17 17:38:42 2001
From: js9s at netscape.net (js9s at netscape.net)
Date: Wed, 17 Oct 2001 11:38:42 -0400
Subject: Internationalization patch, i18n, iconv, ...
Message-ID: <15A46EDB.7C475F29.0000408D@netscape.net>

I have something like uid=someone,ou=???,dc=domain,dc=org. The ou value is in gb2312 encoding.  If I use PyString_(En/De) the whole dn string, OpenLDAP doesn't like it.  So I have to parse out the ou=, and only PyString_(En/De) that piece, which make things quite bit more complicated, and I did not spend time to figure out why. I choose a quick and easy(dirty ?) way out for myself, and get this thread started. I will certainly vote for someone who can device an effecient and clean way to do it cross platforms. 

Michael Str??der <michael at stroeder.com> wrote:

>js9s at netscape.net wrote:
>> 
>> The iconv is part of glibc 2.2.2 and above, so iconv.h should be in
>> any recent LINUX system
>
>web2ldap based on python-ldap aims to run on Win32 platform too...
>
>Anyway all character set translation should be based on Unicode
>support introduced in Python 1.6 because the codec concept looks
>very clean. There are Unicode codecs for Python based on iconv lib
>if the built-in Python codecs are not sufficient.
>
>> I did try to use PyString_(De/En)code, but it is not very well
>> suited to openldap type of applications, especially if dn has mixed
>> ascii and utf8 encodings.
>
>I'm not sure what you mean with "mixed ascii and utf8 encodings".
>
>UTF-8 is a variable length encoding of the ISO-10646 character set


>which maps the page containing the ASCII characters directly to
>ASCII.
>
>Example with my last name:
>
>>>> unicode('Str?der','iso-8859-1').encode('utf-8')
>'Str\xc3\xb6der'
>
>Ciao, Michael.
>




From michael at stroeder.com  Thu Oct 18 17:34:25 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 18 Oct 2001 17:34:25 +0200
Subject: ldif.py 0.3.0
Message-ID: <3BCEF681.EEEF8318@stroeder.com>

HI!

I've checked in some modifications to the ldif module.

See details on:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Lib/ldif.py?rev=1.6&content-type=text/vnd.viewcvs-markup

Please test. Especially those of you still using Python 1.5.x or
prior versions.

Ciao, Michael.



From art at rtv.AWOLart.com  Thu Oct 18 15:56:27 2001
From: art at rtv.AWOLart.com (Art Vossberg)
Date: Thu, 18 Oct 2001 09:56:27 -0400
Subject: Python-LDAP-dev digest, Vol 1 #179 - 1 msg
References: <E15tw9z-00040w-00@usw-sf-list1.sourceforge.net>
Message-ID: <3BCEDF8B.2050306@rtv.AWOLart.com>

>
>
>FYI: With web2ldap I already try to handle differences of
>python-ldap built against different versions of the OpenLDAP libs.
>This works fairly well with the patches exposing the "version"
>attribute. I take the presence of the "version" attribute as
>indicator that the OpenLDAP 2 libs are used.
>
What patches are you referring to ?

>
>However if the python-ldap was built against OpenLDAP 2 libs with
>patches which does not expose the "version" attribute it is assumed
>that the OpenLDAP 1 libs are in place and setting the LDAP
>connection options via attribute "options" obviously fails.
>
>For those of you interested in the gory details check out module
>ldapsession.py shipped with web2ldap.
>
>
I looked at ldapsession and grepped everything in site to see where 
openldap version is set.
However, I am still getting the same error messages.

I am using web2ldap-20011015 and the most recent python-ldap CVS build.


-- 
The information contained in this message is privileged and confi-
dential. If you have received this message in error, please notify 
the sender at the address or the telephone number set forth below.

Arthur E. Vossberg III
1100 Buckingham Way
Yardley, PA 19067
Telephone: +1 215 295 8207

For secure transmissions over the Internet, 
please use the sender's gpg public key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (SunOS)
Comment: Issued by art at rtv.AWOLart.com

mQGiBDurtG8RBACLL+gvAe9pkG4a45rxCAbPW+Zn+Oy0wdWy/6dQFZ91bbQsf0KM
XFm0EN/9IEqEl2H7xafjUtw4MDNVeYrKM6ikujq9zRIEP3JLCUpxX7DAQ7uK0Yq4
2+WhciR2XxQsMnUnZfd5WcNuC3MmgP6BM1h7mUjhImrxzP+jgYn3Phu+wwCgl5da
e8+JWgAJwM1Pkgi387U7s8sD/2eLgzaTLpCfJ9yFDLT6ItbtYz28LszfNCkSJRYR
pgaXaKnravHvts66PlB3Y96UAh8HMTeLHtytWS0m6UCMIDXAS9QR3JaEk2ig9Oxx
uAXgnSypCGYb5gk29AuDNNOzZfvEeGN2aUPT/TbUom7BkuraxF5WGwX3DuaSlNEE
hpAuA/4+sndzENT1uJ50A1kL2/L6Tf2u7dGgSQyKiEEeegCUWEgNS3bdmWoKzfCi
Sg2ZHFtm0k1xZTCG2lLeuZAzYv5elzk4/4op8dXJcV8qh2eClDwhDaYomLeNdWod
u3QiSDgycx+VPB+Xg35XHRw81ceNvRiAJJFPM1EX50OoiDuQprQsQXJ0IFZvc3Ni
ZXJnIChncGdVc2VyKSA8YXJ0QHJ0di5BV09MYXJ0LmNvbT6IXQQTEQIAHQUCO6u0
bwUJBaOagAULBwoDBAMVAwIDFgIBAheAAAoJELq8qjjqxHt4xEEAn3hp9PXriwv5
mAiDXgi95sq4spg/AJ46P7IMM0NkXs4yV7+47l2UFoeysrkBDQQ7q7UzEAQAuIJc
v9Zjl1qB7+lfZoaqk7FpCRO9MddH2BRkvRvCgfZUDwx8cCYtPE6HcElB06rHGVcn
y8bPbNvrZAHB058/xX46PNTH3XGkUWpwyC6y1XGbGGaNS6QaGWRGJGqFCagMg8Qf
wu6qeyYrc5pldiS0wQOnDz+Ck9gme/UzlJh1yb8AAwcD/jos272U+F5WGvwZ15jo
ic/6wF3LAZBzGEw6oyacY/qR0sesGO9PPDBvvD+93n4OB9FKjwFTeaE8IifO1nXe
TTDPqDy+eGKKCIBROtAU6SqBCzUvwfKWTs2De0z7Orru1fdruZnDW3VhKFeCD+f4
iXWSp1zGa0ZoRkjgobXNE4VziEwEGBECAAwFAjurtTMFCQWjmoAACgkQuryqOOrE
e3ilmgCcDqtqLyPmb0OOWaWP5O6FRxiZVJYAn2xHATJorP9M+TLxtrOaZV0v8NWG
=HpkW
-----END PGP PUBLIC KEY BLOCK-----






From michael at stroeder.com  Thu Oct 18 20:22:43 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 18 Oct 2001 20:22:43 +0200
Subject: Python-LDAP-dev digest, Vol 1 #179 - 1 msg
References: <E15tw9z-00040w-00@usw-sf-list1.sourceforge.net> <3BCEDF8B.2050306@rtv.AWOLart.com>
Message-ID: <3BCF1DF3.4AC305E9@stroeder.com>

Art Vossberg wrote:
> 
> >FYI: With web2ldap I already try to handle differences of
> >python-ldap built against different versions of the OpenLDAP libs.
> >This works fairly well with the patches exposing the "version"
> >attribute. I take the presence of the "version" attribute as
> >indicator that the OpenLDAP 2 libs are used.
> >
> What patches are you referring to ?

You can find them in the mailing list archives. Konstantin announced
to check in his patches soon but did not find the time yet, I guess.
The OpenLDAP 2 libs adaption in web2ldap is exactly something I've
implemented for him because he definitely needs LDAPv3 binds
(instead of LDAPv2).

> >However if the python-ldap was built against OpenLDAP 2 libs with
> >patches which does not expose the "version" attribute it is assumed
> >that the OpenLDAP 1 libs are in place and setting the LDAP
> >connection options via attribute "options" obviously fails.
> >
> I looked at ldapsession and grepped everything in site to see where
> openldap version is set.
> However, I am still getting the same error messages.

As I wrote above setting the "options" attribute fails. Check out
LDAPSession.__setattr__().

Sorry, just removing code in web2ldap's modules isn't the solution.
The solution is to inform the maintainer of your python-ldap RPM or
patched source tree that attribute "version" and probably some
others are not exposed properly.

Ciao, Michael.



From michael at stroeder.com  Fri Oct 19 13:48:21 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 19 Oct 2001 13:48:21 +0200
Subject: start tls
References: <m3wv5aytil.fsf@gondolin.beleriand>
Message-ID: <3BD01305.744F8614@stroeder.com>

Steffen Ries wrote:
> 
> attached is a small (experimental) patch, which enables
> 'start_tls_s()' in python-ldap. The patch requires OpenLDAP 2.0.x (I
> tested it only against 2.0.11 on Redhat 6.2).
> [..]
> A simple demonstration looks like this:
> >>> server = ldap.open('localhost')
> >>> server.version = ldap.VERSION3
> >>> server.start_tls_s()
> >>> server.simple_bind_s(...)
> 
> If the ldap server supports startTLS and the Certificate maps to the
> host, the call to start_tls_s() succeeds, otherwise an exception is
> thrown.

How's the trusted CA cert chain configured? It does not really make
sense to use TLS if the LDAP client does not verify the server's
certificate against a trusted root CA cert.

Also doing a
>>> del l
crashs the interpreter no matter if unbind_s() was called before or
not.

Ciao, Michael.



From michael at stroeder.com  Fri Oct 19 14:37:19 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 19 Oct 2001 14:37:19 +0200
Subject: Detecting underlying LDAP lib
References: <3BCD9AAA.40803@rtv.AWOLart.com> <3BCDC731.867C5F05@stroeder.com>
Message-ID: <3BD01E7F.55124B51@stroeder.com>

Michael Str?der wrote:
> 
> Art Vossberg wrote:
> > [..]
> > Traceback (most recent call last):
> > [..]
> > NameError: cannot set that field
> > [..]
> > Obviously, most of this data is environmental data, but the last several
> > lines indicate a setoption or __setattr__ problem.
> 
> FYI: With web2ldap I already try to handle differences of
> python-ldap built against different versions of the OpenLDAP libs.

BTW: I think python-ldap should expose the following constants:

LDAP_API_VERSION
LDAP_VENDOR_NAME
LDAP_VENDOR_VERSION

This would make it possible that an application can check more
precise the API vendor and version.

Other constants might be interesting as well:

LDAP_API_FEATURE_*

Ciao, Michael.



From art at rtv.AWOLart.com  Fri Oct 19 17:18:43 2001
From: art at rtv.AWOLart.com (Art Vossberg)
Date: Fri, 19 Oct 2001 11:18:43 -0400
Subject: Python-LDAP-dev digest, Vol 1 #179 - 1 msg
References: <E15tw9z-00040w-00@usw-sf-list1.sourceforge.net> <3BCEDF8B.2050306@rtv.AWOLart.com> <3BCF1DF3.4AC305E9@stroeder.com>
Message-ID: <3BD04453.6040106@rtv.AWOLart.com>

Michael Str?der wrote:

>
>As I wrote above setting the "options" attribute fails. Check out
>LDAPSession.__setattr__().
>
I believe this is the section of ldapsession.py to which you refer.
  def set_option(self,name,value):
    """Set LDAPObject option or attribute"""
    if self.openldap2 or name=='deref':
      setattr(self.l,name,value)

Based upon the error log, this is definitely the source of (or at least 
one of the sources of) my problems.
Where is the "openldap2" referred to above.

Apropos of the above I note that web2lapp/cnf.py has the following line
from web2ldapcnf import ldap_def

I have no such definition in webldapcnf. Do I need to add one and, if 
so, what is the appropriate ref:
openldap2, deref, etc.

>
>
>Sorry, just removing code in web2ldap's modules isn't the solution.
>The solution is to inform the maintainer of your python-ldap RPM or
>patched source tree that attribute "version" and probably some
>others are not exposed properly.
>
I am that maintainer you speak of.

>
>Ciao, Michael.
>


-- 
The information contained in this message is privileged and confi-
dential. If you have received this message in error, please notify 
the sender at the address or the telephone number set forth below.

Arthur E. Vossberg III
1100 Buckingham Way
Yardley, PA 19067
Telephone: +1 215 295 8207

For secure transmissions over the Internet, 
please use the sender's gpg public key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (SunOS)
Comment: Issued by art at rtv.AWOLart.com

mQGiBDurtG8RBACLL+gvAe9pkG4a45rxCAbPW+Zn+Oy0wdWy/6dQFZ91bbQsf0KM
XFm0EN/9IEqEl2H7xafjUtw4MDNVeYrKM6ikujq9zRIEP3JLCUpxX7DAQ7uK0Yq4
2+WhciR2XxQsMnUnZfd5WcNuC3MmgP6BM1h7mUjhImrxzP+jgYn3Phu+wwCgl5da
e8+JWgAJwM1Pkgi387U7s8sD/2eLgzaTLpCfJ9yFDLT6ItbtYz28LszfNCkSJRYR
pgaXaKnravHvts66PlB3Y96UAh8HMTeLHtytWS0m6UCMIDXAS9QR3JaEk2ig9Oxx
uAXgnSypCGYb5gk29AuDNNOzZfvEeGN2aUPT/TbUom7BkuraxF5WGwX3DuaSlNEE
hpAuA/4+sndzENT1uJ50A1kL2/L6Tf2u7dGgSQyKiEEeegCUWEgNS3bdmWoKzfCi
Sg2ZHFtm0k1xZTCG2lLeuZAzYv5elzk4/4op8dXJcV8qh2eClDwhDaYomLeNdWod
u3QiSDgycx+VPB+Xg35XHRw81ceNvRiAJJFPM1EX50OoiDuQprQsQXJ0IFZvc3Ni
ZXJnIChncGdVc2VyKSA8YXJ0QHJ0di5BV09MYXJ0LmNvbT6IXQQTEQIAHQUCO6u0
bwUJBaOagAULBwoDBAMVAwIDFgIBAheAAAoJELq8qjjqxHt4xEEAn3hp9PXriwv5
mAiDXgi95sq4spg/AJ46P7IMM0NkXs4yV7+47l2UFoeysrkBDQQ7q7UzEAQAuIJc
v9Zjl1qB7+lfZoaqk7FpCRO9MddH2BRkvRvCgfZUDwx8cCYtPE6HcElB06rHGVcn
y8bPbNvrZAHB058/xX46PNTH3XGkUWpwyC6y1XGbGGaNS6QaGWRGJGqFCagMg8Qf
wu6qeyYrc5pldiS0wQOnDz+Ck9gme/UzlJh1yb8AAwcD/jos272U+F5WGvwZ15jo
ic/6wF3LAZBzGEw6oyacY/qR0sesGO9PPDBvvD+93n4OB9FKjwFTeaE8IifO1nXe
TTDPqDy+eGKKCIBROtAU6SqBCzUvwfKWTs2De0z7Orru1fdruZnDW3VhKFeCD+f4
iXWSp1zGa0ZoRkjgobXNE4VziEwEGBECAAwFAjurtTMFCQWjmoAACgkQuryqOOrE
e3ilmgCcDqtqLyPmb0OOWaWP5O6FRxiZVJYAn2xHATJorP9M+TLxtrOaZV0v8NWG
=HpkW
-----END PGP PUBLIC KEY BLOCK-----


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20011019/5a6e17f7/attachment.html>

From Konstantin.Chuguev at dante.org.uk  Fri Oct 19 15:29:11 2001
From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev)
Date: Fri, 19 Oct 2001 14:29:11 +0100
Subject: Detecting underlying LDAP lib
References: <3BCD9AAA.40803@rtv.AWOLart.com> <3BCDC731.867C5F05@stroeder.com> <3BD01E7F.55124B51@stroeder.com>
Message-ID: <3BD02AA7.6896F887@dante.org.uk>

Michael Str?der wrote:

> Michael Str?der wrote:
> >
> BTW: I think python-ldap should expose the following constants:
>
> LDAP_API_VERSION
> LDAP_VENDOR_NAME
> LDAP_VENDOR_VERSION
>

It's not quite clear, because python-ldap is itself an API :-)
Maybe LDAP_C_API_VERSION or simpler: LDAP_C_API_NAME.
Currently supported versions are OPENLDAP_1 and OPENLDAP_2...


--
         * *       Konstantin Chuguev           Francis House
      *      *     Application Engineer         112 Hills Road
    *              Tel: +44 1223 302992         Cambridge CB2 1PQ
D  A  N  T  E      WWW: http://www.dante.net    United Kingdom






From michael at stroeder.com  Fri Oct 19 15:38:47 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 19 Oct 2001 15:38:47 +0200
Subject: Detecting underlying LDAP lib
References: <3BCD9AAA.40803@rtv.AWOLart.com> <3BCDC731.867C5F05@stroeder.com> <3BD01E7F.55124B51@stroeder.com> <3BD02AA7.6896F887@dante.org.uk>
Message-ID: <3BD02CE7.9088C99C@stroeder.com>

Konstantin Chuguev wrote:
> 
> Michael Str?der wrote:
> 
> > Michael Str?der wrote:
> > >
> > BTW: I think python-ldap should expose the following constants:
> >
> > LDAP_API_VERSION
> > LDAP_VENDOR_NAME
> > LDAP_VENDOR_VERSION
> >
> 
> It's not quite clear, because python-ldap is itself an API :-)

Obviously you're right. ;-)

> Maybe LDAP_C_API_VERSION or simpler: LDAP_C_API_NAME.
> Currently supported versions are OPENLDAP_1 and OPENLDAP_2...

But I'd really like to have a more fine-grained versioning. How
about:

C_API_VENDOR_NAME
C_API_VENDOR_VERSION

Since the OpenLDAP 2 API seems to be the only one coming with such
constants we have no problems following their naming and versioning
scheme and setting values to reasonable defaults in case of OpenLDAP
1.

Ciao, Michael.



From michael at stroeder.com  Sat Oct 20 18:38:10 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 20 Oct 2001 18:38:10 +0200
Subject: start tls
References: <m3wv5aytil.fsf@gondolin.beleriand> <3BD01305.744F8614@stroeder.com>
Message-ID: <3BD1A872.ABA3DB24@stroeder.com>

Michael Str?der wrote:
> 
> Steffen Ries wrote:
> >
> > attached is a small (experimental) patch, which enables
> > 'start_tls_s()' in python-ldap. The patch requires OpenLDAP 2.0.x (I
> > tested it only against 2.0.11 on Redhat 6.2).
> 
> Also doing a
> >>> del l
> crashs the interpreter no matter if unbind_s() was called before or
> not.

Steffen, I wonder which Python version you're using. It seems to run
stable under Python 2.0 but crashes under Python 2.1.x very often.
Most times in the case when the LDAP connection object is
deleted/cleaned up. Maybe there were significant changes in
reference counting, garbage collection etc. introduced in Python
2.1?

Steffen, Konstantin, would you mind glancing over
http://www.amk.ca/python/2.1/ ?

Ciao, Michael.



From steffen.ries at sympatico.ca  Sat Oct 20 19:11:50 2001
From: steffen.ries at sympatico.ca (Steffen Ries)
Date: 20 Oct 2001 13:11:50 -0400
Subject: start tls
In-Reply-To: Michael =?iso-8859-1?q?Str=F6der's?= message of "Sat, 20 Oct 2001 18:38:10 +0200"
References: <m3wv5aytil.fsf@gondolin.beleriand>
	<3BD01305.744F8614@stroeder.com> <3BD1A872.ABA3DB24@stroeder.com>
Message-ID: <m3pu7ib5ih.fsf@gondolin.beleriand>

Michael Str?der <michael at stroeder.com> writes:

> Michael Str?der wrote:
> > 
> > Steffen Ries wrote:
> > >
> > > attached is a small (experimental) patch, which enables
> > > 'start_tls_s()' in python-ldap. The patch requires OpenLDAP 2.0.x (I
> > > tested it only against 2.0.11 on Redhat 6.2).
> > 
> > Also doing a
> > >>> del l
> > crashs the interpreter no matter if unbind_s() was called before or
> > not.
> 
> Steffen, I wonder which Python version you're using. It seems to run
> stable under Python 2.0 but crashes under Python 2.1.x very often.
> Most times in the case when the LDAP connection object is
> deleted/cleaned up. Maybe there were significant changes in
> reference counting, garbage collection etc. introduced in Python
> 2.1?

I'm using both Python 2.0 (Solaris 8) and Python 2.1 (Linux [Redhat
7.1]). I have not seen stability problems and could not reproduce the
problems you had.

I have currently very little time, but I'll try to work on python-ldap
in the near future.

Can you give me more details what you do to crash the interpreter? A
simple bind+search works for me:

--8<--
Python 2.1.1 (#1, Jul 20 2001, 19:59:19) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import ldap
>>> s = ldap.open('localhost')
>>> s.version = ldap.VERSION3
>>> s.simple_bind_s(...)
>>> s.search_s(...)  
...
>>> del s
>>> 
--8<--

> Steffen, Konstantin, would you mind glancing over
> http://www.amk.ca/python/2.1/ ?

will do.

/steffen
-- 
steffen.ries at sympatico.ca	<> Gravity is a myth -- the Earth sucks!




From jfdoyon at server.methane.org  Mon Oct 22 20:10:37 2001
From: jfdoyon at server.methane.org (jfdoyon at server.methane.org)
Date: Mon, 22 Oct 2001 14:10:37 -0400 (EDT)
Subject: Undefined Symbol?
Message-ID: <Pine.LNX.4.10.10110221401490.32275-100000@server.methane.org>

Hello,

I just installed OpenLDAP 2.0.17 and the CVS version of python-ldap, and
am having the following error when trying to use it with Zope's
LDAPAdpater:

2001-10-22T17:49:27 ERROR(200) Zope Could not import Products.LDAPAdapter
Traceback (innermost last):
  File /usr/local/Zope-2.4.2/lib/python/OFS/Application.py, line 563, in
import_product
  File /usr/local/Zope-2.4.2/lib/python/Products/LDAPAdapter/__init__.py,
line 90, in ?
  File
/usr/local/Zope-2.4.2/lib/python/Products/LDAPAdapter/LDAPAdapter.py, line
120, in ?
  File /usr/lib/python2.1/site-packages/ldap.py, line 2, in ?
ImportError: /usr/lib/python2.1/site-packages/_ldap.so: undefined symbol:
ldap_ufn_setfilter

I know that that function exists in OpenLDAP, or at least is documented
...

The site mentionned patches, where do I get those, if that's the problem?

Thanks!

J.F.




From michael at stroeder.com  Mon Oct 22 20:22:06 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Mon, 22 Oct 2001 20:22:06 +0200
Subject: Undefined Symbol?
References: <Pine.LNX.4.10.10110221401490.32275-100000@server.methane.org>
Message-ID: <3BD463CE.2074BEA4@stroeder.com>

jfdoyon at server.methane.org wrote:
> 
> 
> I just installed OpenLDAP 2.0.17 and the CVS version of python-ldap,

See item 3 on http://python-ldap.sourceforge.net/faq.shtml

Note that applying patches to python-ldap is experimental.

Ciao, Michael.



From nick at brainstorm.co.uk  Tue Oct 23 14:27:30 2001
From: nick at brainstorm.co.uk (Nick Bower)
Date: Tue, 23 Oct 2001 13:27:30 +0100
Subject: How to generally handle exceptions?
Message-ID: <3BD56232.5DF133BC@brainstorm.co.uk>

Is there any possible way to tell what exception has been raised in
python-ldap without catching every single possibile type of
_ldap.LDAPError?

It would be really nice in example included in the python-ldap
documentation if an exception was caught in the following general way:

try:
  <connect, bind and search, as is currently shown>
except:
  <display type of exception and its description>

at the moment, there is no example code with exceptions in the
documentation or distribution and i can't figure out how to catch one
from the exception references provided without trying to catch every
single possibility.

thanks alot, nick.



From donal.hunt2 at mail.dcu.ie  Tue Oct 23 14:49:15 2001
From: donal.hunt2 at mail.dcu.ie (Donal Hunt)
Date: Tue, 23 Oct 2001 13:49:15 +0100
Subject: How to generally handle exceptions?
References: <3BD56232.5DF133BC@brainstorm.co.uk>
Message-ID: <3BD5674B.FDEBE32B@mail.dcu.ie>

Nick,

try this:


From michael at stroeder.com  Wed Oct 24 11:11:14 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 24 Oct 2001 11:11:14 +0200
Subject: How to generally handle exceptions?
References: <3BD56232.5DF133BC@brainstorm.co.uk>
Message-ID: <3BD685B2.62E84B8D@stroeder.com>

Nick Bower wrote:
> 
> Is there any possible way to tell what exception has been raised in
> python-ldap without catching every single possibile type of
> _ldap.LDAPError?
> 
> It would be really nice in example included in the python-ldap
> documentation if an exception was caught in the following general way:
> 
> try:
>   <connect, bind and search, as is currently shown>
> except:
>   <display type of exception and its description>
> 
> at the moment, there is no example code with exceptions in the
> documentation or distribution and i can't figure out how to catch one
> from the exception references provided without trying to catch every
> single possibility.

import ldap

try:
    <connect, bind and search, as is currently shown>
except ldap.LDAPError,e:
    print repr(e)

Well, exception instances are not really implemented completely
pythonic but it's a start.

Ciao, Michael.



From michael at stroeder.com  Wed Oct 24 14:41:02 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 24 Oct 2001 14:41:02 +0200
Subject: How to generally handle exceptions?
References: <3BD56232.5DF133BC@brainstorm.co.uk> <3BD685B2.62E84B8D@stroeder.com> <3BD691F1.8A8CB293@brainstorm.co.uk>
Message-ID: <3BD6B6DE.3B493008@stroeder.com>

Nick Bower wrote:
> 
> thanks - i was having trouble knowing where this "desc" field was.  so i
> se now that it is:
> 
> except _ldap.LDAPError, e
>   print 'Your error is ' + e[0]['desc']
> 
> thanks for the help.

Sometimes you can't rely on the exact data structure with e.args
being a dictionary of the form {'desc':'','info':''}. I'd also
recommend to display the info field. E.g. recent versions of
OpenLDAP 2 give more information about schema violation which is
useful for the user.

Maybe it's overkill how web2ldap does it but take the snippet below
as food for thought. Note that web2ldap trys to also handle older
versions of python-ldap floating around:

LDAPError = ldap.LDAPError

[..]

    except LDAPError,e:
      if __debug__:
        w2lapp.core.log_exception(errfile,sid,command,form,ls,env)
      try:
        if type(e.args[0])==type({}):
          ErrMsg = '%s: %s' %
(e.args[0]['desc'],e.args[0].get('info',''))
        elif type(e.args[0])==type(1):
          ErrMsg = 'Error Code: %d<br />Error description: %s' % (
            e.args[0],e.args[1]
          )
        else:
          ErrMsg = str(e.args)
      except TypeError:
        ErrMsg = str(e.args)
      except IndexError:
        ErrMsg = str(e.args)
      w2lapp.gui.ExceptionMsg(
        sid,outf,form,ls,'LDAP exception',ErrMsg
      )

[..]

Ciao, Michael.



From michael at stroeder.com  Thu Oct 25 13:31:31 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 25 Oct 2001 13:31:31 +0200
Subject: Undefined Symbol?
References: <Pine.LNX.4.10.10110231039300.10090-100000@server.methane.org>
Message-ID: <3BD7F813.B699808B@stroeder.com>

jfdoyon at server.methane.org wrote:
> 
> server = ldap.open('myhost',636)
> server.version = ldap.VERSION3
> server.start_tls_s()
> server.simple_bind_s("hidden","hidden")
> [..]
> ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"}

Took me also a while to figure this one out. The CN attribute in the
server's certificate has to be EXACTLY the same like the host name
you're using when calling ldap.open(). Check that.

Note that since there's no certificate validation in place this
patch does not provide protection against MITM-attacks. It has
experimental status and shouldn't be used in a productive
environment.

Ciao, Michael.



From jfdoyon at server.methane.org  Mon Oct 22 23:01:01 2001
From: jfdoyon at server.methane.org (jfdoyon at server.methane.org)
Date: Mon, 22 Oct 2001 17:01:01 -0400 (EDT)
Subject: Undefined Symbol?
In-Reply-To: <3BD463CE.2074BEA4@stroeder.com>
Message-ID: <Pine.LNX.4.10.10110221657560.927-100000@server.methane.org>

Michael,

I did see it, unfortunately, I'm not sure WHERE to find these patches,
they don't seem to be in the CVS tree! Also, the README in the CVS says it
was tested again OpenLDAP 2.0 and Python 2.0 ... Which is pretty damn
close to what I'm using (Python 2.1.1 with OpenLDAP 2.0.17, although the
files say 2.0.11 for some reason).

Maybe I'll try the RPM's :) I just like hacking things myself!

Thanks!
J.F.



On Mon, 22 Oct 2001, Michael [iso-8859-1] Str?der wrote:

> jfdoyon at server.methane.org wrote:
> > 
> > 
> > I just installed OpenLDAP 2.0.17 and the CVS version of python-ldap,
> 
> See item 3 on http://python-ldap.sourceforge.net/faq.shtml
> 
> Note that applying patches to python-ldap is experimental.
> 
> Ciao, Michael.
> 
> 

From jfdoyon at methane.org  Tue Oct 23 05:15:55 2001
From: jfdoyon at methane.org (Jean-François Doyon)
Date: Mon, 22 Oct 2001 23:15:55 -0400
Subject: Undefined Symbol?
In-Reply-To: <Pine.LNX.4.10.10110221657560.927-100000@server.methane.org>
Message-ID: <000001c15b71$079657d0$6601a8c0@pcjdoyon2>

Hello,

OK, never mind, I eventually figured it out :) Turns out the patches are
hidden inside the RPM's !

I had to do some manual work since I wanted it to work with Python 2.1, but
now I'm not getting any errors ...

I'm looking forward to trying it out :)

Thanks for the contribution!

Jean-Fran?ois Doyon
Carbon IT
http://methane.org
Tel.: (819) 827-9997
Fax : (819) 827-6653

-----Original Message-----
From: python-ldap-dev-admin at lists.sourceforge.net
[mailto:python-ldap-dev-admin at lists.sourceforge.net]On Behalf Of
jfdoyon at server.methane.org
Sent: October 22, 2001 5:01 PM
To: Michael Str?der
Cc: python-ldap-dev at lists.sourceforge.net
Subject: Re: Undefined Symbol?

Michael,

I did see it, unfortunately, I'm not sure WHERE to find these patches,
they don't seem to be in the CVS tree! Also, the README in the CVS says it
was tested again OpenLDAP 2.0 and Python 2.0 ... Which is pretty damn
close to what I'm using (Python 2.1.1 with OpenLDAP 2.0.17, although the
files say 2.0.11 for some reason).

Maybe I'll try the RPM's :) I just like hacking things myself!

Thanks!
J.F.



On Mon, 22 Oct 2001, Michael [iso-8859-1] Str?der wrote:

> jfdoyon at server.methane.org wrote:
> >
> >
> > I just installed OpenLDAP 2.0.17 and the CVS version of python-ldap,
>
> See item 3 on http://python-ldap.sourceforge.net/faq.shtml
>
> Note that applying patches to python-ldap is experimental.
>
> Ciao, Michael.
>
> 

From jfdoyon at server.methane.org  Tue Oct 23 16:46:55 2001
From: jfdoyon at server.methane.org (jfdoyon at server.methane.org)
Date: Tue, 23 Oct 2001 10:46:55 -0400 (EDT)
Subject: Undefined Symbol?
In-Reply-To: <000001c15b71$079657d0$6601a8c0@pcjdoyon2>
Message-ID: <Pine.LNX.4.10.10110231039300.10090-100000@server.methane.org>

Hello,

I am now trying to get an SSL connection working with my OpenLDAP 2.0.11
slapd server, and have run into problems again :(

I run my slapd with "-h ldaps:///" so that it runs ONLY over SSL, this
means it listens on port 636.

Here's my bit of code:

server = ldap.open('myhost',636)
server.version = ldap.VERSION3
server.start_tls_s()
server.simple_bind_s("hidden","hidden")

And here's the result:

Traceback (most recent call last):
  File "urds.py", line 5, in ?
    server.start_tls_s()
ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"}

Here's what my slapd, with maximum logging (1), has to say about that:

Oct 23 10:38:57 grumbler slapd[5627]: connection_get(9): got connid=4 
Oct 23 10:38:57 grumbler slapd[5627]: connection_read(9): checking for
input on id=4 
Oct 23 10:38:57 grumbler slapd[5627]: connection_read(9): TLS accept error
error=-1 id=4, closing 
Oct 23 10:38:57 grumbler slapd[5627]: connection_closing: readying conn=4
sd=9 for close 
Oct 23 10:38:57 grumbler slapd[5627]: connection_close: conn=4 sd=9 

Unfortunately, not very helpfull!

Any ideas? I successfully connect to this server using Perl and various
tools.  I compiled my pyton-ldap from CVS and patched with all the patches
in the original "starttls" message from the list.

One thing: It would me nice ot have a central place where to get patches
and so on, took me a while to figure out where to get them, and even now,
I'm not allways sure which patch does what!

Thanks again!
J.F.


On Mon, 22 Oct 2001, Jean-Fran?ois Doyon wrote:

> Hello,
> 
> OK, never mind, I eventually figured it out :) Turns out the patches are
> hidden inside the RPM's !
> 
> I had to do some manual work since I wanted it to work with Python 2.1, but
> now I'm not getting any errors ...
> 
> I'm looking forward to trying it out :)
> 
> Thanks for the contribution!
> 
> Jean-Fran?ois Doyon
> Carbon IT
> http://methane.org
> Tel.: (819) 827-9997
> Fax : (819) 827-6653
> 
> -----Original Message-----
> From: python-ldap-dev-admin at lists.sourceforge.net
> [mailto:python-ldap-dev-admin at lists.sourceforge.net]On Behalf Of
> jfdoyon at server.methane.org
> Sent: October 22, 2001 5:01 PM
> To: Michael Str?der
> Cc: python-ldap-dev at lists.sourceforge.net
> Subject: Re: Undefined Symbol?
> 
> Michael,
> 
> I did see it, unfortunately, I'm not sure WHERE to find these patches,
> they don't seem to be in the CVS tree! Also, the README in the CVS says it
> was tested again OpenLDAP 2.0 and Python 2.0 ... Which is pretty damn
> close to what I'm using (Python 2.1.1 with OpenLDAP 2.0.17, although the
> files say 2.0.11 for some reason).
> 
> Maybe I'll try the RPM's :) I just like hacking things myself!
> 
> Thanks!
> J.F.
> 
> 
> 
> On Mon, 22 Oct 2001, Michael [iso-8859-1] Str?der wrote:
> 
> > jfdoyon at server.methane.org wrote:
> > >
> > >
> > > I just installed OpenLDAP 2.0.17 and the CVS version of python-ldap,
> >
> > See item 3 on http://python-ldap.sourceforge.net/faq.shtml
> >
> > Note that applying patches to python-ldap is experimental.
> >
> > Ciao, Michael.
> >
> > 

From jajcus at bnet.pl  Thu Nov  8 14:32:00 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Thu, 8 Nov 2001 14:32:00 +0100
Subject: Some questions (status,SSL,Unicode)
Message-ID: <20011108143200.A4318@serwus.bnet.pl>

Hi,

I am new to the list. I have some questions about python-ldap. I have
not found answers for them in the archives, so I am asking here...

1. Is the project alive? The mailing list and CVS logs make me think it
is dead :-(

2. What about SSL/TLS/STARTTLS support? I realy need encrypted
connection to LDAP server.

3. What about Unicode? All strings with non-ascii characters are
encoded as Unicode in a directory and returned as UTF-8 from LDAP
search. It seems reasonable to store them as Unicode objects in python,
but It would require python-ldap to know some details about schema.
I think python-ldap should be just simple interface to LDAP, and the
application should be responsible for interpreting the results.

I am currently working on LDAP browser with curses interface. I need
such thing for managing users and such on my servers.
To make the browser (I want to use python for that) I need
python bindings to LDAP. So I use python-ldap (ver. 1.10alpha3-1).

If it is necessery I can help with developing python-ldap, as it is very
important to me. I am using Linux with openldap-2.0.18, so I could test
it only on this platform.

BTW. My browser is working now, but only supports anonymous browsing of
LDAP directory and has no editing capabilities.

Greets,
	Jacek



From jajcus at bnet.pl  Sat Nov 10 20:07:24 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Sat, 10 Nov 2001 20:07:24 +0100
Subject: Updates for OpenLDAP >= 2.0.12
Message-ID: <20011110200724.A16536@nic.bnet.pl>

Hi,

current python-ldap won't work with OpenLDAP >= 2.0.21. 

Here is part of CHANGES file from OpenLDAP sources:

OpenLDAP 2.0.12 Release
        ...
        Removed -lldap UFN search support
        ...

python-ldap uses those UFN search functions which are not included in
openldap libraries any more, so it crashes with "unresolved sybol" when
used.

Below is a patch, which removes (in fact makes conditional) support for
UFN search in python-ldap. 
It seems that autoconf support is broken, and I don't know how to check
things like existence of some function with setup.py, so the only way
to activate UFN search again is to '#define UFN_SEARCH'.

I would like to have it commited as soon as possible, so I can work on
TLS support without mixing things :-)

Greets,
        Jacek

Index: setup.cfg
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/setup.cfg,v
retrieving revision 1.2
diff -u -r1.2 setup.cfg
--- setup.cfg	2001/05/16 02:26:00	1.2
+++ setup.cfg	2001/11/10 18:56:43
@@ -1,6 +1,6 @@
 [_ldap]
 class = OpenLDAP2
-library_dirs = /usr/local/lib
-include_dirs = /usr/local/include
+library_dirs = /usr/lib
+include_dirs = /usr/include
 ; libs = lber ldap
 
Index: Modules/LDAPObject.c
===================================================================

RCS file: /cvsroot/python-ldap/python-ldap/Modules/LDAPObject.c,v
retrieving revision 1.11
diff -u -r1.11 LDAPObject.c
--- Modules/LDAPObject.c	2001/06/06 23:40:04	1.11
+++ Modules/LDAPObject.c	2001/11/10 18:56:57
@@ -1451,6 +1451,7 @@
 
 /* ldap_search_s == ldap_search_st */
 
+#ifdef UFN_SEARCH
 /* ldap_ufn_search_c */
 
 /* ldap_ufn_search_ct */
@@ -1534,6 +1535,7 @@
 "\tSee the LDAP library manual pages for more information on these\n"
 "\t`user-friendly name' functions.";
 
+#endif /* UFN_SEARCH */
 /* ldap_sort_entries */
 
 /* ldap_url_search */
@@ -1688,9 +1690,11 @@
     {"search",		(PyCFunction)l_ldap_search,		METH_VARARGS,	doc_search},	
     {"search_s",	(PyCFunction)l_ldap_search_st,		METH_VARARGS,	doc_search},	
     {"search_st",	(PyCFunction)l_ldap_search_st,		METH_VARARGS,	doc_search},	
+#ifdef UFN_SEARCH
     {"ufn_search_s",	(PyCFunction)l_ldap_ufn_search_s,	METH_VARARGS,	doc_ufn},
     {"ufn_setfilter",	(PyCFunction)l_ldap_ufn_setfilter,	METH_VARARGS,	doc_ufn},
     {"ufn_setprefix",	(PyCFunction)l_ldap_ufn_setprefix,	METH_VARARGS,	doc_ufn},
+#endif /* UFN_SEARCH */
     {"url_search_s",	(PyCFunction)l_ldap_url_search_st,	METH_VARARGS,	doc_url_search},	
     {"url_search_st",	(PyCFunction)l_ldap_url_search_st,	METH_VARARGS,	doc_url_search},	
 #if defined(FILENO_SUPPORTED)




From michael at stroeder.com  Thu Nov  8 15:15:57 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 08 Nov 2001 15:15:57 +0100
Subject: Some questions (status,SSL,Unicode)
References: <20011108143200.A4318@serwus.bnet.pl>
Message-ID: <3BEA939D.F45ECD9D@stroeder.com>

Jacek Konieczny wrote:
> 
> 1. Is the project alive?

See item 1 on http://python-ldap.sourceforge.net/faq.shtml ;-).

> 2. What about SSL/TLS/STARTTLS support? I realy need encrypted
> connection to LDAP server.

Patches for using StartTLS were provided but not landed in CVS yet.
Also the implementation was somewhat incomplete since it lacks
support for setting up a local SSL context (trusted root CA certs,
CRL handling etc.).

> 3. What about Unicode? All strings with non-ascii characters are
> encoded as Unicode in a directory and returned as UTF-8 from LDAP
> search. It seems reasonable to store them as Unicode objects in python,
> but It would require python-ldap to know some details about schema.
> I think python-ldap should be just simple interface to LDAP, and the
> application should be responsible for interpreting the results.

Yes. The low-level C wrapper module in python-ldap should not handle
Unicode objects. It should pass strings not knowing if these are
text strings or binary blobs.

> If it is necessery I can help with developing python-ldap, as it is very
> important to me.

You're welcome to help.

> I am using Linux with openldap-2.0.18, so I could test
> it only on this platform.

There are various public LDAP servers.

> BTW. My browser is working now, but only supports anonymous browsing of
> LDAP directory and has no editing capabilities.

You might wanna check out
http://python-ldap.sourceforge.net/apps.shtml to learn more about
what login and editing capabilities mean by looking at existing
code.

Ciao, Michael.



From michael at stroeder.com  Sun Nov 11 01:53:17 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Nov 2001 01:53:17 +0100
Subject: Commited patches for OpenLDAP 2.0 libs
Message-ID: <3BEDCBFD.333769BF@stroeder.com>

HI!

I've commited the patches provided by Konstantin and Steffen for
building against OpenLDAP 2.0.x libs.

Grab it. Test it!

Ciao, Michael.



From michael at stroeder.com  Sun Nov 11 01:37:32 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Nov 2001 01:37:32 +0100
Subject: Some questions (status,SSL,Unicode)
References: <20011110200903.B16536@nic.bnet.pl>
Message-ID: <3BEDC84C.FDE76FB0@stroeder.com>

Jacek Konieczny wrote:
> 
> On Thu, Nov 08, 2001 at 03:15:57PM +0100, Michael Str?der wrote:
> > See item 1 on http://python-ldap.sourceforge.net/faq.shtml ;-).
> >
> > > 2. What about SSL/TLS/STARTTLS support? I realy need encrypted
> > > connection to LDAP server.
> >
> > Patches for using StartTLS were provided but not landed in CVS yet.
> > Also the implementation was somewhat incomplete since it lacks
> > support for setting up a local SSL context (trusted root CA certs,
> > CRL handling etc.).
> Could you send me those patches, please?
> So I won't duplicate work when I start doing this.

See attachment.

Ciao, Michael.
-------------- next part --------------
Index: setup.py
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/setup.py,v
retrieving revision 1.5
diff -u -w -r1.5 setup.py
--- setup.py	2001/05/24 21:07:42	1.5
+++ setup.py	2001/07/15 16:11:10
@@ -13,7 +13,7 @@
 	library_dirs =	[ ]
 	include_dirs =	[ ]
 	libs =		['ldap', 'lber']
-	defines =	[('USE_CIDICT', None),
+	defines =	[#('USE_CIDICT', None),
 			 #('WITH_KERBEROS', None),
 			 #('HAVE_DES_SETKEY', None),
 			 ('LDAP_TYPE_IS_OPAQUE', None),
@@ -25,6 +25,7 @@
 			 ('HAVE_LDAP_MODRDN2', None),
 			 ('HAVE_LDAP_MODRDN2_S', None),
 			 ('HAVE_LDAP_SET_CACHE_OPTIONS', None),
+			 ('HAVE_LDAP_START_TLS_S', None),
 			 ('HAVE_LDAP_UNCACHE_ENTRY', None),
 			 ('HAVE_LDAP_UNCACHE_REQUEST', None),
 			 ('HAVE_DISPTMPL_H', None),
Index: Modules/LDAPObject.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/LDAPObject.c,v
retrieving revision 1.11
diff -u -w -r1.11 LDAPObject.c
--- Modules/LDAPObject.c	2001/06/06 23:40:04	1.11
+++ Modules/LDAPObject.c	2001/07/15 16:11:12
@@ -515,7 +515,7 @@
     return Py_None;
 }
 
-#ifdef LDAP_REFERRALS
+#if defined(LDAP_REFERRALS) || LDAP_API_VERSION >= 2000
 
 /* ldap_set_rebind_proc */
 
@@ -1211,9 +1211,9 @@
     double timeout = -1.0;
     struct timeval tv;
     struct timeval* tvp;
-    int res_type, result;
+    int res_type;
     LDAPMessage *msg = NULL;
-    PyObject *result_str, *retval;
+    PyObject *result_str, *retval, *pmsg;
 
     if (!PyArg_ParseTuple( args, "|iid", &msgid, &all, &timeout ))
     	return NULL;
@@ -1239,29 +1239,50 @@
     	return Py_None;
     }
 
-    /* thanks to Konstantin Chuguev for this */
-    if (res_type != LDAP_RES_SEARCH_ENTRY) {
+    if (res_type == LDAP_RES_SEARCH_ENTRY
+#if LDAP_API_VERSION >= 2000
+	    || res_type == LDAP_RES_SEARCH_REFERENCE
+#endif
+	)
+	pmsg = LDAPmessage_to_python( self->ldap, msg );
+    else {
+	int result;
+#if LDAP_API_VERSION >= 2000
+	char **refs = NULL;
+	LDAP_BEGIN_ALLOW_THREADS( self );
+	ldap_parse_result( self->ldap, msg, &result, NULL, NULL, &refs, NULL, 0 );
+#else
 	LDAP_BEGIN_ALLOW_THREADS( self );
 	result = ldap_result2error( self->ldap, msg, 0 );
+#endif
 	LDAP_END_ALLOW_THREADS( self );
 
 	if (result != LDAP_SUCCESS) {		/* result error */
+#if LDAP_API_VERSION >= 2000
+	    char *e, err[1024];
+	    if (result == LDAP_REFERRAL && refs && refs[0]) {
+		snprintf(err, sizeof(err), "Referral:\n%s", refs[0]);
+		e = err;
+	    } else
+		e = "ldap_parse_result";
+	    return LDAPerror( self->ldap, e );
+#else
 	    return LDAPerror( self->ldap, "ldap_result2error" );
+#endif
 	}
+	pmsg = Py_None;
     }
 
     result_str = LDAPconstant( res_type );
 
-    if (msg == NULL) {
-    	retval = Py_BuildValue("(OO)", result_str, Py_None);
-    } else {
-	PyObject *pmsg = LDAPmessage_to_python( self->ldap, msg );
-	if (pmsg == NULL) 
+    if (pmsg == NULL) {
 	    retval = NULL;
-	else
+    } else {
 	    retval = Py_BuildValue("(OO)", result_str, pmsg);
+	if (pmsg != Py_None) {
         Py_DECREF(pmsg);
     }
+    }
     Py_DECREF(result_str);
     return retval;
 }
@@ -1451,6 +1472,9 @@
 
 /* ldap_search_s == ldap_search_st */
 
+#if LDAP_API_VERSION < 2000
+/* OpenLDAPv1 */
+
 /* ldap_ufn_search_c */
 
 /* ldap_ufn_search_ct */
@@ -1534,8 +1558,39 @@
 "\tSee the LDAP library manual pages for more information on these\n"
 "\t`user-friendly name' functions.";
 
+#endif /* LDAP_API_VERSION < 2000 */
+
 /* ldap_sort_entries */
 
+#ifdef HAVE_LDAP_START_TLS_S
+/* ldap_start_tls_s */
+
+static PyObject*
+l_ldap_start_tls_s( LDAPObject* self, PyObject* args )
+{
+    int result;
+
+    if (!PyArg_ParseTuple( args, "" )) return NULL;
+    if (not_valid(self)) return NULL;
+
+    result = ldap_start_tls_s( self->ldap, NULL, NULL );
+    if ( result != LDAP_SUCCESS ){
+	ldap_set_option(self->ldap, LDAP_OPT_ERROR_NUMBER, &result);
+	return LDAPerror( self->ldap, "ldap_start_tls_s" );
+    }
+
+    Py_INCREF(Py_None);
+    return Py_None;
+}
+
+static char doc_start_tls[] =
+"start_tls_s() -> None\n\n"
+"\tNegotiate TLS with server. The `version' attribute must have been\n"
+"\tset to VERSION3 before calling start_tls_s.\n"
+"\tIf TLS could not be started an exception will be raised.\n"
+;
+#endif
+
 /* ldap_url_search */
 
 /* ldap_url_search_s */
@@ -1631,7 +1686,7 @@
     {"add_s",		(PyCFunction)l_ldap_add_s,		METH_VARARGS,	doc_add},	
     {"bind",		(PyCFunction)l_ldap_bind,		METH_VARARGS,	doc_bind},	
     {"bind_s",		(PyCFunction)l_ldap_bind_s,		METH_VARARGS,	doc_bind},	
-#ifdef LDAP_REFERRALS
+#if defined(LDAP_REFERRALS) || LDAP_API_VERSION >= 2000
     {"set_rebind_proc",	(PyCFunction)l_ldap_set_rebind_proc,	METH_VARARGS,	doc_set_rebind_proc},	
 #endif /* LDAP_REFERRALS */
     {"simple_bind",	(PyCFunction)l_ldap_simple_bind,	METH_VARARGS,	doc_bind},	
@@ -1688,9 +1743,14 @@
     {"search",		(PyCFunction)l_ldap_search,		METH_VARARGS,	doc_search},	
     {"search_s",	(PyCFunction)l_ldap_search_st,		METH_VARARGS,	doc_search},	
     {"search_st",	(PyCFunction)l_ldap_search_st,		METH_VARARGS,	doc_search},	
+#ifdef HAVE_LDAP_START_TLS_S
+    {"start_tls_s",	(PyCFunction)l_ldap_start_tls_s,	METH_VARARGS,	doc_start_tls},
+#endif
+#if LDAP_API_VERSION < 2000
     {"ufn_search_s",	(PyCFunction)l_ldap_ufn_search_s,	METH_VARARGS,	doc_ufn},
     {"ufn_setfilter",	(PyCFunction)l_ldap_ufn_setfilter,	METH_VARARGS,	doc_ufn},
     {"ufn_setprefix",	(PyCFunction)l_ldap_ufn_setprefix,	METH_VARARGS,	doc_ufn},
+#endif
     {"url_search_s",	(PyCFunction)l_ldap_url_search_st,	METH_VARARGS,	doc_url_search},	
     {"url_search_st",	(PyCFunction)l_ldap_url_search_st,	METH_VARARGS,	doc_url_search},	
 #if defined(FILENO_SUPPORTED)
@@ -1766,6 +1826,47 @@
 getattr( LDAPObject* self, char* name ) 
 {
 
+#if LDAP_API_VERSION >= 2000
+/* OpenLDAPv2 */
+	int res, option, intval, is_string = 0;
+	char *strval;
+
+	if (streq(name,"version"))
+		option = LDAP_OPT_PROTOCOL_VERSION;
+	else if (streq(name,"deref")) 
+		option = LDAP_OPT_DEREF;
+	else if (streq(name,"referrals"))
+		option = LDAP_OPT_REFERRALS;
+	else if (streq(name,"restart"))
+		option = LDAP_OPT_REFERRALS;
+	else if (streq(name,"timelimit")) 
+		option = LDAP_OPT_TIMELIMIT;
+	else if (streq(name,"sizelimit")) 
+		option = LDAP_OPT_SIZELIMIT;
+	else if (streq(name,"errno")) 
+		option = LDAP_OPT_ERROR_NUMBER;
+	else if (streq(name,"error")) {
+		option = LDAP_OPT_ERROR_STRING;
+		is_string = 1;
+	} else if (streq(name,"matched")) {
+		option = LDAP_OPT_MATCHED_DN;
+		is_string = 1;
+	} else
+		return Py_FindMethod( methods, (PyObject*)self, name );
+	LDAP_BEGIN_ALLOW_THREADS( self );
+	res = ldap_get_option(self->ldap, option, is_string ? (void *)&strval
+	                                                    : (void *)&intval);
+	LDAP_END_ALLOW_THREADS( self );
+	if (res < 0)
+		return LDAPerror( self->ldap, "ldap_get_option" );
+	if (!is_string)
+		return PyInt_FromLong(intval);
+	if (strval != NULL)
+		return PyString_FromString(strval);
+	Py_INCREF(Py_None);
+	return Py_None;
+#else
+/* OpenLDAPv1 */
 #ifndef LDAP_TYPE_IS_OPAQUE
 	if (streq(name,"lberoptions")) 
 		return PyInt_FromLong(self->ldap->ld_lberoptions);
@@ -1798,6 +1899,7 @@
 		return PyInt_FromLong(self->valid);
 
 	return Py_FindMethod( methods, (PyObject*)self, name );
+#endif /* LDAP_API_VERSION >= 2000 */
 }
 
 /* set attribute */
@@ -1805,7 +1907,12 @@
 static int
 setattr( LDAPObject* self, char* name, PyObject* value ) 
 {
+#if LDAP_API_VERSION >= 2000
+	int res, intval, option;
+	int *intptr = &intval;
+#else
 	long intval;
+#endif
 
 	if (streq(name,"errno") ||
 	    streq(name,"error") ||
@@ -1821,6 +1928,34 @@
 	    return -1;
 	}
 
+#if defined(LDAP_API_VERSION)
+/* OpenLDAPv2 */
+	if (streq(name,"deref")) 
+		option = LDAP_OPT_DEREF;
+	else if(streq(name,"version"))
+		option = LDAP_OPT_PROTOCOL_VERSION;
+	else if(streq(name,"referrals")) {
+		option = LDAP_OPT_REFERRALS;
+		intptr = (void *)intval;
+	} else if(streq(name,"restart")) {
+		option = LDAP_OPT_RESTART;
+		intptr = (void *)intval;
+	} else if (streq(name,"timelimit")) 
+		option = LDAP_OPT_TIMELIMIT;
+	else if (streq(name,"sizelimit")) 
+		option = LDAP_OPT_SIZELIMIT;
+	else {
+		PyErr_SetString( PyExc_NameError, "cannot set that field" );
+		return -1;
+	}
+	LDAP_BEGIN_ALLOW_THREADS( self );
+	res = ldap_set_option(self->ldap, option, intptr);
+	LDAP_END_ALLOW_THREADS( self );
+	if (res < 0)
+		return LDAPerror( self->ldap, "ldap_get_option" ), -1;
+	return 0;
+#else
+/* OpenLDAPv1 */
 #       define set(a,max)                                          \
 	if (streq(name,#a)) {                                       \
 	    if (intval < 0 || intval > max )                        \
@@ -1844,6 +1979,7 @@
 	/* it fell through to here */
 	PyErr_SetString( PyExc_NameError, "cannot set that field" );
 	return -1;
+#endif /* LDAP_API_VERSION >= 2000 */
 }
 
 /* type entry */
Index: Modules/constants.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/constants.c,v
retrieving revision 1.6
diff -u -w -r1.6 constants.c
--- Modules/constants.c	2001/05/12 08:05:09	1.6
+++ Modules/constants.c	2001/07/15 16:11:12
@@ -79,6 +79,27 @@
 	add_int(d,REQ_COMPARE);
 	add_int(d,REQ_ABANDON);
 
+#if LDAP_API_VERSION >= 2000
+	/* OpenLDAPv2 */
+	add_int(d,VERSION3);
+	add_int(d,VERSION_MIN);
+	add_int(d,VERSION_MAX);
+	add_int(d,TAG_LDAPDN);
+	add_int(d,TAG_LDAPCRED);
+	add_int(d,TAG_CONTROLS);
+	add_int(d,TAG_REFERRAL);
+
+	add_int(d,REQ_EXTENDED);
+#endif
+#if LDAP_API_VERSION >= 2004
+	add_int(d,TAG_NEWSUPERIOR);
+	add_int(d,TAG_EXOP_REQ_OID);
+	add_int(d,TAG_EXOP_REQ_VALUE);
+	add_int(d,TAG_EXOP_RES_OID);
+	add_int(d,TAG_EXOP_RES_VALUE);
+	add_int(d,TAG_SASL_RES_CREDS);
+#endif
+
 	/* reversibles */
 
 	zero = PyInt_FromLong( 0 );
@@ -95,6 +116,14 @@
 	add_int_r(d,RES_COMPARE);
 	add_int(d,RES_ANY);
 
+#if LDAP_API_VERSION >= 2000
+	/* OpenLDAPv2 */
+	add_int_r(d,RES_SEARCH_REFERENCE);
+	add_int_r(d,RES_EXTENDED);
+	add_int_r(d,RES_EXTENDED_PARTIAL);
+	add_int_r(d,RES_UNSOLICITED);
+#endif
+
 	/* non-reversibles */
 
 	add_int(d,AUTH_NONE);
@@ -121,6 +150,21 @@
 	add_int(d,MOD_DELETE);
 	add_int(d,MOD_REPLACE);
 	add_int(d,MOD_BVALUES);
+
+#if LDAP_API_VERSION >= 2000
+	/* OpenLDAPv2 */
+	add_int(d,FILTER_EXT);
+	add_int(d,FILTER_EXT_OID);
+	add_int(d,FILTER_EXT_TYPE);
+	add_int(d,FILTER_EXT_VALUE);
+	add_int(d,FILTER_EXT_DNATTRS);
+
+	add_int(d,SCOPE_DEFAULT);
+
+	add_int(d,MSG_ONE);
+	add_int(d,MSG_ALL);
+	add_int(d,MSG_RECEIVED);
+#endif
 
 	/* (errors.c contains the error constants) */
 
Index: Modules/errors.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/errors.c,v
retrieving revision 1.3
diff -u -w -r1.3 errors.c
--- Modules/errors.c	2000/08/14 22:37:37	1.3
+++ Modules/errors.c	2001/07/15 16:11:12
@@ -17,7 +17,12 @@
 
 /* list of error objects */
 
+#if LDAP_API_VERSION >= 2000
+	/* OpenLDAPv2 */
+#define NUM_LDAP_ERRORS		LDAP_REFERRAL_LIMIT_EXCEEDED+1
+#else
 #define NUM_LDAP_ERRORS		LDAP_NO_MEMORY+1
+#endif
 static PyObject* 
 errobjects[ NUM_LDAP_ERRORS ];
 
@@ -30,21 +35,26 @@
 		PyErr_SetFromErrno( LDAPexception_class );
 		return NULL;
 	}
-#ifdef LDAP_TYPE_IS_OPAQUE
+#if defined(LDAP_TYPE_IS_OPAQUE) && LDAP_API_VERSION < 2000
 	else {
 		PyErr_SetString(LDAPexception_class,
 			"unknown error (C API does not expose error)");
 		return NULL;
 	}
-#else
+#else /* defined(LDAP_TYPE_IS_OPAQUE) && LDAP_API_VERSION < 2000 */
 	else {
 		int errnum;
 		PyObject *errobj;
 		PyObject *info;
 		PyObject *str;
 
+#if LDAP_API_VERSION >= 2000
+		char *matched, *error;
+		if (ldap_get_option(l, LDAP_OPT_ERROR_NUMBER, &errnum) < 0)
+#else
 		errnum = l->ld_errno;
 		if (errnum<0 || errnum>=NUM_LDAP_ERRORS)
+#endif
 			errobj = LDAPexception_class;	/* unknown error XXX */
 		else
 			errobj = errobjects[errnum];
@@ -61,6 +71,34 @@
 			PyDict_SetItemString( info, "desc", str );
 		Py_XDECREF(str);
 
+#if LDAP_API_VERSION >= 2000
+		if (ldap_get_option(l, LDAP_OPT_MATCHED_DN, &matched) >= 0
+			&& matched != NULL) {
+		    if (*matched != '\0') {
+			str = PyString_FromString(matched);
+			if (str)
+			    PyDict_SetItemString( info, "matched", str );
+			Py_XDECREF(str);
+		    }
+		    ldap_memfree(matched);
+		}
+		
+		if (errnum == LDAP_REFERRAL) {
+		    str = PyString_FromString(msg);
+		    if (str)
+			PyDict_SetItemString( info, "info", str );
+		    Py_XDECREF(str);
+		} else if (ldap_get_option(l, LDAP_OPT_ERROR_STRING, &error) >= 0
+			&& error != NULL) {
+		    if (error != '\0') {
+			str = PyString_FromString(error);
+			if (str)
+			    PyDict_SetItemString( info, "info", str );
+			Py_XDECREF(str);
+		    }
+		    ldap_memfree(error);
+		}
+#else /* LDAP_API_VERSION >= 2000 */
 		if (l->ld_matched != NULL && *l->ld_matched != '\0') 
 		{
 		   str = PyString_FromString(l->ld_matched);
@@ -76,11 +114,12 @@
 			   PyDict_SetItemString( info, "info", str );
 		   Py_XDECREF(str);
 		}
+#endif /* LDAP_API_VERSION >= 2000 */
 		PyErr_SetObject( errobj, info );
 		Py_DECREF(info);
 		return NULL;
 	}
-#endif
+#endif /* defined(LDAP_TYPE_IS_OPAQUE) && LDAP_API_VERSION < 2000 */
 }
 
 
@@ -163,4 +202,20 @@
 	seterrobj(USER_CANCELLED);
 	seterrobj(PARAM_ERROR);
 	seterrobj(NO_MEMORY);
+#if LDAP_API_VERSION >= 2000
+	/* OpenLDAPv2 */
+	seterrobj(REFERRAL);
+	seterrobj(ADMINLIMIT_EXCEEDED);
+	seterrobj(UNAVAILABLE_CRITICAL_EXTENSION);
+	seterrobj(CONFIDENTIALITY_REQUIRED);
+	seterrobj(SASL_BIND_IN_PROGRESS);
+	seterrobj(AFFECTS_MULTIPLE_DSAS);
+	seterrobj(CONNECT_ERROR);
+	seterrobj(NOT_SUPPORTED);
+	seterrobj(CONTROL_NOT_FOUND);
+	seterrobj(NO_RESULTS_RETURNED);
+	seterrobj(MORE_RESULTS_TO_RETURN);
+	seterrobj(CLIENT_LOOP);
+	seterrobj(REFERRAL_LIMIT_EXCEEDED);
+#endif
 }
Index: Modules/message.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/message.c,v
retrieving revision 1.7
diff -u -w -r1.7 message.c
--- Modules/message.c	2001/07/13 10:21:59	1.7
+++ Modules/message.c	2001/07/15 16:11:12
@@ -1,7 +1,7 @@
 /* David Leonard <david.leonard at csee.uq.edu.au>, 1999. Public domain. */
 /*
  * LDAPMessageObject - wrapper around an LDAPMessage*
- * $Id: message.c,v 1.7 2001/07/13 10:21:59 kchuguev Exp $
+ * $Id: message.c,v 1.6 2000/08/18 00:21:46 leonard Exp $
  */
 
 #include "common.h"
@@ -51,7 +51,11 @@
 	 if (attrdict == NULL) {
 		Py_DECREF(result);
 		ldap_msgfree( m );
+#if LDAP_API_VERSION >= 2000
+		ldap_memfree(dn);
+#else
 		free(dn);
+#endif
 		return NULL;
 	 }
 
@@ -82,7 +86,12 @@
 		if (ber != NULL)
 		    ber_free(ber, 0);
 		ldap_msgfree( m );
+#if LDAP_API_VERSION >= 2000
+		ldap_memfree(attr);
+		ldap_memfree(dn);
+#else
 		free(dn);
+#endif
 		return NULL;
 	     }
 
@@ -102,7 +111,12 @@
 			if (ber != NULL)
 			    ber_free(ber, 0);
 			ldap_msgfree( m );
+#if LDAP_API_VERSION >= 2000
+			ldap_memfree(attr);
+			ldap_memfree(dn);
+#else
 			free(dn);
+#endif
 			return NULL;
 		    }
 		    Py_DECREF(valuestr);
@@ -110,14 +124,59 @@
 		ldap_value_free_len(bvals);
 	     }
 	     Py_DECREF( valuelist );
+#if LDAP_API_VERSION >= 2000
+	     ldap_memfree(attr);
+#endif
 	 }
 
 	 entrytuple = Py_BuildValue("(sO)", dn, attrdict);
+#if LDAP_API_VERSION >= 2000
+	 ldap_memfree(dn);
+#else
          free(dn);
+#endif
 	 Py_DECREF(attrdict);
 	 PyList_Append(result, entrytuple);
 	 Py_DECREF(entrytuple);
+#if ( LDAP_API_VERSION > 2000 )
+	 if (ber != NULL)
+		 ber_free(ber, 0);
+#endif
+     }
+#if LDAP_API_VERSION >= 2000
+     for(entry = ldap_first_reference(ld,m);
+	 entry != NULL;
+	 entry = ldap_next_reference(ld,entry))
+     {
+	 char **refs = NULL;
+	 PyObject* entrytuple;
+	 PyObject* reflist = PyList_New(0);
+
+	 if (reflist == NULL)  {
+	     Py_DECREF(result);
+	     ldap_msgfree( m );
+	     return NULL;
+	 }
+	 if (ldap_parse_reference(ld, entry, &refs, NULL, 0) != LDAP_SUCCESS) {
+	     Py_DECREF(result);
+	     ldap_msgfree( m );
+	     return LDAPerror( ld, "ldap_parse_reference" );
+	 }
+	 if (refs) {
+	     int i;
+	     for (i=0; refs[i] != NULL; i++) {
+		 PyObject *refstr = PyString_FromString(refs[i]);
+		 PyList_Append(reflist, refstr);
+		 Py_DECREF(refstr);
+	     }
+	     ber_memvfree( (void **) refs );
+	 }
+	 entrytuple = Py_BuildValue("(sO)", NULL, reflist);
+	 Py_DECREF(reflist);
+	 PyList_Append(result, entrytuple);
+	 Py_DECREF(entrytuple);
      }
+#endif
      ldap_msgfree( m );
      return result;
 }

From michael at stroeder.com  Sun Nov 11 01:39:07 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Nov 2001 01:39:07 +0100
Subject: Updates for OpenLDAP >= 2.0.12
References: <20011110200724.A16536@nic.bnet.pl>
Message-ID: <3BEDC8AB.7771FB7C@stroeder.com>

Jacek Konieczny wrote:
> 
> I would like to have it commited as soon as possible, so I can work on
> TLS support without mixing things :-)

I'd appreciate if you could implement the missing parameters of
start_tls_s() which passes a SSL context (trusted root certs, CRL
checking, etc.).

Ciao, Michael.



From michael at stroeder.com  Sun Nov 11 15:07:34 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Nov 2001 15:07:34 +0100
Subject: TODO list python-ldap
Message-ID: <3BEE8626.C6F21AEF@stroeder.com>

HI!

Please have a look at the current TODO file of python-ldap:
------------------- snip -------------------
General:
- Define common license for all modules

Modules/
- Completion of start_tls_s() with SSL context
- Support for LDAP over SSL
- Look into OpenLDAP 2's lib ldap_r to make python-ldap re-entrant
- Support for SASL bind
- Support for VLV control
- Support for server-side sorting control
- Wrap ldap_explode_rdn
- Support for binding with in DSA control mode

Lib/
- Remove obsolete/unsupported modules
- LDAPv3 schema support (BNF parser needed)
- Add ldapurl module from web2ldap
- LDIF parser for replication logs
- DSML support

------------------- snip -------------------

If you have some spare cycles and want to contribute please jump on
in.

I'm also planning to contribute some of my modules implemented for
web2ldap (see pylib/ldaputil/ of recent web2ldap snapshot) to
python-ldap with a more liberal license. Please check these modules
and comment.

We should agree on a commonly used license. At the moment the
license is undefined and some modules have different license. I
relaxed the license of my ldif module which was strict GPL.

Ciao, Michael.



From michael at stroeder.com  Sun Nov 11 15:20:06 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Nov 2001 15:20:06 +0100
Subject: TLS context
References: <20011111114445.A3004@nic.bnet.pl>
Message-ID: <3BEE8916.1E442B81@stroeder.com>

Jacek Konieczny wrote:
> 
> On Sun, Nov 11, 2001 at 08:26:57PM +1000, David Leonard wrote:
> > Can you give an example of what a python program might look like
> > using these?
> 
> The only thing I implemented and tested now is the ldap.initialize().

This whole stuff including your Python examples looks reasonable to
me.

> You can use ldap.init() instead of ldap.initialize(). ldap.open()
> should not be used as it is depreciated, and it won't work for LDAP over
> SSL (as connection would be open before tls options are set).

Keep the name ldap.initialize(). That makes it easy to find it in
ldap.h. BTW: Support for ldapi:// (local domain socket) should be
possible with this either.

I'd also appreciate if you could manage to use ldap_r and wrap it in
such a way that python-ldap is re-entrant. Do you think that's
feasible? My module ldapthreadlock is just a weird work-around with
some serious deficiencies.

> I have not yet checked if TLS options all global or connection-specific.

I would assume that TLS/SSL options are connection-specific since
you might have different trusted root CA certs, etc.

Does the OpenLDAP API expose a call-back interface to implement CRL
checking and such?

Ciao, Michael.



From jajcus at bnet.pl  Sun Nov 11 10:18:45 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Sun, 11 Nov 2001 10:18:45 +0100
Subject: TLS context
Message-ID: <20011111101845.A4424@nic.bnet.pl>

Hi,

I was looking at the code to see how should make the support for TLS
context.
IMHO using the areguments for ldap_start_tls_s would be quite
complicated, and would probably require some low-level SSL coding.
But it seems it can be done using OpenLDAP options such as:
LDAP_OPT_X_TLS_CTX
LDAP_OPT_X_TLS_CACERTFILE
LDAP_OPT_X_TLS_CACERTDIR
LDAP_OPT_X_TLS_CERTFILE
LDAP_OPT_X_TLS_KEYFILE
LDAP_OPT_X_TLS_REQUIRE_CERT
LDAP_OPT_X_TLS_CIPHER_SUITE
LDAP_OPT_X_TLS_RANDOM_FILE
LDAP_OPT_X_TLS_NEVER
LDAP_OPT_X_TLS_HARD
LDAP_OPT_X_TLS_DEMAND
LDAP_OPT_X_TLS_ALLOW
LDAP_OPT_X_TLS_TRY

This can be done by extending getattr/setattr functions.
Of course many not TLS-related options can (and IMHO should) be added.

One more thing, which IMHO should be added is ldap_initialize()
function, which can be used to connect to LDAP server using its URI.
It would also handle ldaps:// URIs.

Should I do all/part of these?

Greets,
        Jacek



From jajcus at bnet.pl  Sun Nov 11 11:44:46 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Sun, 11 Nov 2001 11:44:46 +0100
Subject: TLS context
In-Reply-To: <Pine.BSO.4.33.0111112026340.19312-100000@cathexis.bovingdon-st.fnarg.net.au>
Message-ID: <20011111114445.A3004@nic.bnet.pl>

On Sun, Nov 11, 2001 at 08:26:57PM +1000, David Leonard wrote:
> Can you give an example of what a python program might look like
> using these?

The only thing I implemented and tested now is the ldap.initialize().
This works like that (this will start LDAP over SSL connection):

import ldap
l=ldap.initialize("ldaps://some.ldap.server")
l.bind("","")
...

I am currently testing those options (OpenLDAP API is not documented
very well).

I think it would work like this (using StartTLS):

import ldap
l=ldap.initialize("ldap://some.ldap.server")
l.tls_cacert_file="cacert.pem"
l.tls_cert_file="mycert.pem"
l.tls_key_file="mykey.pem"
l.tls_require_cert=1
l.start_tls_s()
l.bind("mydn","mypasswd")

Using LDAP over SSL it whould be:
import ldap
l=ldap.initialize("ldaps://some.ldap.server")
l.tls_cacert_file="cacert.pem"
l.tls_cert_file="mycert.pem"
l.tls_key_file="mykey.pem"
l.tls_require_cert=1
l.bind("mydn","mypasswd")

You can use ldap.init() instead of ldap.initialize(). ldap.open() 
should not be used as it is depreciated, and it won't work for LDAP over
SSL (as connection would be open before tls options are set).

It seems some of OpenLDAP options (eg. LDAP_OPT_DEBUG_LEVEL) are global
flags, not specific to any LDAPObject. So we need some interface to set
those for whole ldap module. I don't know how to implement this.
Should it be some function like ldap.set_option(), or a global variable
set like attribute of LDAPObject. Is ther C interface for such thing?
I have not yet checked if TLS options all global or connection-specific.

Greets,
        Jacek



From michael at stroeder.com  Sun Nov 11 20:24:34 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Nov 2001 20:24:34 +0100
Subject: TLS context
References: <20011111114445.A3004@nic.bnet.pl>
Message-ID: <3BEED072.BB2C08DB@stroeder.com>

Jacek Konieczny wrote:
> 
> import ldap
> l=ldap.initialize("ldaps://some.ldap.server")
> l.bind("","")
> ...

I really wonder how a validation of the server certificate is done
in this case...

Ciao, Michael.



From jajcus at bnet.pl  Sun Nov 11 16:12:45 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Sun, 11 Nov 2001 16:12:45 +0100
Subject: TLS context
In-Reply-To: <3BEE8916.1E442B81@stroeder.com>
Message-ID: <20011111161244.A4203@nic.bnet.pl>

On Sun, Nov 11, 2001 at 03:20:06PM +0100, Michael Str?der wrote:
> Keep the name ldap.initialize(). 
That is what I have done.

> That makes it easy to find it in
> ldap.h. BTW: Support for ldapi:// (local domain socket) should be
> possible with this either.
I think so.

> I'd also appreciate if you could manage to use ldap_r and wrap it in
> such a way that python-ldap is re-entrant. Do you think that's
> feasible? 
I don't have any experience with threads. I may try, but I could make it
wrong.

> My module ldapthreadlock is just a weird work-around with
> some serious deficiencies.

> Does the OpenLDAP API expose a call-back interface to implement CRL
> checking and such?
It doesn't seem so. There is no trace of any CRL handling in ldap.h nor
i the openldap sources.
But I hope they will fix it soon.

Greets,
        Jacek



From jajcus at bnet.pl  Mon Nov 12 08:58:03 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Mon, 12 Nov 2001 08:58:03 +0100
Subject: TLS context
In-Reply-To: <3BEED072.BB2C08DB@stroeder.com>
Message-ID: <20011112085803.A3053@nic.bnet.pl>

On Sun, Nov 11, 2001 at 08:24:34PM +0100, Michael Str?der wrote:
> Jacek Konieczny wrote:
> > 
> > import ldap
> > l=ldap.initialize("ldaps://some.ldap.server")
> > l.bind("","")
> > ...
> 
> I really wonder how a validation of the server certificate is done
> in this case...
In this case no validation is made. Some validation would be probably
done if l.tls_* flags were set between ldap.initialize() and l.bind().

Greets,
        Jacek



From jajcus at bnet.pl  Mon Nov 12 11:16:06 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Mon, 12 Nov 2001 11:16:06 +0100
Subject: TLS context
In-Reply-To: <3BEE8916.1E442B81@stroeder.com>
Message-ID: <20011112111606.D3053@nic.bnet.pl>

On Sun, Nov 11, 2001 at 03:20:06PM +0100, Michael Str?der wrote:
> > I have not yet checked if TLS options all global or connection-specific.
> 
> I would assume that TLS/SSL options are connection-specific since
> you might have different trusted root CA certs, etc.

I have checked this and it turned out, that mose TLS options are global,
and cannot be set per LDAPObject. 
To support global options (which can eventualy be available as object
options) I have moved part of setattr and getattr of LDAPObject to other
functions, which can also be used without object for setting global
options.

Here is (working) fragment of python-ldap program:

import ldap
ldap.set_option("tls_require_cert",1)
ldap.set_option("tls_cacertfile","my_cacerts.pem")
l=ldap.initialize("https://some.ldap.server")
l.tls=ldap.TLS_HARD
l.bind("","")

Should I commit the changes (as soon as I polish them a bit more)?
And is there any way to make it work like this?:

ldap.tls_require_cert=1

It is easy for object (that is the way it is done for LDAPObject), but
is there any way to implement this in module?

And one more thing:

Do we really need suport for OpenLDAP < 2.x?
Now python-ldap compiled with OpenLDAP1 and python-ldap compiled with
OpenLDAP2 are so different as they are different modules. And the code
is quite hard to maintain.
It was long time ago, when OpenLDAP2 was experimental.

Greets,
        Jacek



From michael at stroeder.com  Mon Nov 12 11:59:37 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Mon, 12 Nov 2001 11:59:37 +0100
Subject: TLS context
References: <20011112111606.D3053@nic.bnet.pl>
Message-ID: <3BEFAB99.66357F75@stroeder.com>

Jacek Konieczny wrote:
> 
> On Sun, Nov 11, 2001 at 03:20:06PM +0100, Michael Str?der wrote:
> > > I have not yet checked if TLS options all global or connection-specific.
> >
> > I would assume that TLS/SSL options are connection-specific since
> > you might have different trusted root CA certs, etc.
> 
> I have checked this and it turned out, that mose TLS options are global,
> and cannot be set per LDAPObject.
> To support global options (which can eventualy be available as object
> options) I have moved part of setattr and getattr of LDAPObject to other
> functions, which can also be used without object for setting global
> options.

Well, if the TLS options are global they should be handled globally.
Therefore any global option must not be wrapped by an attribute of
the LDAP connection object. The application programmer has to deal
with it.

> Do we really need suport for OpenLDAP < 2.x?

No. It was decided ages ago that we drop support for OpenLDAP 1.x,
Netscape SDK and Novell SDK if we have something stable working with
OpenLDAP 2.x.

> Now python-ldap compiled with OpenLDAP1 and python-ldap compiled with
> OpenLDAP2 are so different as they are different modules. And the code
> is quite hard to maintain.

You're welcome to throw away any code not needed when compiling
against OpenLDAP 2.x libs. E.g. I already removed autoconf stuff
from CVS. If someone needs that he/she can check out the tagged old
version.

> It was long time ago, when OpenLDAP2 was experimental.

Yes.

Ciao, Michael.



From david.leonard at itee.uq.edu.au  Mon Nov 12 15:52:34 2001
From: david.leonard at itee.uq.edu.au (David Leonard)
Date: Tue, 13 Nov 2001 00:52:34 +1000 (EST)
Subject: TLS context
In-Reply-To: <20011112151603.B4013@nic.bnet.pl>
Message-ID: <Pine.BSO.4.33.0111130047310.29076-100000@cathexis.bovingdon-st.fnarg.net.au>

On Mon, 12 Nov 2001, Jacek Konieczny typed thusly:

> ldap.set_option("tls_cacertfile","file")
>
> against:
>
> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"file")
>
> The first solution is shorter to use, the second is more like OpenLDAP C
> API. Which one should I use? If it is to be separated from "local"
> options (implemented as attribute) then IMHO the second would be better.
> Currently I have the first one implemented, but it is easy to change.

the latter is better: lets you catch errors in python faster (same trick
used in Xt)

you might also like to intern the strings so you can use == in C.

> > You're welcome to throw away any code not needed when compiling
> > against OpenLDAP 2.x libs. E.g. I already removed autoconf stuff
> > from CVS. If someone needs that he/she can check out the tagged old
> > version.
> OK. So I will do it. I will add "#error" for LDAP_API_VERSION < 2000

:)

d
-- 
David Leonard                           David.Leonard at itee.uq.edu.au
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8




From jajcus at bnet.pl  Mon Nov 12 15:16:03 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Mon, 12 Nov 2001 15:16:03 +0100
Subject: TLS context
In-Reply-To: <3BEFAB99.66357F75@stroeder.com>
Message-ID: <20011112151603.B4013@nic.bnet.pl>

On Mon, Nov 12, 2001 at 11:59:37AM +0100, Michael Str?der wrote:
> 
> Well, if the TLS options are global they should be handled globally.
> Therefore any global option must not be wrapped by an attribute of
> the LDAP connection object. The application programmer has to deal
> with it.
The problem is, that some of the options can be used globally and
locally. Eg. LDAP_OPT_X_TLS.
But we can handle those two cases separately.

Currently I handle the global options as strings (like it was for local
options implemented as attributes). But maybe it would be better to
handle them as constants.

eg.:

ldap.set_option("tls_cacertfile","file")

against:

ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"file")

The first solution is shorter to use, the second is more like OpenLDAP C
API. Which one should I use? If it is to be separated from "local"
options (implemented as attribute) then IMHO the second would be better.
Currently I have the first one implemented, but it is easy to change.

> You're welcome to throw away any code not needed when compiling
> against OpenLDAP 2.x libs. E.g. I already removed autoconf stuff
> from CVS. If someone needs that he/she can check out the tagged old
> version.
OK. So I will do it. I will add "#error" for LDAP_API_VERSION < 2000

It will be easier to extend the module then.

Greets,
        Jacek



From michael at stroeder.com  Mon Nov 12 16:01:56 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Mon, 12 Nov 2001 16:01:56 +0100
Subject: TLS context
References: <20011112151603.B4013@nic.bnet.pl>
Message-ID: <3BEFE464.977DBAD7@stroeder.com>

Jacek Konieczny wrote:
> 
> eg.:
> 
> ldap.set_option("tls_cacertfile","file")
> 
> against:
> 
> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"file")

I also vote for the 2nd option.

Ciao, Michael.



From michael at stroeder.com  Tue Nov 13 00:25:57 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 13 Nov 2001 00:25:57 +0100
Subject: ldap.set_option() ready
References: <20011112212031.A7541@nic.bnet.pl>
Message-ID: <3BF05A85.EA3E0B90@stroeder.com>

Jacek Konieczny wrote:
> 
> I will also make ldap.get_option() function and get_option/set_option
> methods of LDAPObject.

Shouldn't the LDAPObject-related options be implemented by
__getattr__() and __setattr__()? I have no personal preference but
this is how it's done today (e.g. "version" etc.) and it's very
Pythonic.

Ciao, Michael.



From jajcus at bnet.pl  Mon Nov 12 21:20:31 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Mon, 12 Nov 2001 21:20:31 +0100
Subject: ldap.set_option() ready
Message-ID: <20011112212031.A7541@nic.bnet.pl>

Hi,

I have just commited ldap.set_option() function and ldap.OPT_* constants.
It is not perfect yet (probably boolean options don't work as they
should), but it can already be used for TLS certificate validation
setup.

You can try this:

ldap.set_option(ldap.OPT_DEBUG_LEVEL,255)
ldap.set_option(ldap.OPT_X_TLS,ldap.OPT_X_TLS_HARD)
ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"cacerts.pem")
ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT,1)
l=ldap.initialize("ldaps://some.ldap.host")
l.simple_bind_s("","")

I will also make ldap.get_option() function and get_option/set_option
methods of LDAPObject.

Greets,
        Jacek



From david.leonard at itee.uq.edu.au  Tue Nov 13 03:59:59 2001
From: david.leonard at itee.uq.edu.au (David Leonard)
Date: Tue, 13 Nov 2001 12:59:59 +1000 (EST)
Subject: ldap.set_option() ready
In-Reply-To: <3BF05A85.EA3E0B90@stroeder.com>
Message-ID: <Pine.BSO.4.33.0111131208070.29076-100000@cathexis.bovingdon-st.fnarg.net.au>

On Tue, 13 Nov 2001, Michael Str?der typed thusly:

> Jacek Konieczny wrote:
> >
> > I will also make ldap.get_option() function and get_option/set_option
> > methods of LDAPObject.
>
> Shouldn't the LDAPObject-related options be implemented by
> __getattr__() and __setattr__()? I have no personal preference but
> this is how it's done today (e.g. "version" etc.) and it's very
> Pythonic.

you mean, like this?

	print ldap.option.api_info

	ldap.option.debug_level = 2

i think it is just as easy doing it the current get_option() way,
and means that OpenLDAP's documentation/manuals remains sensible for
people who want to read up on what the options mean.

The only real plus I can think of with attributes is that you have the
advantage of hasattr() and as you say, it is more pythonic.

d
-- 
David Leonard                           David.Leonard at itee.uq.edu.au
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8





From david.leonard at itee.uq.edu.au  Tue Nov 13 03:07:35 2001
From: david.leonard at itee.uq.edu.au (David Leonard)
Date: Tue, 13 Nov 2001 12:07:35 +1000 (EST)
Subject: result() timeout
Message-ID: <Pine.BSO.4.33.0111131153161.29076-100000@cathexis.bovingdon-st.fnarg.net.au>


i am cleaning out some of the diffs in my local tree; and want to know if this
change needs to be committed or something different.

currently when l.result(msgid, all, timeout) is called with a nonzero timeout
and timeout expires, then None is returned rather than the usual
 (res_type, value) tuple.

this change makes result() raise an ldap.TIMEOUT exception instead.
supposedly this makes it easier to write code to handle result timeouts?

old way:
	res = l.result(ldap.RES_ANY, 1, timeout)
	if res is None:
		#-- handle timeout
	else:
		typ,msg = res
		#-- handle message

new way:
	try:
		typ,msg = l.result(ldap.RES_ANY, 1, tiemout)
		#-- handle message
	except ldap.TIMEOUT:
		#-- handle timeout

so... ditch or commit?

The current documentation is totally wrong anyway; it says
	"\tIf a timeout occurs, the tuple (None, None) is returned.";
which is false. In any event it should be fixed.


Index: Modules/LDAPObject.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/LDAPObject.c,v
retrieving revision 1.14
diff -u -u -r1.14 LDAPObject.c
--- Modules/LDAPObject.c	2001/11/12 14:47:51	1.14
+++ Modules/LDAPObject.c	2001/11/13 02:06:41
@@ -1237,8 +1237,7 @@

     if (res_type == 0) {
 	/* Timeout has occured */
-	Py_INCREF(Py_None);
-    	return Py_None;
+	return PyErr_SetObject(errobjects[LDAP_TIMEOUT], Py_None);
     }

     if (res_type == LDAP_RES_SEARCH_ENTRY
@@ -1321,7 +1320,7 @@
 "\tindefinitely if timeout is negative.  A timeout of 0 will effect\n"
 "\ta poll.  The timeout can be expressed as a floating-point value.\n"
 "\n"
-"\tIf a timeout occurs, the tuple (None, None) is returned.";
+"\tIf a timeout occurs, a TIMEOUT exception is raised.";

 /* ldap_search */

Index: Doc/libldap.tex
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Doc/libldap.tex,v
retrieving revision 1.4
diff -u -u -r1.4 libldap.tex
--- Doc/libldap.tex	2001/11/13 01:50:51	1.4
+++ Doc/libldap.tex	2001/11/13 02:06:43
@@ -525,8 +525,7 @@
 the method will wait indefinitely for a response.
 The timeout can be expressed as a floating-point value, and
 a value of \constant{0} effects a poll.
-If a timeout does occur, the tuple \constant{(None,None)} is returned.
-(This should really have been a \exception{TIMEOUT} exception!)
+If a timeout does occur, a \exception{TIMEOUT} exception is raised.

 The \method{result()} method returns a tuple of the form
 \code{(\textit{result-type}, \textit{result-data})}.

-- 
David Leonard                           David.Leonard at itee.uq.edu.au
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8




From michael at stroeder.com  Tue Nov 13 10:51:08 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 13 Nov 2001 10:51:08 +0100
Subject: result() timeout
References: <Pine.BSO.4.33.0111131153161.29076-100000@cathexis.bovingdon-st.fnarg.net.au>
Message-ID: <3BF0ED0C.A146A6CE@stroeder.com>

David Leonard wrote:
> 
> currently when l.result(msgid, all, timeout) is called with a nonzero timeout
> and timeout expires, then None is returned rather than the usual
>  (res_type, value) tuple.
> 
> this change makes result() raise an ldap.TIMEOUT exception instead.
> supposedly this makes it easier to write code to handle result timeouts?

I'm fine with either way. But ldap.TIMEOUT should only be raised if
the timeout value was really nonzero. If the timeout value is zero
returning solely None is the most reasonable way.

I have to look into ldapthreading if I have to change something.

Ciao, Michael.



From michael at stroeder.com  Tue Nov 13 10:54:36 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 13 Nov 2001 10:54:36 +0100
Subject: ldap.set_option() ready
References: <Pine.BSO.4.33.0111131208070.29076-100000@cathexis.bovingdon-st.fnarg.net.au>
Message-ID: <3BF0EDDC.E68B2C73@stroeder.com>

David Leonard wrote:
> 
> On Tue, 13 Nov 2001, Michael Str?der typed thusly:
> 
> > Jacek Konieczny wrote:
> > >
> > > I will also make ldap.get_option() function and get_option/set_option
> > > methods of LDAPObject.
> >
> > Shouldn't the LDAPObject-related options be implemented by
> > __getattr__() and __setattr__()? I have no personal preference but
> > this is how it's done today (e.g. "version" etc.) and it's very
> > Pythonic.
> 
> you mean, like this?
> 
>         print ldap.option.api_info
> 
>         ldap.option.debug_level = 2
> 
> i think it is just as easy doing it the current get_option() way,
> and means that OpenLDAP's documentation/manuals remains sensible for
> people who want to read up on what the options mean.
> 
> The only real plus I can think of with attributes is that you have the
> advantage of hasattr() and as you say, it is more pythonic.

As I said, I have no personal preference. We can keep get_option()
to be more compliant with OpenLDAP's LDAP-EXT API. I can do the
Pythonic way in a Python wrapper module above if needed some time.

Ciao, Michael.



From jajcus at bnet.pl  Tue Nov 13 13:29:39 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Tue, 13 Nov 2001 13:29:39 +0100
Subject: ldap.set_option() ready
In-Reply-To: <Pine.BSO.4.33.0111132212090.32412-100000@cathexis.bovingdon-st.fnarg.net.au>
Message-ID: <20011113132939.C5155@nic.bnet.pl>

On Tue, Nov 13, 2001 at 10:13:54PM +1000, David Leonard wrote:
> On Tue, 13 Nov 2001, Jacek Konieczny typed thusly:
> 
> > The two interfaces can coexist.
> 
> um, i'd like to avoid too many ways of doing the same thing.. it leads to
> confusion... so, just one way or the other thanks :)

In this case IMHO set_option() seems more reasonable. But it will break
backward compatibility (for those options which are already implemented
as attributes).
Using attributes of LDAPObject for connection-specific options and
set_object() function for global/default options will make mess like
this:


import ldap
ldap.set_option(ldap.OPT_SIZELIMIT,100)   # sets default size limit
l=ldap.initialize("ldap://localhost/")
l.sizelimit=100                           # sets size limit for connection l

As you see the same option is set in two totally different ways. I the 
C API both are set using the same function with only difference is that,
in the first case first argument (LDAP object) is NULL.

I won't touch __setattr__() and set_option() of LDAPObject until we
decide on some solution.
 
I personally still think that the two (attribute, set_option()) solution
can coexist, provided they share as much code as possible.

Greets,
        Jacek



From jajcus at bnet.pl  Tue Nov 13 13:07:27 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Tue, 13 Nov 2001 13:07:27 +0100
Subject: ldap.set_option() ready
In-Reply-To: <3BF05A85.EA3E0B90@stroeder.com>
Message-ID: <20011113130727.B5155@nic.bnet.pl>

On Tue, Nov 13, 2001 at 12:25:57AM +0100, Michael Str?der wrote:
> Jacek Konieczny wrote:
> > 
> > I will also make ldap.get_option() function and get_option/set_option
> > methods of LDAPObject.
> 
> Shouldn't the LDAPObject-related options be implemented by
> __getattr__() and __setattr__()? I have no personal preference but
> this is how it's done today (e.g. "version" etc.) and it's very
> Pythonic.

LDAP API includes ldap_set_option() function. Anybody who knows this API
will search for something similar in python-ldap. The same function is
used to set some global/default options and to set connection-specific
options. It would be quite strange to treat them differently.
I agree, that __getattr__() and __setattr__() are more Pythonic, so I
think it should stay for at least some options. The two interfaces can
coexist. In fact __setattr__() will call set_option() internally, after
translating attribute name to LDAP_OPT_* constant.

Greets,
        Jacek



From david.leonard at itee.uq.edu.au  Tue Nov 13 13:13:54 2001
From: david.leonard at itee.uq.edu.au (David Leonard)
Date: Tue, 13 Nov 2001 22:13:54 +1000 (EST)
Subject: ldap.set_option() ready
In-Reply-To: <20011113130727.B5155@nic.bnet.pl>
Message-ID: <Pine.BSO.4.33.0111132212090.32412-100000@cathexis.bovingdon-st.fnarg.net.au>

On Tue, 13 Nov 2001, Jacek Konieczny typed thusly:

> The two interfaces can coexist.

um, i'd like to avoid too many ways of doing the same thing.. it leads to
confusion... so, just one way or the other thanks :)

d
-- 
David Leonard                           David.Leonard at itee.uq.edu.au
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8




From michael at stroeder.com  Tue Nov 13 14:01:03 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 13 Nov 2001 14:01:03 +0100
Subject: ldap.set_option() ready
References: <20011113132939.C5155@nic.bnet.pl>
Message-ID: <3BF1198F.70710214@stroeder.com>

Jacek Konieczny wrote:
> 
> On Tue, Nov 13, 2001 at 10:13:54PM +1000, David Leonard wrote:
> > On Tue, 13 Nov 2001, Jacek Konieczny typed thusly:
> >
> > > The two interfaces can coexist.
> >
> > um, i'd like to avoid too many ways of doing the same thing.. it leads to
> > confusion... so, just one way or the other thanks :)
> 
> In this case IMHO set_option() seems more reasonable.

Go for it.

> But it will break
> backward compatibility (for those options which are already implemented
> as attributes).

Backward compability to python-ldap with OpenLDAP 1 libs regarding
options was broken with OpenLDAP 2 patches anyway. I don't mind.

> I won't touch __setattr__() and set_option() of LDAPObject until we
> decide on some solution.

Go for set_option() since the C module part should map OpenLDAP 2
API more or less directly.

Ciao, Michael.



From fog at debian.org  Tue Nov 13 15:36:56 2001
From: fog at debian.org (Federico Di Gregorio)
Date: 13 Nov 2001 15:36:56 +0100
Subject: Python parts of module ldap
In-Reply-To: <3BF12183.B7ACF2AE@stroeder.com>
References: <3BF12183.B7ACF2AE@stroeder.com>
Message-ID: <1005662217.1174.10.camel@nenya>

On Tue, 2001-11-13 at 14:34, Michael Str?der wrote:
> HI!
> 
> As already announced I'd like to contribute some of my LDAP-related
> Python modules to python-ldap.
> 
> But I don't want to pollute the module name space with a lot of
> separate names. Therefore I'd suggest that we turn the module ldap
> into a directory-based module package adding more sub-modules later.
> 
> ldap/__init__.py would import all symbols from _ldap for the sake of
> backward compability (like ldap.py already does today).
> 
> Comments?

perfect. my work and other projects (psycopg notably) suck-up all my
time. just relegate my code under a dir, i'll update it when i'll have
some more time.

ciao,
federico (currently fighting with apache auth_ldap)

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog at debian.org
INIT.D Developer                                           fog at initd.org
                             Best friends are often failed lovers. -- Me
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20011113/8c78ca82/attachment.pgp>

From michael at stroeder.com  Tue Nov 13 14:34:59 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 13 Nov 2001 14:34:59 +0100
Subject: Python parts of module ldap
Message-ID: <3BF12183.B7ACF2AE@stroeder.com>

HI!

As already announced I'd like to contribute some of my LDAP-related
Python modules to python-ldap.

But I don't want to pollute the module name space with a lot of
separate names. Therefore I'd suggest that we turn the module ldap
into a directory-based module package adding more sub-modules later.

ldap/__init__.py would import all symbols from _ldap for the sake of
backward compability (like ldap.py already does today).

Comments?

Ciao, Michael.



From rsalz at zolera.com  Tue Nov 13 15:26:47 2001
From: rsalz at zolera.com (Rich Salz)
Date: Tue, 13 Nov 2001 09:26:47 -0500
Subject: Python parts of module ldap
References: <3BF12183.B7ACF2AE@stroeder.com>
Message-ID: <3BF12DA7.B0EA3F9D@zolera.com>

+1

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com




From jajcus at bnet.pl  Tue Nov 13 16:03:21 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Tue, 13 Nov 2001 16:03:21 +0100
Subject: Python parts of module ldap
In-Reply-To: <3BF12183.B7ACF2AE@stroeder.com>
Message-ID: <20011113160321.B6191@nic.bnet.pl>

On Tue, Nov 13, 2001 at 02:34:59PM +0100, Michael Str?der wrote:
> Comments?
Sounds like a good idea.

Greets,
        Jacek



From Konstantin.Chuguev at dante.org.uk  Tue Nov 13 16:18:18 2001
From: Konstantin.Chuguev at dante.org.uk (Konstantin Chuguev)
Date: Tue, 13 Nov 2001 15:18:18 +0000
Subject: Python parts of module ldap
References: <3BF12183.B7ACF2AE@stroeder.com>
Message-ID: <3BF139BA.D90E7D97@dante.org.uk>

Michael Str?der wrote:

> As already announced I'd like to contribute some of my LDAP-related
> Python modules to python-ldap.
>
> But I don't want to pollute the module name space with a lot of
> separate names. Therefore I'd suggest that we turn the module ldap
> into a directory-based module package adding more sub-modules later.
>
> ldap/__init__.py would import all symbols from _ldap for the sake of
> backward compability (like ldap.py already does today).
>

Good idea!

Thank you Michael and all who brought python-ldap development back to life
recently! Unfortunately I do not have time to spend on it nowadays.

Regards,
    Konstantin.

--
         * *       Konstantin Chuguev           Francis House
      *      *     Application Engineer         112 Hills Road
    *              Tel: +44 1223 302992         Cambridge CB2 1PQ
D  A  N  T  E      WWW: http://www.dante.net    United Kingdom






From michael at stroeder.com  Tue Nov 13 16:17:16 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 13 Nov 2001 16:17:16 +0100
Subject: Removed files: Makefile.python-1.4
References: <E163fFq-0006Ao-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <3BF1397C.2123BF04@stroeder.com>

David Leonard wrote:
> 
> Removed files:
>         Misc           : Makefile.python-1.4

This also raises the question if the Build/ and Win32/ directories
are still needed.

Any good or bad experiences with building C modules under Win32 with
the help of DistUtils?

Ciao, Michael.



From michael at stroeder.com  Tue Nov 13 18:04:17 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 13 Nov 2001 18:04:17 +0100
Subject: `errobjects' undeclared
Message-ID: <3BF15291.635FADAE@stroeder.com>

David's last check-in of LDAPObject.c

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Modules/LDAPObject.c.diff?r1=1.15&r2=1.16

broke the build:

Modules/LDAPObject.c: In function `l_ldap_result':
Modules/LDAPObject.c:1243: `errobjects' undeclared (first use in
this function)

I don't know how to fix it.

Ciao, Michael.



From jlittle at ee.stanford.edu  Tue Nov 13 19:50:29 2001
From: jlittle at ee.stanford.edu (Joe Little)
Date: Tue, 13 Nov 2001 10:50:29 -0800
Subject: ldap.set_option() ready
In-Reply-To: <3BF1198F.70710214@stroeder.com>
Message-ID: <4ED1514B-D867-11D5-A396-0003930B38C0@ee.stanford.edu>

I just wanted to butt in with my opinion here.

It seems that to date, the python-ldap API has mirrored that of the 
c-API, but also provided an LDAP object wrapper.

I think is correct as well as ideal for us to support both the 
set_option() method in the direct API, but for object-oriented purposes 
provide an internal mechanism that calls the set_option using set_attr 
and get_attr syntax. Those who will use the LDAPObject and similar 
mentality will appreciate the latter, and I feel it doesn't confuse 
things if those methods are documented as object methods.

On Tuesday, November 13, 2001, at 05:01 AM, Michael Str?der wrote:

> Jacek Konieczny wrote:
>>
>> On Tue, Nov 13, 2001 at 10:13:54PM +1000, David Leonard wrote:
>>> On Tue, 13 Nov 2001, Jacek Konieczny typed thusly:
>>>
>>>> The two interfaces can coexist.
>>>
>>> um, i'd like to avoid too many ways of doing the same thing.. it 
>>> leads to
>>> confusion... so, just one way or the other thanks :)
>>
>> In this case IMHO set_option() seems more reasonable.
>
> Go for it.
>
>> But it will break
>> backward compatibility (for those options which are already implemented
>> as attributes).
>
> Backward compability to python-ldap with OpenLDAP 1 libs regarding
> options was broken with OpenLDAP 2 patches anyway. I don't mind.
>
>> I won't touch __setattr__() and set_option() of LDAPObject until we
>> decide on some solution.
>
> Go for set_option() since the C module part should map OpenLDAP 2
> API more or less directly.
>
> Ciao, Michael.
>
> 

From michael at stroeder.com  Wed Nov 14 00:59:55 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 14 Nov 2001 00:59:55 +0100
Subject: ldap.set_option() ready
References: <4ED1514B-D867-11D5-A396-0003930B38C0@ee.stanford.edu>
Message-ID: <3BF1B3FB.895111EE@stroeder.com>

Joe Little wrote:
> 
> It seems that to date, the python-ldap API has mirrored that of the
> c-API, but also provided an LDAP object wrapper.
> 
> I think is correct as well as ideal for us to support both the
> set_option() method in the direct API, but for object-oriented purposes
> provide an internal mechanism that calls the set_option using set_attr
> and get_attr syntax.

Since experience of the last months shows that most people on this
list don't like to muck out old C code I'd prefer to keep it as lean
as possible.

It's trivial to write a Python object wrapper around it which maps
set_option() to __setattr__().

Ciao, Michael.



From jajcus at bnet.pl  Tue Nov 13 19:42:14 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Tue, 13 Nov 2001 19:42:14 +0100
Subject: Documenting python-ldap
Message-ID: <20011113194214.A11247@nic.bnet.pl>

Hi,

Good software needs documentation. Especially any kind of API.
I made some basic docstrings for functions I had implemented, but they
are not perfect. And there is no docs for them in Doc/libldap.tex.
I don't thing my english is good enough to do the documentation, but
maybe there is someone here who would like to do this...
The other problem is, that OpenLDAP API has hardly any documentation :-(

Greets,
        Jacek



From david.leonard at itee.uq.edu.au  Wed Nov 14 00:43:12 2001
From: david.leonard at itee.uq.edu.au (David Leonard)
Date: Wed, 14 Nov 2001 09:43:12 +1000 (EST)
Subject: Documenting python-ldap
In-Reply-To: <20011113194214.A11247@nic.bnet.pl>
Message-ID: <Pine.BSO.4.33.0111140934260.4504-100000@cathexis.bovingdon-st.fnarg.net.au>

On Tue, 13 Nov 2001, Jacek Konieczny typed thusly:

> Hi,
> I made some basic docstrings for functions I had implemented, but they
> are not perfect. And there is no docs for them in Doc/libldap.tex.
> I don't thing my english is good enough to do the documentation, but
> maybe there is someone here who would like to do this...

It is sufficient at this stage to edit the documentation and write
"To Be Documented" where the documentation should go :) i think your
english is fine

Another approach to documentation is to write simple, commented examples
and leave them in the Demo directory

> The other problem is, that OpenLDAP API has hardly any documentation :-(

yes it seems not to have progressed much since the days of Umich man pages.
Maybe everyone who should be writing documentation is instead making
money by writing books about it? :)

d
-- 
David Leonard                           David.Leonard at itee.uq.edu.au
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8




From michael at stroeder.com  Wed Nov 14 13:49:47 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 14 Nov 2001 13:49:47 +0100
Subject: CIDict.c
References: <E163oVN-0006jE-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <3BF2686B.9D727F0A@stroeder.com>

David Leonard wrote:
> 
> Modified files:
>         Modules        : CIDict.c
> 
> Log message:
> some old fixes to cidict, useful if it ever gets enabled again

I'd suggest to simply throw CIDict.c away. It's far from being
something complete and can be more easily implemented in Python
based on UserDict.UserDict.

Ciao, Michael.



From jajcus at bnet.pl  Wed Nov 14 18:47:07 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Wed, 14 Nov 2001 18:47:07 +0100
Subject: CVS: python-ldap
In-Reply-To: <3BF2ABD2.D9A287B0@stroeder.com>
Message-ID: <20011114184707.A4615@nic.bnet.pl>

On Wed, Nov 14, 2001 at 06:37:22PM +0100, Michael Str?der wrote:
> > l.get_option(ldap.OPT_ERROR_NUMBER)
> >         instead of
> > l.errno
> > 
> > l.get_option(ldap.OPT_ERROR_STRING)
> >         instead of
> > l.error
> > 
> > l.get_option(ldap.OPT_MATCHED_DN)
> >         instead of
> > l.matched
> 
> Removed from where? 
 From LDAPObject. Probably noone used these attributes anyway.

> These should be class attributes of LDAPError
> exception instances.
And they still are. I didn't touch LDAPError code.

Greetsm,
        JAcek



From michael at stroeder.com  Wed Nov 14 17:34:05 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 14 Nov 2001 17:34:05 +0100
Subject: CVS: python-ldap
References: <E1642ql-0002Ov-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <3BF29CFD.F8AB7B24@stroeder.com>

Jacek Konieczny wrote:
> 
> Log message:
> - setattr() removed, getattr() made minimal

Can you shortly describe what this exactly means now? I lost track
of what get_options()/set_options() is used for at the moment.

How about you completing/updating the new example script
Demo/initialize.py ? You can commit the few lines without testing
and I will test it against my locally installed OpenLDAP 2 server.

Ciao, Michael.



From jajcus at bnet.pl  Wed Nov 14 18:15:56 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Wed, 14 Nov 2001 18:15:56 +0100
Subject: CVS: python-ldap
In-Reply-To: <3BF29CFD.F8AB7B24@stroeder.com>
Message-ID: <20011114181556.A4319@nic.bnet.pl>

On Wed, Nov 14, 2001 at 05:34:05PM +0100, Michael Str?der wrote:
> Jacek Konieczny wrote:
> > 
> > Log message:
> > - setattr() removed, getattr() made minimal
> 
> Can you shortly describe what this exactly means now? I lost track
> of what get_options()/set_options() is used for at the moment.
It is used for everything that ldap_set_option() in C API is used for.
It replaces some attributes of LDAPObject, which have been removed.

Sou you should use now:

l.set_option(ldap.OPT_PROTOCOL_VERSION,3)
        instead of
l.version=3

l.set_option(ldap.OPT_DEREF,1)
        instead of
l.deref=1

l.set_option(ldap.OPT_REFERRALS,1)
        instead of
l.referrals=3

l.set_option(ldap.OPT_RESTART,1)
        instead of
l.restart=1

l.set_option(ldap.OPT_TIMELIMIT,10)
        instead of
l.timelimit=10

l.set_option(ldap.OPT_SIZELIMIT,100)
        instead of
l.sizelimit=100

The same about reading the attribute and l.get_option().

Additionaly:

l.get_option(ldap.OPT_ERROR_NUMBER)
        instead of
l.errno

l.get_option(ldap.OPT_ERROR_STRING)
        instead of
l.error

l.get_option(ldap.OPT_MATCHED_DN)
        instead of
l.matched

I don't know what some of them do, but this are attributes I have
removed.

> How about you completing/updating the new example script
> Demo/initialize.py ? You can commit the few lines without testing
> and I will test it against my locally installed OpenLDAP 2 server.
I have done this before I got this mail :-)

Greets,
        Jacek



From michael at stroeder.com  Wed Nov 14 18:37:22 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 14 Nov 2001 18:37:22 +0100
Subject: CVS: python-ldap
References: <20011114181556.A4319@nic.bnet.pl>
Message-ID: <3BF2ABD2.D9A287B0@stroeder.com>

Jacek Konieczny wrote:
> 
> Additionaly:
> 
> l.get_option(ldap.OPT_ERROR_NUMBER)
>         instead of
> l.errno
> 
> l.get_option(ldap.OPT_ERROR_STRING)
>         instead of
> l.error
> 
> l.get_option(ldap.OPT_MATCHED_DN)
>         instead of
> l.matched

Removed from where? These should be class attributes of LDAPError
exception instances.

Ciao, Michael.



From david.leonard at itee.uq.edu.au  Thu Nov 15 00:26:02 2001
From: david.leonard at itee.uq.edu.au (David Leonard)
Date: Thu, 15 Nov 2001 09:26:02 +1000 (EST)
Subject: CVS: python-ldap
In-Reply-To: <E1649MI-0001kI-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <Pine.BSO.4.33.0111150924440.21990-100000@cathexis.bovingdon-st.fnarg.net.au>


On Wed, 14 Nov 2001, David Leonard typed thusly:
> restore setattr/getattr of options on LDAPObjects, but in a different way.

let me know what you think of this please.. (check out the array at the
top of options.c)

d
-- 
David Leonard                           David.Leonard at itee.uq.edu.au
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8




From michael at stroeder.com  Thu Nov 15 01:23:28 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 15 Nov 2001 01:23:28 +0100
Subject: cidict.py as LDAP entry class
References: <E1649gH-0002ur-00@usw-pr-cvs1.sourceforge.net>
Message-ID: <3BF30B00.7DCA9FEB@stroeder.com>

David Leonard wrote:
> 
> CVSROOT:        /cvsroot/python-ldap
> Module name:    python-ldap
> Changes by:     leonard 2001/11/14 15:42:57
> 
> Added files:
>         Lib            : cidict.py
> 
> Log message:
> oh, hello again

Note that this does not preserve the case of attribute type names
which might confuse other (broken) LDAP implementations. That's why
ldap.modlist.modifyModlist() looks so f*beep*ing complicated: This
function trys hard to be case-respecting (although I won't guarantee
anything! ;-)

I'd really like to implement those kind of things in a OID-based and
schema-aware Python class for LDAP entries. Compiler-freaks check
out SPARK (see
http://pages.cpsc.ucalgary.ca/~aycock/spark/) as a candidate for
parsing the schema descriptions according to the BNF described in
RFC 2252 etc.

Ciao, Michael.



From jajcus at bnet.pl  Thu Nov 15 17:39:15 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Thu, 15 Nov 2001 17:39:15 +0100
Subject: cidict.py as LDAP entry class
In-Reply-To: <3BF30B00.7DCA9FEB@stroeder.com>
Message-ID: <20011115173915.B4818@nic.bnet.pl>

On Thu, Nov 15, 2001 at 01:23:28AM +0100, Michael Str?der wrote:
> I'd really like to implement those kind of things in a OID-based and
> schema-aware Python class for LDAP entries.
This won't work very well with LDAP v2. But it may work, when schema
could be read from files instead of the server.

> Compiler-freaks check
> out SPARK (see
> http://pages.cpsc.ucalgary.ca/~aycock/spark/) as a candidate for
> parsing the schema descriptions according to the BNF described in
> RFC 2252 etc.

I made some simple schema parser in python for my pydibr, but I don't
think it is good enough to be part of python-ldap --- I made many
simplifying assumtions, and I haven't even read RFC 2252 (I couldn't
find the right RFC to find this).

Greets,
        Jacek



From michael at stroeder.com  Thu Nov 15 18:00:22 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 15 Nov 2001 18:00:22 +0100
Subject: cidict.py as LDAP entry class
References: <20011115173915.B4818@nic.bnet.pl>
Message-ID: <3BF3F4A6.2467F0C2@stroeder.com>

Jacek Konieczny wrote:
> 
> On Thu, Nov 15, 2001 at 01:23:28AM +0100, Michael Str?der wrote:
> > I'd really like to implement those kind of things in a OID-based and
> > schema-aware Python class for LDAP entries.
> This won't work very well with LDAP v2. But it may work, when schema
> could be read from files instead of the server.

You're right.

I would like to have local schema files at the client side for
LDAPv2 servers like already done for old OpenLDAP 1 schema files in
web2ldap. The schema parsing would have to tolerate string-based
fake OIDs anyway like e.g. used with Domino/LDAP R5 which is LDAPv3
but has no OIDs defined for customized schema extensions.

Ciao, Michael.



From jajcus at bnet.pl  Thu Nov 15 17:34:18 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Thu, 15 Nov 2001 17:34:18 +0100
Subject: CVS: python-ldap
In-Reply-To: <Pine.BSO.4.33.0111150924440.21990-100000@cathexis.bovingdon-st.fnarg.net.au>
Message-ID: <20011115173417.A4818@nic.bnet.pl>

On Thu, Nov 15, 2001 at 09:26:02AM +1000, David Leonard wrote:
> 
> On Wed, 14 Nov 2001, David Leonard typed thusly:
> > restore setattr/getattr of options on LDAPObjects, but in a different way.
> 
> let me know what you think of this please.. (check out the array at the
> top of options.c)

Seems very good. I can learn a lot from you about writting python
modules in C.
There is only one thing which doesn't seem very good: 
/* List of attributes that that are visible through attributes */

:-)

In Poland we call this "maslo maslane" ("butter-like butter"). :-)

Greets,
        Jacek



From michael at stroeder.com  Sun Nov 18 17:09:17 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 18 Nov 2001 17:09:17 +0100
Subject: python-ldap and --with-pymalloc
Message-ID: <3BF7DD2D.64DB32E7@stroeder.com>

HI!

It seems that I found the solution why python-ldap was seg faulting
with my Python 2.1 installation. It was compiled with configuration
option --with-pymalloc.

Without this option python-ldap runs fine with Python 2.1.1 and
2.2b2. :-)

Can somebody with C knowledge dig into that? At least python-ldap
build should failed if the Python interpreter was built with
--with-pymalloc.

Ciao, Michael.



From jens at zope.com  Sun Nov 18 23:12:33 2001
From: jens at zope.com (Jens Vagelpohl)
Date: Sun, 18 Nov 2001 17:12:33 -0500
Subject: python-ldap and --with-pymalloc
In-Reply-To: <3BF7DD2D.64DB32E7@stroeder.com>
Message-ID: <5D5EF47C-DC71-11D5-BAA6-00039363690C@zope.com>

it's actually not just python-ldap that is being bitten by pymalloc, there 
is quite a few people reporting mysterious crashes of Zope. some have 
simply recompiled their python --without-pymalloc and they went away...

i haven't heard anything from the pythonlabs guys about it yet.

jens


On Sunday, November 18, 2001, at 11:09 , Michael Str?der wrote:

> HI!
>
> It seems that I found the solution why python-ldap was seg faulting
> with my Python 2.1 installation. It was compiled with configuration
> option --with-pymalloc.
>
> Without this option python-ldap runs fine with Python 2.1.1 and
> 2.2b2. :-)
>
> Can somebody with C knowledge dig into that? At least python-ldap
> build should failed if the Python interpreter was built with
> --with-pymalloc.
>
> Ciao, Michael.
>
> 

From michael at stroeder.com  Mon Nov 19 00:46:48 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Mon, 19 Nov 2001 00:46:48 +0100
Subject: python-ldap and --with-pymalloc
References: <5D5EF47C-DC71-11D5-BAA6-00039363690C@zope.com>
Message-ID: <3BF84868.FDA439EC@stroeder.com>

Jens Vagelpohl wrote:
> 
> it's actually not just python-ldap that is being bitten by pymalloc, there
> is quite a few people reporting mysterious crashes of Zope. some have
> simply recompiled their python --without-pymalloc and they went away...

Are they using ZServerSSL with M2Crypto? My problems with M2Crypto
also vanished when recompiling everything --without-pymalloc.

Ciao, Michael.



From michael at stroeder.com  Thu Nov 22 12:41:46 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 22 Nov 2001 12:41:46 +0100
Subject: Win32 support
Message-ID: <3BFCE47A.DC21F822@stroeder.com>

HI!

I suspect that we silently dropped Win32 support in python-ldap by
abandoning building against old Umich libs.

Hmm, are there any Win32 hackers here who can check if it would be
possible to build recent python-ldap against
http://www.fivesight.com/downloads/openldap.asp ?

Ciao, Michael.



From jajcus at bnet.pl  Thu Nov 22 21:52:47 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Thu, 22 Nov 2001 21:52:47 +0100
Subject: Win32 support
In-Reply-To: <3BFCE47A.DC21F822@stroeder.com>
Message-ID: <20011122215247.A7201@nic.bnet.pl>

On Thu, Nov 22, 2001 at 12:41:46PM +0100, Michael Str?der wrote:
> HI!
> 
> I suspect that we silently dropped Win32 support in python-ldap by
> abandoning building against old Umich libs.
> 
> Hmm, are there any Win32 hackers here who can check if it would be
> possible to build recent python-ldap against
> http://www.fivesight.com/downloads/openldap.asp ?

AFAIK there are only executables (no DLL's) there. So it is no good for
us.

We need some hacker to build OpenLDAP libraries for Win32. It should be
possible.

Greets,
        Jacek



From mcicogni at siosistemi.it  Fri Nov 23 16:57:42 2001
From: mcicogni at siosistemi.it (Mauro Cicognini)
Date: Fri, 23 Nov 2001 16:57:42 +0100
Subject: Win32 support
References: <20011122215247.A7201@nic.bnet.pl>
Message-ID: <3BFE71F6.476E7816@siosistemi.it>

Jacek Konieczny wrote:

> On Thu, Nov 22, 2001 at 12:41:46PM +0100, Michael Str?der wrote:
> > HI!
> >
> > I suspect that we silently dropped Win32 support in python-ldap by
> > abandoning building against old Umich libs.
> >
> > Hmm, are there any Win32 hackers here who can check if it would be
> > possible to build recent python-ldap against
> > http://www.fivesight.com/downloads/openldap.asp ?
>
> AFAIK there are only executables (no DLL's) there. So it is no good for
> us.
>
> We need some hacker to build OpenLDAP libraries for Win32. It should be
> possible.
>
> Greets,
>         Jacek
>

I'm willing to do some work in this respect.
I'll let you know in a couple weeks.

Mauro


-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcicogni.vcf
Type: text/x-vcard
Size: 584 bytes
Desc: Card for Mauro Cicognini
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20011123/d390a65d/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2053 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20011123/d390a65d/attachment.bin>

From michael at stroeder.com  Tue Dec  4 21:01:59 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 04 Dec 2001 21:01:59 +0100
Subject: LDAP.SIZELIMIT_EXCEEDED exception thrown erroneously?
References: <20011204105829.A451@sigfs.org> <3C0D0343.630FC32@stroeder.com> <20011204134710.A657@sigfs.org>
Message-ID: <3C0D2BB7.E9D46956@stroeder.com>

Nick Reinking wrote:
> 
> Oh!  I realize my mistake.  I guess I should have done some research on what
> "size limit" means in LDAP. I had thought it meant the maximum number of
> matches, not the maximum number of DNs to iterate over.

It is a server-side limit. It has nothing to do with python-ldap in
the first place. Refer to your LDAP server's documentation to figure
out what this limit exactly means. Depending on the server's
implementation there could be various types of limits.

> Perhaps the description could be changed to something a bit more clear?

No, it can't be changed in python-ldap. The textual description is
sent by the LDAP server. python-ldap does exactly the right thing:
Raise an exception matching the error code and pass the error text
provided by the LDAP server in the exception instance to the
application.

As always proper error handling in your application gets complicated
if you want to do it correctly and complete...

Ciao, Michael.



From nick at sigfs.org  Tue Dec  4 17:58:30 2001
From: nick at sigfs.org (Nick Reinking)
Date: Tue, 4 Dec 2001 10:58:30 -0600
Subject: LDAP.SIZELIMIT_EXCEEDED exception thrown erroneously?
Message-ID: <20011204105829.A451@sigfs.org>

David, maybe you can help me.  I've got a really large in-house LDAP search
engine that I've built, and I've come across something rather unusual.

>>> import ldap

>>> ldap.__version__
'1.10alpha3'

>>> a = ldap.open("ldapsm")

>>> a
<LDAP {lberoptions:1, deref:DEREF_NEVER, timelimit:0 (NO_LIMIT), sizelimit:0 (NO_LIMIT), errno:4, error:'', matched:'', refhoplimit:5, options:< OPT_REFERRALS >}>

>>> a.simple_bind_s("","")

>>> result = a.search_st("o=supervalu.com",ldap.SCOPE_SUBTREE,"uid=*homth0*")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ldap.SIZELIMIT_EXCEEDED: {'desc': 'Sizelimit exceeded'}


However, if I do the same search in PHP, I get just one (relatively small)
result.  Why is this happening (especially since sizelimit == 0)?

Thanks!

- Nick Reinking



From michael at stroeder.com  Tue Dec  4 18:09:23 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 04 Dec 2001 18:09:23 +0100
Subject: LDAP.SIZELIMIT_EXCEEDED exception thrown erroneously?
References: <20011204105829.A451@sigfs.org>
Message-ID: <3C0D0343.630FC32@stroeder.com>

Nick Reinking wrote:
> 
> David, maybe you can help me.  I've got a really large in-house LDAP search
> engine that I've built, and I've come across something rather unusual.
> [..]
> ldap.SIZELIMIT_EXCEEDED: {'desc': 'Sizelimit exceeded'}

Nick, your application code has to deal with that. It signals that
only partial search results were returned. It's caused by a
server-side configuration limit (which is useful on large LDAP
servers!).

> However, if I do the same search in PHP, I get just one (relatively small)
> result.  Why is this happening (especially since sizelimit == 0)?

If it's different in PHP then PHP/LDAP is flawed.

Ciao, Michael.



From michael at stroeder.com  Fri Dec  7 21:01:48 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 07 Dec 2001 21:01:48 +0100
Subject: Win32 support
References: <20011122215247.A7201@nic.bnet.pl> <3BFE71F6.476E7816@siosistemi.it>
Message-ID: <3C11202C.D87A8EBD@stroeder.com>

Mauro Cicognini wrote:
> 
> Jacek Konieczny wrote:
> 
> > On Thu, Nov 22, 2001 at 12:41:46PM +0100, Michael Str?der wrote:
> > >
> > > I suspect that we silently dropped Win32 support in python-ldap by
> > > abandoning building against old Umich libs.
> > >
> > > Hmm, are there any Win32 hackers here who can check if it would be
> > > possible to build recent python-ldap against
> > > http://www.fivesight.com/downloads/openldap.asp ?
> >
> > AFAIK there are only executables (no DLL's) there. So it is no good for
> > us.
> >
> > We need some hacker to build OpenLDAP libraries for Win32. It should be
> > possible.
> 
> I'm willing to do some work in this respect.
> I'll let you know in a couple weeks.

Is that of any help?
http://starship.python.net/crew/kernr/mingw32/Notes.html

Ciao, Michael.



From michael at stroeder.com  Sun Dec  9 00:35:35 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 09 Dec 2001 00:35:35 +0100
Subject: New sub-module ldap.async
Message-ID: <3C12A3C7.F1E0836@stroeder.com>

HI!

During a hopeless effort to clean up the code in web2ldap ;-) I
wrote a base class for doing e.g. stream processing and
pseudo-paging of LDAP entries with async searches.

I think it's useful for others too. Therefore I've checked in
Lib/ldap/async.py. Demo/asyncldif.py should make clear how it's
used.

Reviews welcome.

Ciao, Michael.



From michael at stroeder.com  Sun Dec  9 14:29:20 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 09 Dec 2001 14:29:20 +0100
Subject: LDAP.SIZELIMIT_EXCEEDED exception thrown erroneously?
References: <20011204105829.A451@sigfs.org> <3C0D0343.630FC32@stroeder.com>
Message-ID: <3C136730.635573FF@stroeder.com>

Michael Str?der wrote:
> 
> Nick Reinking wrote:
> >
> > David, maybe you can help me.  I've got a really large in-house LDAP search
> > engine that I've built, and I've come across something rather unusual.
> > [..]
> > ldap.SIZELIMIT_EXCEEDED: {'desc': 'Sizelimit exceeded'}
> 
> Nick, your application code has to deal with that.

BTW: I've checked in Demo/asyncsizelimit.py which shows how to use
new sub-module ldap.async for retrieving the partial search results
in an almost synchronous manner even if ldap.SIZELIMIT_EXCEEDED was
raised.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Demo/asyncsizelimit.py

Ciao, Michael.



From michael at stroeder.com  Tue Dec 11 00:28:31 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 11 Dec 2001 00:28:31 +0100
Subject: Stability of python-ldap
References: <1143.011211@technologist.com>
Message-ID: <3C15451F.F4AED421@stroeder.com>

Paul Sokolovsky wrote:
> 
>   Can the maintainers comment on stability of python-ldap? Can it be
> used for production?

Which level of "production"?

> If so, which CVS tag is suggested?

Depends on your OS.

> And why there were no releases for more than year,

Hmm...

Ciao, Michael.



From Paul.Sokolovsky at technologist.com  Tue Dec 11 00:02:31 2001
From: Paul.Sokolovsky at technologist.com (Paul Sokolovsky)
Date: Tue, 11 Dec 2001 01:02:31 +0200
Subject: Stability of python-ldap
Message-ID: <1143.011211@technologist.com>

Hello python-ldap-dev,

  Can the maintainers comment on stability of python-ldap? Can it be
used for production? If so, which CVS tag is suggested? And why there
were no releases for more than year, with latest one being quite
feature-old and good deal of development happening all the time?

  Thanks,

--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135





From michael at stroeder.com  Tue Dec 11 09:21:05 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 11 Dec 2001 09:21:05 +0100
Subject: Stability of python-ldap
References: <1143.011211@technologist.com> <1008045758.15010.2.camel@typhaon>
Message-ID: <3C15C1F1.A59F3D69@stroeder.com>

Grahame Bowland wrote:
> 
> I am running a patched version to add some functionality from LDAP v3
> that wasn't in the upstream release at the time, but the patches are
> relatively trivial.

Note to Paul: These patches are in recent CVS version today. I would
also state that the C wrapper module _ldap is fairly stable at the
moment. The only caveat is that the OpenLDAP 2 libs are not
available for Win32. If that is your platform you have to dig into
that.

But without further knowledge about the production task and the OS
it's not possible to give a good answer.

Ciao, Michael.



From grahame at ucs.uwa.edu.au  Tue Dec 11 05:42:38 2001
From: grahame at ucs.uwa.edu.au (Grahame Bowland)
Date: 11 Dec 2001 12:42:38 +0800
Subject: Stability of python-ldap
In-Reply-To: <1143.011211@technologist.com>
References: <1143.011211@technologist.com>
Message-ID: <1008045758.15010.2.camel@typhaon>

On Tue, 2001-12-11 at 07:02, Paul Sokolovsky wrote:
> Hello python-ldap-dev,
> 
>   Can the maintainers comment on stability of python-ldap? Can it be
> used for production? If so, which CVS tag is suggested? And why there
> were no releases for more than year, with latest one being quite
> feature-old and good deal of development happening all the time?

I'm not a maintainer, but we do use python-ldap for a largish and fairly
critical application (along with mod-python for apache) and it's worked
flawlessly for almost a year now.

I am running a patched version to add some functionality from LDAP v3
that wasn't in the upstream release at the time, but the patches are
relatively trivial.

Cheers,
Grahame

-- 
Grahame Bowland                       Email: grahame at ucs.uwa.edu.au
University Communications Services    Phone: +61 8 9380 1175
The University of Western Australia     Fax: +61 8 9380 1109
                                     CRICOS: 00126G




From Paul.Sokolovsky at technologist.com  Tue Dec 11 21:37:03 2001
From: Paul.Sokolovsky at technologist.com (Paul Sokolovsky)
Date: Tue, 11 Dec 2001 22:37:03 +0200
Subject: Stability of python-ldap
In-Reply-To: <3C15451F.F4AED421@stroeder.com>
References: <3C15451F.F4AED421@stroeder.com>
Message-ID: <7942.011211@technologist.com>

Hello Michael,

Michael Str?der wrote on Tuesday, December 11, 2001:

MS> Paul Sokolovsky wrote:
>>
>>   Can the maintainers comment on stability of python-ldap? Can it be
>> used for production?

MS> Which level of "production"?

    When one can use it in a separate product without becoming
python-ldap hacker or bother its developers too much ;-)

>> If so, which CVS tag is suggested?

MS> Depends on your OS.

    Linux.

>> And why there were no releases for more than year,

MS> Hmm...

MS> Ciao, Michael.


--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135





From michael at stroeder.com  Tue Dec 11 23:36:50 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 11 Dec 2001 23:36:50 +0100
Subject: Stability of python-ldap
References: <3C15451F.F4AED421@stroeder.com> <7942.011211@technologist.com>
Message-ID: <3C168A82.356601AD@stroeder.com>

Paul Sokolovsky wrote:
> 
> Michael Str?der wrote on Tuesday, December 11, 2001:
> 
> MS> Paul Sokolovsky wrote:
> >>
> >>   Can the maintainers comment on stability of python-ldap? Can it be
> >> used for production?
> 
> MS> Which level of "production"?
> 
>     When one can use it in a separate product without becoming
> python-ldap hacker or bother its developers too much ;-)

Look into the examples in Demo/. Please provide more programming
examples if you feel the need for it. Support for LDAP with StartTLS
and LDAP over SSL is currently undocumented and needs testing
(especially things like certificate validation and using client
certs).

> >> If so, which CVS tag is suggested?
> 
> MS> Depends on your OS.
> 
>     Linux.

On Linux you check out recent version and build against recent
OpenLDAP 2 libs (IMHO should be 2.0.12+). There's currently not much
activity in the C wrapper part. Remember not to promise Win32
support to your customers at the moment (or hack OpenLDAP 2 libs
into DLLs yourself).

I'm currently rewriting pure-Python module ldif. Expect the API to
change.

Ciao, Michael.



From michael at stroeder.com  Thu Dec 13 21:13:23 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 13 Dec 2001 21:13:23 +0100
Subject: Stability of python-ldap
References: <3C168A82.356601AD@stroeder.com> <10917.011213@technologist.com>
Message-ID: <3C190BE3.DF80A263@stroeder.com>

Paul Sokolovsky wrote:
> 
>       Thanks, it seems to work fine. I was looking for LDAP module to
> convert some SourceForge scripts from Perl to Python. We probably
> stick to it instead of popen()ing ldapsearch.

Well, it should be more stable than popen()ing. ;-)

The following Python modules are currently under some work and might
be subject to changes:
ldap/async.py
ldap/modlist.py
ldif.py

This shouldn't prevent you from looking into them and give feedback.
:-)

Ciao, Michael.



From Paul.Sokolovsky at technologist.com  Thu Dec 13 21:00:46 2001
From: Paul.Sokolovsky at technologist.com (Paul Sokolovsky)
Date: Thu, 13 Dec 2001 22:00:46 +0200
Subject: Stability of python-ldap
In-Reply-To: <3C168A82.356601AD@stroeder.com>
References: <3C168A82.356601AD@stroeder.com>
Message-ID: <10917.011213@technologist.com>

Hello Michael,

      Thanks, it seems to work fine. I was looking for LDAP module to
convert some SourceForge scripts from Perl to Python. We probably
stick to it instead of popen()ing ldapsearch.


Michael Str?der wrote on Wednesday, December 12, 2001:

MS> Paul Sokolovsky wrote:
>>
>> Michael Str?der wrote on Tuesday, December 11, 2001:
>>
>> MS> Paul Sokolovsky wrote:
>> >>
>> >>   Can the maintainers comment on stability of python-ldap? Can it be
>> >> used for production?
>>
>> MS> Which level of "production"?
>>
>>     When one can use it in a separate product without becoming
>> python-ldap hacker or bother its developers too much ;-)

MS> Look into the examples in Demo/. Please provide more programming
MS> examples if you feel the need for it. Support for LDAP with StartTLS
MS> and LDAP over SSL is currently undocumented and needs testing
MS> (especially things like certificate validation and using client
MS> certs).

>> >> If so, which CVS tag is suggested?
>>
>> MS> Depends on your OS.
>>
>>     Linux.

MS> On Linux you check out recent version and build against recent
MS> OpenLDAP 2 libs (IMHO should be 2.0.12+). There's currently not much
MS> activity in the C wrapper part. Remember not to promise Win32
MS> support to your customers at the moment (or hack OpenLDAP 2 libs
MS> into DLLs yourself).

MS> I'm currently rewriting pure-Python module ldif. Expect the API to
MS> change.

MS> Ciao, Michael.




--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135






From Paul.Sokolovsky at technologist.com  Thu Dec 13 21:06:25 2001
From: Paul.Sokolovsky at technologist.com (Paul Sokolovsky)
Date: Thu, 13 Dec 2001 22:06:25 +0200
Subject: [patch] Demo/simplebrowse.py fixes/enhancemnts
Message-ID: <15921.011213@technologist.com>

Hello python-ldap-dev,

  Since there's no patch manager on
http://sf.net/projects/python-ldap/ :

  I like simplebrowse.py - it's kind of utility I was always missing
in my communication with LDAP ;-) . I'm missing "cd .." though, and it
keeps saying "invalid command" for almost any entered one. Fix is
attached.

--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simplebrowse.py.diff
Type: application/octet-stream
Size: 1320 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20011213/bdde1d0a/attachment.obj>

From michael at stroeder.com  Thu Dec 13 21:17:23 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 13 Dec 2001 21:17:23 +0100
Subject: [patch] Demo/simplebrowse.py fixes/enhancemnts
References: <15921.011213@technologist.com>
Message-ID: <3C190CD3.429DB840@stroeder.com>

Paul Sokolovsky wrote:
> 
>   I like simplebrowse.py - it's kind of utility I was always missing
> in my communication with LDAP ;-) . I'm missing "cd .." though, and it
> keeps saying "invalid command" for almost any entered one. Fix is
> attached.

I've commited it.

Ciao, Michael.



From jajcus at bnet.pl  Fri Dec 14 17:38:55 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Fri, 14 Dec 2001 17:38:55 +0100
Subject: [patch] Demo/simplebrowse.py fixes/enhancemnts
In-Reply-To: <15921.011213@technologist.com>
Message-ID: <20011214173855.D4085@nic.bnet.pl>

On Thu, Dec 13, 2001 at 10:06:25PM +0200, Paul Sokolovsky wrote:
> Hello python-ldap-dev,
> 
>   Since there's no patch manager on
> http://sf.net/projects/python-ldap/ :
> 
>   I like simplebrowse.py - it's kind of utility I was always missing
> in my communication with LDAP ;-) 

So maybe you could help me with testing my pydibr --- LDAP browser with
curses interface.

No release yet, but it is available on PLD's anoncvs:
cvs -d ':pserver:cvs at cvs.pld.org.pl:/cvsroot' login
(password cvs)
cvs -d ':pserver:cvs at cvs.pld.org.pl:/cvsroot' checkout pydibr

I know I should clean it up, make a release (but I am waiting for
python-ldap release) and prepare home page for this project, but 
I am a bit lazy and (at the moment) busy :-)
And I think that if there is anybody interested in such thing he is on
this list :-)

Greets,
        Jacek



From michael at stroeder.com  Fri Dec 14 17:50:20 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 14 Dec 2001 17:50:20 +0100
Subject: [patch] Demo/simplebrowse.py fixes/enhancemnts
References: <20011214173855.D4085@nic.bnet.pl>
Message-ID: <3C1A2DCC.CE81610B@stroeder.com>

Jacek Konieczny wrote:
> 
> On Thu, Dec 13, 2001 at 10:06:25PM +0200, Paul Sokolovsky wrote:
> > Hello python-ldap-dev,
> >
> >   Since there's no patch manager on
> > http://sf.net/projects/python-ldap/ :
> >
> >   I like simplebrowse.py - it's kind of utility I was always missing
> > in my communication with LDAP ;-)
> 
> So maybe you could help me with testing my pydibr --- LDAP browser with
> curses interface.

Hmm, then I'd like to note that http://web2ldap.de's HTML output is
intentionally friendly to console-based web browsers like lynx and
w3m. Check the online demo at http://sites.inka.de:8002/web2ldap.
Testers welcome... ;-)

Ciao, Michael.



From jajcus at bnet.pl  Fri Dec 14 18:03:31 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Fri, 14 Dec 2001 18:03:31 +0100
Subject: [patch] Demo/simplebrowse.py fixes/enhancemnts
In-Reply-To: <3C1A2DCC.CE81610B@stroeder.com>
Message-ID: <20011214180331.A4512@nic.bnet.pl>

On Fri, Dec 14, 2001 at 05:50:20PM +0100, Michael Str?der wrote:
> Hmm, then I'd like to note that http://web2ldap.de's HTML output is
> intentionally friendly to console-based web browsers like lynx and
> w3m. 
I belive your web2ldap is a great thing, but I don't need another layer
between LDAP and UI.
And the second thing is, that I am going to use LDAP for system
administration, and I don't like mixing administration with web
(I hate WWW interfaces to network devices like switches etc.)

> Check the online demo at http://sites.inka.de:8002/web2ldap.
> Testers welcome... ;-)
At the moment I don't even have time to work on pydibr (or check if it
stll works), but I will check this some day :-)

Greets,
        Jacek



From michael at stroeder.com  Fri Dec 14 19:54:33 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 14 Dec 2001 19:54:33 +0100
Subject: [patch] Demo/simplebrowse.py fixes/enhancemnts
References: <20011214180331.A4512@nic.bnet.pl>
Message-ID: <3C1A4AE9.D790DA43@stroeder.com>

Jacek Konieczny wrote:
> 
> > Check the online demo at http://sites.inka.de:8002/web2ldap.
> > Testers welcome... ;-)
> At the moment I don't even have time to work on pydibr (or check if it
> stll works), but I will check this some day :-)

If you have already python-ldap installed (the big hurdle) running
web2ldap is just unzipping the source distribution and issuing the
command

$ python sbin/web2ldap -d off

in the unzipped directory without prior configuration. The default
config is suitable for doing something meaningful with ~80% of LDAP
servers out there.

If you don't have the time to work on your pydibr that might be a
good chance to have at least something working despite your mental
problems with web interfaces in general... ;-)

Note: The recent web2ldap snapshots need python-ldap checked out
from CVS *very* recently (mostly the same day :-).

Ciao, Michael.



From michael at stroeder.com  Sat Dec 15 21:31:25 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 15 Dec 2001 21:31:25 +0100
Subject: Python parts of module ldap
References: <20011215211837.A7810@nic.bnet.pl>
Message-ID: <3C1BB31D.6FCEDF00@stroeder.com>

Jacek Konieczny wrote:
> 
> On Sat, Dec 15, 2001 at 09:03:44PM +0100, Michael Str?der wrote:
> > After checking in some of my modules below Lib/ldap/ I noticed a
> > serious drawback:
> > All modules are dependent on availability of OpenLDAP 2 libs if
> > located under Lib/ldap/ because of the "from _ldap import *" done in
> > Lib/ldap/__init__.py.
> >
> [...]
> >
> > Any opinions?
> 
> Maybe you could put "from _ldap import *" in some "try:/except:" block.

I already thought of that. But this makes error reports about
importing problems somewhat harder. E.g. if linking of shared libs
fails it's much more useful to have the original traceback instead
of e.g. a NameError exception afterwards. That's not good style.

Ciao, Michael.



From michael at stroeder.com  Sat Dec 15 21:03:44 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 15 Dec 2001 21:03:44 +0100
Subject: Python parts of module ldap
References: <3BF12183.B7ACF2AE@stroeder.com>
Message-ID: <3C1BACA0.EFEE6E70@stroeder.com>

Michael Str?der wrote:
> 
> As already announced I'd like to contribute some of my LDAP-related
> Python modules to python-ldap.
> 
> But I don't want to pollute the module name space with a lot of
> separate names. Therefore I'd suggest that we turn the module ldap
> into a directory-based module package adding more sub-modules later.
> 
> ldap/__init__.py would import all symbols from _ldap for the sake of
> backward compability (like ldap.py already does today).
> 
> Comments?

Hmm, following-up on my own request.

After checking in some of my modules below Lib/ldap/ I noticed a
serious drawback:
All modules are dependent on availability of OpenLDAP 2 libs if
located under Lib/ldap/ because of the "from _ldap import *" done in
Lib/ldap/__init__.py.

But I'm also using some of my modules separately on platforms where
the OpenLDAP 2 libs are not available. This affects mostly the
modules ldapurl, ldif, upcoming module dsml and upcoming module
containing generic filter classes. The only solution I have at the
moment is to make a new directory-based module package under Lib/ or
a new project.

Any opinions?

Ciao, Michael.



From jajcus at bnet.pl  Sat Dec 15 21:18:38 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Sat, 15 Dec 2001 21:18:38 +0100
Subject: Python parts of module ldap
In-Reply-To: <3C1BACA0.EFEE6E70@stroeder.com>
Message-ID: <20011215211837.A7810@nic.bnet.pl>

On Sat, Dec 15, 2001 at 09:03:44PM +0100, Michael Str?der wrote:
> After checking in some of my modules below Lib/ldap/ I noticed a
> serious drawback:
> All modules are dependent on availability of OpenLDAP 2 libs if
> located under Lib/ldap/ because of the "from _ldap import *" done in
> Lib/ldap/__init__.py.
> 
[...]
> 
> Any opinions?

Maybe you could put "from _ldap import *" in some "try:/except:" block.

Greets,
        Jacek



From jlittle at open-it.org  Sat Dec 15 22:26:02 2001
From: jlittle at open-it.org (Joe Little)
Date: Sat, 15 Dec 2001 13:26:02 -0800
Subject: Python parts of module ldap
In-Reply-To: <3C1BB31D.6FCEDF00@stroeder.com>
Message-ID: <B840FFEA.2A8E%jlittle@open-it.org>

Go one step further and use the try:except: with a variable.. ie, under some
condition (such as a no_openldap def), do the try:except:.. otherwise,
normal import

On 12/15/01 12:31 PM, "Michael Str?der" <michael at stroeder.com> wrote:

> Jacek Konieczny wrote:
>> 
>> On Sat, Dec 15, 2001 at 09:03:44PM +0100, Michael Str?der wrote:
>>> After checking in some of my modules below Lib/ldap/ I noticed a
>>> serious drawback:
>>> All modules are dependent on availability of OpenLDAP 2 libs if
>>> located under Lib/ldap/ because of the "from _ldap import *" done in
>>> Lib/ldap/__init__.py.
>>> 
>> [...]
>>> 
>>> Any opinions?
>> 
>> Maybe you could put "from _ldap import *" in some "try:/except:" block.
> 
> I already thought of that. But this makes error reports about
> importing problems somewhat harder. E.g. if linking of shared libs
> fails it's much more useful to have the original traceback instead
> of e.g. a NameError exception afterwards. That's not good style.
> 
> Ciao, Michael.
> 
> 

From michael at stroeder.com  Sat Dec 15 22:41:06 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 15 Dec 2001 22:41:06 +0100
Subject: Python parts of module ldap
References: <B840FFEA.2A8E%jlittle@open-it.org>
Message-ID: <3C1BC372.DFBCD19B@stroeder.com>

Joe Little wrote:
> 
> Go one step further and use the try:except: with a variable.. ie, under some
> condition (such as a no_openldap def), do the try:except:.. otherwise,
> normal import

You mean a variable in the module's name space? Hmm, that would have
to be set by the installing routine, DistUtils in our case.

Ciao, Michael.



From jeff at ollie.clive.ia.us  Sat Dec 15 23:24:07 2001
From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie)
Date: Sat, 15 Dec 2001 16:24:07 -0600
Subject: Python parts of module ldap
In-Reply-To: <3C1BB31D.6FCEDF00@stroeder.com>
References: <20011215211837.A7810@nic.bnet.pl> <3C1BB31D.6FCEDF00@stroeder.com>
Message-ID: <20011215162407.B6683@ollie.clive.ia.us>

On Sat, Dec 15, 2001 at 09:31:25PM +0100, Michael Str?der wrote:
> Jacek Konieczny wrote:
> > 
> > On Sat, Dec 15, 2001 at 09:03:44PM +0100, Michael Str?der wrote:
> > > After checking in some of my modules below Lib/ldap/ I noticed a
> > > serious drawback:
> > > All modules are dependent on availability of OpenLDAP 2 libs if
> > > located under Lib/ldap/ because of the "from _ldap import *" done in
> > > Lib/ldap/__init__.py.
> > >
> > [...]
> > >
> > > Any opinions?
> > 
> > Maybe you could put "from _ldap import *" in some "try:/except:" block.
> 
> I already thought of that. But this makes error reports about
> importing problems somewhat harder. E.g. if linking of shared libs
> fails it's much more useful to have the original traceback instead
> of e.g. a NameError exception afterwards. That's not good style.

What about something like:

import sys
_ldap_import_exception = (None, None, None)
try:
    from _ldap import *
except ImportError:
    _ldap_import_exception = sys.exc_info()

Jeff




From michael at stroeder.com  Sat Dec 15 23:35:48 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 15 Dec 2001 23:35:48 +0100
Subject: Python parts of module ldap
References: <20011215211837.A7810@nic.bnet.pl> <3C1BB31D.6FCEDF00@stroeder.com> <20011215162407.B6683@ollie.clive.ia.us>
Message-ID: <3C1BD044.CF72D72C@stroeder.com>

"Jeffrey C. Ollie" wrote:
> 
> On Sat, Dec 15, 2001 at 09:31:25PM +0100, Michael Str?der wrote:
> > Jacek Konieczny wrote:
> > >
> > > On Sat, Dec 15, 2001 at 09:03:44PM +0100, Michael Str?der wrote:
> > > > After checking in some of my modules below Lib/ldap/ I noticed a
> > > > serious drawback:
> > > > All modules are dependent on availability of OpenLDAP 2 libs if
> > > > located under Lib/ldap/ because of the "from _ldap import *" done in
> > > > Lib/ldap/__init__.py.
> > > >
> > > [...]
> > > >
> > > > Any opinions?
> > >
> > > Maybe you could put "from _ldap import *" in some "try:/except:" block.
> >
> > I already thought of that. But this makes error reports about
> > importing problems somewhat harder. E.g. if linking of shared libs
> > fails it's much more useful to have the original traceback instead
> > of e.g. a NameError exception afterwards. That's not good style.
> 
> What about something like:
> 
> import sys
> _ldap_import_exception = (None, None, None)
> try:
>     from _ldap import *
> except ImportError:
>     _ldap_import_exception = sys.exc_info()

Well, then it's easier to tell somebody to do a

$ python -c "import _ldap"

to track down problems.

Another issue I forgot to mention so far is that I can't reuse
constants of _ldap if importing it fails. I have to define them
separately anyway.

Hmm, I think I will stick with a separate module package.

Ciao, Michael.



From david.leonard at itee.uq.edu.au  Wed Dec 19 16:05:25 2001
From: david.leonard at itee.uq.edu.au (David Leonard)
Date: Thu, 20 Dec 2001 01:05:25 +1000 (EST)
Subject: [patch] Demo/simplebrowse.py fixes/enhancemnts
In-Reply-To: <3C190CD3.429DB840@stroeder.com>
Message-ID: <Pine.BSO.4.33.0112200059240.7254-100000@organ.bovingdon-st.fnarg.net.au>

On Thu, 13 Dec 2001, Michael Str?der typed thusly:

> >   I like simplebrowse.py - it's kind of utility I was always missing
> > in my communication with LDAP ;-) . I'm missing "cd .." though, and it
> > keeps saying "invalid command" for almost any entered one. Fix is
> > attached.
>
> I've commited it.

But, the structure of DNs is not that simple. What you're saying is that
you want to find the 'parent' object of an object. But the simple removing
of some component of the DN isn't guaranteed to work.

e.g.  A=a,B=b,C=c may not have as parent A=a,B=b but instead B=b,C=c.
I found this out the hard way when doing some testing ..

Now, I don't fully understand X.500 so maybe someone else knows a way of
properly defining and implementing "cd .."?

d
-- 
David Leonard                           David.Leonard at itee.uq.edu.au
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8




From michael at stroeder.com  Wed Dec 19 16:33:25 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 19 Dec 2001 16:33:25 +0100
Subject: [patch] Demo/simplebrowse.py fixes/enhancemnts
References: <Pine.BSO.4.33.0112200059240.7254-100000@organ.bovingdon-st.fnarg.net.au>
Message-ID: <3C20B345.19ABACCA@stroeder.com>

David Leonard wrote:
> 
> On Thu, 13 Dec 2001, Michael Str?der typed thusly:
> 
> > >   I like simplebrowse.py - it's kind of utility I was always missing
> > > in my communication with LDAP ;-) . I'm missing "cd .." though, and it
> > > keeps saying "invalid command" for almost any entered one. Fix is
> > > attached.
> >
> > I've commited it.
> 
> But, the structure of DNs is not that simple. What you're saying is that
> you want to find the 'parent' object of an object. But the simple removing
> of some component of the DN isn't guaranteed to work.

???

David, you're right that DN parsing is not that simple (escaping of
special chars). Therefore I've commited a patch that uses
ldap.explode_dn(dn) instead string.split(dn,",") hoping that the
LDAP lib does it right.

But going up one level in the LDAP DN hierarchy is exactly removing
the RDN, the first DN component (first item of list returned by
ldap.explode_dn()).

> e.g.  A=a,B=b,C=c may not have as parent A=a,B=b but instead B=b,C=c.
> I found this out the hard way when doing some testing ..

Yes. The parent entry of A=a,B=b,C=c with LDAP is B=b,C=c. That's
exactly what Paul's patch is doing.

> Now, I don't fully understand X.500 so maybe someone else knows a way of
> properly defining and implementing "cd .."?

Note that in X.500 DNs are usually noted from root to entry's RDN in
the order left-to-right. In opposite with LDAP the order from tree
root to entry's RDN is right-to-left (separated by comma, see RFC
2253).

Ciao, Michael.



From Paul.Sokolovsky at technologist.com  Wed Dec 19 16:47:34 2001
From: Paul.Sokolovsky at technologist.com (Paul Sokolovsky)
Date: Wed, 19 Dec 2001 17:47:34 +0200
Subject: [patch] Demo/simplebrowse.py fixes/enhancemnts
In-Reply-To: <Pine.BSO.4.33.0112200059240.7254-100000@organ.bovingdon-st.fnarg.net.au>
References: <Pine.BSO.4.33.0112200059240.7254-100000@organ.bovingdon-st.fnarg.net.au>
Message-ID: <2741.011219@technologist.com>

Hello David,

David Leonard wrote on Wednesday, December 19, 2001:

[]

DL> e.g.  A=a,B=b,C=c may not have as parent A=a,B=b but instead B=b,C=c.
DL> I found this out the hard way when doing some testing ..

DL> Now, I don't fully understand X.500 so maybe someone else knows a way of
DL> properly defining and implementing "cd .."?

    I understand that it's not that simple, but it's just the demo and
my hack likely fixed it a bit and added some feature ;-) . I don't
think it's a big problem anyway - yes, some intermediate levels may
not exist, but don't you want to see corresponding exception with
your own eyes? I've tested that I can get to RootDNS with it (on my
own install, it's closed on ldap://openldap.org for example), and that
I can't get above it, so it's kinda QAed ;-) .

DL> d
DL> --
DL> David Leonard                           David.Leonard at itee.uq.edu.au

[]


--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135





From michael at stroeder.com  Wed Dec 19 17:37:01 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 19 Dec 2001 17:37:01 +0100
Subject: DN parsing (was: [patch] Demo/simplebrowse.py fixes/enhancemnts)
References: <Pine.BSO.4.33.0112200213390.7254-100000@organ.bovingdon-st.fnarg.net.au>
Message-ID: <3C20C22D.515205B4@stroeder.com>

David Leonard wrote:
> 
> On Wed, 19 Dec 2001, Michael Str?der typed thusly:
> 
> > Note that in X.500 DNs are usually noted from root to entry's RDN in
> > the order left-to-right. In opposite with LDAP the order from tree
> > root to entry's RDN is right-to-left (separated by comma, see RFC
> > 2253).
> 
> ahhhh... that was the cause of some of my confusion.  thanks.

Over LDAP you always get the LDAP DN string representation of the
DN. No matter if the LDAP server just acts as a gateway to a X.500
DSA or as a stand-alone LDAP server with own DB backend.

BTW: Even OpenLDAP does not do the DN parsing completely. Comparing
equality of DNs is not trivial. I thought about implementing a
Python class for that.

David, do you have a suggestion how to implement parsing DNs? E.g.
break up

'cn=Stroeder\, Michael+mail=michael at stroeder.com,ou=Weird
chars\=\+\,\#,dc=stroeder,dc=com'

into a Python data structure:

[
  [
    ('cn',u'Stroeder, Michael'),
    ('mail',u'michael at stroeder.com')
  ],
  [
    ('ou',u'Weird chars=+,#')
  ],
  [
    ('dc',u'stroeder')
  ],
  [
   ('dc',u'com')
  [,
]

Note the multi-valued RDN. See RFC 2253 for the BNF of this mess...

Ciao, Michael.



From david.leonard at itee.uq.edu.au  Wed Dec 19 17:17:10 2001
From: david.leonard at itee.uq.edu.au (David Leonard)
Date: Thu, 20 Dec 2001 02:17:10 +1000 (EST)
Subject: [patch] Demo/simplebrowse.py fixes/enhancemnts
In-Reply-To: <3C20B345.19ABACCA@stroeder.com>
Message-ID: <Pine.BSO.4.33.0112200213390.7254-100000@organ.bovingdon-st.fnarg.net.au>

On Wed, 19 Dec 2001, Michael Str?der typed thusly:

> Note that in X.500 DNs are usually noted from root to entry's RDN in
> the order left-to-right. In opposite with LDAP the order from tree
> root to entry's RDN is right-to-left (separated by comma, see RFC
> 2253).

ahhhh... that was the cause of some of my confusion.  thanks.

Paul Sokolovsky wrote:
> yes, some intermediate levels may not exist, but don't you want to
> see corresponding exception with your own eyes?

mmmm.. yes - i guess its just a demo as you say :)

d
-- 
David Leonard                           David.Leonard at itee.uq.edu.au
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8






From michael at stroeder.com  Wed Dec 19 17:04:32 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 19 Dec 2001 17:04:32 +0100
Subject: [patch] Demo/simplebrowse.py fixes/enhancemnts
References: <Pine.BSO.4.33.0112200059240.7254-100000@organ.bovingdon-st.fnarg.net.au> <2741.011219@technologist.com>
Message-ID: <3C20BA90.45DDFDAB@stroeder.com>

Paul Sokolovsky wrote:
> 
> DL> Now, I don't fully understand X.500 so maybe someone else knows a way of
> DL> properly defining and implementing "cd .."?
> 
>     I understand that it's not that simple, but it's just the demo and
> my hack likely fixed it a bit and added some feature ;-) . I don't
> think it's a big problem anyway - yes, some intermediate levels may
> not exist, but don't you want to see corresponding exception with
> your own eyes?

If the parent entry does not exist you either have to catch
ldap.NO_SUCH_OBJECT or handle a referral. I see no problem either.

Ciao, Michael.



From krjackson at lbl.gov  Wed Dec 19 22:32:29 2001
From: krjackson at lbl.gov (Keith Jackson)
Date: Wed, 19 Dec 2001 13:32:29 -0800
Subject: SASL support
Message-ID: <3C21076D.1080309@lbl.gov>

Hi All,
I noticed in the TODO file that SASL support still needs to be added. Is 
anyone currently working on this? I'm going to need to be able to do a 
sasl_bind for a project, so if no one is working on this I might try to 
do it over xmas.
Comments?
--keith


From michael at stroeder.com  Wed Dec 19 22:44:07 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 19 Dec 2001 22:44:07 +0100
Subject: SASL support
References: <3C21076D.1080309@lbl.gov>
Message-ID: <3C210A27.3D6739A9@stroeder.com>

Keith Jackson wrote:
> 
> I noticed in the TODO file that SASL support still needs to be added. Is
> anyone currently working on this? I'm going to need to be able to do a
> sasl_bind for a project, so if no one is working on this I might try to
> do it over xmas.

Please go for it.

Ciao, Michael.



From michael at stroeder.com  Thu Dec 20 21:09:49 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 20 Dec 2001 21:09:49 +0100
Subject: Wrapped ldap_rename() and ldap_rename_s()
Message-ID: <3C22458D.F9B2D6E6@stroeder.com>

HI!

Although being a real C illiterate it seems that I managed to wrap
ldap_rename() and ldap_rename_s() found in OpenLDAP 2 libs. See
(expired) ID draft-ietf-ldapext-ldap-c-api.

Please test it! It's somewhat likely that I did something wrong.

See diffs:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Modules/LDAPObject.c.diff?r1=1.23&r2=1.24

Also added Demo/rename.py. Note: rename() only works with LDAPv3
servers.

Ciao, Michael.



From michael at stroeder.com  Fri Dec 21 15:24:14 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 21 Dec 2001 15:24:14 +0100
Subject: New wrapper-class ldap.ldapobject.LDAPObject and stripping down 
 _ldap.LDAPObject.c
References: <E16HN1J-0004ii-00@sancho.ccd.uniroma2.it> <3C2315CE.9E6E688E@stroeder.com>
Message-ID: <3C23460E.FF523D7C@stroeder.com>

Michael Str?der wrote:
> 
> I'm currently implementing a Python wrapper module ldap.LDAPObject
> around _ldap.LDAPObject based on work already done in
> ldapthreading.LDAPObject.

I've checked in the Python wrapper module ldap.ldapobject and
removed module ldapthreading.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Lib/ldap/ldapobject.py

When doing

import ldap
l=ldap.open()

the new module is automagically used.

Please test and give feedback!

Ciao, Michael.



From david.leonard at itee.uq.edu.au  Sat Dec 22 12:41:13 2001
From: david.leonard at itee.uq.edu.au (David Leonard)
Date: Sat, 22 Dec 2001 21:41:13 +1000 (EST)
Subject: Stripped LDAPObject.c
In-Reply-To: <3C239EFA.6ADA087F@stroeder.com>
Message-ID: <Pine.BSO.4.33.0112222126110.7450-100000@organ.bovingdon-st.fnarg.net.au>


hmmm, i'm not sure if i am completely comfortable with this

are the removed foo_s() functions really handled in the underlying library as a
call to foo() followed by ldap_result()?

i note you left in simple_bind_s() probably because from my reading of
the openldap source code, it shows that some complicated things happen at
the end of it that don't happen in simple_bind() ... i had a quick
skim and couldn't see the others doing much more ...

however, i do see how having a python-level wrapper is a good thing
(allows subclassing, locks, custom tracing)

d

On Fri, 21 Dec 2001, Michael Str?der typed thusly:

> HI!
>
> I've stripped all *_doc strings and almost all *_s() methods from
> LDAPObject.c. Also removed the deprecated Kerberos stuff completely.
>
> _ldap.so was 14kB smaller on my system (comparison after invoking
> strip). I also believe that it will be far easier to maintain the
> module now since there's not so much code subject to e.g. memory
> leaks etc. anymore.
>
> I did not check it in so far although it seems to work for me.
> Please check the attached C source and give feedback. Especially
> review and test the rename() and url_search() methods.
>
> For using all the *_s() methods you will need module
> Lib/ldap/ldapobject.py. So make sure your CVS tree is up-to-date.
>
> Ciao, Michael.

-- 
David Leonard                           David.Leonard at itee.uq.edu.au
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8





From michael at stroeder.com  Fri Dec 21 21:43:38 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 21 Dec 2001 21:43:38 +0100
Subject: Stripped LDAPObject.c
Message-ID: <3C239EFA.6ADA087F@stroeder.com>

HI!

I've stripped all *_doc strings and almost all *_s() methods from
LDAPObject.c. Also removed the deprecated Kerberos stuff completely.

_ldap.so was 14kB smaller on my system (comparison after invoking
strip). I also believe that it will be far easier to maintain the
module now since there's not so much code subject to e.g. memory
leaks etc. anymore.

I did not check it in so far although it seems to work for me.
Please check the attached C source and give feedback. Especially
review and test the rename() and url_search() methods.

For using all the *_s() methods you will need module
Lib/ldap/ldapobject.py. So make sure your CVS tree is up-to-date.

Ciao, Michael.
-------------- next part --------------
/* David Leonard <david.leonard at csee.uq.edu.au>, 1999. Public domain. */

/* 
 * LDAPObject - wrapper around an LDAP* context
 * $Id: LDAPObject.c,v 1.25 2001/12/21 13:21:14 stroeder Exp $
 */

#include <math.h>
#include <limits.h>
#include "common.h"
#include "errors.h"
#include "constants.h"
#include "LDAPObject.h"
#include "message.h"
#include "options.h"

static void free_attrs(char***);

/* constructor */

LDAPObject*
newLDAPObject( LDAP* l ) 
{
    LDAPObject* self = (LDAPObject*) PyObject_NEW(LDAPObject, &LDAP_Type);
    if (self == NULL) 
    	return NULL;
    self->ldap = l;
    self->_save = NULL;
    self->valid = 1;
    return self;
}

/* destructor */

static void
dealloc( LDAPObject* self )
{
    if (self->ldap) {
	if (self->valid) {
	    LDAP_BEGIN_ALLOW_THREADS( self );
	    ldap_unbind( self->ldap );
	    LDAP_END_ALLOW_THREADS( self );
	    self->valid = 0;
	}
	self->ldap = NULL;
    }
    PyMem_DEL(self);
}

/*------------------------------------------------------------
 * utility functions
 */

/* 
 * check to see if the LDAPObject is valid, 
 * ie has been opened, and not closed. An exception is set if not valid.
 */

static int
not_valid( LDAPObject* l ) {
    if (l->valid) {
    	return 0;
    } else {
    	PyErr_SetString( LDAPexception_class, "LDAP connection invalid" );
	return 1;
    }
}
  
/* free a LDAPMod (complete or partially) allocated in Tuple_to_LDAPMod() */

static void
LDAPMod_DEL( LDAPMod* lm )
{
    int i;

    if (lm->mod_type)
	PyMem_DEL(lm->mod_type);
    if (lm->mod_bvalues) {
	for (i = 0; lm->mod_bvalues[i]; i++) {
	    PyMem_DEL(lm->mod_bvalues[i]);
	}
	PyMem_DEL(lm->mod_bvalues);
    }
    PyMem_DEL(lm);
}

/* 
 * convert a tuple of the form (int,str,[str,...]) 
 * or (str, [str,...]) if no_op is true, into an LDAPMod structure.
 * See ldap_modify(3) for details.
 *
 * NOTE: the resulting LDAPMod structure has pointers directly into
 *       the Python string storage, so LDAPMod structures MUST have a
 *	 shorter lifetime than the tuple passed in.
 */

/* XXX - there is no way to pass complex-structured BER objects in here! */

static LDAPMod*
Tuple_to_LDAPMod( PyObject* tup, int no_op ) 
{
    int op;
    char *type;
    PyObject *list, *item;
    LDAPMod *lm = NULL;
    int i, len, nstrs;

    if (!PyTuple_Check(tup)) {
	PyErr_SetObject(PyExc_TypeError, Py_BuildValue("sO",
	   "expected a tuple", tup));
	return NULL;
    }

    if (no_op) {
	if (!PyArg_ParseTuple( tup, "sO", &type, &list ))
		return NULL;
	op = 0;
    } else {
	if (!PyArg_ParseTuple( tup, "isO", &op, &type, &list ))
		return NULL;
    }

    lm = PyMem_NEW(LDAPMod, 1);
    if (lm == NULL)
	goto nomem;

    lm->mod_op = op | LDAP_MOD_BVALUES;
    lm->mod_bvalues = NULL;

    len = strlen(type);
    lm->mod_type = PyMem_NEW(char, len + 1);
    if (lm->mod_type == NULL)
	goto nomem;
    memcpy(lm->mod_type, type, len + 1);

    if (list == Py_None) {
	/* None indicates a NULL mod_bvals */
    } else if (PyString_Check(list)) {
	/* Single string is a singleton list */
	lm->mod_bvalues = PyMem_NEW(struct berval *, 2);
	if (lm->mod_bvalues == NULL)
		goto nomem;
	lm->mod_bvalues[0] = PyMem_NEW(struct berval, 1);
	if (lm->mod_bvalues[0] == NULL)
		goto nomem;
	lm->mod_bvalues[1] = NULL;
	lm->mod_bvalues[0]->bv_len = PyString_Size(list);
	lm->mod_bvalues[0]->bv_val = PyString_AsString(list);
    } else if (PySequence_Check(list)) {
	nstrs = PySequence_Length(list);
	lm->mod_bvalues = PyMem_NEW(struct berval *, nstrs + 1);
	if (lm->mod_bvalues == NULL)
		goto nomem;
	for (i = 0; i < nstrs; i++) {
	   lm->mod_bvalues[i] = PyMem_NEW(struct berval, 1);
	   if (lm->mod_bvalues[i] == NULL)
		goto nomem;
	   lm->mod_bvalues[i+1] = NULL;
	   item = PySequence_GetItem(list, i);
	   if (item == NULL)
		goto error;
	   if (!PyString_Check(item)) {
		PyErr_SetObject( PyExc_TypeError, Py_BuildValue( "sO",
		   "expected a string in the list", item));
		Py_DECREF(item);
		goto error;
	   }
	   lm->mod_bvalues[i]->bv_len = PyString_Size(item);
	   lm->mod_bvalues[i]->bv_val = PyString_AsString(item);
	   Py_DECREF(item);
	}
	if (nstrs == 0)
	    lm->mod_bvalues[0] = NULL;
    }

    return lm;

nomem:
    PyErr_NoMemory();
error:
    if (lm) 
	LDAPMod_DEL(lm);

    return NULL;
}

/* free the structure allocated in List_to_LDAPMods() */

static void
LDAPMods_DEL( LDAPMod** lms ) {
    LDAPMod** lmp;
    for ( lmp = lms; *lmp; lmp++ )
    	LDAPMod_DEL( *lmp );
    PyMem_DEL(lms);
}

/* 
 * convert a list of tuples into a LDAPMod*[] array structure 
 * NOTE: list of tuples must live longer than the LDAPMods
 */

static LDAPMod**
List_to_LDAPMods( PyObject *list, int no_op ) {

    int i, len;
    LDAPMod** lms;
    PyObject *item;

    if (!PySequence_Check(list)) {
	PyErr_SetObject( PyExc_TypeError, Py_BuildValue("sO",
			"expected list of tuples", list ));
    	return NULL;
    }

    len = PySequence_Length(list);

    lms = PyMem_NEW(LDAPMod *, len + 1);
    if (lms == NULL) 
	goto nomem;

    for (i = 0; i < len; i++) {
        lms[i] = NULL;
        item = PySequence_GetItem(list, i);
        if (item == NULL) 
		goto error;
        lms[i] = Tuple_to_LDAPMod(item, no_op);
        Py_DECREF(item);
        if (lms[i] == NULL)
	    goto error;
    }
    lms[len] = NULL;
    return lms;

nomem:
    PyErr_NoMemory();
error:
    if (lms)
	LDAPMods_DEL(lms);
    return NULL;
}

/*
 * convert a python list of strings into an attr list (char*[]).
 * returns 1 if successful, 0 if not (with exception set)
 * XXX the strings should live longer than the resulting attrs pointer.
 */

int
attrs_from_List( PyObject *attrlist, char***attrsp ) {

    char **attrs = NULL;
    int i, len;
    PyObject *item;

    if (attrlist == Py_None) {
	/* None means a NULL attrlist */
    } else if (PyString_Check(attrlist)) {
	/* caught by John Benninghoff <johnb at netscape.com> */
	PyErr_SetObject( PyExc_TypeError, Py_BuildValue("sO",
		  "expected *list* of strings, not a string", attrlist ));
	goto error;
    } else if (PySequence_Check(attrlist)) {
	len = PySequence_Length(attrlist);
        attrs = PyMem_NEW(char *, len + 1);
	if (attrs == NULL)
	    goto nomem;

	for (i = 0; i < len; i++) {
	    attrs[i] = NULL;
	    item = PySequence_GetItem(attrlist, i);
	    if (item == NULL)
		goto error;
	    if (!PyString_Check(item)) {
		PyErr_SetObject(PyExc_TypeError, Py_BuildValue("sO",
			  "expected string in list", item));
		Py_DECREF(item);
		goto error;
	    }
	    attrs[i] = PyString_AsString(item);
	    Py_DECREF(item);
	}
	attrs[len] = NULL;
    } else {
    	PyErr_SetObject( PyExc_TypeError, Py_BuildValue("sO",
			  "expected list of strings or None", attrlist ));
	goto error;
    }

    *attrsp = attrs;
    return 1;

nomem:
    PyErr_NoMemory();
error:
    free_attrs(&attrs);
    return 0;
}

/* free memory allocated from above routine */

static void
free_attrs( char*** attrsp ) {
    char **attrs = *attrsp;

    if (attrs != NULL) {
   	PyMem_DEL(attrs);
	*attrsp = NULL;
    }
}

static void
set_timeval_from_double( struct timeval *tv, double d ) {
	tv->tv_usec = (long) ( fmod(d, 1.0) * 1000000.0 );
	tv->tv_sec = (long) floor(d);
}

/*------------------------------------------------------------
 * methods
 */

/* ldap_unbind */

static PyObject*
l_ldap_unbind( LDAPObject* self, PyObject* args )
{
    int ret;

    if (!PyArg_ParseTuple( args, "")) return NULL;
    if (not_valid(self)) return NULL;
    LDAP_BEGIN_ALLOW_THREADS( self );
    ret = ldap_unbind( self->ldap );
    LDAP_END_ALLOW_THREADS( self );
    if (ret == -1)
    	return LDAPerror( self->ldap, "ldap_unbind" );
    self->valid = 0;
    Py_INCREF(Py_None);
    return Py_None;
}

static char doc_unbind[] = "";

/* ldap_abandon */

static PyObject*
l_ldap_abandon( LDAPObject* self, PyObject* args )
{
    int msgid;
    int ret;

    if (!PyArg_ParseTuple( args, "i", &msgid)) return NULL;
    if (not_valid(self)) return NULL;
    LDAP_BEGIN_ALLOW_THREADS( self );
    ret = ldap_abandon( self->ldap, msgid );
    LDAP_END_ALLOW_THREADS( self );
    if (ret == -1)
    	return LDAPerror( self->ldap, "ldap_abandon" );
    Py_INCREF(Py_None);
    return Py_None;
}

static char doc_abandon[] = "";

/* ldap_add */

static PyObject *
l_ldap_add( LDAPObject* self, PyObject *args )
{
    char *dn;
    PyObject *modlist;
    int msgid;
    LDAPMod **mods;

    if (!PyArg_ParseTuple( args, "sO", &dn, &modlist )) return NULL;
    if (not_valid(self)) return NULL;

    mods = List_to_LDAPMods( modlist, 1 );
    if (mods == NULL)
	return NULL;

    LDAP_BEGIN_ALLOW_THREADS( self );
    msgid = ldap_add( self->ldap, dn, mods );
    LDAP_END_ALLOW_THREADS( self );
    LDAPMods_DEL( mods );

    if (msgid == -1)
    	return LDAPerror( self->ldap, "ldap_add" );

    return PyInt_FromLong(msgid);
}

static char doc_add[] = "";

static char doc_bind[] = "";

/* ldap_bind */

static PyObject*
l_ldap_bind( LDAPObject* self, PyObject* args )
{
    char *who, *cred;
    int method;
    int msgid;

    if (!PyArg_ParseTuple( args, "ssi", &who, &cred, &method)) return NULL;
    if (not_valid(self)) return NULL;
    LDAP_BEGIN_ALLOW_THREADS( self );
    msgid = ldap_bind( self->ldap, who, cred, method );
    LDAP_END_ALLOW_THREADS( self );
    if (msgid == -1)
    	return LDAPerror( self->ldap, "ldap_bind" );
    return PyInt_FromLong( msgid );
}


#if 0 
/* removed until made OpenLDAP2 compatible */

/* ldap_set_rebind_proc */

/* XXX - this could be called when threads are allowed!!! */

  static PyObject* rebind_callback_func = NULL;
  static LDAPObject* rebind_callback_ld = NULL;

  static int rebind_callback( LDAP*ld, char**dnp, char**credp, 
  			      int*methp, int freeit
#ifdef LDAP_SET_REBIND_PROC_3ARGS
			      , void *unused			/* Ugh */
#endif
			      )
  {
      PyObject *result;
      PyObject *args;
      int was_saved;

      char *dn, *cred;
      int  meth;

      if (freeit)  {
      	if (*dnp) free(*dnp);
	if (*credp) free(*credp);
	return LDAP_SUCCESS;
      }

      /* paranoia? */
      if (rebind_callback_ld == NULL)
      	Py_FatalError("rebind_callback: rebind_callback_ld == NULL");
      if (rebind_callback_ld->ldap != ld) 
      	Py_FatalError("rebind_callback: rebind_callback_ld->ldap != ld");
      if (not_valid(rebind_callback_ld)) 
      	Py_FatalError("rebind_callback: ldap connection closed");

      was_saved = (rebind_callback_ld->_save != NULL);

      if (was_saved)
	  LDAP_END_ALLOW_THREADS( rebind_callback_ld );

      args = Py_BuildValue("(O)", rebind_callback_ld);
      result = PyEval_CallObject( rebind_callback_func, args );
      Py_DECREF(args);

      if (result != NULL && 
          !PyArg_ParseTuple( result, "ssi", &dn, &cred, &meth ) )
      {
	  Py_DECREF( result );
          result = NULL;
      }

      if (result == NULL) {
	PyErr_Print();
	if (was_saved) 
	    LDAP_BEGIN_ALLOW_THREADS( rebind_callback_ld );
      	return !LDAP_SUCCESS;
      }

      Py_DECREF(result);
      *dnp = strdup(dn);
      if (!*dnp) return LDAP_NO_MEMORY;
      *credp = strdup(cred);
      if (!*credp) return LDAP_NO_MEMORY;
      *methp = meth;

      if (was_saved) 
      	  LDAP_BEGIN_ALLOW_THREADS( rebind_callback_ld );

      return LDAP_SUCCESS;
  }

static PyObject*
l_ldap_set_rebind_proc( LDAPObject* self, PyObject* args )
{
    PyObject *func;

    if (!PyArg_ParseTuple( args, "O", &func)) return NULL;
    if (not_valid(self)) return NULL;


    if ( PyNone_Check(func) ) {
        Py_XDECREF(rebind_callback_func);
        Py_XDECREF(rebind_callback_ld);
        rebind_callback_func = NULL;
        rebind_callback_ld = NULL;
#ifdef LDAP_SET_REBIND_PROC_3ARGS
    	ldap_set_rebind_proc( self->ldap, NULL, 0);
#else
    	ldap_set_rebind_proc( self->ldap, NULL );
#endif
	Py_INCREF(Py_None);
	return Py_None;
    }

    if ( PyCallable_Check(func) ) {
        Py_XDECREF(rebind_callback_func);
        Py_XDECREF(rebind_callback_ld);
	rebind_callback_func = func;
	rebind_callback_ld = self;
	Py_INCREF(func);
	Py_INCREF(self);
#ifdef LDAP_SET_REBIND_PROC_3ARGS
        ldap_set_rebind_proc( self->ldap, rebind_callback, 0);
#else
        ldap_set_rebind_proc( self->ldap, rebind_callback);
#endif
	Py_INCREF(Py_None);
	return Py_None;
    }

    PyErr_SetString( PyExc_TypeError, "expected function or None" );
    return NULL;
}

static char doc_set_rebind_proc[] = "";

#endif


#ifndef NO_CACHE
#ifdef HAVE_LDAP_ENABLE_CACHE

/* ldap_enable_cache */

static PyObject*
l_ldap_enable_cache( LDAPObject* self, PyObject* args )
{
    long timeout = LDAP_NO_LIMIT;
    long maxmem  = LDAP_NO_LIMIT;

    if (!PyArg_ParseTuple( args, "|ll", &timeout, &maxmem )) return NULL;
    if (not_valid(self)) return NULL;
    if ( ldap_enable_cache( self->ldap, timeout, maxmem ) == -1 )
    	return LDAPerror( self->ldap, "ldap_enable_cache" );
    Py_INCREF( Py_None );
    return Py_None;
}

static char doc_enable_cache[] = "";
#endif

#ifdef HAVE_LDAP_DISABLE_CACHE
/* ldap_disable_cache */

static PyObject *
l_ldap_disable_cache( LDAPObject* self, PyObject *args )
{
    if (!PyArg_ParseTuple( args, "" )) return NULL;
    if (not_valid(self)) return NULL;
    ldap_disable_cache( self->ldap );
    Py_INCREF( Py_None );
    return Py_None;
}

static char doc_disable_cache[] = "";
#endif

#ifdef HAVE_LDAP_SET_CACHE_OPTIONS
/* ldap_set_cache_options */

static PyObject *
l_ldap_set_cache_options( LDAPObject* self, PyObject *args )
{
    long opts;

    if (!PyArg_ParseTuple( args, "l", &opts )) return NULL;
    if (not_valid(self)) return NULL;
    ldap_set_cache_options( self->ldap, opts );
    Py_INCREF( Py_None );
    return Py_None;
}

static char doc_set_cache_options[] = "";
#endif

#ifdef HAVE_LDAP_DESTROY_CACHE
/* ldap_destroy_cache */

static PyObject *
l_ldap_destroy_cache( LDAPObject* self, PyObject *args )
{
    if (!PyArg_ParseTuple( args, "" )) return NULL;
    if (not_valid(self)) return NULL;
    ldap_destroy_cache( self->ldap );
    Py_INCREF( Py_None );
    return Py_None;
}

static char doc_destroy_cache[] = "";
#endif

#ifdef HAVE_LDAP_FLUSH_CACHE
/* ldap_flush_cache */

static PyObject *
l_ldap_flush_cache( LDAPObject* self, PyObject *args )
{
    if (!PyArg_ParseTuple( args, "" )) return NULL;
    if (not_valid(self)) return NULL;
    ldap_flush_cache( self->ldap );
    Py_INCREF( Py_None );
    return Py_None;
}

static char doc_flush_cache[] = "";
#endif


#ifdef HAVE_LDAP_UNCACHE_ENTRY
/* ldap_uncache_entry */

static PyObject *
l_ldap_uncache_entry( LDAPObject* self, PyObject *args )
{
    char *dn;

    if (!PyArg_ParseTuple( args, "s", &dn )) return NULL;
    if (not_valid(self)) return NULL;
    ldap_uncache_entry( self->ldap, dn );
    Py_INCREF( Py_None );
    return Py_None;
}

static char doc_uncache_entry[] = "";
#endif

#ifdef HAVE_LDAP_UNCACHE_REQUEST
/* ldap_uncache_request */

static PyObject *
l_ldap_uncache_request( LDAPObject* self, PyObject *args )
{
    int msgid;

    if (!PyArg_ParseTuple( args, "i", &msgid )) return NULL;
    if (not_valid(self)) return NULL;
    ldap_uncache_request( self->ldap, msgid );
    Py_INCREF( Py_None );
    return Py_None;
}

static char doc_uncache_request[] = "";
#endif

#endif /* !NO_CACHE */

/* ldap_compare */

static PyObject *
l_ldap_compare( LDAPObject* self, PyObject *args )
{
    char *dn, *attr, *value;
    int msgid;

    if (!PyArg_ParseTuple( args, "sss", &dn, &attr, &value )) return NULL;
    if (not_valid(self)) return NULL;
    LDAP_BEGIN_ALLOW_THREADS( self );
    msgid = ldap_compare( self->ldap, dn, attr, value );
    LDAP_END_ALLOW_THREADS( self );
    if (msgid == -1)
    	return LDAPerror( self->ldap, "ldap_compare" );
    return PyInt_FromLong( msgid );
}

static char doc_compare[] = "";


/* ldap_delete */

static PyObject *
l_ldap_delete( LDAPObject* self, PyObject *args )
{
    char *dn;
    int msgid;

    if (!PyArg_ParseTuple( args, "s", &dn )) return NULL;
    if (not_valid(self)) return NULL;
    LDAP_BEGIN_ALLOW_THREADS( self );
    msgid = ldap_delete( self->ldap, dn );
    LDAP_END_ALLOW_THREADS( self );
    if (msgid == -1)
    	return LDAPerror( self->ldap, "ldap_delete" );
    return PyInt_FromLong(msgid);
}

static char doc_delete[] = "";

/* ldap_modify */

static PyObject *
l_ldap_modify( LDAPObject* self, PyObject *args )
{
    char *dn;
    PyObject *modlist;
    int msgid;
    LDAPMod **mods;

    if (!PyArg_ParseTuple( args, "sO", &dn, &modlist )) return NULL;
    if (not_valid(self)) return NULL;

    mods = List_to_LDAPMods( modlist, 0 );
    if (mods == NULL)
	return NULL;

    LDAP_BEGIN_ALLOW_THREADS( self );
    msgid = ldap_modify( self->ldap, dn, mods );
    LDAP_END_ALLOW_THREADS( self );

    LDAPMods_DEL( mods );

    if (msgid == -1)
    	return LDAPerror( self->ldap, "ldap_modify" );

    return PyInt_FromLong( msgid );
}

static char doc_modify[] = "";

/* ldap_modrdn */

static PyObject *
l_ldap_modrdn( LDAPObject* self, PyObject *args )
{
    char *dn, *newrdn;
    int delold = 1;
    int msgid;

    if (!PyArg_ParseTuple( args, "ss|i", &dn, &newrdn, &delold )) 
    	return NULL;
    if (not_valid(self)) return NULL;

    LDAP_BEGIN_ALLOW_THREADS( self );
#if defined(HAVE_LDAP_MODRDN2)
    msgid = ldap_modrdn2( self->ldap, dn, newrdn, delold );
#else
#if    defined(LDAP_MODRDN_3ARGS)
    /* XXX the delold parameter is being ignored! should tell user */
    msgid = ldap_modrdn( self->ldap, dn, newrdn );
#else
    msgid = ldap_modrdn( self->ldap, dn, newrdn, delold );
#endif
#endif
    LDAP_END_ALLOW_THREADS( self );
    if (msgid == -1)
    	return LDAPerror( self->ldap, "ldap_modrdn2" );
    return PyInt_FromLong(msgid);
}

static char doc_modrdn[] = "";


/* ldap_rename */

static PyObject *
l_ldap_rename( LDAPObject* self, PyObject *args )
{
    char *dn, *newrdn, *newSuperior;
    int delold = 1;
    int result, msgid;

    if (!PyArg_ParseTuple( args, "sss|i", &dn, &newrdn, &newSuperior, &delold ))
    	return NULL;
    if (not_valid(self)) return NULL;

    LDAP_BEGIN_ALLOW_THREADS( self );
    result = ldap_rename( self->ldap, dn, newrdn, newSuperior, delold, NULL, NULL, &msgid );
    LDAP_END_ALLOW_THREADS( self );
    if ( result != LDAP_SUCCESS )
    	return LDAPerror( self->ldap, "ldap_rename" );
    return PyInt_FromLong( msgid );
}

static char doc_rename[] = "";


/* ldap_result */

static PyObject *
l_ldap_result( LDAPObject* self, PyObject *args )
{
    int msgid = LDAP_RES_ANY;
    int all = 1;
    double timeout = -1.0;
    struct timeval tv;
    struct timeval* tvp;
    int res_type;
    LDAPMessage *msg = NULL;
    PyObject *result_str, *retval, *pmsg;

    if (!PyArg_ParseTuple( args, "|iid", &msgid, &all, &timeout ))
    	return NULL;
    if (not_valid(self)) return NULL;
    
    if (timeout >= 0) {
        tvp = &tv;
	set_timeval_from_double( tvp, timeout );
    } else {
    	tvp = NULL;
    }

    LDAP_BEGIN_ALLOW_THREADS( self );
    res_type = ldap_result( self->ldap, msgid, all, tvp, &msg );
    LDAP_END_ALLOW_THREADS( self );

    if (res_type < 0)	/* LDAP or system error */
    	return LDAPerror( self->ldap, "ldap_result" );

    if (res_type == 0) {
	/* Polls return (None, None); timeouts raise an exception */
	if (timeout == 0)
		return Py_BuildValue("(OO)", Py_None, Py_None);
	else
		return LDAPerr(LDAP_TIMEOUT);
    }

    if (res_type == LDAP_RES_SEARCH_ENTRY
	    || res_type == LDAP_RES_SEARCH_REFERENCE
	)
	pmsg = LDAPmessage_to_python( self->ldap, msg );
    else {
	int result;
	char **refs = NULL;
	LDAP_BEGIN_ALLOW_THREADS( self );
	ldap_parse_result( self->ldap, msg, &result, NULL, NULL, &refs, NULL, 0 );
	LDAP_END_ALLOW_THREADS( self );

	if (result != LDAP_SUCCESS) {		/* result error */
	    char *e, err[1024];
	    if (result == LDAP_REFERRAL && refs && refs[0]) {
		snprintf(err, sizeof(err), "Referral:\n%s", refs[0]);
		e = err;
	    } else
		e = "ldap_parse_result";
	    return LDAPerror( self->ldap, e );
	}
	pmsg = Py_None;
    }

    result_str = LDAPconstant( res_type );

    if (pmsg == NULL) {
	    retval = NULL;
    } else {
	    retval = Py_BuildValue("(OO)", result_str, pmsg);
	if (pmsg != Py_None) {
        Py_DECREF(pmsg);
    }
    }
    Py_DECREF(result_str);
    return retval;
}

static char doc_result[] = "";

/* ldap_search */

static PyObject*
l_ldap_search( LDAPObject* self, PyObject* args )
{
    char *base;
    int scope;
    char *filter;
    PyObject *attrlist = Py_None;
    char **attrs;
    int attrsonly = 0;

    int msgid;

    if (!PyArg_ParseTuple( args, "sis|Oi", 
    	&base, &scope, &filter, &attrlist, &attrsonly)) return NULL;
    if (not_valid(self)) return NULL;

    if (!attrs_from_List( attrlist, &attrs )) 
   	 return NULL;

    LDAP_BEGIN_ALLOW_THREADS( self );
    msgid = ldap_search( self->ldap, base, scope, filter, 
                             attrs, attrsonly );
    LDAP_END_ALLOW_THREADS( self );

    free_attrs( &attrs );

    if (msgid == -1)
    	return LDAPerror( self->ldap, "ldap_search" );

    return PyInt_FromLong( msgid );
}	

static char doc_search[] = "";

/* ldap_sort_entries */

#ifdef HAVE_LDAP_START_TLS_S
/* ldap_start_tls_s */

static PyObject*
l_ldap_start_tls_s( LDAPObject* self, PyObject* args )
{
    int result;

    if (!PyArg_ParseTuple( args, "" )) return NULL;
    if (not_valid(self)) return NULL;

    result = ldap_start_tls_s( self->ldap, NULL, NULL );
    if ( result != LDAP_SUCCESS ){
	ldap_set_option(self->ldap, LDAP_OPT_ERROR_NUMBER, &result);
	return LDAPerror( self->ldap, "ldap_start_tls_s" );
    }

    Py_INCREF(Py_None);
    return Py_None;
}

static char doc_start_tls[] = "";
;
#endif

/* ldap_url_search */

static PyObject*
l_ldap_url_search( LDAPObject* self, PyObject* args )
{
    char *url;
    int attrsonly = 0;

    int msgid;


    if (!PyArg_ParseTuple( args, "s|i", &url, &attrsonly )) 
    	return NULL;
    if (not_valid(self)) return NULL;

    LDAP_BEGIN_ALLOW_THREADS( self );
    msgid = ldap_url_search( self->ldap, url, attrsonly );
    LDAP_END_ALLOW_THREADS( self );

    if (msgid == -1)
    	return LDAPerror( self->ldap, "ldap_search" );

    return PyInt_FromLong( msgid );
}

static char doc_url_search[] = "";

#if defined(HAVE_FILENO_LD_SB_SB_SD) /* || defined(...) */
#define FILENO_SUPPORTED
#endif

#if defined(FILENO_SUPPORTED)
static PyObject*
l_ldap_fileno(LDAPObject* self, PyObject* args)
{
    int fileno;

    if (PyArg_ParseTuple(args, "") == NULL)
	return NULL;
    if (!self->valid)
	fileno = -1;
    else {
#if defined(HAVE_FILENO_LD_SB_SB_SD)
	fileno = self->ldap->ld_sb.sb_sd;
/* #else ... other techniques */
#endif
    }
    return PyInt_FromLong(fileno);
}
static char doc_fileno[] = "";
#endif /* FILENO_SUPPORTED */

/* ldap_set_option */

static PyObject*
l_ldap_set_option(PyObject* self, PyObject *args)
{
    PyObject *value;
    int option;

    if (!PyArg_ParseTuple(args, "iO:set_option", &option, &value))
    	return NULL;
    if (LDAP_set_option((LDAPObject *)self, option, value) == -1)
	return NULL;
    Py_INCREF(Py_None);
    return Py_None;
}

static char doc_set_option[] =  "";

/* ldap_get_option */

static PyObject*
l_ldap_get_option(PyObject* self, PyObject *args)
{
    int option;

    if (!PyArg_ParseTuple(args, "i:get_option", &option))
    	return NULL;
    return LDAP_get_option((LDAPObject *)self, option);
}

static char doc_get_option[] =  "";

/* methods */

static PyMethodDef methods[] = {
    {"unbind",		(PyCFunction)l_ldap_unbind,		METH_VARARGS,	doc_unbind},
    {"unbind_s",	(PyCFunction)l_ldap_unbind,		METH_VARARGS,	doc_unbind},
    {"abandon",		(PyCFunction)l_ldap_abandon,		METH_VARARGS,	doc_abandon},
    {"add",		(PyCFunction)l_ldap_add,		METH_VARARGS,	doc_add},
    {"bind",		(PyCFunction)l_ldap_bind,		METH_VARARGS,	doc_bind},
#if 0    
    {"set_rebind_proc",	(PyCFunction)l_ldap_set_rebind_proc,	METH_VARARGS,	doc_set_rebind_proc},
#endif
#ifndef NO_CACHE
#ifdef HAVE_LDAP_ENABLE_CACHE
    {"enable_cache",	(PyCFunction)l_ldap_enable_cache,	METH_VARARGS,	doc_enable_cache},
#endif
#ifdef HAVE_LDAP_DISABLE_CACHE
    {"disable_cache",	(PyCFunction)l_ldap_disable_cache,	METH_VARARGS,	doc_disable_cache},
#endif
#ifdef HAVE_LDAP_SET_CACHE_OPTIONS
    {"set_cache_options",(PyCFunction)l_ldap_set_cache_options,	METH_VARARGS,	doc_set_cache_options},
#endif
#ifdef HAVE_LDAP_DESTROY_CACHE
    {"destroy_cache",	(PyCFunction)l_ldap_destroy_cache,	METH_VARARGS,	doc_destroy_cache},
#endif
#ifdef HAVE_LDAP_FLUSH_CACHE
    {"flush_cache",	(PyCFunction)l_ldap_flush_cache,	METH_VARARGS,	doc_flush_cache},
#endif
#ifdef HAVE_LDAP_UNCACHE_ENTRY
    {"uncache_entry",	(PyCFunction)l_ldap_uncache_entry,	METH_VARARGS,	doc_uncache_entry},
#endif
#ifdef HAVE_LDAP_UNCACHE_REQUEST
    {"uncache_request",	(PyCFunction)l_ldap_uncache_request,	METH_VARARGS,	doc_uncache_request},
#endif
#endif /* !NO_CACHE */
    {"compare",		(PyCFunction)l_ldap_compare,		METH_VARARGS,	doc_compare},
    {"delete",		(PyCFunction)l_ldap_delete,		METH_VARARGS,	doc_delete},
    {"modify",		(PyCFunction)l_ldap_modify,		METH_VARARGS,	doc_modify},
    {"modrdn",		(PyCFunction)l_ldap_modrdn,		METH_VARARGS,	doc_modrdn},
    {"rename",		(PyCFunction)l_ldap_rename,		METH_VARARGS,	doc_rename},
    {"result",		(PyCFunction)l_ldap_result,		METH_VARARGS,	doc_result},
    {"search",		(PyCFunction)l_ldap_search,		METH_VARARGS,	doc_search},
#ifdef HAVE_LDAP_START_TLS_S
    {"start_tls_s",	(PyCFunction)l_ldap_start_tls_s,	METH_VARARGS,	doc_start_tls},
#endif
    {"url_search",	(PyCFunction)l_ldap_url_search,	        METH_VARARGS,	doc_url_search},
    {"set_option",	(PyCFunction)l_ldap_set_option,		METH_VARARGS,	doc_set_option},
    {"get_option",	(PyCFunction)l_ldap_get_option,		METH_VARARGS,	doc_get_option},
#if defined(FILENO_SUPPORTED)
    {"fileno",		(PyCFunction)l_ldap_fileno,		METH_VARARGS,	doc_fileno},
#endif
    { NULL, NULL }
};

/* representation */

static PyObject*
repr( LDAPObject* self )
{
    static char buf[4096];

#   define STRFMT	"%s%s%s"
#   define STRFMTP(s)							\
    		(s)==NULL?"":"'",					\
		(s)==NULL?"None":(s),					\
		(s)==NULL?"":"'"

#   define LIMITFMT	"%d%s"
#   define LIMITFMTP(v)							\
    		(v),							\
		(v)==LDAP_NO_LIMIT?" (NO_LIMIT)":""
    		

    sprintf(buf,
#ifndef LDAP_TYPE_IS_OPAQUE
    	"<LDAP {lberoptions:%d, deref:%s, "
	"timelimit:" LIMITFMT ", "
	"sizelimit:" LIMITFMT ", "
	"errno:%d, error:" STRFMT ", "
	"matched:" STRFMT ", refhoplimit:%d, options:< %s%s%s>}>",
	    self->ldap->ld_lberoptions,
	    (
		self->ldap->ld_deref==LDAP_DEREF_NEVER ? "DEREF_NEVER" :
		self->ldap->ld_deref==LDAP_DEREF_SEARCHING ? "DEREF_SEARCHING" :
		self->ldap->ld_deref==LDAP_DEREF_FINDING ? "DEREF_FINDING" :
		self->ldap->ld_deref==LDAP_DEREF_ALWAYS ? "DEREF_ALWAYS" :
							  "*illegal*" 
	    ),
	    LIMITFMTP(self->ldap->ld_timelimit),
	    LIMITFMTP(self->ldap->ld_sizelimit),
	    self->ldap->ld_errno,
	    STRFMTP(self->ldap->ld_error),
	    STRFMTP(self->ldap->ld_matched),
	    self->ldap->ld_refhoplimit,

#ifdef LDAP_DNS
	   (self->ldap->ld_options & LDAP_OPT_DNS ? "OPT_DNS ":""),
#else
	      "",
#endif /* LDAP_DNS */

#ifdef LDAP_REFERRALS
	   (self->ldap->ld_options & LDAP_OPT_REFERRALS ? "OPT_REFERRALS ":""),
#else
	      "",
#endif /* LDAP_REFERRALS */

	   (self->ldap->ld_options & LDAP_OPT_RESTART   ? "OPT_RESTART ":"")
#else	/* LDAP_TYPE_IS_OPAQUE */
	"<LDAP>"
#endif
    );
    return PyString_FromString( buf );
}

/* get attribute */

static PyObject*
getattr(LDAPObject* self, char* name) 
{
	int option;

	option = LDAP_optionval_by_name(name);
	if (option != -1)
		return LDAP_get_option(self, option);

	return Py_FindMethod(methods, (PyObject*)self, name);
}

/* set attribute */

static int
setattr(LDAPObject* self, char* name, PyObject* value) 
{
	int option;

	option = LDAP_optionval_by_name(name);
	if (option != -1)
		return LDAP_set_option(self, option, value);

	PyErr_SetString(PyExc_AttributeError, name);
	return -1;
}

/* type entry */

PyTypeObject LDAP_Type = {
#if defined(WIN32) || defined(__CYGWIN__)
	/* see http://www.python.org/doc/FAQ.html#3.24 */
	PyObject_HEAD_INIT(NULL)
#else /* ! WIN32 */
	PyObject_HEAD_INIT(&PyType_Type)
#endif /* ! WIN32 */
	0,                      /*ob_size*/
	"LDAP",                 /*tp_name*/
	sizeof(LDAPObject),     /*tp_basicsize*/
	0,                      /*tp_itemsize*/
	/* methods */
	(destructor)dealloc,	/*tp_dealloc*/
	0,                      /*tp_print*/
	(getattrfunc)getattr,	/*tp_getattr*/
	(setattrfunc)setattr,	/*tp_setattr*/
	0,                      /*tp_compare*/
	(reprfunc)repr,         /*tp_repr*/
	0,                      /*tp_as_number*/
	0,                      /*tp_as_sequence*/
	0,                      /*tp_as_mapping*/
	0,                      /*tp_hash*/
};

From michael at stroeder.com  Fri Dec 21 11:58:22 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 21 Dec 2001 11:58:22 +0100
Subject: New wrapper-class ldap.ldapobject.LDAPObject and stripping down 
 _ldap.LDAPObject.c
References: <E16HN1J-0004ii-00@sancho.ccd.uniroma2.it>
Message-ID: <3C2315CE.9E6E688E@stroeder.com>

Lorenzo,

thanks for your feedback and suggestions.

>         def mod_rdn(dn, newrdn, delete=1):
>                 _ldap.rename(dn,newrdn,None,delete)

I'm currently implementing a Python wrapper module ldap.LDAPObject
around _ldap.LDAPObject based on work already done in
ldapthreading.LDAPObject.

This allows to implement optional parameter handling without mucking
with the C code at all.

The class wrapper will have the following benefits:
- LDAPObject's to act as real Python class without having to
implement
  Pythonic behaviour in LDAPObject.c.
- Solely use the async C module methods if available. This allows
  to throw out all the boring and hard to maintain code from
LDAPObject.c 
  repeatedly calling *_s() functions of the OpenLDAP libs.
- __doc__ strings more pydoc friendly.
- Using a threadlock to serialize LDAP calls is just setting an
optional
  key-word parameter when calling functions open() or initialize().
- Easier to maintain.
- Produce trace output of LDAP calls.

Feedback appreciated! Especially all interested folks should review
ldapthreading.LDAPObject.result(). From my own experience with
web2ldap it seems to work smoothly but please do code reviews!

>    Even better, if newsuperior is made optional and defaulted to NULL,
>    the user can simply forget about mod_rdn in the long term and choose
>    between:
>         rename(dn, newrdn)
>         rename(dn, newrdn, newsuperior)

At the moment I'm not sure how LDAPv2 servers are dealing with it.
We'll see.

> 2. You are overlooking client/server controls, which I agree to keep as NULLs
>    now, but I think should in the long term get implemented and at least
>    documented as an expected API, being it like

Yes. But unfortunately I'm not a C programmer. I have no idea how to
implement LDAP controls. C hackers should jump-on-in.

Ciao, Michael.



From jajcus at bnet.pl  Fri Dec 21 18:53:51 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Fri, 21 Dec 2001 18:53:51 +0100
Subject: New wrapper-class ldap.ldapobject.LDAPObject and stripping down _ldap.LDAPObject.c
In-Reply-To: <3C23460E.FF523D7C@stroeder.com>
Message-ID: <20011221185351.A4779@nic.bnet.pl>

On Fri, Dec 21, 2001 at 03:24:14PM +0100, Michael Str?der wrote:
> I've checked in the Python wrapper module ldap.ldapobject and
> removed module ldapthreading.
[...]
> 
> Please test and give feedback!

I found two bugs, which made my pydibr refuse to work:
- get_option() instead of set_option() in one place
- and intialize() instead of initialize() in another

I have already commited the fixed. I hope there are no more such
"typos".

Greets,
        Jacek



From michael at stroeder.com  Sat Dec 22 14:47:26 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 22 Dec 2001 14:47:26 +0100
Subject: Removing __doc__ strings from LDAPObject.c (was: Wrapped ldap_rename..)
References: <Pine.BSO.4.33.0112222105460.7450-100000@organ.bovingdon-st.fnarg.net.au>
Message-ID: <3C248EEE.D8ADE08C@stroeder.com>

David Leonard wrote:
> 
> On Fri, 21 Dec 2001, Michael Str?der typed thusly:
> 
> > David Leonard wrote:
> > > looks good... we'll make you a C hacker out of you yet, michael!
> >
> > Definitely not. Heh, you did not see my Python wrapper module for
> > LDAPObject yet. ;-)
> >
> > I really plan to remove all __doc__ strings and *_s()/*_st() methods
> > from LDAPObject.c. Will be *much* shorter and hopefully easier to
> > maintain afterwards.
> 
> hmmm...  would be nice to have the doc strings in a separate file - maybe
> autogenerated... but is probably easier to leave them where they are to
> meet the python-ish coding standard (unless that standard has changed?)

The __doc__ strings should be where the methods used by the
applications are. IMHO that's Lib/ldap/ldapobject.py. IMO
applications should not directly import _ldap anymore.

The current __doc__ strings are quite longish anyway. I shortened
some of them, others need an overhaul. E.g. pydoc generates working
web links to RFCs and recognizes URLs => it would be possible to
link to the python-ldap HTML docs and RFCs directly. Hmm,
documentation...

Ciao, Michael.



From michael at stroeder.com  Sat Dec 22 14:48:46 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 22 Dec 2001 14:48:46 +0100
Subject: New wrapper-class ldap.ldapobject.LDAPObject and stripping down 
 _ldap.LDAPObject.c
References: <20011221185351.A4779@nic.bnet.pl>
Message-ID: <3C248F3E.D3686257@stroeder.com>

Jacek Konieczny wrote:
> 
> On Fri, Dec 21, 2001 at 03:24:14PM +0100, Michael Str?der wrote:
> > I've checked in the Python wrapper module ldap.ldapobject and
> > removed module ldapthreading.
> [...]
> >
> > Please test and give feedback!
> 
> I found two bugs, which made my pydibr refuse to work:

Thanks for testing and fixing it!

> I have already commited the fixed. I hope there are no more such
> "typos".

Any general comments about this approach?

Ciao, Michael.



From michael at stroeder.com  Sat Dec 22 14:38:30 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 22 Dec 2001 14:38:30 +0100
Subject: Stripped LDAPObject.c
References: <Pine.BSO.4.33.0112222126110.7450-100000@organ.bovingdon-st.fnarg.net.au>
Message-ID: <3C248CD6.DE1460@stroeder.com>

David Leonard wrote:
> 
> i note you left in simple_bind_s()

??? No, I didn't.

> probably because from my reading of
> the openldap source code, it shows that some complicated things happen at
> the end of it that don't happen in simple_bind()

Ooops. I have to check that.

> however, i do see how having a python-level wrapper is a good thing
> (allows subclassing, locks, custom tracing)

BTW: Shall the tread lock always be used or should we really have a
keyword parameter in open()/initialize()? Anyway I will check in
some code in ldapobject.py today to make sure it works without
thread support in the local Python installation.

Ciao, Michael.



From michael at stroeder.com  Sat Dec 22 15:01:38 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 22 Dec 2001 15:01:38 +0100
Subject: Stripped LDAPObject.c
References: <Pine.BSO.4.33.0112222126110.7450-100000@organ.bovingdon-st.fnarg.net.au>
Message-ID: <3C249242.2459F9BA@stroeder.com>

David Leonard wrote:
> 
> i note you left in simple_bind_s() probably because from my reading of
> the openldap source code, it shows that some complicated things happen at
> the end of it that don't happen in simple_bind() ... i had a quick
> skim and couldn't see the others doing much more ...

I glanced over ldap_simple_bind_s() of
openldap-HEAD/ldap/libraries/libldap/sbind.c. It just looks like a
simple wrapper around ldap_sasl_bind_s() (see below). Hmm, we could
do the same in ldapobject.c once ldap_sasl_bind() is wrapped.

I'm also very much in favour of looking into how to use OpenLDAP 2's
libldap_r to check if we could build a thread-safe python-ldap C
wrapper. A global thread lock is sometimes annoying (e.g. if
ldap.open()/initialize() takes very long). Anyone willing to do
this? Another advantage of a very short LDAPObject.c is that these
kind of jobs get easier.

Ciao, Michael.

-------------------------------- snip
--------------------------------
int
ldap_simple_bind_s( LDAP *ld, LDAP_CONST char *dn, LDAP_CONST char
*passwd )
{
	struct berval cred;

	Debug( LDAP_DEBUG_TRACE, "ldap_simple_bind_s\n", 0, 0, 0 );

	if ( passwd != NULL ) {
		cred.bv_val = (char *) passwd;
		cred.bv_len = strlen( passwd );
	} else {
		cred.bv_val = "";
		cred.bv_len = 0;
	}

	return ldap_sasl_bind_s( ld, dn, LDAP_SASL_SIMPLE, &cred,
		NULL, NULL, NULL );
}
-------------------------------- snip
--------------------------------



From michael at stroeder.com  Sat Dec 22 16:14:51 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 22 Dec 2001 16:14:51 +0100
Subject: Stripped LDAPObject.c
References: <20011222153112.C3148@nic.bnet.pl>
Message-ID: <3C24A36B.BFC61AE7@stroeder.com>

Jacek Konieczny wrote:
> 
> AFAIK OpenLDAP, even in libldap_r is not very therad-safe.

Kurt Zeilenga wrote that the application has to take care of some
data structures. In our case this could be the C wrapper module.
Don't you think it would be feasible for at least some LDAP
operation methods?

> And libldap_r is missing some functions.

Which ones?

> IMHO we should not touch this
> unless it will be officialy supported and known to work without
> problems.

Yes, maybe it's too early.

Hmm, maybe python-ldap sits on top of the wrong LDAP C lib? We
currently do not have Win32 support and it's not thread-safe.

In opposite iPlanet C SDK (see
http://www.mozilla.org/directory/csdk.html) is known to be
thread-safe and is available on various platforms. Unfortunately the
API of the LDAP C SDKs diverged some much that it's unpossible to
#ifdef the differences. It's a decision for either one of those.

Ciao, Michael.



From jajcus at bnet.pl  Sat Dec 22 15:31:12 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Sat, 22 Dec 2001 15:31:12 +0100
Subject: Stripped LDAPObject.c
In-Reply-To: <3C249242.2459F9BA@stroeder.com>
Message-ID: <20011222153112.C3148@nic.bnet.pl>

On Sat, Dec 22, 2001 at 03:01:38PM +0100, Michael Str?der wrote:
> I'm also very much in favour of looking into how to use OpenLDAP 2's
> libldap_r to check if we could build a thread-safe python-ldap C
> wrapper. 
AFAIK OpenLDAP, even in libldap_r is not very therad-safe. And
libldap_r is missing some functions. IMHO we should not touch this
unless it will be officialy supported and known to work without
problems.

Greets,
        Jacek



From jajcus at bnet.pl  Sat Dec 22 15:20:45 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Sat, 22 Dec 2001 15:20:45 +0100
Subject: New wrapper-class ldap.ldapobject.LDAPObject and stripping down _ldap.LDAPObject.c
In-Reply-To: <3C248F3E.D3686257@stroeder.com>
Message-ID: <20011222152044.A3148@nic.bnet.pl>

On Sat, Dec 22, 2001 at 02:48:46PM +0100, Michael Str?der wrote:
> > I have already commited the fixed. I hope there are no more such
> > "typos".
> 
> Any general comments about this approach?

It seems like a very good idea.

Greets,
        Jacek



From david.leonard at itee.uq.edu.au  Sat Dec 22 12:41:13 2001
From: david.leonard at itee.uq.edu.au (David Leonard)
Date: Sat, 22 Dec 2001 21:41:13 +1000 (EST)
Subject: Stripped LDAPObject.c
In-Reply-To: <3C239EFA.6ADA087F@stroeder.com>
Message-ID: <Pine.BSO.4.33.0112222126110.7450-100000@organ.bovingdon-st.fnarg.net.au>


hmmm, i'm not sure if i am completely comfortable with this

are the removed foo_s() functions really handled in the underlying library as a
call to foo() followed by ldap_result()?

i note you left in simple_bind_s() probably because from my reading of
the openldap source code, it shows that some complicated things happen at
the end of it that don't happen in simple_bind() ... i had a quick
skim and couldn't see the others doing much more ...

however, i do see how having a python-level wrapper is a good thing
(allows subclassing, locks, custom tracing)

d

On Fri, 21 Dec 2001, Michael Str?der typed thusly:

> HI!
>
> I've stripped all *_doc strings and almost all *_s() methods from
> LDAPObject.c. Also removed the deprecated Kerberos stuff completely.
>
> _ldap.so was 14kB smaller on my system (comparison after invoking
> strip). I also believe that it will be far easier to maintain the
> module now since there's not so much code subject to e.g. memory
> leaks etc. anymore.
>
> I did not check it in so far although it seems to work for me.
> Please check the attached C source and give feedback. Especially
> review and test the rename() and url_search() methods.
>
> For using all the *_s() methods you will need module
> Lib/ldap/ldapobject.py. So make sure your CVS tree is up-to-date.
>
> Ciao, Michael.

-- 
David Leonard                           David.Leonard at itee.uq.edu.au
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8




From jajcus at bnet.pl  Sat Dec 22 16:20:19 2001
From: jajcus at bnet.pl (Jacek Konieczny)
Date: Sat, 22 Dec 2001 16:20:19 +0100
Subject: Stripped LDAPObject.c
In-Reply-To: <3C24A36B.BFC61AE7@stroeder.com>
Message-ID: <20011222162019.A3594@nic.bnet.pl>

On Sat, Dec 22, 2001 at 04:14:51PM +0100, Michael Str?der wrote:
> Hmm, maybe python-ldap sits on top of the wrong LDAP C lib? We
> currently do not have Win32 support and it's not thread-safe.
> 
> In opposite iPlanet C SDK (see
> http://www.mozilla.org/directory/csdk.html) is known to be
> thread-safe and is available on various platforms. Unfortunately the
> API of the LDAP C SDKs diverged some much that it's unpossible to
> #ifdef the differences. It's a decision for either one of those.

I was looking for some other API, but it seems they all have
weird/commercial licenses. And I wouldn't like to have pay for some
license to use python-ldap.
When I tried to download iPlanet SDK, I was asked to agree to lincense
which allowed me to use it just for 60 days or something.

Greets,
        Jacek



From michael at stroeder.com  Tue Dec 25 16:51:31 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 25 Dec 2001 16:51:31 +0100
Subject: Stripped LDAPObject.c
References: <3C239EFA.6ADA087F@stroeder.com>
Message-ID: <3C28A083.7D7A4FB7@stroeder.com>

Michael Str?der wrote:
> 
> I've stripped all *_doc strings and almost all *_s() methods from
> LDAPObject.c. Also removed the deprecated Kerberos stuff completely.

Since I now hopefully solved all the backwards compability issues
with ldapobject.py I'd like to check in the radically stripped
Modules/LDAPObject.c.

Any objections against that?

Ciao, Michael.



From michael at stroeder.com  Thu Dec 27 10:54:04 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 27 Dec 2001 10:54:04 +0100
Subject: Wrapped ldap_explode_rdn()
Message-ID: <3C2AEFBC.362752A5@stroeder.com>

HI!

in functions.c I've wrapped ldap_explode_rdn().

It works like this:

$ python2.2 
Python 2.2 (#1, Dec 24 2001, 16:35:00) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> import ldap
>>> ldap.explode_rdn('cn=Michael Stroeder+mail=michael at stroeder.com')
['cn=Michael Stroeder', 'mail=michael at stroeder.com']
>>> 

Ciao, Michael.



From michael at stroeder.com  Fri Dec 28 20:17:34 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 28 Dec 2001 20:17:34 +0100
Subject: Python parts of module ldap
References: <3C29E4A8000002CE@hawk.dcu.ie>
Message-ID: <3C2CC54E.C4B6DB89@stroeder.com>

donal.hunt2 at mail.dcu.ie wrote:
> 
> ImportError: /usr/local/lib/libldap.so.2: undefined symbol: res_query

On which system are you building python-ldap?

I believe you have to explicitly link libresolv.
Tweak setup.cfg to contain this line:

libs = lber ldap resolv

Ciao, Michael.



From donal.hunt2 at mail.dcu.ie  Fri Dec 28 18:27:20 2001
From: donal.hunt2 at mail.dcu.ie (donal.hunt2 at mail.dcu.ie)
Date: Fri, 28 Dec 2001 17:27:20 +0000
Subject: Python parts of module ldap
In-Reply-To: <3C1BD044.CF72D72C@stroeder.com>
Message-ID: <3C29E4A8000002CE@hawk.dcu.ie>

Hey there,

I'm having a similar problem at the moment...

OpenLDAP 2.0.18 (openldap-stable-20011102.tgz)
CVS copy of python-ldap (checked out today in the past 4 hours)
Linux box

trying to do a simple open and getting:


From donal.hunt2 at mail.dcu.ie  Sat Dec 29 16:25:56 2001
From: donal.hunt2 at mail.dcu.ie (donal.hunt2 at mail.dcu.ie)
Date: Sat, 29 Dec 2001 15:25:56 +0000
Subject: Python parts of module ldap
In-Reply-To: <3C2CC54E.C4B6DB89@stroeder.com>
Message-ID: <3C29E4A8000003D9@hawk.dcu.ie>

Michael,

System is a Suse Linux install on a S390 VM!

donal at myVMbox:~ > uname -a
Linux myVMbox 2.2.16 #1 SMP Wed Nov 8 10:57:03 GMT 2000 s390 unknown

The tweak below sorted the problem.  Nice one.
Regards

Donal

>-- Original Message --
>Date: Fri, 28 Dec 2001 20:17:34 +0100
>From: Michael Str?der <michael at stroeder.com>
>Reply-To: michael at stroeder.com
>To: donal.hunt2 at mail.dcu.ie
>Cc: python-ldap-dev <python-ldap-dev at lists.sourceforge.net>
>Subject: Re: Python parts of module ldap
>
>
>donal.hunt2 at mail.dcu.ie wrote:
>> 
>> ImportError: /usr/local/lib/libldap.so.2: undefined symbol: res_query
>
>On which system are you building python-ldap?
>
>I believe you have to explicitly link libresolv.
>Tweak setup.cfg to contain this line:
>
>libs = lber ldap resolv
>
>Ciao, Michael.