From michael at stroeder.com  Tue Apr  4 12:16:29 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 04 Apr 2006 12:16:29 +0200
Subject: [PATCH] Plug two leaks in python-ldap
In-Reply-To: <1144143920.763.11.camel@spirit>
References: <1144143920.763.11.camel@spirit>
Message-ID: <4432477D.905@stroeder.com>

Xin LI wrote:
> 
> Here is a patch that corrects two memory leaks in python-ldap.  Tracker
> #1464085.

Thanks for submitting the patch.
Do you have Python code demonstrating the leak?

Do you add the ldap_msgfree(msg) because LDAPmessage_to_python() is not
called in these error cases?

> BTW.  Is there any plan to release a new version soon?

I could release a new version very soon. (Despite that SF sucks and
again I can't contact the CVS repository via SSH at the moment.)

Note that as already stated in CVS version of CHANGES upcoming
python-ldap 2.2.0 will require OpenLDAP libs 2.2.x or later for the build.

Ciao, Michael.



From delphij at delphij.net  Tue Apr  4 12:22:27 2006
From: delphij at delphij.net (Xin LI)
Date: Tue, 04 Apr 2006 18:22:27 +0800
Subject: [PATCH] Plug two leaks in python-ldap
In-Reply-To: <4432477D.905@stroeder.com>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com>
Message-ID: <1144146147.763.15.camel@spirit>

Hi, Michael,

? 2006-04-04?? 12:16 +0200?Michael Str?der???
> Thanks for submitting the patch.
> Do you have Python code demonstrating the leak?

By searching a non-existent entry DN from LDAP server, it would end up
with the error path and got the leak.

> Do you add the ldap_msgfree(msg) because LDAPmessage_to_python() is not
> called in these error cases?

Yes.  It takes me some minutes to figure out that the ldap message was
actually free'ed by LDAPmessage_to_python() in the usual path :-)

> > BTW.  Is there any plan to release a new version soon?
> 
> I could release a new version very soon. (Despite that SF sucks and
> again I can't contact the CVS repository via SSH at the moment.)
> 
> Note that as already stated in CVS version of CHANGES upcoming
> python-ldap 2.2.0 will require OpenLDAP libs 2.2.x or later for the build.

Glad to hear that :-)  Thanks!

Cheers,
-- 
Xin LI <delphij delphij net>    http://www.delphij.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: ???????????
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20060404/7a5f824d/attachment.pgp>

From michael at stroeder.com  Tue Apr  4 12:27:52 2006
From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=)
Date: Tue, 04 Apr 2006 12:27:52 +0200
Subject: Planning python-ldap release 2.2.0
In-Reply-To: <1144146147.763.15.camel@spirit>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com> <1144146147.763.15.camel@spirit>
Message-ID: <44324A28.4030302@stroeder.com>

Xin LI wrote:
> 
>>>BTW.  Is there any plan to release a new version soon?
>>
>>I could release a new version very soon. (Despite that SF sucks and
>>again I can't contact the CVS repository via SSH at the moment.)
>>
>>Note that as already stated in CVS version of CHANGES upcoming
>>python-ldap 2.2.0 will require OpenLDAP libs 2.2.x or later for the build.
> 
> Glad to hear that :-)  Thanks!

How soon would you need a new release version in your project?

Anyone else on the list should comment now(!) about the new requirement
for OpenLDAP libs 2.2.

Ciao, Michael.




From michael at stroeder.com  Tue Apr  4 12:28:37 2006
From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=)
Date: Tue, 04 Apr 2006 12:28:37 +0200
Subject: [PATCH] Plug two leaks in python-ldap
In-Reply-To: <1144146147.763.15.camel@spirit>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com> <1144146147.763.15.camel@spirit>
Message-ID: <44324A55.3080303@stroeder.com>

Xin LI wrote:
> 
> 12:16 +0200?Michael Str?der?
> 
>>Thanks for submitting the patch.
>>Do you have Python code demonstrating the leak?
> 
> By searching a non-existent entry DN from LDAP server, it would end up
> with the error path and got the leak.
> 
>>Do you add the ldap_msgfree(msg) because LDAPmessage_to_python() is not
>>called in these error cases?
> 
> Yes.  It takes me some minutes to figure out that the ldap message was
> actually free'ed by LDAPmessage_to_python() in the usual path :-)

Ok, will commit your patch ASAP.

Ciao, Michael.




From michael at stroeder.com  Tue Apr  4 12:16:29 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 04 Apr 2006 12:16:29 +0200
Subject: [PATCH] Plug two leaks in python-ldap
In-Reply-To: <1144143920.763.11.camel@spirit>
References: <1144143920.763.11.camel@spirit>
Message-ID: <4432477D.905@stroeder.com>

Xin LI wrote:
> 
> Here is a patch that corrects two memory leaks in python-ldap.  Tracker
> #1464085.

Thanks for submitting the patch.
Do you have Python code demonstrating the leak?

Do you add the ldap_msgfree(msg) because LDAPmessage_to_python() is not
called in these error cases?

> BTW.  Is there any plan to release a new version soon?

I could release a new version very soon. (Despite that SF sucks and
again I can't contact the CVS repository via SSH at the moment.)

Note that as already stated in CVS version of CHANGES upcoming
python-ldap 2.2.0 will require OpenLDAP libs 2.2.x or later for the build.

Ciao, Michael.





From jens at dataflake.org  Tue Apr  4 12:43:44 2006
From: jens at dataflake.org (Jens Vagelpohl)
Date: Tue, 4 Apr 2006 11:43:44 +0100
Subject: Planning python-ldap release 2.2.0
In-Reply-To: <44324A28.4030302@stroeder.com>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com> <1144146147.763.15.camel@spirit> <44324A28.4030302@stroeder.com>
Message-ID: <7DC99BC2-0713-45B5-96C1-E57599DC5E62@dataflake.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 4 Apr 2006, at 11:27, Michael Str?der wrote:
>>> Note that as already stated in CVS version of CHANGES upcoming
>>> python-ldap 2.2.0 will require OpenLDAP libs 2.2.x or later for  
>>> the build.
>>
>> Glad to hear that :-)  Thanks!
>
> How soon would you need a new release version in your project?
>
> Anyone else on the list should comment now(!) about the new  
> requirement
> for OpenLDAP libs 2.2.

I have no problem with it.

You'll probably end up with more support questions, though, because  
this requirement shuts out people on RH9/RHEL3/FC3 and earlier who  
use the distribution-provided OpenLDAP.

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEMk3gRAx5nvEhZLIRAgNlAJ9ihSDHwO11MEoSRJh2rocRWdpQvQCguUgl
Fp9U8/1waBJo3tZpAFPnQ7g=
=QwLk
-----END PGP SIGNATURE-----




From jens at dataflake.org  Tue Apr  4 12:55:45 2006
From: jens at dataflake.org (Jens Vagelpohl)
Date: Tue, 4 Apr 2006 11:55:45 +0100
Subject: Planning python-ldap release 2.2.0
In-Reply-To: <44324F60.5090009@stroeder.com>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com> <1144146147.763.15.camel@spirit> <44324A28.4030302@stroeder.com> <7DC99BC2-0713-45B5-96C1-E57599DC5E62@dataflake.org> <44324F60.5090009@stroeder.com>
Message-ID: <E47733D9-3074-464A-89D6-1E1B73D0E1D2@dataflake.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 4 Apr 2006, at 11:50, Michael Str?der wrote:

> Jens Vagelpohl wrote:
>>>> Anyone else on the list should comment now(!) about the new   
>>>> requirement
>>>> for OpenLDAP libs 2.2.
>>
>> I have no problem with it.
>>
>> You'll probably end up with more support questions, though, because
>> this requirement shuts out people on RH9/RHEL3/FC3 and earlier  
>> who  use
>> the distribution-provided OpenLDAP.
>
> Yes, I expect these people to request support for OpenLDAP 2.0.x. But
> people not willing to use a C compiler probably will have to stick to
> older python-ldap releases anyway. ;-)

Yes, absolutely, I just fear those people who have this irrational  
urge to upgrade just for upgrading's sake if something new is  
released, and a lot of them don't like answers such as "If you're on  
OL 2.0.27, please use python-ldap versions <= 2.0.10 because the  
newest versions won't run against your antique OpenLDAP". :P

jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEMlCyRAx5nvEhZLIRAlcEAJ9qkLi35DctFo9MZzjwK+zs/ZqI3gCgkm9V
klufummU/drZLg/YKMvm8xY=
=oajH
-----END PGP SIGNATURE-----




From michael at stroeder.com  Tue Apr  4 12:50:08 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 04 Apr 2006 12:50:08 +0200
Subject: Planning python-ldap release 2.2.0
In-Reply-To: <7DC99BC2-0713-45B5-96C1-E57599DC5E62@dataflake.org>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com> <1144146147.763.15.camel@spirit> <44324A28.4030302@stroeder.com> <7DC99BC2-0713-45B5-96C1-E57599DC5E62@dataflake.org>
Message-ID: <44324F60.5090009@stroeder.com>

Jens Vagelpohl wrote:
>>> Anyone else on the list should comment now(!) about the new  requirement
>>> for OpenLDAP libs 2.2.
> 
> I have no problem with it.
> 
> You'll probably end up with more support questions, though, because 
> this requirement shuts out people on RH9/RHEL3/FC3 and earlier who  use
> the distribution-provided OpenLDAP.

Yes, I expect these people to request support for OpenLDAP 2.0.x. But
people not willing to use a C compiler probably will have to stick to
older python-ldap releases anyway. ;-)

Ciao, Michael.




From delphij at delphij.net  Tue Apr  4 13:31:02 2006
From: delphij at delphij.net (Xin LI)
Date: Tue, 04 Apr 2006 19:31:02 +0800
Subject: Planning python-ldap release 2.2.0
In-Reply-To: <44324A28.4030302@stroeder.com>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com>
	 <1144146147.763.15.camel@spirit>  <44324A28.4030302@stroeder.com>
Message-ID: <1144150262.763.23.camel@spirit>

? 2006-04-04?? 12:27 +0200?Michael Str?der???
> Xin LI wrote:
> > 
> >>>BTW.  Is there any plan to release a new version soon?
> >>
> >>I could release a new version very soon. (Despite that SF sucks and
> >>again I can't contact the CVS repository via SSH at the moment.)
> >>
> >>Note that as already stated in CVS version of CHANGES upcoming
> >>python-ldap 2.2.0 will require OpenLDAP libs 2.2.x or later for the build.
> > 
> > Glad to hear that :-)  Thanks!
> 
> How soon would you need a new release version in your project?

It's kind of you, Michael.  For my own project it's not an urgent need
as I can deploy patched version to fulfill my need, but I would happy to
see if you guys would release a new release, so we can update the
FreeBSD port (currently it's 2.0.10) without adding "local patchset" to
the FreeBSD ports repository.

Cheers,
-- 
Xin LI <delphij delphij net>    http://www.delphij.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: ???????????
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20060404/761686c5/attachment.pgp>

From michael at stroeder.com  Tue Apr  4 12:50:08 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 04 Apr 2006 12:50:08 +0200
Subject: Planning python-ldap release 2.2.0
In-Reply-To: <7DC99BC2-0713-45B5-96C1-E57599DC5E62@dataflake.org>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com> <1144146147.763.15.camel@spirit> <44324A28.4030302@stroeder.com> <7DC99BC2-0713-45B5-96C1-E57599DC5E62@dataflake.org>
Message-ID: <44324F60.5090009@stroeder.com>

Jens Vagelpohl wrote:
>>> Anyone else on the list should comment now(!) about the new  requirement
>>> for OpenLDAP libs 2.2.
> 
> I have no problem with it.
> 
> You'll probably end up with more support questions, though, because 
> this requirement shuts out people on RH9/RHEL3/FC3 and earlier who  use
> the distribution-provided OpenLDAP.

Yes, I expect these people to request support for OpenLDAP 2.0.x. But
people not willing to use a C compiler probably will have to stick to
older python-ldap releases anyway. ;-)

Ciao, Michael.


From michael at stroeder.com  Tue Apr  4 12:28:37 2006
From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=)
Date: Tue, 04 Apr 2006 12:28:37 +0200
Subject: [PATCH] Plug two leaks in python-ldap
In-Reply-To: <1144146147.763.15.camel@spirit>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com> <1144146147.763.15.camel@spirit>
Message-ID: <44324A55.3080303@stroeder.com>

Xin LI wrote:
> 
> 12:16 +0200?Michael Str?der?
> 
>>Thanks for submitting the patch.
>>Do you have Python code demonstrating the leak?
> 
> By searching a non-existent entry DN from LDAP server, it would end up
> with the error path and got the leak.
> 
>>Do you add the ldap_msgfree(msg) because LDAPmessage_to_python() is not
>>called in these error cases?
> 
> Yes.  It takes me some minutes to figure out that the ldap message was
> actually free'ed by LDAPmessage_to_python() in the usual path :-)

Ok, will commit your patch ASAP.

Ciao, Michael.


From michael at stroeder.com  Tue Apr  4 12:27:52 2006
From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=)
Date: Tue, 04 Apr 2006 12:27:52 +0200
Subject: Planning python-ldap release 2.2.0
In-Reply-To: <1144146147.763.15.camel@spirit>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com> <1144146147.763.15.camel@spirit>
Message-ID: <44324A28.4030302@stroeder.com>

Xin LI wrote:
> 
>>>BTW.  Is there any plan to release a new version soon?
>>
>>I could release a new version very soon. (Despite that SF sucks and
>>again I can't contact the CVS repository via SSH at the moment.)
>>
>>Note that as already stated in CVS version of CHANGES upcoming
>>python-ldap 2.2.0 will require OpenLDAP libs 2.2.x or later for the build.
> 
> Glad to hear that :-)  Thanks!

How soon would you need a new release version in your project?

Anyone else on the list should comment now(!) about the new requirement
for OpenLDAP libs 2.2.

Ciao, Michael.


From michael at stroeder.com  Thu Apr  6 00:45:04 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 06 Apr 2006 00:45:04 +0200
Subject: [PATCH] Plug two leaks in python-ldap
In-Reply-To: <1144143920.763.11.camel@spirit>
References: <1144143920.763.11.camel@spirit>
Message-ID: <44344870.50802@stroeder.com>

Xin LI wrote:
> 
> Here is a patch that corrects two memory leaks in python-ldap.  Tracker
> #1464085.

I've committed this patch. Not sure when it will appear in anon CVS
since SF has some problems with CVS service.

Ciao, Michael.



From michael at stroeder.com  Thu Apr  6 06:58:04 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 06 Apr 2006 06:58:04 +0200
Subject: PEP 353 - preparation for Python 2.5
Message-ID: <44349FDC.3010201@stroeder.com>

HI!

I'm very short on spare time at the moment.

Could someone please check python-ldap to support PEP 353 (see
http://www.python.org/dev/peps/pep-0353/) and create a patch for the
changes required?

See also:

http://groups.google.com/group/comp.lang.python/tree/browse_frm/thread/7e55ac8f0ca175a0/69951264453fdfb2?rnum=1&_done=%2Fgroup%2Fcomp.lang.python%2Fbrowse_frm%2Fthread%2F7e55ac8f0ca175a0%2F69951264453fdfb2%3F#doc_69951264453fdfb2

http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py

Many thanks in advance.

Ciao, Michael.


From delphij at delphij.net  Tue Apr  4 12:22:27 2006
From: delphij at delphij.net (Xin LI)
Date: Tue, 04 Apr 2006 18:22:27 +0800
Subject: [PATCH] Plug two leaks in python-ldap
In-Reply-To: <4432477D.905@stroeder.com>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com>
Message-ID: <1144146147.763.15.camel@spirit>

Hi, Michael,

? 2006-04-04?? 12:16 +0200?Michael Str?der???
> Thanks for submitting the patch.
> Do you have Python code demonstrating the leak?

By searching a non-existent entry DN from LDAP server, it would end up
with the error path and got the leak.

> Do you add the ldap_msgfree(msg) because LDAPmessage_to_python() is not
> called in these error cases?

Yes.  It takes me some minutes to figure out that the ldap message was
actually free'ed by LDAPmessage_to_python() in the usual path :-)

> > BTW.  Is there any plan to release a new version soon?
> 
> I could release a new version very soon. (Despite that SF sucks and
> again I can't contact the CVS repository via SSH at the moment.)
> 
> Note that as already stated in CVS version of CHANGES upcoming
> python-ldap 2.2.0 will require OpenLDAP libs 2.2.x or later for the build.

Glad to hear that :-)  Thanks!

Cheers,
-- 
Xin LI <delphij delphij net>    http://www.delphij.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: ???????????
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20060404/7a5f824d/attachment-0001.pgp>

From pkoelle at gmail.com  Tue Apr  4 13:53:49 2006
From: pkoelle at gmail.com (=?ISO-8859-1?Q?Paul_K=F6lle?=)
Date: Tue, 04 Apr 2006 13:53:49 +0200
Subject: Planning python-ldap release 2.2.0
In-Reply-To: <E47733D9-3074-464A-89D6-1E1B73D0E1D2@dataflake.org>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com> <1144146147.763.15.camel@spirit> <44324A28.4030302@stroeder.com> <7DC99BC2-0713-45B5-96C1-E57599DC5E62@dataflake.org> <44324F60.5090009@stroeder.com> <E47733D9-3074-464A-89D6-1E1B73D0E1D2@dataflake.org>
Message-ID: <44325E4D.6020104@gmail.com>

Jens Vagelpohl wrote:
> 
> On 4 Apr 2006, at 11:50, Michael Str?der wrote:
>>> Yes, I expect these people to request support for OpenLDAP 2.0.x. But
>>> people not willing to use a C compiler probably will have to stick to
>>> older python-ldap releases anyway. ;-)
> 
> Yes, absolutely, I just fear those people who have this irrational urge
> to upgrade just for upgrading's sake if something new is released, and a
> lot of them don't like answers such as "If you're on OL 2.0.27, please
> use python-ldap versions <= 2.0.10 because the newest versions won't run
> against your antique OpenLDAP". :P
> 
> jens
Let's hope that the "irrational urge to upgrade" will solve the OL 2.0.x
issue for them as well.

cheers
 Paul







From delphij at delphij.net  Tue Apr  4 13:31:02 2006
From: delphij at delphij.net (Xin LI)
Date: Tue, 04 Apr 2006 19:31:02 +0800
Subject: Planning python-ldap release 2.2.0
In-Reply-To: <44324A28.4030302@stroeder.com>
References: <1144143920.763.11.camel@spirit>  <4432477D.905@stroeder.com>
	 <1144146147.763.15.camel@spirit>  <44324A28.4030302@stroeder.com>
Message-ID: <1144150262.763.23.camel@spirit>

? 2006-04-04?? 12:27 +0200?Michael Str?der???
> Xin LI wrote:
> > 
> >>>BTW.  Is there any plan to release a new version soon?
> >>
> >>I could release a new version very soon. (Despite that SF sucks and
> >>again I can't contact the CVS repository via SSH at the moment.)
> >>
> >>Note that as already stated in CVS version of CHANGES upcoming
> >>python-ldap 2.2.0 will require OpenLDAP libs 2.2.x or later for the build.
> > 
> > Glad to hear that :-)  Thanks!
> 
> How soon would you need a new release version in your project?

It's kind of you, Michael.  For my own project it's not an urgent need
as I can deploy patched version to fulfill my need, but I would happy to
see if you guys would release a new release, so we can update the
FreeBSD port (currently it's 2.0.10) without adding "local patchset" to
the FreeBSD ports repository.

Cheers,
-- 
Xin LI <delphij delphij net>    http://www.delphij.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: ???????????
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20060404/761686c5/attachment-0001.pgp>

From michael at stroeder.com  Sat Apr  8 20:44:09 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Sat, 08 Apr 2006 20:44:09 +0200
Subject: FYI: python-ldap and web2ldap at OpenLDAP booth, Linuxtag 2006
Message-ID: <44380479.7050401@stroeder.com>

HI!

once again OpenLDAP will be presented by a team of volunteers

  at Linuxtag 2006
  in Wiesbaden, Germany
  from Wednesday, 2006-05-03
  until Saturday, 2006-05-06

  http://www.linuxtag.org/2006/

Several deployment scenarios based on OpenLDAP will be demonstrated with
various LDAP clients.

I will also present web2ldap and answer questions about python-ldap too.
I'd be glad to meet members of the community personally there.

See you at booth #11 in hall no. 9!

Ciao, Michael.

-- 
Michael Str?der
E-Mail: michael at stroeder.com
http://www.stroeder.com



From TimurIzhbulatov at oilspace.com  Wed Apr 12 14:29:25 2006
From: TimurIzhbulatov at oilspace.com (Timur Izhbulatov)
Date: Wed, 12 Apr 2006 16:29:25 +0400
Subject: python-ldap
In-Reply-To: <4436317C.1000409@stroeder.com>
References: <20060406234905.GA14503@oilspace.com> <4436317C.1000409@stroeder.com>
Message-ID: <20060412122925.GA1100@oilspace.com>

Michael,

Thanks for answering!

On Fri, Apr 07, 2006 at 11:31:40AM +0200, Michael Str?der wrote:
> Timur Izhbulatov wrote:

> > Also I would like to ask you to pay your attention to the issue I reported some
> > time ago:
> > http://sourceforge.net/tracker/index.php?func=detail&aid=1440151&group_id=2072&atid=102072.

> So if it's urgent for you to get your issue done I'd like to encourage
> you to submit a patch. Even if your patch is not perfect this makes it
> easier for me to start working on it.

My patch for HEAD is attached. And, yes, it's not perfect, just a quick fix. For
example the ldap.ldapobject.SimpleLDAPObject.passwd method still doesn't return
server generated password if the newpw argument is omitted.

> Maybe your requirement could be solved in the Python wrapper module
> ldap.ldapobject. Not sure about it though.

Not only in ldap.ldapobject. The problem is also in Modules/LDAPObject.c: l_ldap_passwd

> Please, stay tuned to the python-ldap-dev mailing list. I'm reading it
> and will answer there. Maybe someone else on the list feels like taking
> over the task.

For those who are interested. More details can be found in my previous report:
http://sourceforge.net/mailarchive/forum.php?thread_id=9546124&forum_id=4346

Cheers,

-- 
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:TimurIzhbulatov at oilspace.com
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com
-------------- next part --------------
diff -urN python-ldap.orig/Lib/ldap/ldapobject.py python-ldap/Lib/ldap/ldapobject.py
--- python-ldap.orig/Lib/ldap/ldapobject.py	2006-04-12 15:41:48.000000000 +0400
+++ python-ldap/Lib/ldap/ldapobject.py	2006-04-12 15:45:57.000000000 +0400
@@ -323,10 +323,10 @@
   def modrdn_s(self,dn,newrdn,delold=1):
     return self.rename_s(dn,newrdn,None,delold)
 
-  def passwd(self,user,oldpw,newpw,serverctrls=None,clientctrls=None):
+  def passwd(self,user=None,oldpw=None,newpw=None,serverctrls=None,clientctrls=None):
     return self._ldap_call(self._l.passwd,user,oldpw,newpw,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls))
 
-  def passwd_s(self,user,oldpw,newpw,serverctrls=None,clientctrls=None):
+  def passwd_s(self,user=None,oldpw=None,newpw=None,serverctrls=None,clientctrls=None):
     msgid = self.passwd(user,oldpw,newpw,serverctrls,clientctrls)
     return self.result(msgid,all=1,timeout=self.timeout)
 
diff -urN python-ldap.orig/Modules/LDAPObject.c python-ldap/Modules/LDAPObject.c
--- python-ldap.orig/Modules/LDAPObject.c	2006-04-12 15:41:48.000000000 +0400
+++ python-ldap/Modules/LDAPObject.c	2006-04-12 15:43:22.000000000 +0400
@@ -1177,7 +1177,7 @@
     int msgid;
     int ldaperror;
 
-    if (!PyArg_ParseTuple( args, "s#s#s#|OO", &user.bv_val, &user_len, &oldpw.bv_val, &oldpw_len, &newpw.bv_val, &newpw_len, &serverctrls, &clientctrls ))
+    if (!PyArg_ParseTuple( args, "|z#z#z#OO", &user.bv_val, &user_len, &oldpw.bv_val, &oldpw_len, &newpw.bv_val, &newpw_len, &serverctrls, &clientctrls ))
     	return NULL;
 
     user.bv_len = (ber_len_t) user_len;
@@ -1199,7 +1199,13 @@
     }
 
     LDAP_BEGIN_ALLOW_THREADS( self );
-    ldaperror = ldap_passwd( self->ldap, &user, &oldpw, &newpw, server_ldcs, client_ldcs, &msgid );
+    ldaperror = ldap_passwd( self->ldap,
+            user.bv_val != NULL ? &user : NULL,
+            oldpw.bv_val != NULL ? &oldpw : NULL,
+            newpw.bv_val != NULL ? &newpw : NULL,
+            server_ldcs,
+            client_ldcs,
+            &msgid );
     LDAP_END_ALLOW_THREADS( self );
     
     LDAPControl_List_DEL( server_ldcs );

From michael at stroeder.com  Thu Apr 13 19:47:05 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 13 Apr 2006 19:47:05 +0200
Subject: ldap_passwd.diff
In-Reply-To: <20060412122925.GA1100@oilspace.com>
References: <20060406234905.GA14503@oilspace.com> <4436317C.1000409@stroeder.com> <20060412122925.GA1100@oilspace.com>
Message-ID: <443E8E99.8050106@stroeder.com>

Timur Izhbulatov wrote:
> 
> On Fri, Apr 07, 2006 at 11:31:40AM +0200, Michael Str?der wrote:
> 
>>Timur Izhbulatov wrote:
> 
>>>Also I would like to ask you to pay your attention to the issue I reported some
>>>time ago:
>>>http://sourceforge.net/tracker/index.php?func=detail&aid=1440151&group_id=2072&atid=102072.
> 
>>So if it's urgent for you to get your issue done I'd like to encourage
>>you to submit a patch. Even if your patch is not perfect this makes it
>>easier for me to start working on it.
> 
> My patch for HEAD is attached. And, yes, it's not perfect, just a quick fix. For
> example the ldap.ldapobject.SimpleLDAPObject.passwd method still doesn't return
> server generated password if the newpw argument is omitted.

Timur, thanks for your patch.

1. As long as returning a server-generated password is not implemented
it does not make sense to make newpw optional and/or accept None as value.

2. Personally I'd like avoid to turn arguments user,oldpw,newpw of
passwd() into optional key-word arguments (and we can't do that for only
user and oldpw, see 1.). I'd rather prefer the application developer to
really know what he's doing. But I'm open to other opinions.

> For those who are interested. More details can be found in my previous report:
> http://sourceforge.net/mailarchive/forum.php?thread_id=9546124&forum_id=4346

Ciao, Michael.




From TimurIzhbulatov at oilspace.com  Fri Apr 14 13:15:40 2006
From: TimurIzhbulatov at oilspace.com (Timur Izhbulatov)
Date: Fri, 14 Apr 2006 15:15:40 +0400
Subject: ldap_passwd.diff
In-Reply-To: <443E8E99.8050106@stroeder.com>
References: <20060406234905.GA14503@oilspace.com> <4436317C.1000409@stroeder.com> <20060412122925.GA1100@oilspace.com> <443E8E99.8050106@stroeder.com>
Message-ID: <20060414111540.GA18973@oilspace.com>

On Thu, Apr 13, 2006 at 07:47:05PM +0200, Michael Str?der wrote:
> Timur, thanks for your patch.
> 
> 1. As long as returning a server-generated password is not implemented
> it does not make sense to make newpw optional and/or accept None as value.

Agree. I just blindly followed the RFC.

> 2. Personally I'd like avoid to turn arguments user,oldpw,newpw of
> passwd() into optional key-word arguments (and we can't do that for only
> user and oldpw, see 1.). I'd rather prefer the application developer to
> really know what he's doing. But I'm open to other opinions.

In this case the application developer won't be able to do some important
things. For example, changing other users's passwords will be impossible even if
tha application is bound with root DN.

And if you really don't like changing the passwd() method I suggest adding new
method or overriding the existing on in subclass. Of course, this implies my
patch for LDAPObject.c.

WDYT?

-- 
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:TimurIzhbulatov at oilspace.com
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com




From michael at stroeder.com  Sun Apr 16 12:46:44 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Sun, 16 Apr 2006 12:46:44 +0200
Subject: ldap_passwd.diff
In-Reply-To: <20060414111540.GA18973@oilspace.com>
References: <20060406234905.GA14503@oilspace.com> <4436317C.1000409@stroeder.com> <20060412122925.GA1100@oilspace.com> <443E8E99.8050106@stroeder.com> <20060414111540.GA18973@oilspace.com>
Message-ID: <44422094.5080608@stroeder.com>

Timur Izhbulatov wrote:
> On Thu, Apr 13, 2006 at 07:47:05PM +0200, Michael Str?der wrote:
> 
>>1. As long as returning a server-generated password is not implemented
>>it does not make sense to make newpw optional and/or accept None as value.
> 
> Agree. I just blindly followed the RFC.

If we can't make newpw an optional key-word argument we also can't make
user and oldpw to optional key-word arguments.

>>2. Personally I'd like avoid to turn arguments user,oldpw,newpw of
>>passwd() into optional key-word arguments (and we can't do that for only
>>user and oldpw, see 1.). I'd rather prefer the application developer to
>>really know what he's doing. But I'm open to other opinions.
> 
> In this case the application developer won't be able to do some important
> things. For example, changing other users's passwords will be impossible even if
> tha application is bound with root DN.

The developer could simply pass value None to passwd() for user and oldpw.

Ciao, Michael.


From TimurIzhbulatov at oilspace.com  Sun Apr 16 14:24:07 2006
From: TimurIzhbulatov at oilspace.com (Timur Izhbulatov)
Date: Sun, 16 Apr 2006 16:24:07 +0400
Subject: ldap_passwd.diff
In-Reply-To: <44422094.5080608@stroeder.com>
References: <20060406234905.GA14503@oilspace.com> <4436317C.1000409@stroeder.com> <20060412122925.GA1100@oilspace.com> <443E8E99.8050106@stroeder.com> <20060414111540.GA18973@oilspace.com> <44422094.5080608@stroeder.com>
Message-ID: <20060416122407.GA5436@oilspace.com>

On Sun, Apr 16, 2006 at 12:46:44PM +0200, Michael Str?der wrote:
> Timur Izhbulatov wrote:
> > On Thu, Apr 13, 2006 at 07:47:05PM +0200, Michael Str?der wrote:
> > 
> >>1. As long as returning a server-generated password is not implemented
> >>it does not make sense to make newpw optional and/or accept None as value.
> > 
> > Agree. I just blindly followed the RFC.
> 
> If we can't make newpw an optional key-word argument we also can't make
> user and oldpw to optional key-word arguments.

Yes, now I see. At this moment there is no point in making any of the
arguments optional.

> >>2. Personally I'd like avoid to turn arguments user,oldpw,newpw of
> >>passwd() into optional key-word arguments (and we can't do that for only
> >>user and oldpw, see 1.). I'd rather prefer the application developer to
> >>really know what he's doing. But I'm open to other opinions.
> > 
> > In this case the application developer won't be able to do some important
> > things. For example, changing other users's passwords will be impossible even if
> > tha application is bound with root DN.
> 
> The developer could simply pass value None to passwd() for user and oldpw.

Passing None is OK as long as l_ldap_passwd() allows this. So I suggest applying
my changes only to Modules/LDAPObject.c.

Cheers,

-- 
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:TimurIzhbulatov at oilspace.com
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com


From michael at stroeder.com  Tue Apr 18 13:18:08 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 18 Apr 2006 13:18:08 +0200
Subject: ldap_passwd.diff
In-Reply-To: <20060416122407.GA5436@oilspace.com>
References: <20060406234905.GA14503@oilspace.com> <4436317C.1000409@stroeder.com> <20060412122925.GA1100@oilspace.com> <443E8E99.8050106@stroeder.com> <20060414111540.GA18973@oilspace.com> <44422094.5080608@stroeder.com> <20060416122407.GA5436@oilspace.com>
Message-ID: <4444CAF0.70409@stroeder.com>

Timur Izhbulatov wrote:
> On Sun, Apr 16, 2006 at 12:46:44PM +0200, Michael Str?der wrote:
> 
>>Timur Izhbulatov wrote:
>>
>>>On Thu, Apr 13, 2006 at 07:47:05PM +0200, Michael Str?der wrote:
>>>
>>>>2. Personally I'd like avoid to turn arguments user,oldpw,newpw of
>>>>passwd() into optional key-word arguments (and we can't do that for only
>>>>user and oldpw, see 1.). I'd rather prefer the application developer to
>>>>really know what he's doing. But I'm open to other opinions.
>>>
>>>In this case the application developer won't be able to do some important
>>>things. For example, changing other users's passwords will be impossible even if
>>>tha application is bound with root DN.
>>
>>The developer could simply pass value None to passwd() for user and oldpw.
> 
> Passing None is OK as long as l_ldap_passwd() allows this. So I suggest applying
> my changes only to Modules/LDAPObject.c.

Ok, I've committed the patch below. Please test.

Ciao, Michael

Index: Modules/LDAPObject.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/LDAPObject.c,v
retrieving revision 1.74
diff -u -r1.74 LDAPObject.c
--- Modules/LDAPObject.c        5 Apr 2006 22:40:14 -0000       1.74
+++ Modules/LDAPObject.c        18 Apr 2006 11:12:24 -0000
@@ -1179,7 +1179,7 @@
     int msgid;
     int ldaperror;

-    if (!PyArg_ParseTuple( args, "s#s#s#|OO", &user.bv_val, &user_len,
&oldpw.bv_val, &oldpw_len, &newpw.bv_val, &newpw_len, &serverctrls,
&clientctrls ))
+    if (!PyArg_ParseTuple( args, "z#z#z#|OO", &user.bv_val, &user_len,
&oldpw.bv_val, &oldpw_len, &newpw.bv_val, &newpw_len, &serverctrls,
&clientctrls ))
        return NULL;

     user.bv_len = (ber_len_t) user_len;
@@ -1201,7 +1201,13 @@
     }

     LDAP_BEGIN_ALLOW_THREADS( self );
-    ldaperror = ldap_passwd( self->ldap, &user, &oldpw, &newpw,
server_ldcs, client_ldcs, &msgid );
+    ldaperror = ldap_passwd( self->ldap,
+            user.bv_val != NULL ? &user : NULL,
+            oldpw.bv_val != NULL ? &oldpw : NULL,
+            newpw.bv_val != NULL ? &newpw : NULL,
+            server_ldcs,
+            client_ldcs,
+            &msgid );
     LDAP_END_ALLOW_THREADS( self );

     LDAPControl_List_DEL( server_ldcs );




From TimurIzhbulatov at oilspace.com  Wed Apr 19 08:50:48 2006
From: TimurIzhbulatov at oilspace.com (Timur Izhbulatov)
Date: Wed, 19 Apr 2006 10:50:48 +0400
Subject: ldap_passwd.diff
In-Reply-To: <4444CAF0.70409@stroeder.com>
References: <20060406234905.GA14503@oilspace.com> <4436317C.1000409@stroeder.com> <20060412122925.GA1100@oilspace.com> <443E8E99.8050106@stroeder.com> <20060414111540.GA18973@oilspace.com> <44422094.5080608@stroeder.com> <20060416122407.GA5436@oilspace.com> <4444CAF0.70409@stroeder.com>
Message-ID: <20060419065048.GA20766@oilspace.com>

On Tue, Apr 18, 2006 at 01:18:08PM +0200, Michael Str?der wrote:
> Ok, I've committed the patch below. Please test.

It is working. Thank you!

-- 
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:TimurIzhbulatov at oilspace.com
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com


From michael at stroeder.com  Sat Apr 29 18:53:32 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Sat, 29 Apr 2006 18:53:32 +0200
Subject: python-ldap, compare_s() return only true in all cases
In-Reply-To: <44527969.8050405@gentoo-br.org>
References: <44527969.8050405@gentoo-br.org>
Message-ID: <44539A0C.3000708@stroeder.com>

Fernando Ribeiro wrote:
> 
>    I'm studing the python, and begin with python-ldap. But i have a
> little problem with ldap.compare_s(dn, attr, value) function.

Please subscribe and post to python-ldap-dev list (Cc:-ed).

https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

>    While using ldap_slave.compare_s("dc=domain,dc=com,dc=br",
> "objectClass", "top");
>    It return true.
>    But look in ldap_slave don't have the 'objectClass: top'.

Every structural object class is implicitly derived from 'top'. So I'd
expect this to evaluate to True each time.

What exactly are you trying to achieve?

Could you please verify with another attribute?

Ciao, Michael.


From fernando at gentoo-br.org  Sun Apr 30 13:55:41 2006
From: fernando at gentoo-br.org (Fernando Ribeiro)
Date: Sun, 30 Apr 2006 08:55:41 -0300
Subject: python-ldap, compare_s() return only true in all cases
In-Reply-To: <44539A0C.3000708@stroeder.com>
References: <44527969.8050405@gentoo-br.org> <44539A0C.3000708@stroeder.com>
Message-ID: <4454A5BD.3080500@gentoo-br.org>

Hi Michael,

Michael Str?der wrote:
> Fernando Ribeiro wrote:
>   
>>    I'm studing the python, and begin with python-ldap. But i have a
>> little problem with ldap.compare_s(dn, attr, value) function.
>>     
>
> Please subscribe and post to python-ldap-dev list (Cc:-ed).
>
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>
>   
subscribed, thanks.
>>    While using ldap_slave.compare_s("dc=domain,dc=com,dc=br",
>> "objectClass", "top");
>>    It return true.
>>    But look in ldap_slave don't have the 'objectClass: top'.
>>     
>
> Every structural object class is implicitly derived from 'top'. So I'd
> expect this to evaluate to True each time.
>   
It return true to all objectClasses.
With others atribute (except objectClass) it work fine.
I have tested with C too, and it return the same result.
Its "ignoring" the objectClass to compare.

> What exactly are you trying to achieve?
>
> Could you please verify with another attribute?
>
> Ciao, Michael.
>
>   
    Exists other way to compare entries?

    Thank you a million by attention.


Best Regards,
Fernando Ribeiro

-- 
--------------------------------------------------
- Fernando Ribeiro - GPG-KEY: 0x8D7255F4
- Linux Counter: #273768 - ICQ: 175630330
- RHCE - Red Hat Certified Engineer
- LPIC-2 - Advanced Linux
- CCSA - CheckPoint Cert. Security Admin.
- phone: +55 61 9115 4852
- http://www.musb.org
--------------------------------------------------
Firthunands (firthu quer dizer "paz", nands
significa audaz. Dessa maneira, a tradu??o seria:
"Aquele que se atreve a tudo para conservar a Paz"


From michael at stroeder.com  Mon May  1 12:29:59 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 01 May 2006 12:29:59 +0200
Subject: python-ldap, compare_s() return only true in all cases
In-Reply-To: <4454A5BD.3080500@gentoo-br.org>
References: <44527969.8050405@gentoo-br.org> <44539A0C.3000708@stroeder.com> <4454A5BD.3080500@gentoo-br.org>
Message-ID: <4455E327.3080000@stroeder.com>

Fernando Ribeiro wrote:
> 
>>>    While using ldap_slave.compare_s("dc=domain,dc=com,dc=br",
>>> "objectClass", "top");
>>>    It return true.
>>>    But look in ldap_slave don't have the 'objectClass: top'.
>>
>> Every structural object class is implicitly derived from 'top'. So I'd
>> expect this to evaluate to True each time.
> 
> It return true to all objectClasses.
> With others atribute (except objectClass) it work fine.
> I have tested with C too, and it return the same result.

Can you please post the LDAP filter strings you tested with?

Can you reproduce the same results with OpenLDAP's command-line tool
ldapcompare? If yes, please discuss the question on the
OpenLDAP-Software mailing list (see http://www.openldap.org/lists/)
detailing your tests.

>    Exists other way to compare entries?

What exactly do you mean with comparing entries? Please describe in
slightly more detail what you are trying to achieve.

You can off course simply retrieve entries with a search request and
compare attributes in your Python application.

Ciao, Michael.


From sysadmin at meteo.mcgill.ca  Thu Jun  1 21:21:35 2006
From: sysadmin at meteo.mcgill.ca (Marc Lanctot)
Date: Thu, 01 Jun 2006 15:21:35 -0400
Subject: Simple test failing
Message-ID: <447F3E3F.1000704@meteo.mcgill.ca>

Hello,

I'm trying to get pykota working with LDAP and running into problems 
connecting to the LDAP server.

So, using the code I found on the website I ran testldap.py (see 
attached), and the output I get is:

tsunami:~ # ./testldap.py
Traceback (most recent call last):
   File "./testldap.py", line 18, in ?
     l.simple_bind(username, password)
   File "/usr/lib64/python2.3/site-packages/ldap/ldapobject.py", line 
169, in simple_bind
     return 
self._ldap_call(self._l.simple_bind,who,cred,serverctrls,clientctrls)
   File "/usr/lib64/python2.3/site-packages/ldap/ldapobject.py", line 
94, in _ldap_call
     result = func(*args,**kwargs)
ldap.ENCODING_ERROR: {'desc': 'Encoding error'}
tsunami:~ #

I'm using MD5 hashes for my passwords. Could this be why? How can I tell 
Python-LDAP to use MD5 hashing? I find in the docs what the error means, 
but I don't see anything about fixing it, nor not supporting those 
hashing mechanisms...

Thanks,
Marc


-------------- next part --------------
A non-text attachment was scrubbed...
Name: testldap.py
Type: text/x-python
Size: 677 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20060601/bd104a82/attachment.py>

From michael at stroeder.com  Fri Jun  2 12:25:31 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 02 Jun 2006 12:25:31 +0200
Subject: Simple test failing
In-Reply-To: <447F3E3F.1000704@meteo.mcgill.ca>
References: <447F3E3F.1000704@meteo.mcgill.ca>
Message-ID: <4480121B.2020107@stroeder.com>

Marc Lanctot wrote:
> 
> I'm trying to get pykota working with LDAP and running into problems
> connecting to the LDAP server.

Which LDAP server? Which version?

> self._ldap_call(self._l.simple_bind,who,cred,serverctrls,clientctrls)
>   File "/usr/lib64/python2.3/site-packages/ldap/ldapobject.py", line 94,
> in _ldap_call
>     result = func(*args,**kwargs)
> ldap.ENCODING_ERROR: {'desc': 'Encoding error'}
> tsunami:~ #

Which version of python-ldap are you using and which OpenLDAP libs are
used by python-ldap?

> I'm using MD5 hashes for my passwords. Could this be why? How can I tell
> Python-LDAP to use MD5 hashing? I find in the docs what the error means,
> but I don't see anything about fixing it, nor not supporting those
> hashing mechanisms...

You simply have to pass the clear-text password to the simple_bind()
method call. (You probably want to use simple_bind_s() though.)

Ciao, Michael.


From sysadmin at meteo.mcgill.ca  Fri Jun  2 16:41:25 2006
From: sysadmin at meteo.mcgill.ca (Marc Lanctot)
Date: Fri, 02 Jun 2006 10:41:25 -0400
Subject: Simple test failing
In-Reply-To: <4480121B.2020107@stroeder.com>
References: <447F3E3F.1000704@meteo.mcgill.ca> <4480121B.2020107@stroeder.com>
Message-ID: <44804E15.7070304@meteo.mcgill.ca>

Michael Str?der wrote:
> Marc Lanctot wrote:
> 
>>I'm trying to get pykota working with LDAP and running into problems
>>connecting to the LDAP server.
> 
> 
> Which LDAP server? Which version?
> 

LOL, sorry... I expected it to be quite a common problem.

I'm running OpenLDAP server on a 32-bit RHES 3 (Taroon Update 5). I 
installed it from the usual up2date:

[mlanct2 at zephyr mlanct2]$ rpm -qa | grep openldap
openldap-devel-2.0.27-20
openldap-2.0.27-20
openldap-servers-2.0.27-20
openldap-clients-2.0.27-20
[mlanct2 at zephyr mlanct2]$

Weird, I was quite sure I had an version 3 server ... my clients can 
connect fine using pam_ldap around the dept.

>>self._ldap_call(self._l.simple_bind,who,cred,serverctrls,clientctrls)
>>  File "/usr/lib64/python2.3/site-packages/ldap/ldapobject.py", line 94,
>>in _ldap_call
>>    result = func(*args,**kwargs)
>>ldap.ENCODING_ERROR: {'desc': 'Encoding error'}
>>tsunami:~ #
> 
> 
> Which version of python-ldap are you using and which OpenLDAP libs are
> used by python-ldap?

The client script runs on a Suse (x86_64) 9.2 machine. Version

tsunami:~ # cat /etc/SuSE-release
SuSE Linux 9.2 (x86-64)
VERSION = 9.2
tsunami:~ # rpm -qa | grep ldap
ldapcpplib-0.0.3-28
openldap2-client-2.2.15-5.3
pam_ldap-169-29.2
nss_ldap-215-60.2
openldap2-2.2.15-5.1
yast2-ldap-2.10.4-2
yast2-ldap-client-2.10.7-2
python-ldap-2.0.2-2.1
php4-ldap-4.3.8-8.2
tsunami:~ #

Weird, the clients also list as v2 here ... but in the desc. it says v3. 
  Also, the ldap* commands work fine from this machine.

> You simply have to pass the clear-text password to the simple_bind()
> method call. (You probably want to use simple_bind_s() though.)

Ok, but will it use the "password: md5" setting from /etc/ldap.conf to 
encrypt the password?

And, can you tell me what "encoding error" means?

Thanks,
Marc

-- 
"The ships hung in the sky in much the same way that bricks don't."
   -- Douglas Adams


From sluggoster at gmail.com  Wed Jun 21 00:41:01 2006
From: sluggoster at gmail.com (Mike Orr)
Date: Tue, 20 Jun 2006 15:41:01 -0700
Subject: Debugging SSL connections
In-Reply-To: <6e9196d20606201523o24e3df82l70d37ebf9c548cb@mail.gmail.com>
References: <6e9196d20606201444y2e4c9411o8488a214e33539b5@mail.gmail.com>
	<6e9196d20606201523o24e3df82l70d37ebf9c548cb@mail.gmail.com>
Message-ID: <6e9196d20606201541m40ebec1r7c569a04ecb39bb4@mail.gmail.com>

Hi.  I have a Python application that uses LDAP to authenticate users.
 Today our organization moved the server to one that uses LDAP-SSL,
and I can't connect to it.  I couldn't find anything about SSL in the
python-ldap or openldap documentation, but a Google search found this
letter from 2003:
http://marc2.theaimsgroup.com/?l=python-ldap-dev&m=105298124425061&w=1

David Casti wrote:
> >
> > import ldap
> > l = ldap.initialize( 'ldaps://target:636' )
> > [..]
> > ldap.SERVER_DOWN: {'info': 'error:14090086:SSL
> > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', 'desc':
> > "Can't contact LDAP server"}
>
> The message is pretty clear. The server's certificate cannot be verified.
>
> > ldap.set_option( ldap.OPT_X_TLS_CACERTFILE, '/path/ca.crt' )
>
> This is the right thing to do.
>
> Can you please try something like
>
> openssl s_client -connect target:636 -CAfile /path/ca.crt
>
> and carefully examime its output?

But I don't have a certificate to authenticate against.  Mozilla
Thunderbird works fine without it   "openssl s_client -connect
target:636" ends with:
"Verify return code: 19 (self signed certificate in certificate chain)"

This is not surprising; our organization always uses self-signed
certificates.  The ldapsearch program refuses to run, saying:

TLS certificate verification: Error, self signed certificate in
certificate chain
tls_write: want=7, written=7
  0000:  15 03 01 00 02 02 30                               ......0
TLS trace: SSL3 alert write:fatal:unknown CA
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS: can't connect.
ldap_perror
ldap_bind: Can't contact LDAP server (-1)
        additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Is there an option for "just accept the certificate anyway"?  Is there
a list of LDAP options anywhere?  I couldn't find one.

Is there a HOWTO anywhere for using python-ldap with SSL?  I only
discovered ldaps: by guessing maybe it works like https:.

-- 
Mike Orr <sluggoster at gmail.com>




From michael at stroeder.com  Wed Jun 21 01:05:26 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 21 Jun 2006 01:05:26 +0200
Subject: Debugging SSL connections
In-Reply-To: <6e9196d20606201541m40ebec1r7c569a04ecb39bb4@mail.gmail.com>
References: <6e9196d20606201444y2e4c9411o8488a214e33539b5@mail.gmail.com>	<6e9196d20606201523o24e3df82l70d37ebf9c548cb@mail.gmail.com>
	<6e9196d20606201541m40ebec1r7c569a04ecb39bb4@mail.gmail.com>
Message-ID: <44987F36.3080206@stroeder.com>

Mike Orr wrote:
> 
> I couldn't find anything about SSL in the
> python-ldap or openldap documentation, but a Google search found this
> letter from 2003:
> http://marc2.theaimsgroup.com/?l=python-ldap-dev&m=105298124425061&w=1
> [..]
> But I don't have a certificate to authenticate against.  Mozilla
> Thunderbird works fine without it

Are you sure that you never imported the appropriate CA certificate into
Mozilla cert store? Or do you hit "Accept forever" on each unknown
issuer? Bad idea!

>   "openssl s_client -connect
> target:636" ends with:
> "Verify return code: 19 (self signed certificate in certificate chain)"
> 
> This is not surprising; our organization always uses self-signed
> certificates.

You have to install the CA certificate which issued the SSL server
certificate available as trusted root certificate into each software
using it.

If you're using self-signed server certificates I can only comment that
you SHOULD NOT do this.

> ldap_bind: Can't contact LDAP server (-1)
>         additional info: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> 
> Is there an option for "just accept the certificate anyway"?

Nope. That's by design of the OpenLDAP API.

You can define the server certificate as CA certificate though. But
again, this undermines security measures of SSL/TLS.

>  Is there
> a list of LDAP options anywhere?

Why didn't you follow the advice in the e-mail you cited above:

ldap.set_option( ldap.OPT_X_TLS_CACERTFILE , ..)

> Is there a HOWTO anywhere for using python-ldap with SSL?

See demo script Demo/initialize.py in python-ldap's source distribution.

Ciao, Michael.




From sluggoster at gmail.com  Wed Jun 21 01:38:36 2006
From: sluggoster at gmail.com (Mike Orr)
Date: Tue, 20 Jun 2006 16:38:36 -0700
Subject: Debugging SSL connections
In-Reply-To: <44987F36.3080206@stroeder.com>
References: <6e9196d20606201444y2e4c9411o8488a214e33539b5@mail.gmail.com>
	 <6e9196d20606201523o24e3df82l70d37ebf9c548cb@mail.gmail.com>
	 <6e9196d20606201541m40ebec1r7c569a04ecb39bb4@mail.gmail.com>
	 <44987F36.3080206@stroeder.com>
Message-ID: <6e9196d20606201638w4e1a7d69m9a75bcb6f608d590@mail.gmail.com>

On 6/20/06, Michael Str?der <michael at stroeder.com> wrote:
> Mike Orr wrote:
> >
> > I couldn't find anything about SSL in the
> > python-ldap or openldap documentation, but a Google search found this
> > letter from 2003:
> > http://marc2.theaimsgroup.com/?l=python-ldap-dev&m=105298124425061&w=1
> > [..]
> > But I don't have a certificate to authenticate against.  Mozilla
> > Thunderbird works fine without it
>
> Are you sure that you never imported the appropriate CA certificate into
> Mozilla cert store? Or do you hit "Accept forever" on each unknown
> issuer? Bad idea!

Oh that's right, Mozilla did pop up an "Unknown certificate" dialog.

> >   "openssl s_client -connect
> > target:636" ends with:
> > "Verify return code: 19 (self signed certificate in certificate chain)"
> >
> > This is not surprising; our organization always uses self-signed
> > certificates.
>
> You have to install the CA certificate which issued the SSL server
> certificate available as trusted root certificate into each software
> using it.
>
> If you're using self-signed server certificates I can only comment that
> you SHOULD NOT do this.

I have no control over the server.  And some organizations with tight
budgets balk at paying $100 per year per domain to a company like
Thawte that essentially does nothing.

> > ldap_bind: Can't contact LDAP server (-1)
> >         additional info: error:14090086:SSL
> > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> >
> > Is there an option for "just accept the certificate anyway"?
>
> Nope. That's by design of the OpenLDAP API.
>
> You can define the server certificate as CA certificate though. But
> again, this undermines security measures of SSL/TLS.
>
> >  Is there
> > a list of LDAP options anywhere?
>
> Why didn't you follow the advice in the e-mail you cited above:
>
> ldap.set_option( ldap.OPT_X_TLS_CACERTFILE , ..)

Because I don't have a certificate file to point it to.

I'm checking with the LDAP admins to see if they'll give us the
certificate file.  If not, I don't know what else to do.

-- 
Mike Orr <sluggoster at gmail.com>


From michael at stroeder.com  Wed Jun 21 01:46:33 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 21 Jun 2006 01:46:33 +0200
Subject: Debugging SSL connections
In-Reply-To: <6e9196d20606201638w4e1a7d69m9a75bcb6f608d590@mail.gmail.com>
References: <6e9196d20606201444y2e4c9411o8488a214e33539b5@mail.gmail.com>	
	<6e9196d20606201523o24e3df82l70d37ebf9c548cb@mail.gmail.com>	
	<6e9196d20606201541m40ebec1r7c569a04ecb39bb4@mail.gmail.com>	
	<44987F36.3080206@stroeder.com>
	<6e9196d20606201638w4e1a7d69m9a75bcb6f608d590@mail.gmail.com>
Message-ID: <449888D9.9000809@stroeder.com>

Mike Orr wrote:
> On 6/20/06, Michael Str?der <michael at stroeder.com> wrote:
> 
>> If you're using self-signed server certificates I can only comment that
>> you SHOULD NOT do this.
> 
> I have no control over the server.  And some organizations with tight
> budgets balk at paying $100 per year per domain to a company like
> Thawte that essentially does nothing.

Hint: You can run your own CA. Or there's also cacert.org.

>> > ldap_bind: Can't contact LDAP server (-1)
>> >         additional info: error:14090086:SSL
>> > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>> >
>> > Is there an option for "just accept the certificate anyway"?
>>
>> Nope. That's by design of the OpenLDAP API.
>>
>> You can define the server certificate as CA certificate though. But
>> again, this undermines security measures of SSL/TLS.
>>
>> >  Is there
>> > a list of LDAP options anywhere?
>>
>> Why didn't you follow the advice in the e-mail you cited above:
>>
>> ldap.set_option( ldap.OPT_X_TLS_CACERTFILE , ..)
> 
> Because I don't have a certificate file to point it to.

As I wrote above you can point to the server certificate file.

> I'm checking with the LDAP admins to see if they'll give us the
> certificate file.  If not, I don't know what else to do.

Simply grab it with openssl s_client.

Ciao, Michael.




From michael at stroeder.com  Wed Jun 21 01:05:26 2006
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 21 Jun 2006 01:05:26 +0200
Subject: Debugging SSL connections
In-Reply-To: <6e9196d20606201541m40ebec1r7c569a04ecb39bb4@mail.gmail.com>
References: <6e9196d20606201444y2e4c9411o8488a214e33539b5@mail.gmail.com>	<6e9196d20606201523o24e3df82l70d37ebf9c548cb@mail.gmail.com> <6e9196d20606201541m40ebec1r7c569a04ecb39bb4@mail.gmail.com>
Message-ID: <44987F36.3080206@stroeder.com>

Mike Orr wrote:
> 
> I couldn't find anything about SSL in the
> python-ldap or openldap documentation, but a Google search found this
> letter from 2003:
> http://marc2.theaimsgroup.com/?l=python-ldap-dev&m=105298124425061&w=1
> [..]
> But I don't have a certificate to authenticate against.  Mozilla
> Thunderbird works fine without it

Are you sure that you never imported the appropriate CA certificate into
Mozilla cert store? Or do you hit "Accept forever" on each unknown
issuer? Bad idea!

>   "openssl s_client -connect
> target:636" ends with:
> "Verify return code: 19 (self signed certificate in certificate chain)"
> 
> This is not surprising; our organization always uses self-signed
> certificates.

You have to install the CA certificate which issued the SSL server
certificate available as trusted root certificate into each software
using it.

If you're using self-signed server certificates I can only comment that
you SHOULD NOT do this.

> ldap_bind: Can't contact LDAP server (-1)
>         additional info: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> 
> Is there an option for "just accept the certificate anyway"?

Nope. That's by design of the OpenLDAP API.

You can define the server certificate as CA certificate though. But
again, this undermines security measures of SSL/TLS.

>  Is there
> a list of LDAP options anywhere?

Why didn't you follow the advice in the e-mail you cited above:

ldap.set_option( ldap.OPT_X_TLS_CACERTFILE , ..)

> Is there a HOWTO anywhere for using python-ldap with SSL?

See demo script Demo/initialize.py in python-ldap's source distribution.

Ciao, Michael.


From martinson.jacob at gmail.com  Sat Jun 17 20:43:08 2006
From: martinson.jacob at gmail.com (jacob martinson)
Date: Sat, 17 Jun 2006 13:43:08 -0500
Subject: problem binding to AD with known-good credentials
Message-ID: <5b7479590606171143h50a674bk50034455b5553240@mail.gmail.com>

I am unable to bind to an Active Directory system using python-ldap.

I created a user in AD with search rights and am able to do a simple
bind with the java-based "LDAP Browser" and search/browse the
directory with those credentials.

When I try to do a simple bind to the directory with python-ldap I
don't get an exception, but when I try to perform the search, I get an
exception indicating I didn't bind successfully:

Traceback (most recent call last):
  File "./tmp", line 29, in ?
    search_ad(email='user at domain.com',password='passwd')
  File "./tmp", line 20, in search_ad
    result_type, result_data = l.result(ldap_result_id, 0)
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line
399, in result
    res_type,res_data,res_msgid = self.result2(msgid,all,timeout)
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line
405, in result2
    return self._ldap_call(self._l.result2,msgid,all,timeout)
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 94,
in _ldap_call
    result = func(*args,**kwargs)
ldap.OPERATIONS_ERROR: {'info': '00000000: LdapErr: DSID-0C090627,
comment: In order to perform this operation a successful bind must be
completed on the connection., data 0, vece', 'desc': 'Operations
error'}

I am attaching the script that generated this exception.  Am I missing
something?

Thanks!

jacob
-------------- next part --------------
#!/usr/bin/env python

import ldap
import ldapconf

def search_ad(email,password=''):

        # Connect to ldap server, retrieve the CN tied to the given email addr
        try:
                l = ldap.open(ldapconf.host)
                l.protocol_version = ldap.VERSION3
                l.simple_bind_s(ldapconf.ldap_user,ldapconf.ldap_pass)
        except ldap.LDAPError, e:
                print e

        filter = '%s%s' % ( ldapconf.filter, email )
        ldap_result_id = l.search(ldapconf.base_dn, ldap.SCOPE_SUBTREE, ldapconf.filter, ['cn'])
        result_set = []
        while 1:
                result_type, result_data = l.result(ldap_result_id, 0)
                if (result_data == []):
                        break
                else:
                        if result_type == ldap.RES_SEARCH_ENTRY:
                                result_set.append(result_data)
        print result_set


search_ad(email='user at domain.com',password='passwd')
-------------- next part --------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

From ben at jatosoft.com  Thu Jun 29 00:23:04 2006
From: ben at jatosoft.com (Ben Gollmer)
Date: Wed, 28 Jun 2006 17:23:04 -0500
Subject: Mac OS X Binary Download
Message-ID: <8BEDAE95-70AF-47B2-8912-734D124CDD17@jatosoft.com>

FYI,

I've built a universal binary (PPC & Intel) package for python-ldap.  
This is a standard Mac OS X installer which does not require  
DarwinPorts or Fink. It's hosted at Bob Ippolito's PythonMac packages  
site: http://pythonmac.org/packages/py24-fat/python_ldap-2.2.0-py2.4- 
macosx10.4.zip. It'd be nice to add that link to the Downloads page.

Cheers,
-- 
Ben


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20060628/59a1bb22/attachment.pgp>
-------------- next part --------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

From martinson.jacob at gmail.com  Sat Jun 17 20:45:07 2006
From: martinson.jacob at gmail.com (jacob martinson)
Date: Sat, 17 Jun 2006 13:45:07 -0500
Subject: problem binding to AD with known-good credentials
In-Reply-To: <5b7479590606171143h50a674bk50034455b5553240@mail.gmail.com>
References: <5b7479590606171143h50a674bk50034455b5553240@mail.gmail.com>
Message-ID: <5b7479590606171145v705b4fevd38d9cc2302b8081@mail.gmail.com>

I forgot to add I am using python2.3-ldap 2.0.4-1 on a debian 3.1 system.

thanks,
jacob

On 6/17/06, jacob martinson <martinson.jacob at gmail.com> wrote:
> I am unable to bind to an Active Directory system using python-ldap.
>
> I created a user in AD with search rights and am able to do a simple
> bind with the java-based "LDAP Browser" and search/browse the
> directory with those credentials.
>
> When I try to do a simple bind to the directory with python-ldap I
> don't get an exception, but when I try to perform the search, I get an
> exception indicating I didn't bind successfully:
>
> Traceback (most recent call last):
>   File "./tmp", line 29, in ?
>     search_ad(email='user at domain.com',password='passwd')
>   File "./tmp", line 20, in search_ad
>     result_type, result_data = l.result(ldap_result_id, 0)
>   File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line
> 399, in result
>     res_type,res_data,res_msgid = self.result2(msgid,all,timeout)
>   File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line
> 405, in result2
>     return self._ldap_call(self._l.result2,msgid,all,timeout)
>   File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 94,
> in _ldap_call
>     result = func(*args,**kwargs)
> ldap.OPERATIONS_ERROR: {'info': '00000000: LdapErr: DSID-0C090627,
> comment: In order to perform this operation a successful bind must be
> completed on the connection., data 0, vece', 'desc': 'Operations
> error'}
>
> I am attaching the script that generated this exception.  Am I missing
> something?
>
> Thanks!
>
> jacob
>
>
>

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642