From wido.depping at gmail.com  Tue Jan  4 13:41:42 2005
From: wido.depping at gmail.com (Wido Depping)
Date: Tue, 4 Jan 2005 13:41:42 +0100
Subject: how to use modlist?
In-Reply-To: <41DA5DEC.4030706@it.fts-vn.com>
References: <41DA5DEC.4030706@it.fts-vn.com>
Message-ID: <127079e105010404417ec7ee63@mail.gmail.com>

On Tue, 04 Jan 2005 16:12:12 +0700, tnd at it.fts-vn.com <tnd at it.fts-vn.com> wrote:
> Sorry for my stupid question but the document on ldap.modlist is not
> clear and no example.
> I've tried to use function addModlist like below
> ldap.modlist.addModlist(['key','value'])
> and receive the error
> ...
> AttributeError: 'list' object has no attribute 'keys'
> 
> Could you give me a small example to use modlist correctly.
> Thanks.
> 
> (--ntdt--)

addModlist works on the dictionary of an entry which you get for every
search result. You get something like this: [('cn=foo,o=bar',
{'objectClass': ['top', 'account'], 'uid': ['1028'], 'cn': ['Foo
Bar']}), (second result)]
Get the data dictionary and use addModlist. See here some sample code
from the python console:
>>> a = {'objectClass': ['top', 'account'], 'uid': ['1028'], 'cn': ['Foo Bar']}
>>> import ldap.modlist
>>> ldap.modlist.addModlist(a)
[('objectClass', ['top', 'account']), ('uid', ['1028']), ('cn', ['Foo Bar'])]

The result is your modlist. I hope this makes verything clear.

mfg.
  Wido
-- 
Wido Depping
ICQ: 51303067    AIM: wido3379
Jabber: wido at jabber.ccc.de
Blog: http://widoww.blogspot.com




From tnd at it.fts-vn.com  Tue Jan  4 10:12:12 2005
From: tnd at it.fts-vn.com (tnd at it.fts-vn.com)
Date: Tue, 04 Jan 2005 16:12:12 +0700
Subject: how to use modlist?
Message-ID: <41DA5DEC.4030706@it.fts-vn.com>

Sorry for my stupid question but the document on ldap.modlist is not 
clear and no example.
I've tried to use function addModlist like below
ldap.modlist.addModlist(['key','value'])
and receive the error
...
AttributeError: 'list' object has no attribute 'keys'

Could you give me a small example to use modlist correctly.
Thanks.

(--ntdt--)




From wido.depping at gmail.com  Mon Jan 10 15:13:45 2005
From: wido.depping at gmail.com (Wido Depping)
Date: Mon, 10 Jan 2005 15:13:45 +0100
Subject: Error: Schema fetching on Oracle Directory Server
Message-ID: <127079e10501100613681c6f1a@mail.gmail.com>

Hi All,
I've a problem with Luma when fetching the schema information from an
Oracle Directory Server. Normal search operations work fine, but since
I won't allow any editing of attributes without knowing the schema,
I'm somehow stuck.
Upgrading to 2.0.6 didn't solve the problem either :(

Here's the relevant part of the backtrace I get:

Traceback (most recent call last):
 File "/home/wido/src/luma/lib/luma/base/backend/ObjectClassAttributeInfo.py",
line 83, in retrieveInfoFromServer
   subschemasubentry_dn,schema = ldap.schema.urlfetch(tmpUrl)
 File "/usr/lib/python2.3/site-packages/ldap/schema/subentry.py",
line 415, in urlfetch
   parsed_sub_schema = ldap.schema.SubSchema(subschemasubentry_entry)
 File "/usr/lib/python2.3/site-packages/ldap/schema/subentry.py",
line 51, in __init__
   se_instance = se_class(attr_value)
 File "/usr/lib/python2.3/site-packages/ldap/schema/models.py", line
49, in __init__
   d = extract_tokens(l,self.token_defaults)
 File "/usr/lib/python2.3/site-packages/ldap/schema/tokenizer.py",
line 56, in extract_tokens
   assert l[0].strip()=="(" and l[-1].strip()==")",ValueError(l)
AssertionError: ['(', '2.16.840.1.113894.5.101.1.1063', 'NAME',
'orclUMCTGroupConfig', 'DESC', 'Configuration name defined in the
Media Service', 's', 'Application', 'Profile', ' SYNTAX
1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )']

The value for tmpUrl, the url of the server, is something like this:
 tmpUrl = "ldap://my.oracle.server.com:389"

If you aren't able to fix this bug only with the backtrace, I can give
you the mail of the server admin, who may give you access to his
machine.

mfg.
  Wido
-- 
Wido Depping
ICQ: 51303067    AIM: wido3379
Jabber: wido at jabber.ccc.de
Blog: http://widoww.blogspot.com




From michael at stroeder.com  Wed Jan 12 07:51:29 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 12 Jan 2005 07:51:29 +0100
Subject: Error: Schema fetching on Oracle Directory Server
In-Reply-To: <127079e10501101622478946dc@mail.gmail.com>
References: <127079e10501100613681c6f1a@mail.gmail.com>	 <41E2AAD0.4030206@stroeder.com> <127079e10501101622478946dc@mail.gmail.com>
Message-ID: <41E4C8F1.7050907@stroeder.com>

Wido Depping wrote:
> I've looked into this issue the last hours and have found a solution
> to this. Unfortunately this means (from my perspective) that the old
> split_tokens(string) function must be replaced.

Thanks for diving into it.

> Since the old split_token(string) function wasn't documented and not
> well prepared for handling these special cases, I rewrote the
> function. It can be found here:
> http://home.tu-clausthal.de/~ifwd/luma/split_tokens.py

I'm currently testing your code.

> In the README file
> is specified, that the code should be compatible with Python 1.5. My
> code is compatible with this version. But it needs at least the import
> of the string module, which is provided with 1.5 (Checked in the docs
> from python.org).

Well, ldap.schema is probably not compatible with Python 1.5. I'd really 
like to drop support for older Python versions but that's another issue.

> In the current shape, the function is only 3% slower than the old
> code, but works with all LDAP servers, including Oracle now.

I will test. I'd be happy if you provide a LDIF dump of a sub schema 
entry of Oracle's OID.

> But if we
> could use string.split(aList), this algorithm would be 3 times faster
> than the current one.

I currently do not have the time to analyse this any further. Can you 
please explain why string.split(aList) can't be used within your 
implementation?

> I leave it up to you, to integrate my function, or find your own
> solution.

I'd add your code to python-ldap provided you give away copyright for it 
to the python-ldap project. Please confirm (list Cc:-ed).

Ciao, Michael.


From og at nuxeo.com  Wed Jan 12 16:50:02 2005
From: og at nuxeo.com (Olivier Grisel)
Date: Wed, 12 Jan 2005 16:50:02 +0100
Subject: valid DN and empty password : bug?
Message-ID: <41E5472A.5050806@nuxeo.com>

Hello list,

I experiment a strange behavior (bug?) with python-ldap 2.0.4 and
Sun/Netscape iPlanet LDAP server.

Use case:
The server has an inetOrgPerson entry 'uid=toto,dc=mydomain,dc=com' with
the corresponding userPassword set to some regular non empty value
(something like '{SSHA}sgqsdfqs[...]' ).

When a do a simple_bind_s with toto's DN and the empty password string,
the simple_bind_s succeeds! Although, if I try with another (non empty)
wrong password string I get the expected ldap.INVALID_CREDENTIALS exception.

NB: anonymous has the 'read' permission on the whole directory, but I
haven't asked python-ldap to bind anonymously, I want it to try to bind
with the specified DN (uid=toto,dc=mydomain,dc=com).

I can't reproduce this bug with my OpenLDAP (slapd) server, since I get
the following exception ( toto's DN with an empty password):
"""
ldap.UNWILLING_TO_PERFORM: {'info': 'unauthenticated bind (DN with no
password) disallowed', 'desc': 'Server is unwilling to perform'}
"""
OpenLDAP refuses empty passwords.

It seems to me that python-ldap falls back to anonymous if the
authentication with empty password fails, which is not the expected
behavior (or is it ?). I would like it to raise ldap.INVALID_CREDENTIALS
instead.

I am sorry if this is an known bug, but google couldn't help mefind
references on it.

Regards

Olivier





From michael at stroeder.com  Wed Jan 12 18:57:25 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 12 Jan 2005 18:57:25 +0100
Subject: valid DN and empty password : bug?
In-Reply-To: <41E5472A.5050806@nuxeo.com>
References: <41E5472A.5050806@nuxeo.com>
Message-ID: <41E56505.7020102@stroeder.com>

Olivier Grisel wrote:
> 
> The server has an inetOrgPerson entry 'uid=toto,dc=mydomain,dc=com' with
> the corresponding userPassword set to some regular non empty value
> (something like '{SSHA}sgqsdfqs[...]' ).
> 
> When a do a simple_bind_s with toto's DN and the empty password string,
> the simple_bind_s succeeds! Although, if I try with another (non empty)
> wrong password string I get the expected ldap.INVALID_CREDENTIALS 
> exception.

This is a normal behaviour. But as you already experienced it depends on 
the LDAP server implementation.

(I remember this being debated to death on some IETF mailing lists.)

> but I
> haven't asked python-ldap to bind anonymously, I want it to try to bind
> with the specified DN (uid=toto,dc=mydomain,dc=com).

Some LDAP servers regard an empty password as implicitly being an 
anonymous bind but the log the bind-DN.

> I can't reproduce this bug with my OpenLDAP (slapd) server, since I get
> the following exception ( toto's DN with an empty password):
> """
> ldap.UNWILLING_TO_PERFORM: {'info': 'unauthenticated bind (DN with no
> password) disallowed', 'desc': 'Server is unwilling to perform'}
> """
> OpenLDAP refuses empty passwords.

The OpenLDAP developers simply had a different point of view how to 
handle such a simple bind request by default. You can change this 
behaviour. See the description for config directive "allow bind_anon_dn" in
man 5 slapd.conf:

allow <features>
[..]
bind_anon_dn allows unauthenticated (anonymous) bind when DN
is not empty.
[..]

Refer to the OpenLDAP lists and their archives for reading more about it.

> It seems to me that python-ldap falls back to anonymous if the
> authentication with empty password fails,

Nope! The LDAP client parts are just a primitive wrapper around the 
OpenLDAP API.

Note that my LDAP client application web2ldap implicitly assumes a anon 
bind if a users enters a bind-DN without a password. The bind-DN is set 
to empty string by web2ldap in this case. But python-ldap simply passes 
what the client application told it to send to the LDAP server.

> which is not the expected
> behavior (or is it ?). I would like it to raise ldap.INVALID_CREDENTIALS
> instead.

In case of an error python-ldap directly maps the result code returned 
by the LDAP server to an ldap.LDAPError exception raised. python-ldap 
has no additional behaviour regarding error handling. Your LDAP client 
application has to deal with different error codes returned by different 
LDAP server implementations.

> I am sorry if this is an known bug,

It's definitely not a python-ldap bug.

Ciao, Michael.


From mcicogni at siosistemi.it  Tue Jan 11 12:16:51 2005
From: mcicogni at siosistemi.it (Mauro Cicognini)
Date: Tue, 11 Jan 2005 12:16:51 +0100
Subject: Python-LDAP for Python 2.4?
In-Reply-To: <6.1.2.0.2.20050111100405.01b2e0f8@127.0.0.1>
References: <6.1.2.0.2.20050111100405.01b2e0f8@127.0.0.1>
Message-ID: <41E3B5A3.4060007@siosistemi.it>

Wim Hoekman scrive:

> Hi,
>
> I'm currently using an older version of Python-ldap, but I've recently 
> switched to Python 2.4.
>
> Is there any change of having a build for Python 2.4 (Windows version)?
>
> Thanks in advance.
>
> Best regards,
>
> Wim Hoekman.
>
I'm just having trouble finding the time to launch make :-(
But don't worry, I need the new build for myself too, so it should be a 
matter of days.

Check back on my site next week.

Mauro

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2855 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050111/9f78096f/attachment.bin>

From RyanP at foxracing.com  Thu Jan 13 18:39:17 2005
From: RyanP at foxracing.com (Ryan Parrish)
Date: Thu, 13 Jan 2005 09:39:17 -0800
Subject: Totally stumped on how to use async.
Message-ID: <A868E7E73EAD484C98EAFD0A20BF6C9F7AA9B5@narada.foxracing.com>

Let me preface by saying that I am kind of a newbie with LDAP.  
Here is my problem, I would like to use python-ldap to query the proxyAddresses on my AD domain controller, and eventually write it out to a file.  But since this is AD I have to limit my queries to under 1000 results.  
I am trying to mimic the functionality of this Perl script http://www-personal.umich.edu/~malth/gaptuning/postfix/getadsmtp.pl

1.) When I use the example on the site for asynchronies queries, I don't get all the results - I get 2000 (which I don't understand why, but there is actually 3106)http://homepage.mac.com/mengelhart/python-ldap-samples.html#search
2.) The way I understand 'retrieveAttribuites' to work would be that I only retrieve one particular attribute for each 'cn', and that is how it appears to work in the 'directoyassist' 3rd party script off the site.  So I figured that I could put ['proxyAddresses'] in there and only receive the proxyAddresses, but when I use anything except None I get no results back.

Here is what I have, it is almost a verbatim copy of the example, if you could just give me some pointers on how to use the async queries I will be on my way. Thanks. 
PS I have tried on both my Linux and win box and get the exact same results.


#!/usr/bin/env python
import ldap
from string import split

try:
    l = ldap.open("10.11.2.33")
    l.simple_bind_s('A user name','*****') 
except ldap.LDAPError, e:
    print e

baseDN = "dc=foxracing,dc=com"
searchScope = ldap.SCOPE_SUBTREE
retrieveAttributes = None
#sizelimit = 990

searchFilter = "(& (mailnickname=*) (| (&(objectCategory=person) \
(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*))) \
(&(objectCategory=person)(objectClass=user)(|(homeMDB=*) \
(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=contact)) \
(objectCategory=group)(objectCategory=publicFolder) ))"

try:
    ldap_result_id = l.search(baseDN, searchScope, searchFilter, retrieveAttributes)
    while 1:
	result_type, result_data = l.result(ldap_result_id, 0)
	if (result_data == []):
            break
        else:
	    if result_type == ldap.RES_SEARCH_ENTRY:
		for entry in result_data[0][1]['proxyAddresses']:
		    if 'SMTP' in entry:
			email = "%s OK" % (split(entry, ':')[1])
			print email
except ldap.LDAPError, e:
    print e

_-`-_-`-_-`-_-`-_-`-_-`-_-`-_-`-_-`-_

Ryan Parrish
ryanp at foxracing.com
IT Dept.
408-776-8633 extension 1229
Please direct all support questions to -
(?`?.??.-> itsupport at foxracing.com

_-`-_-`-_-`-_-`-_-`-_-`-_-`-_-`-_-`-_ 




From RyanP at foxracing.com  Thu Jan 13 18:47:52 2005
From: RyanP at foxracing.com (Ryan Parrish)
Date: Thu, 13 Jan 2005 09:47:52 -0800
Subject: Totally stumped on how to use async.
Message-ID: <A868E7E73EAD484C98EAFD0A20BF6C9F57E25C@narada.foxracing.com>

I would like to recall issue #2, I'm an idiot and it DOES work.  But I'm still stumped on getting all my results.
 


-Ryan Parrish 
-----Original Message-----
From: python-ldap-dev-admin at lists.sourceforge.net [mailto:python-ldap-dev-admin at lists.sourceforge.net] On Behalf Of Ryan Parrish
Sent: Thursday, January 13, 2005 9:39 AM
To: python-ldap-dev at lists.sourceforge.net
Subject: Totally stumped on how to use async.

Let me preface by saying that I am kind of a newbie with LDAP.  
Here is my problem, I would like to use python-ldap to query the proxyAddresses on my AD domain controller, and eventually write it out to a file.  But since this is AD I have to limit my queries to under 1000 results.  
I am trying to mimic the functionality of this Perl script http://www-personal.umich.edu/~malth/gaptuning/postfix/getadsmtp.pl

1.) When I use the example on the site for asynchronies queries, I don't get all the results - I get 2000 (which I don't understand why, but there is actually 3106)http://homepage.mac.com/mengelhart/python-ldap-samples.html#search
2.) The way I understand 'retrieveAttribuites' to work would be that I only retrieve one particular attribute for each 'cn', and that is how it appears to work in the 'directoyassist' 3rd party script off the site.  So I figured that I could put ['proxyAddresses'] in there and only receive the proxyAddresses, but when I use anything except None I get no results back.

Here is what I have, it is almost a verbatim copy of the example, if you could just give me some pointers on how to use the async queries I will be on my way. Thanks. 
PS I have tried on both my Linux and win box and get the exact same results.


#!/usr/bin/env python
import ldap
from string import split

try:
    l = ldap.open("10.11.2.33")
    l.simple_bind_s('A user name','*****') except ldap.LDAPError, e:
    print e

baseDN = "dc=foxracing,dc=com"
searchScope = ldap.SCOPE_SUBTREE
retrieveAttributes = None
#sizelimit = 990

searchFilter = "(& (mailnickname=*) (| (&(objectCategory=person) \
(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*))) \
(&(objectCategory=person)(objectClass=user)(|(homeMDB=*) \
(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=contact)) \
(objectCategory=group)(objectCategory=publicFolder) ))"

try:
    ldap_result_id = l.search(baseDN, searchScope, searchFilter, retrieveAttributes)
    while 1:
	result_type, result_data = l.result(ldap_result_id, 0)
	if (result_data == []):
            break
        else:
	    if result_type == ldap.RES_SEARCH_ENTRY:
		for entry in result_data[0][1]['proxyAddresses']:
		    if 'SMTP' in entry:
			email = "%s OK" % (split(entry, ':')[1])
			print email
except ldap.LDAPError, e:
    print e

_-`-_-`-_-`-_-`-_-`-_-`-_-`-_-`-_-`-_

Ryan Parrish
ryanp at foxracing.com
IT Dept.
408-776-8633 extension 1229
Please direct all support questions to - (?`?.??.-> itsupport at foxracing.com

_-`-_-`-_-`-_-`-_-`-_-`-_-`-_-`-_-`-_ 




From michael at stroeder.com  Thu Jan 13 20:11:04 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 13 Jan 2005 20:11:04 +0100
Subject: Totally stumped on how to use async.
In-Reply-To: <A868E7E73EAD484C98EAFD0A20BF6C9F57E25C@narada.foxracing.com>
References: <A868E7E73EAD484C98EAFD0A20BF6C9F57E25C@narada.foxracing.com>
Message-ID: <41E6C7C8.9030205@stroeder.com>

Ryan Parrish wrote:
> I would like to recall issue #2, I'm an idiot and it DOES work.  But
> I'm still stumped on getting all my results.

I'm a little bit in a hurry and did not analyze your code.

But this might be for you:

http://python-ldap.sourceforge.net/doc/python-ldap/ldap.async-example.List.html

You still should think about dividing your single search request into 
several search requests with more fine-grained search filter values.

Ciao, Michael.


From ogrisel at nuxeo.com  Wed Jan 12 16:38:19 2005
From: ogrisel at nuxeo.com (Olivier Grisel)
Date: Wed, 12 Jan 2005 16:38:19 +0100
Subject: valid DN and empty password : bug?
Message-ID: <41E5446B.5000301@nuxeo.com>

Hello list,

I experiment a strange behavior (bug?) with python-ldap 2.0.4 and 
Sun/Netscape iPlanet LDAP server.

Use case:
The server has an inetOrgPerson entry 'uid=toto,dc=mydomain,dc=com' with 
the corresponding userPassword set to some regular non empty value 
(something like '{SSHA}sgqsdfqs[...]' ).

When a do a simple_bind_s with toto's DN and the empty password string, 
the simple_bind_s succeeds! Although, if I try with another (non empty) 
wrong password string I get the expected ldap.INVALID_CREDENTIALS exception.

NB: anonymous has the 'read' permission on the whole directory, but I 
haven't asked python-ldap to bind anonymously, I want it to try to bind 
with the specified DN (uid=toto,dc=mydomain,dc=com).

I can't reproduce this bug with my OpenLDAP (slapd) server, since I get 
the following exception ( toto's DN with an empty password):
"""
ldap.UNWILLING_TO_PERFORM: {'info': 'unauthenticated bind (DN with no 
password) disallowed', 'desc': 'Server is unwilling to perform'}
"""
OpenLDAP refuses empty passwords.

It seems to me that python-ldap falls back to anonymous if the 
authentication with empty password fails, which is not the expected 
behavior (or is it ?). I would like it to raise ldap.INVALID_CREDENTIALS 
instead.

I am sorry if this is an known bug, but google couldn't help mefind 
references on it.

Regards

Olivier




From mcicogni at siosistemi.it  Mon Jan 17 19:34:15 2005
From: mcicogni at siosistemi.it (Mauro Cicognini)
Date: Mon, 17 Jan 2005 19:34:15 +0100
Subject: Python-LDAP for Python 2.4?
In-Reply-To: <41E3B5A3.4060007@siosistemi.it>
References: <6.1.2.0.2.20050111100405.01b2e0f8@127.0.0.1> <41E3B5A3.4060007@siosistemi.it>
Message-ID: <41EC0527.1090900@siosistemi.it>

Mauro Cicognini scrive:

> Wim Hoekman scrive:
>
>> Hi,
>>
>> I'm currently using an older version of Python-ldap, but I've 
>> recently switched to Python 2.4.
>>
>> Is there any change of having a build for Python 2.4 (Windows version)?
>>
>> Thanks in advance.
>>
>> Best regards,
>>
>> Wim Hoekman.
>>
> I'm just having trouble finding the time to launch make :-(
> But don't worry, I need the new build for myself too, so it should be 
> a matter of days.
>
> Check back on my site next week.
>
> Mauro
>
The new Python-LDAP 2.0.6  for Python 2.4 build is on my site.

It still is built against OpenLDAP 2.2.18 since no improvements were 
made to the client libs. OpenSSL has not released anything newer than 
0.9.7e which is what I'm using.

Sorry I did not upgrade the Python 2.3 component (it's still PythonLDAP 
2.0.4), I don't think it's worthwhile.

BTW the Windows setup.cfg in the distro still is the old "MSVC" one, I 
have the new MinGW one I'm using if anyone's interested.

BR,
Mauro

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2855 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050117/73b2d689/attachment.bin>

From michael at stroeder.com  Tue Jan 18 16:51:04 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 18 Jan 2005 16:51:04 +0100
Subject: Python-LDAP for Python 2.4?
In-Reply-To: <41EC0527.1090900@siosistemi.it>
References: <6.1.2.0.2.20050111100405.01b2e0f8@127.0.0.1> <41E3B5A3.4060007@siosistemi.it> <41EC0527.1090900@siosistemi.it>
Message-ID: <41ED3068.10601@stroeder.com>

Mauro Cicognini wrote:
> BTW the Windows setup.cfg in the distro still is the old "MSVC" one, I 
> have the new MinGW one I'm using if anyone's interested.

Please send it to the list. I'll add it under Build/.

Maybe you already sent it to me. In that case I simply lost track of it.

Ciao, Michael.


From michael at stroeder.com  Thu Jan 20 09:23:22 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 20 Jan 2005 09:23:22 +0100
Subject: Error: Schema fetching on Oracle Directory Server
In-Reply-To: <41E4C8F1.7050907@stroeder.com>
References: <127079e10501100613681c6f1a@mail.gmail.com>	 <41E2AAD0.4030206@stroeder.com> <127079e10501101622478946dc@mail.gmail.com> <41E4C8F1.7050907@stroeder.com>
Message-ID: <41EF6A7A.3040808@stroeder.com>

Wido,

Michael Str?der wrote:
> 
>> Since the old split_token(string) function wasn't documented and not
>> well prepared for handling these special cases, I rewrote the
>> function. It can be found here:
>> http://home.tu-clausthal.de/~ifwd/luma/split_tokens.py
> 
> I'm currently testing your code.

There seems to be something wrong with your version of function 
ldap.schema.tokenizer.split_tokens(). I've experienced some strange 
issues when accessing MS AD with web2ldap.

Find attached a script I'm using for regression testing. It fails with 
your implementation. Maybe it helps you to sort out the problems. Please 
extend this script to also cover the Oracle-specific test cases and send 
it back to me. Hmm, the script should be also in 
Tests/Lib/ldap/schema/test_tokenizer.py of python-ldap's CVS.
(Not sure, I'm off-line on the train while writing this.)

Ciao, Michael.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_tokenizer.py
Type: application/x-python
Size: 866 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050120/dbd018e2/attachment.bin>

From wido.depping at gmail.com  Wed Jan 12 22:42:57 2005
From: wido.depping at gmail.com (Wido Depping)
Date: Wed, 12 Jan 2005 22:42:57 +0100
Subject: Error: Schema fetching on Oracle Directory Server
In-Reply-To: <41E4C8F1.7050907@stroeder.com>
References: <127079e10501100613681c6f1a@mail.gmail.com>
	 <41E2AAD0.4030206@stroeder.com>
	 <127079e10501101622478946dc@mail.gmail.com>
	 <41E4C8F1.7050907@stroeder.com>
Message-ID: <127079e1050112134262c1962d@mail.gmail.com>

On Wed, 12 Jan 2005 07:51:29 +0100, Michael Str?der
<michael at stroeder.com> wrote:
> > In the current shape, the function is only 3% slower than the old
> > code, but works with all LDAP servers, including Oracle now.
> 
> I will test. I'd be happy if you provide a LDIF dump of a sub schema
> entry of Oracle's OID.

I'll do that tomorrow.

> 
> > But if we
> > could use string.split(aList), this algorithm would be 3 times faster
> > than the current one.
> 
> I currently do not have the time to analyse this any further. Can you
> please explain why string.split(aList) can't be used within your
> implementation?

Hmm, nothing. I may not have expressed myself clearly enough. I wasn't
sure if you were following certain coding conventions, so i tried to
do the algortihm as simple as possible and keeping the usage of the
string module low. But since we can use this module, the part can be
replaced by string.split().

If have a more general question about some things you do in the source
code. At some points you assign a function from a module to a
variable, like "string_split = string.split".
I've asked myself, why you do this. Is it to improve speed? Your
assignment would spare a lookup of split in the string module and be
somehow faster.
But some quick testing showed, that this trick only gains 0.3 seconds
when splitting a string 1.000.000 times.

> > I leave it up to you, to integrate my function, or find your own
> > solution.
> 
> I'd add your code to python-ldap provided you give away copyright for it
> to the python-ldap project. Please confirm (list Cc:-ed).

I hereby grant the python-ldap project
(http://python-ldap.sourceforge.net/) my copyright belonging to all
parts of code, which is meant to be included into python-ldap. This
includes all future commits, unless otherwise stated.
 
mfg.
  Wido
-- 
Wido Depping
ICQ: 51303067    AIM: wido3379
Jabber: wido at jabber.ccc.de
Blog: http://widoww.blogspot.com




From mcicogni at libero.it  Tue Jan 25 00:44:33 2005
From: mcicogni at libero.it (Mauro Cicognini)
Date: Tue, 25 Jan 2005 00:44:33 +0100
Subject: Python-LDAP for Python 2.4?
In-Reply-To: <41ED3068.10601@stroeder.com>
References: <6.1.2.0.2.20050111100405.01b2e0f8@127.0.0.1> <41E3B5A3.4060007@siosistemi.it> <41EC0527.1090900@siosistemi.it> <41ED3068.10601@stroeder.com>
Message-ID: <41F58861.6040005@libero.it>

Michael Str?der wrote:

> Mauro Cicognini wrote:
>
>> BTW the Windows setup.cfg in the distro still is the old "MSVC" one, 
>> I have the new MinGW one I'm using if anyone's interested.
>
>
> Please send it to the list. I'll add it under Build/.
>
> Maybe you already sent it to me. In that case I simply lost track of it.
>
> Ciao, Michael. 

Here it is (sorry for the delay).
Hope someone finds it useful :-)

Ciao,
Mauro

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setup.cfg
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050125/aab87266/attachment.ksh>

From michael at stroeder.com  Tue Jan 25 19:55:14 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 25 Jan 2005 19:55:14 +0100
Subject: Python-LDAP for Python 2.4?
In-Reply-To: <41F58861.6040005@libero.it>
References: <6.1.2.0.2.20050111100405.01b2e0f8@127.0.0.1> <41E3B5A3.4060007@siosistemi.it> <41EC0527.1090900@siosistemi.it> <41ED3068.10601@stroeder.com> <41F58861.6040005@libero.it>
Message-ID: <41F69612.4030302@stroeder.com>

Mauro Cicognini wrote:
> Michael Str?der wrote:
> 
>> Mauro Cicognini wrote:
>>
>>> BTW the Windows setup.cfg in the distro still is the old "MSVC" one, 
>>> I have the new MinGW one I'm using if anyone's interested.
>>
>> Please send it to the list. I'll add it under Build/.
>>
>> Maybe you already sent it to me. In that case I simply lost track of it.
> 
> Here it is (sorry for the delay).
> Hope someone finds it useful :-)

Added to CVS.

Ciao, Michael.


From marc at msys.ch  Wed Jan 26 10:11:28 2005
From: marc at msys.ch (Marc Balmer)
Date: Wed, 26 Jan 2005 02:11:28 -0700
Subject: LDAP sorting routines
Message-ID: <41F75EC0.8050405@msys.ch>

Hi

OpenLDAP specifies a set of functions to sort a result set:

ldap_sort_entries(),  ldap_sort_values(), and ldap_sort_strcasecmp()

I did not find these functions in the documentation of python-ldap.  Is 
there a reason they are not available in python?  Could they be added?

Regards,
Marc Balmer




From michael at stroeder.com  Thu Jan 27 09:43:44 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 27 Jan 2005 09:43:44 +0100
Subject: LDAP sorting routines
In-Reply-To: <41F75EC0.8050405@msys.ch>
References: <41F75EC0.8050405@msys.ch>
Message-ID: <41F8A9C0.1010400@stroeder.com>

Marc Balmer wrote:
> 
> OpenLDAP specifies a set of functions to sort a result set:
> 
> ldap_sort_entries(),  ldap_sort_values(), and ldap_sort_strcasecmp()

These are helper functions used for sorting at the client side. IMO only 
useful for client applications implemented in C.

> I did not find these functions in the documentation of python-ldap.  Is 
> there a reason they are not available in python?  Could they be added?

It does not make sense to wrap these functions since client-side sorting 
of complete search result sets can be easily achieved by a couple of 
lines of Python code.

Support for server-side sorting together is a different story.

Ciao, Michael.


From wido.depping at gmail.com  Mon Jan 24 18:22:34 2005
From: wido.depping at gmail.com (Wido Depping)
Date: Mon, 24 Jan 2005 18:22:34 +0100
Subject: Error: Schema fetching on Oracle Directory Server
In-Reply-To: <41EF6A7A.3040808@stroeder.com>
References: <127079e10501100613681c6f1a@mail.gmail.com>
	 <41E2AAD0.4030206@stroeder.com>
	 <127079e10501101622478946dc@mail.gmail.com>
	 <41E4C8F1.7050907@stroeder.com> <41EF6A7A.3040808@stroeder.com>
Message-ID: <127079e105012409222e525ebc@mail.gmail.com>

On Thu, 20 Jan 2005 09:23:22 +0100, Michael Str?der
<michael at stroeder.com> wrote:
> There seems to be something wrong with your version of function
> ldap.schema.tokenizer.split_tokens(). I've experienced some strange
> issues when accessing MS AD with web2ldap.
> 
> Find attached a script I'm using for regression testing. It fails with
> your implementation. Maybe it helps you to sort out the problems. Please
> extend this script to also cover the Oracle-specific test cases and send
> it back to me. Hmm, the script should be also in
> Tests/Lib/ldap/schema/test_tokenizer.py of python-ldap's CVS.
> (Not sure, I'm off-line on the train while writing this.)
> 
> Ciao, Michael.

Hi Michael,
Attached are the updated testcase file and my improved split_tokens() function.
This time I use string.split() and string.join() to benefit from their
speed. The added checking in order to comply with the test cases has
the result, that the new algorithm is only slightly faster than the
old one. But now it should work with all known servers :)

mfg.
  Wido
-- 
Wido Depping
ICQ: 51303067    AIM: wido3379
Jabber: wido at jabber.ccc.de
Blog: http://widoww.blogspot.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: split_tokens.py
Type: application/octet-stream
Size: 2824 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050124/99a9bec7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_tokenizer.py
Type: application/octet-stream
Size: 1115 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050124/99a9bec7/attachment-0001.obj>

From michael at stroeder.com  Thu Jan 27 15:46:31 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 27 Jan 2005 15:46:31 +0100
Subject: Error: Schema fetching on Oracle Directory Server
In-Reply-To: <127079e105012409222e525ebc@mail.gmail.com>
References: <127079e10501100613681c6f1a@mail.gmail.com>	 <41E2AAD0.4030206@stroeder.com>	 <127079e10501101622478946dc@mail.gmail.com>	 <41E4C8F1.7050907@stroeder.com> <41EF6A7A.3040808@stroeder.com> <127079e105012409222e525ebc@mail.gmail.com>
Message-ID: <41F8FEC7.40505@stroeder.com>

Wido Depping wrote:
> 
> Attached are the updated testcase file and my improved split_tokens() function.

Hmm, I really dislike your constant keywordDict although I somewhat like 
the idea behind it. But this list of keywords is simply not sufficient.
=> I modified function ldap.schema.tokenizer.extract_tokens() to pass 
argument known_tokens down to your version of split_tokens() as new 
argument keywordDict.

But now the test_tokenizer.py script does not work anymore although 
web2ldap and the script Demo/schema.py seems to work with it.

Well, this surely needs more testing. Please remember to send me a LDIF 
file of Oracle's sub schema sub entry.

Ciao, Michael.


From r.cooke at hodman.net  Tue Feb  1 14:37:31 2005
From: r.cooke at hodman.net (Robert Cooke)
Date: Tue, 01 Feb 2005 14:37:31 +0100
Subject: Adding objectClass to existing dn
Message-ID: <1107265051.5038.11.camel@jesse>

Hi,

I've been trying to add an objectClass to an existing dn.
Now I get messages like :



{'info': "attribute 'cn' not allowed", 'desc': 'Object class violation'}
{'info': 'modify/add: objectClass: value #0 already exists', 'desc':
'Type or value exists'}

In my modlist are all the values nessecary I though. It feels like
the chicken and the egg problem.

To insert an objectClass you need the must attributes and to get the
attributes you need the new objectClass.

Please tell me what I'm missing here.

Thanks robert





From michael at stroeder.com  Tue Feb  1 15:34:43 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 01 Feb 2005 15:34:43 +0100
Subject: Adding objectClass to existing dn
In-Reply-To: <1107265051.5038.11.camel@jesse>
References: <1107265051.5038.11.camel@jesse>
Message-ID: <41FF9383.6000202@stroeder.com>

Robert Cooke wrote:
> 
> I've been trying to add an objectClass to an existing dn.
> Now I get messages like :
> 
> {'info': "attribute 'cn' not allowed", 'desc': 'Object class violation'}
> {'info': 'modify/add: objectClass: value #0 already exists', 'desc':
> 'Type or value exists'}
> 
> In my modlist are all the values nessecary I though. It feels like
> the chicken and the egg problem.

There's no chicken and egg problem here. The error description says that 
the attribute value for attribute 'cn' is already there. To be clear: 
Not only the attribute 'cn' itself is present. The very same attribute 
value is already stored in attribute 'cn' of this entry. This violates 
the X.500 data model. Just leave the 'cn' out of your modify list.

> To insert an objectClass you need the must attributes and to get the
> attributes you need the new objectClass.

This is another problem and can be easily solved. Add and modify 
requests are atomic.

Ciao, Michael.


From michael at stroeder.com  Tue Feb  1 19:05:24 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 01 Feb 2005 19:05:24 +0100
Subject: Adding objectClass to existing dn
In-Reply-To: <1107271474.10924.6.camel@flmrroach.okmaybe.com>
References: <1107265051.5038.11.camel@jesse> <1107271474.10924.6.camel@flmrroach.okmaybe.com>
Message-ID: <41FFC4E4.20300@stroeder.com>

Mark Roach wrote:
> 
>>{'info': "attribute 'cn' not allowed", 'desc': 'Object class violation'}
>>{'info': 'modify/add: objectClass: value #0 already exists', 'desc':
>>'Type or value exists'}
 >
> mlist = ldap.modlist.modifyModlist(attrs, newattrs)

ldap.modlist.modifyModlist() is a function which calculates the delta of 
an old entry and what a new entry should like. The result is a list to 
be passed to LDAPObject.modify() and .modify_s(). Using this function 
would certainly help with the problem the original poster has since it 
would supress adding the same attribute value twice.

But use this function with care! There surely are situations where the 
dumb case-sensitive string match for generating the delta is not 
sufficient. Therefore I don't recommend it unless you're really know 
what you're doing. Better you have full control of what you're doing.

Ciao, Michael.


From mrroach at okmaybe.com  Tue Feb  1 16:24:33 2005
From: mrroach at okmaybe.com (Mark Roach)
Date: Tue, 01 Feb 2005 10:24:33 -0500
Subject: Adding objectClass to existing dn
In-Reply-To: <1107265051.5038.11.camel@jesse>
References: <1107265051.5038.11.camel@jesse>
Message-ID: <1107271474.10924.6.camel@flmrroach.okmaybe.com>

On Tue, 2005-02-01 at 14:37 +0100, Robert Cooke wrote:
> Hi,
> 
> I've been trying to add an objectClass to an existing dn.
> Now I get messages like :

> {'info': "attribute 'cn' not allowed", 'desc': 'Object class violation'}
> {'info': 'modify/add: objectClass: value #0 already exists', 'desc':
> 'Type or value exists'}

I'm not sure how you're building your modlist, but you might want to
using ldap.modlist: (example off the top of my head, may have typos)

import ldap
import ldap.modlist
import copy

l = ldap.initialize('ldap://server')
l.bind_s('...', 'pass')
dn, attrs = l.search_s(dn, ldap.SCOPE_BASE)

newattrs = copy.deepcopy(attrs)
newattrs['objectClass'].append('newobjectclass')
newattrs['cn'] = ('cn_value',)

mlist = ldap.modlist.modifyModlist(attrs, newattrs)
l.modify_s(dn, mlist)


-Mark







From mrroach at okmaybe.com  Tue Feb  1 17:46:17 2005
From: mrroach at okmaybe.com (Mark Roach)
Date: Tue, 01 Feb 2005 11:46:17 -0500
Subject: Adding objectClass to existing dn
In-Reply-To: <1107274303.5038.24.camel@jesse>
References: <1107265051.5038.11.camel@jesse>
	 <1107271474.10924.6.camel@flmrroach.okmaybe.com>
	 <1107274303.5038.24.camel@jesse>
Message-ID: <1107276377.10924.13.camel@flmrroach.okmaybe.com>

On Tue, 2005-02-01 at 17:11 +0100, Robert Cooke wrote:
> Hi,
> 
> Thanks mark for your quick response but I'm sorry to tell the problem is
> not yet solved.

Hmm... perhaps the problem is adding new attributes as a tuple. Here is
a snippet from actual working code:

    sambaAttributes = deepcopy(newAttributes)
    sambaAttributes['objectClass'].append('sambaSAMAccount')
    sambaSID = domainSID + "-" + str(int(uidNumber) * 2 + 1000)
    sambaAttributes['sambaSID'] = sambaSID
    sambaAttributes['sambaAcctFlags'] = '[UX]'
    modlist = ldap.modlist.modifyModlist(newAttributes, sambaAttributes)
    self._conn.modify_s(userdn, modlist)

As you can see, the new attributes are just strings. That really
*shouldn't* make a difference though. ... oh wait. I think I see a
problem here:

> list(newattrs['objectClass']).append('ipHost')

This is creating a new copy of newattrs['objectClass'] and appending the
new objectClass to that list. You don't need the list() call at all, in
fact you need to not use list().

-Mark





From steuwer at univention.de  Mon Jan  3 11:00:29 2005
From: steuwer at univention.de (Ingo Steuwer)
Date: Mon, 03 Jan 2005 11:00:29 +0100
Subject: Implementation of LDAPControls
In-Reply-To: <41C694D6.2090006@stroeder.com>
References: <1103200570.1037.443.camel@anton.knut.univention.de>
	 <41C694D6.2090006@stroeder.com>
Message-ID: <1104746429.28453.29.camel@anton.knut.univention.de>

Am Mo, den 20.12.2004 schrieb Michael Str?der um 10:01:
> Ingo Steuwer wrote:
> > 
> > To fulfill our upcomming goals we need to use LDAPControls, but the
> > latest released version of python-ldap doesn't support them. 
> 
> Yes, you'll find a hint in file TODO.
> 
> > We did some experimental implementations in the C-backend (for "proof of
> > concept") and would now like to define a general approach. This should
> > be done in coordination with you to see our work in upcoming versions of
> > python-ldap.
> 
> Since I'm not a C programmer (David wrote the C code) I'd be really glad 
> if someone would jump on in and contribute code for LDAP controls and 
> extended operations.
> 
> I already tried to wrap the arguments whereever appropriate. Please 
> review this.
> 
> > My attempt would defining a python-class LDAPControl (containing OID,
> > iscritcal and value (dictionary)) and implement a correspondig wrapper
> > to *LDAPControl.
> 
> But value can be a complex ASN.1 structure as well.
> 
> > I think the most diffcult part will be the
> > representation of berval/berelement in python.
> 
> Yes.
> 
> > - is there somebody else implementing this (I didn't look at the cvs) ?
> 
> No. And I'm currently rather short on time. I'd highly appreciate your 
> contributions. But note that you should give away copyright for your 
> contributed code. Make sure that your legal department agrees on that.

Sorry for my late answer. It's Ok.

> > - are there already thoughts, definitions or an approach I should know ?
> 
> There are several approaches.
> 
> 1. Python classes for controls with a method berencode(). This method 
> would be called before passing the controls as argument to the functions 
> in _ldap. This would be the most flexible approach and independent of 
> the underlying OpenLDAP API. Drawbacks are that you need a BER module 
> for this and it's much work for complex controls.
> 
> 1.a Wrap libber.
> 
> 1.b Implement a pure Python BER module. Maybe we could get one from a 
> SNMP implementation implemented in Python?

I'd prefer this way, as mentioned by Hans there are already
implementations. In our first attempt we will not include but prepare
for them.


Ingo Steuwer

> 2. We could also wrap the helper functions in libldap (see controls.c, 
> vlvctrl.c, sortctrl.c). But this would add another strong dependency on 
> the OpenLDAP libs.
> 
> > - do you know about wrappers between berval/berelement and python ?
> 
> No. You could try to wrap OpenLDAP's libber.
> 
> Ciao, Michael.
-- 
Ingo Steuwer       steuwer at univention.de         fon: +49 421 22 232- 0
Entwicklung        Linux for Your Business       
Univention GmbH    http://www.univention.de/     fax: +49 421 22 232-99





From Michael.Strecker at oks-software.com  Tue Feb  8 14:49:25 2005
From: Michael.Strecker at oks-software.com (Michael Strecker)
Date: Tue, 8 Feb 2005 14:49:25 +0100
Subject: Python & LDAP & Oracle
Message-ID: <D18A89DE9E26834A83439FA5C2E8C3FF1FE519@oks2000.oks.oks-software.com>

Hello,
is Python compatible with Oracle?
I would read out the users on openLDAP Servers, copy them and insert the
users into the Oracle Database.

Dear Michael




From michael at stroeder.com  Tue Feb  8 18:11:15 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 08 Feb 2005 18:11:15 +0100
Subject: Python & LDAP & Oracle
In-Reply-To: <D18A89DE9E26834A83439FA5C2E8C3FF1FE519@oks2000.oks.oks-software.com>
References: <D18A89DE9E26834A83439FA5C2E8C3FF1FE519@oks2000.oks.oks-software.com>
Message-ID: <4208F2B3.5070405@stroeder.com>

Michael Strecker wrote:
>
> is Python compatible with Oracle?

There are surely DB-API modules for Python to access Oracle databases. 
But this is off-topic on this list.

Since we're here on python-ldap-dev you maybe ask about access Oracle 
Internet Directory which is the LDAP server product implemented by 
Oracle. Is this what you're after?

> I would read out the users on openLDAP Servers, copy them and insert the
> users into the Oracle Database.

Should be no problem to access OpenLDAP with python-ldap.

Ciao, Michael.


From gdoughtie at anim.dreamworks.com  Tue Feb  8 18:13:17 2005
From: gdoughtie at anim.dreamworks.com (Gavin Doughtie)
Date: Tue, 08 Feb 2005 09:13:17 -0800
Subject: Python & LDAP & Oracle
In-Reply-To: <D18A89DE9E26834A83439FA5C2E8C3FF1FE519@oks2000.oks.oks-software.com>
References: <D18A89DE9E26834A83439FA5C2E8C3FF1FE519@oks2000.oks.oks-software.com>
Message-ID: <4208F32D.7000105@anim.dreamworks.com>

Yes, we have many python applications talking to Oracle 8.1 and 9

Michael Strecker wrote:
> Hello,
> is Python compatible with Oracle?
> I would read out the users on openLDAP Servers, copy them and insert the
> users into the Oracle Database.
> 
> Dear Michael
> 
> 
> 

From bgrotan at stud.ntnu.no  Tue Feb  8 16:21:03 2005
From: bgrotan at stud.ntnu.no (Bjorn Ove Grotan)
Date: Tue, 8 Feb 2005 16:21:03 +0100
Subject: Python & LDAP & Oracle
In-Reply-To: <D18A89DE9E26834A83439FA5C2E8C3FF1FE519@oks2000.oks.oks-software.com>
References: <D18A89DE9E26834A83439FA5C2E8C3FF1FE519@oks2000.oks.oks-software.com>
Message-ID: <20050208152103.GA16959@itea.ntnu.no>

Michael Strecker:
> Hello,
> is Python compatible with Oracle?
> I would read out the users on openLDAP Servers, copy them and insert the
> users into the Oracle Database.

A bit OT for this list perhaps, but - anyways...
http://www.python.org/topics/database/modules.html has a list of which
databases are supported in Python and which module you can use. 

-- 
Regards
 
Bj?rn Ove Gr?tan




From richm at netscape.net  Wed Feb 16 20:21:25 2005
From: richm at netscape.net (Rich Megginson)
Date: Wed, 16 Feb 2005 12:21:25 -0700
Subject: Native python LDAP?
Message-ID: <42139D35.7050500@netscape.net>

Has anyone ever thought about doing a native (not based on ldap sdk 
binaries) python LDAP client?  Something like Net::LDAP (which is a very 
nice object model, even though it's perl).  It depends on several 
modules being available.  For example, is there a python ASN.1 parser?  
Most everything else is already available in python - sockets, ssl, etc.




From michael at stroeder.com  Mon Feb 21 18:30:31 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 21 Feb 2005 18:30:31 +0100
Subject: Native python LDAP?
In-Reply-To: <42139D35.7050500@netscape.net>
References: <42139D35.7050500@netscape.net>
Message-ID: <421A1AB7.7040907@stroeder.com>

Rich,

nice to see you here. Sorry for following up so late. I'm swamped with 
orga stuff so this rather long response took a while...

Rich Megginson wrote:
> Has anyone ever thought about doing a native (not based on ldap sdk 
> binaries) python LDAP client?

Yes, every now and then I'm thinking about this. In fact the LDAPObject 
wrapper class was the first step towards that. Modules ldap.schema, ldif 
and ldapurl are pure Python by purpose. I wanted to reduce dependencies 
on LDAP C SDKs whereever I could...

Actually there is 'ldaptor' which is a pure-Python LDAP implementation 
based on Twisted. But the web site is very unclear, no docs, no release 
history, no response from the author to my request of working together, 
and last not least a strong dependency on Twisted. :-(

There are various good reasons for reimplementing python-ldap from the 
ground up.

The RFC1823-style API still looks through the LDAPObject class letting 
application code look very unpythonic.

The data types returned from and passed to LDAPObject methods are not 
specific to python-ldap:
- list of dicts for search results
- no clear distinction between search results and search continuations
- raw lists for change records
etc.

With LDAPControls we cannot stay away from messing with BER any longer. 
Therefore we could reimplement much of the LDAP protocol stuff following 
a nice object model.

Compiling the various SDKs is a mess on some platforms (e.g. building 
OpenLDAP libs on Win32). The binaries are often behind the current 
release although some people are really doing great work providing 
up-to-date pre-built binaries.

Licensing situation not suitable for contributing python-ldap to 
Python's standard lib.

etc.

> Something like Net::LDAP (which is a very 
> nice object model, even though it's perl).

Don't know this since I never used Perl. If it's really a good object 
model we could simply borrow from it.

> It depends on several modules being available.

Yes, that's where the sadness begins...

> For example, is there a python ASN.1 parser?

The short answer: No there's no standard ASN.1 / BER / DER module for 
Python which could just be imported by python-ldap without any licensing 
and installation hassles.

The long answer:

There are some BER modules in SNMP modules. Don't know how to solve the 
licensing issues.

In web2ldap I'm using a slightly modified version of pisces.asn1 which 
is under old CNRI license. The author planned to work out a better 
license with CNRI but got stuck.

=> It boils down to developing a ASN.1 module and contribute it to 
Python's standard libs (following licensing advice by PSF from the very 
beginning).

> Most everything else is already available in python - sockets, ssl, etc.

Hmm, SSL support in Python's standard lib is very basic. AFAIK there's 
no proper certificate and CRL checking at all. And there's also SASL, 
Kerberos, etc. to think about.

Off course I'd be willing to put work into it. But it would need several 
developers to reach the same functional level as today's python-ldap 
within a reasonable time frame.

Let's discuss design goals...mine are:

Let's call the module 'ldap2'.

'ldap2' should go into Python's standard lib in the long run.

Drop back-ward compabilty to 'ldap'. One could try to implement a 
compability class API later but this should not be a first-time 
requirement which then turns out to be an obstacle for a clean object model.

Drop support for Python versions prior 2.3 (because of sets, datetime 
and various other modules)

Add support for Unicode whereever suitable.

....to be continued...

Ciao, Michael.


From deepak at arlut.utexas.edu  Thu Feb 17 23:30:05 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Thu, 17 Feb 2005 16:30:05 -0600
Subject: Implementation of LDAPControls
Message-ID: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu>

Hi, guys! 

Has there been any progress on implementing LDAPControl objects in
python-ldap? There were some messages posted on the list in late
December/early January about this, but I haven't heard much since then.

The project I'm working on is at a point where this feature is a
necessity, so if implementation of this feature is at a standstill I'm
willing to get the ball rolling again.

Is there any work that's already begun? I didn't see anything in the CVS
repository. If anyone has any existing code, I'd much appreciate it if I
could take a look at it.

Cheers!
Deepak

ps - earlier, my colleague posted on the OpenLDAP mailing list about
what we're trying to accomplish:
http://www.openldap.org/lists/openldap-software/200502/msg00392.html

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin





From michael at stroeder.com  Mon Feb 21 19:02:17 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 21 Feb 2005 19:02:17 +0100
Subject: Implementation of LDAPControls
In-Reply-To: <200502191048.21597.steuwer@univention.de>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu> <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu> <200502191048.21597.steuwer@univention.de>
Message-ID: <421A2229.6050906@stroeder.com>

Ingo Steuwer wrote:
> 
> Enclosed you find my mail including the necessary code-extraction 
> for basic ldap-controls in python-ldap.

Glad to see some progress in this field. Thanks.

Could you please send a unified diff against the CVS tree? I will take a 
closer look at it.

There's also another issue with licensing:
Which plans Univention has with this code? Would Univention be willing 
to give away copyright so that some time in the future we can 
stream-line the licensing?
I'm not a lawyer. But I guess strictly speaking we would need kind of a 
legal person to give the copyright to. Maybe contributing the code under 
Python style license would be easier...sigh!

Please consult your management and your legal department before we can 
incorporate code into the python-ldap CVS.

Ciao, Michael.


From steuwer at univention.de  Sat Feb 19 10:48:21 2005
From: steuwer at univention.de (Ingo Steuwer)
Date: Sat, 19 Feb 2005 10:48:21 +0100
Subject: Implementation of LDAPControls
In-Reply-To: <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu> <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>
Message-ID: <200502191048.21597.steuwer@univention.de>

Am Freitag, 18. Februar 2005 19:53 schrieb Deepak Giridharagopal:
> Hello, me again. :)
>
> On Thu, 2005-02-17 at 16:30 -0600, Deepak Giridharagopal wrote:
> > The project I'm working on is at a point where this feature is a
> > necessity, so if implementation of this feature is at a standstill I'm
> > willing to get the ball rolling again.
>
> As a proof of concept, I've gone ahead and begun coding up support for
> LDAP Controls. My goal for the test was to successfully do an
> ldap_modify_ext operation on our Active Directory server, using AD's
> Security Descriptor Modification control (http://tinyurl.com/5tlok).
>
> It works great!
>

Hello

I answered your mail yesterday but it was rejected because my attachement was 
too big. Enclosed you find my mail including the necessary code-extraction 
for basic ldap-controls in python-ldap.

Regards
Ingo Steuwer

> Hello
> 
> we've implemented basic support for LDAP-Controls in Python LDAP. We defined 
> an LDAPControl Python-class and some helper function and pre-defined OID's 
> for using it. It is prepared for but lacks support of bervals (we don't need 
> it at the moment). We're using this version in our test-cases and think it 
is 
> stable.
> 
> You can i.e. see deleted DN's in AD by using:
> 
> ------------------------------------------------------------------------
> import ldap
> lo = ldap.open("ad-host")
> login_dn = "cn=Administrator,cn=Users,dc=windomain"
> login_pw = 'secret'
> 
> lo.simple_bind_s(login_dn, login_pw)
> lc1 = ldap.create_control("LDAP_SERVER_SHOW_DELETED_OID")
> res = lo.search_ext_s(
> ?"dc=w2k3st,dc=univention,dc=de",ldap.SCOPE_SUBTREE,sys.argv[1],serverctrls=[lc1])
> # print res
> ------------------------------------------------------------------------
> 
> I wanted to send you this files earlier, but didn't had the time for it. 
> Attached you will find a tgz of "our" python-ldap -- I'm still to short on 
> time to make a patch...
> 
> Included is an other extension of python-ldap which makes it possible to 
> request ldap-schema-definitions from an open-ldap-server. We're using this 
> for a long time but AFAIK it is not our implementation (at least not mine).
> 
> To get a part of the "official" python-ldap package our 
> LDAP-Control-Implementation is provided with acknowledgment of the 
> python-license and there provided without any guaranty -- which means we are 
> not responsible for your problems with our code. Enough 
> "Legal-Department"-comments.
> 
> We're interested in your meanings and experiences looking at or using our 
code 
> and will try to help if there are any problems.
> 
> Regards
> Ingo Steuwer
> 


-- 
Ingo Steuwer       steuwer at univention.de         fon: +49 421 22 232- 0
Entwicklung        Linux for Your Business
Univention GmbH    http://www.univention.de/     fax: +49 421 22 232-99
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-ldap-controls.tgz
Type: application/x-tgz
Size: 48851 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050219/19813f55/attachment.bin>

From deepak at arlut.utexas.edu  Fri Feb 18 19:53:32 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Fri, 18 Feb 2005 12:53:32 -0600
Subject: Implementation of LDAPControls
In-Reply-To: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu>
Message-ID: <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>

Hello, me again. :)

On Thu, 2005-02-17 at 16:30 -0600, Deepak Giridharagopal wrote:
> The project I'm working on is at a point where this feature is a
> necessity, so if implementation of this feature is at a standstill I'm
> willing to get the ball rolling again.

As a proof of concept, I've gone ahead and begun coding up support for
LDAP Controls. My goal for the test was to successfully do an
ldap_modify_ext operation on our Active Directory server, using AD's
Security Descriptor Modification control (http://tinyurl.com/5tlok).

It works great!

I've only so far implemented control support in:
set_option
ldap_search_ext
ldap_modify_ext

...but adding support for the other LDAP operations (I hope) should be
easy.

My approach has been to model the OpenLDAP LDAPControl struct as a
tuple:

(OID <string>, Criticality Flag <boolean>, Value <string/list of bytes>)

The "Value" field needs to be an ASN.1 encoded list of bytes. I've taken
the position that however the user actually encodes his Python data
structure into ASN.1 is (for the moment) not my concern. This way, the C
code remains simple. 

I figure that once we settle on a pure-python ASN.1 encoding module, we
can handle marshalling/unmarshalling an LDAPControl object's payload at
a higher level than the C code, perhaps in a utility module like
"modlist.py" ("control_builder.py"?).

That said, for the moment I've been using Pices' ASN.1 encoding module.
It's a single Python file and trivial to use:

http://www.cnri.reston.va.us/software/pisces/manual/module-pisces.asn1.html

Here is the code I use to set a control:

#######################
import asn1 # This is the Pices module

# This is the OID for the MS security descriptor control I described
# above.
oid = "1.2.840.113556.1.4.801"
criticality = 1

# Here's where I actually construct the payload. The payload for this
# AD control needs to be an ASN.1 sequence with a single int inside.
payload = asn1.Sequence()
payload.append(0xf)

# Ta da, here is the control
control = ( oid, criticality, payload.encode() )

# Now do the operation
dn = "cn=foobar,cn=users,dc=activedirectory,dc=com"
modifications = [(ldap.MOD_REPLACE, "ntSecurityDescriptor", "blah")]
conn.modify_ext_s(dn, modifications, serverctrls=[control])
######################

Like I said, it works great!

The C code I've written looks very similar to the existing code in
LDAPObject.c that handles LDAPMod objects (I used the LDAPMod code as a
template for my stuff). If you guys want, I can start throwing patches
your way. 

Any thoughts on all of this?

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin





From michael at stroeder.com  Tue Feb 22 09:43:17 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 22 Feb 2005 09:43:17 +0100
Subject: Implementation of LDAPControls
In-Reply-To: <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu> <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>
Message-ID: <421AF0A5.8020403@stroeder.com>

Deepak Giridharagopal wrote:
> 
> That said, for the moment I've been using Pices' ASN.1 encoding module.
> It's a single Python file and trivial to use:
> 
> http://www.cnri.reston.va.us/software/pisces/manual/module-pisces.asn1.html

I use a slightly improved version of it in web2ldap for the built-in 
X.509 certificate/CRL parser.

There are some issues with the CNRI license which prevents this module 
to be shipped with Debian Linux. See http://bugs.debian.org/80195 for a 
discussion about it.

Jeremy, the author of picses, already planned to negotiate a more 
liberal license with CNRI. A similar license issue was solved for Python 
itself before. But AFAIK no progress so far.

I have to look into module pysnmp.ber. Found some old conversation with 
Ilya in my archive about implementing a ASN.1 module...
(In the year 2000! time is running...!)

Ciao, Michael.


From michael at stroeder.com  Tue Feb 22 09:57:05 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 22 Feb 2005 09:57:05 +0100
Subject: Implementation of LDAPControls
In-Reply-To: <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu> <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>
Message-ID: <421AF3E1.8060002@stroeder.com>

Deepak Giridharagopal wrote:
> 
> My approach has been to model the OpenLDAP LDAPControl struct as a
> tuple:
> 
> (OID <string>, Criticality Flag <boolean>, Value <string/list of bytes>)

I'd prefer to have a dedicated class hierachy for this in a separate 
sub-module ldap.controls. I will provide something for it which is 
compatible with your modifications to LDAPObject.c.

> The "Value" field needs to be an ASN.1 encoded list of bytes.
> [..]
> # Here's where I actually construct the payload. The payload for this
> # AD control needs to be an ASN.1 sequence with a single int inside.
> payload = asn1.Sequence()
> payload.append(0xf)
> 
> # Ta da, here is the control
> control = ( oid, criticality, payload.encode() )

I think we could move the invocation of .encode() for all controls in a 
list into the wrapper classldap.ldapobject.LDAPObject. Together with a 
well-defined control class possible type conflicts would clash early in 
the Python wrapper code. This makes debugging easier.

Ciao, Michael.


From deepak at arlut.utexas.edu  Mon Feb 21 21:00:28 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Mon, 21 Feb 2005 14:00:28 -0600
Subject: Implementation of LDAPControls
In-Reply-To: <421A2229.6050906@stroeder.com>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu>
	 <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>
	 <200502191048.21597.steuwer@univention.de>  <421A2229.6050906@stroeder.com>
Message-ID: <1109016028.8180.62.camel@csdpc10.arlut.utexas.edu>

On Mon, 2005-02-21 at 19:02 +0100, Michael Str?der wrote:
> Ingo Steuwer wrote:
> > 
> > Enclosed you find my mail including the necessary code-extraction 
> > for basic ldap-controls in python-ldap.
> 
> Glad to see some progress in this field. Thanks.
> 
> Could you please send a unified diff against the CVS tree? I will take a 
> closer look at it.

Well, I'm not Ingo, but for my university here I've finished support for
LDAP controls. This includes server and client control support for every
ldap_*_ext method in LDAPObject.c, and I've also implemented set_option
and get_option (from options.c) for both types of controls as well.

My modifications of the ldap_*_ext functions are always the same 3
steps:
1) Parse the serverctrls and clientctrls PyObjects into an array of
LDAPControl structs

2) Modify the actual libldap function call to use those parsed arrays
instead of NULL like we're doing now

3) De-allocate those newly created LDAPControl arrays.

You can see an example of usage in my previous email to the list.

I've attached a unified diff of my changes, which as I said before are
modeled closely after the existing implementation of LDAPMod structures.

> I'm not a lawyer. But I guess strictly speaking we would need kind of a 
> legal person to give the copyright to. Maybe contributing the code under 
> Python style license would be easier...sigh!

Copyright for the patch is all yours! I wouldn't turn down a mention at
the bottom of the README file, though. :)

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldapcontrols.patch
Type: text/x-patch
Size: 20113 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050221/7eccdc39/attachment.bin>

From deepak at arlut.utexas.edu  Tue Feb 22 21:02:04 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Tue, 22 Feb 2005 14:02:04 -0600
Subject: Implementation of LDAPControls
In-Reply-To: <421AF3E1.8060002@stroeder.com>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu>
	 <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>
	 <421AF3E1.8060002@stroeder.com>
Message-ID: <1109102524.8180.110.camel@csdpc10.arlut.utexas.edu>

On Tue, 2005-02-22 at 09:57 +0100, Michael Str?der wrote:
> > My approach has been to model the OpenLDAP LDAPControl struct as a
> > tuple:
> > 
> > (OID <string>, Criticality Flag <boolean>, Value <string/list of bytes>)
> 
> I'd prefer to have a dedicated class hierachy for this in a separate 
> sub-module ldap.controls. I will provide something for it which is 
> compatible with your modifications to LDAPObject.c.

Great! I held off on implementing a higher-level abstraction since I
wanted to get opinions first on the lower level patch. But it's awesome
that we're moving forward on this. :)

On Tue, 2005-02-22 at 09:43 +0100, Michael Str?der wrote: 
> Jeremy, the author of picses, already planned to negotiate a more 
> liberal license with CNRI. A similar license issue was solved for Python 
> itself before. But AFAIK no progress so far.

That's too bad. :( I'll take a look at pysnmp.ber and see how it
compares.

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin





From steuwer at univention.de  Wed Feb 23 07:41:30 2005
From: steuwer at univention.de (Ingo Steuwer)
Date: Wed, 23 Feb 2005 07:41:30 +0100
Subject: Implementation of LDAPControls
In-Reply-To: <421AF3E1.8060002@stroeder.com>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu> <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu> <421AF3E1.8060002@stroeder.com>
Message-ID: <200502230741.30459.steuwer@univention.de>

Am Dienstag, 22. Februar 2005 09:57 schrieb Michael Str?der:
> Deepak Giridharagopal wrote:
> > My approach has been to model the OpenLDAP LDAPControl struct as a
> > tuple:
> >
> > (OID <string>, Criticality Flag <boolean>, Value <string/list of bytes>)
>
> I'd prefer to have a dedicated class hierachy for this in a separate
> sub-module ldap.controls. I will provide something for it which is
> compatible with your modifications to LDAPObject.c.
>
> > The "Value" field needs to be an ASN.1 encoded list of bytes.
> > [..]
> > # Here's where I actually construct the payload. The payload for this
> > # AD control needs to be an ASN.1 sequence with a single int inside.
> > payload = asn1.Sequence()
> > payload.append(0xf)
> >
> > # Ta da, here is the control
> > control = ( oid, criticality, payload.encode() )
>
> I think we could move the invocation of .encode() for all controls in a
> list into the wrapper classldap.ldapobject.LDAPObject. Together with a
> well-defined control class possible type conflicts would clash early in
> the Python wrapper code. This makes debugging easier.

This is prepared in our implementation, we would see the BerVal (or "payload") 
as python-class which internaly saves types and values which should be used 
for encoding. But I don't expect that we will implement this in the near 
future...

Regards
Ingo


> Ciao, Michael.
>
>
> 

From michael at stroeder.com  Fri Feb 25 17:49:59 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 25 Feb 2005 17:49:59 +0100
Subject: Error: Schema fetching on Oracle Directory Server
In-Reply-To: <127079e105012409222e525ebc@mail.gmail.com>
References: <127079e10501100613681c6f1a@mail.gmail.com>	 <41E2AAD0.4030206@stroeder.com>	 <127079e10501101622478946dc@mail.gmail.com>	 <41E4C8F1.7050907@stroeder.com> <41EF6A7A.3040808@stroeder.com> <127079e105012409222e525ebc@mail.gmail.com>
Message-ID: <421F5737.4000507@stroeder.com>

Wido Depping wrote:
> 
> Attached are the updated testcase file and my improved split_tokens() function.
> This time I use string.split() and string.join() to benefit from their
> speed. The added checking in order to comply with the test cases has
> the result, that the new algorithm is only slightly faster than the
> old one. But now it should work with all known servers :)

Your patches were added to CVS. The test script I've checked in does not 
work although the new version of split_tokens() seems to work correctly. 
But I've committed it anyway to save the new test cases.

Note that there was also a change necessary to ldap.schema.models:

http://cvs.sourceforge.net/viewcvs.py/python-ldap/python-ldap/Lib/ldap/schema/models.py?r1=1.26&r2=1.27

(CVS changes might not yet be up-to-date in the web interface.)

Ciao, Michael.


From michael at stroeder.com  Fri Feb 25 18:29:36 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 25 Feb 2005 18:29:36 +0100
Subject: Implementation of LDAPControls
In-Reply-To: <1109016028.8180.62.camel@csdpc10.arlut.utexas.edu>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu>	 <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>	 <200502191048.21597.steuwer@univention.de>  <421A2229.6050906@stroeder.com> <1109016028.8180.62.camel@csdpc10.arlut.utexas.edu>
Message-ID: <421F6080.8050008@stroeder.com>

Deepak Giridharagopal wrote:
> 
> I've attached a unified diff of my changes, which as I said before are
> modeled closely after the existing implementation of LDAPMod structures.

I've committed your patches to CVS since they seem to be the most 
complete solution. But I'd really prefer to have code without 
goto-statements. Could you please work out a solution for this? And 
maybe it would be nice to extract the helper functions for LDAPControls 
to a separate C source text called ldapcontrols.c?

One thing I wonder about is whether it's possible to send a control 
where the control value is absent (e.g. by passing None as control 
value)? See RFC3296 chapter 3 for an example (ManageDsaIT Control).

Now for the Python parts:

I fixed some wrong argument lists in ldap.ldapobject.LDAPObject to make 
it work correctly at that level.
(Note that importing _ldap is considered bad!)

I also started to work on a basic Python class API in sub-module 
ldap.controls. I could not test it yet. But you get the idea.

Regarding ManageDsaIT Control: Once support for LDAPControls is complete 
I think we SHOULD drop l_ldap_manage_dsa_it() in LDAPObject.c and 
re-implement it completely in method 
ldap.ldapobject.LDAPObject.manage_dsa_it().

> I wouldn't turn down a mention at
> the bottom of the README file, though. :)

Already in CVS. Thanks again for working on it!

Ciao, Michael.


From deepak at arlut.utexas.edu  Fri Feb 25 22:06:31 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Fri, 25 Feb 2005 15:06:31 -0600
Subject: Implementation of LDAPControls
In-Reply-To: <421F6080.8050008@stroeder.com>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu>
	 <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>
	 <200502191048.21597.steuwer@univention.de> <421A2229.6050906@stroeder.com>
	 <1109016028.8180.62.camel@csdpc10.arlut.utexas.edu>
	 <421F6080.8050008@stroeder.com>
Message-ID: <1109365591.8180.189.camel@csdpc10.arlut.utexas.edu>

On Fri, 2005-02-25 at 18:29 +0100, Michael Str?der wrote:
> I've committed your patches to CVS since they seem to be the most 
> complete solution. 

Great! :) 

Regarding your suggestions, I've attached a new patch (I diff'ed against
the cvs HEAD). 

> But I'd really prefer to have code without 
> goto-statements. Could you please work out a solution for this? 

Done!

(FWIW, I'd prefer to have code without goto-statements, too, but I'm of
the opinion that error handling in C is one of the few situations in
which goto's actually *help* readability. But since you're the boss,
I'll heed your conventions. :) )

> And 
> maybe it would be nice to extract the helper functions for LDAPControls 
> to a separate C source text called ldapcontrols.c?

Done!

> One thing I wonder about is whether it's possible to send a control 
> where the control value is absent (e.g. by passing None as control 
> value)? See RFC3296 chapter 3 for an example (ManageDsaIT Control).

Done!

(Before, an error would have been thrown. Now, 'None' is permitted.)

> Thanks again for working on it!

No problem. :)

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldapcontrols_take2.patch
Type: text/x-patch
Size: 10846 bytes
Desc: 
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050225/9a56aa6a/attachment.bin>

From michael at stroeder.com  Sun Feb 27 22:41:05 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Sun, 27 Feb 2005 22:41:05 +0100
Subject: Implementation of LDAPControls
In-Reply-To: <1109365591.8180.189.camel@csdpc10.arlut.utexas.edu>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu>	 <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>	 <200502191048.21597.steuwer@univention.de> <421A2229.6050906@stroeder.com>	 <1109016028.8180.62.camel@csdpc10.arlut.utexas.edu>	 <421F6080.8050008@stroeder.com> <1109365591.8180.189.camel@csdpc10.arlut.utexas.edu>
Message-ID: <42223E71.5090909@stroeder.com>

Deepak Giridharagopal wrote:
 >
 > Regarding your suggestions, I've attached a new patch (I diff'ed
 > against the cvs HEAD).

Thanks again for contributing! Committed to CVS.

 >>One thing I wonder about is whether it's possible to send a control
 >>where the control value is absent (e.g. by passing None as control
 >>value)? See RFC3296 chapter 3 for an example (ManageDsaIT Control).
 >
 > Done!
 > (Before, an error would have been thrown. Now, 'None' is permitted.)

Now I can start re-implementing LDAPObject.manage_dsa_it()...

Ciao, Michael.



From michael at stroeder.com  Tue Mar  1 20:41:28 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 01 Mar 2005 20:41:28 +0100
Subject: Seg fault with ldap.get_option(ldap.OPT_SERVER_CONTROLS)
In-Reply-To: <42223E71.5090909@stroeder.com>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu>	 <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>	 <200502191048.21597.steuwer@univention.de> <421A2229.6050906@stroeder.com>	 <1109016028.8180.62.camel@csdpc10.arlut.utexas.edu>	 <421F6080.8050008@stroeder.com> <1109365591.8180.189.camel@csdpc10.arlut.utexas.edu> <42223E71.5090909@stroeder.com>
Message-ID: <4224C568.3080901@stroeder.com>

Michael Str?der wrote:
> Deepak Giridharagopal wrote:
>  >
>  > Regarding your suggestions, I've attached a new patch (I diff'ed
>  > against the cvs HEAD).
> 
> Thanks again for contributing! Committed to CVS.

I have problems using ldap.get_option(ldap.OPT_SERVER_CONTROLS):

$ python2.4 -c "import ldap;ldap.get_option(ldap.OPT_SERVER_CONTROLS)"
Segmentation fault

Any clue? I'm not a C programmer so I can't tell where the bug lies.

Ciao, Michael.


From michael at stroeder.com  Tue Mar  1 21:18:09 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 01 Mar 2005 21:18:09 +0100
Subject: Seg fault with ldap.get_option(ldap.OPT_SERVER_CONTROLS)
In-Reply-To: <1109707760.28021.29.camel@csdpc10.arlut.utexas.edu>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu>	 <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>	 <200502191048.21597.steuwer@univention.de> <421A2229.6050906@stroeder.com>	 <1109016028.8180.62.camel@csdpc10.arlut.utexas.edu>	 <421F6080.8050008@stroeder.com>	 <1109365591.8180.189.camel@csdpc10.arlut.utexas.edu>	 <42223E71.5090909@stroeder.com>  <4224C568.3080901@stroeder.com> <1109707760.28021.29.camel@csdpc10.arlut.utexas.edu>
Message-ID: <4224CE01.1010507@stroeder.com>

Deepak Giridharagopal wrote:
> On Tue, 2005-03-01 at 20:41 +0100, Michael Str?der wrote:
> 
>>I have problems using ldap.get_option(ldap.OPT_SERVER_CONTROLS):
>>
>>$ python2.4 -c "import ldap;ldap.get_option(ldap.OPT_SERVER_CONTROLS)"
>>Segmentation fault
> 
> I found it...there was one spot where I forgot to check to make sure a
> pointer wasn't NULL before I messed with it.

Thanks for the quick fix. Seems to work.

> Also, as an aside, I noticed that in the CVS head the setup.py file
> doesn't include the new ldapcontrol.c file in its list of files to be
> compiled.

Already noticed that. Please sync your CVS and test.

Ciao, Michael.


From michael at stroeder.com  Tue Mar  1 21:24:28 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 01 Mar 2005 21:24:28 +0100
Subject: Please review and test preliminary support for LDAP controls
Message-ID: <4224CF7C.8020205@stroeder.com>

Dear python-ldap users!

Thanks to the contributions of Deepak Giridharagopal, there's now 
preliminary support for LDAP controls in python-ldap.

Up to now the application has to do the BER encoding itself with the 
help of a third-party module. But looking at Demo/ldapcontrols.py and 
sub-module ldap.controls should give you an idea how it's supposed to work.

Anyway I'd appreciate every one's feedback whether the modifications in 
class LDAPControl and the sub-module ldap.controls seems suitable. So 
please bring your CVS working dir in sync and test. Thanks!

Ciao, Michael.


From deepak at arlut.utexas.edu  Tue Mar  1 21:09:20 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Tue, 01 Mar 2005 14:09:20 -0600
Subject: Seg fault with ldap.get_option(ldap.OPT_SERVER_CONTROLS)
In-Reply-To: <4224C568.3080901@stroeder.com>
References: <1108679405.4377.75.camel@csdpc10.arlut.utexas.edu>
	 <1108752813.4377.118.camel@csdpc10.arlut.utexas.edu>
	 <200502191048.21597.steuwer@univention.de> <421A2229.6050906@stroeder.com>
	 <1109016028.8180.62.camel@csdpc10.arlut.utexas.edu>
	 <421F6080.8050008@stroeder.com>
	 <1109365591.8180.189.camel@csdpc10.arlut.utexas.edu>
	 <42223E71.5090909@stroeder.com>  <4224C568.3080901@stroeder.com>
Message-ID: <1109707760.28021.29.camel@csdpc10.arlut.utexas.edu>

On Tue, 2005-03-01 at 20:41 +0100, Michael Str?der wrote:
> I have problems using ldap.get_option(ldap.OPT_SERVER_CONTROLS):
> 
> $ python2.4 -c "import ldap;ldap.get_option(ldap.OPT_SERVER_CONTROLS)"
> Segmentation fault
> 
> Any clue? I'm not a C programmer so I can't tell where the bug lies.

I found it...there was one spot where I forgot to check to make sure a
pointer wasn't NULL before I messed with it. Embarrassing! :) It's a
2-line fix, and I've attached the patch.

Maybe we should start throwing together some simple tests and throw them
into Tests/Lib/ldap/test_ldapcontrols.py or the like?

Also, as an aside, I noticed that in the CVS head the setup.py file
doesn't include the new ldapcontrol.c file in its list of files to be
compiled. This (a 1-line change) is also in the patch.

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldapcontrols_getoption_fix.patch
Type: text/x-patch
Size: 871 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050301/7089ab0f/attachment.bin>

From dhawes at vt.edu  Wed Mar  2 18:30:32 2005
From: dhawes at vt.edu (David Hawes)
Date: Wed, 2 Mar 2005 12:30:32 -0500
Subject: Odd error with sasl_interactive_bind_s
Message-ID: <200503021230.32194.dhawes@vt.edu>

I am attempting to connect to a directory using SASL EXTERNAL with Python (my 
version, from Debian packages, is 2.1.3) and python-ldap-2.0.6.  With both my 
code and the python-ldap-2.0.6/Demo/sasl_bind.py example, I get the following 
exception:

Traceback (most recent call last):
  File "sasl_bind.py", line 69, in ?
    l.sasl_interactive_bind_s("", sasl_auth)
  File "/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line 196, in
sasl_interactive_bind_s    return
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,serverctrls,clientctrls
,sasl_flags)  
 File "/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line
94, in _ldap_call    
 result = func(*args,**kwargs)
TypeError: argument 5 must be impossible<bad format char>, not int

Argument 5 is sasl_flags, which seems to be ldap.SASL_QUIET by default.  The 
TypeError output changes when I send sasl_interactive_bind_s different values 
for the sasl_flags argument. 

python-ldap is linked against OpenLDAP-2.2.23 (compiled with SSL and SASL 
support), and ldap.TLS_AVAIL and ldap.SASL_AVAIL both have 1 as their value.  
The OpenLDAP tools work as expected.  python-ldap works as expected when not 
using SASL.  

Has anyone seen similar errors?  What can I try to fix these errors?

Thanks for the help,

dave





From deepak at arlut.utexas.edu  Wed Mar  2 21:11:35 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Wed, 02 Mar 2005 14:11:35 -0600
Subject: Odd error with sasl_interactive_bind_s
In-Reply-To: <200503021230.32194.dhawes@vt.edu>
References: <200503021230.32194.dhawes@vt.edu>
Message-ID: <1109794295.23261.48.camel@csdpc10.arlut.utexas.edu>

Hi, Dave! 

I've reproduced your bug, and I've attached a patch that fixes the
problem. It might interest you to know that this bug doesn't affect more
recent versions of Python, for what that's worth. :)

The long answer:

On Wed, 2005-03-02 at 12:30 -0500, David Hawes wrote:
> Traceback (most recent call last):
>   File "sasl_bind.py", line 69, in ?
>     l.sasl_interactive_bind_s("", sasl_auth)
>   File "/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line 196, in
> sasl_interactive_bind_s    return
> self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,serverctrls,clientctrls
> ,sasl_flags)  
>  File "/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line
> 94, in _ldap_call    
>  result = func(*args,**kwargs)
> TypeError: argument 5 must be impossible<bad format char>, not int

Eek! This looks like a bug in the C code. The function that throws this
error is PyArg_ParseTuple, a C function bundled with Python that takes
Python objects and converts them to vanilla C-types.

The offending bit looks to be lines 648-649 in LDAPObject.c:

if (!PyArg_ParseTuple(args, "sOOOI", &who, &SASLObject, &serverctrls,
&clientctrls, &sasl_flags ))
    return NULL;

The 'sasl_flags' variable is declared as an unsigned int, but it looks
like we're trying to convert it using the "I" flag, which is meant to
convert longs. Replacing that "I" with "i" tells Python to convert that
argument to an int (rather than a long), and it seems to do the trick.

More info on these arcane conversion flags (for the curious):
http://docs.python.org/api/arg-parsing.html

Don't you just love C programming? :)

The fix makes Python 2.1.3 work again, and the fix doesn't appear to
break anything for more recent versions of Python (which, as I said,
don't seem to suffer from the problem).

Can you try the patch and let me know if it fixes things for you?
Thanks, Dave!

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldap_sasl_typerror_fix.patch
Type: text/x-patch
Size: 596 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050302/d249ea91/attachment.bin>

From dhawes at vt.edu  Wed Mar  2 21:28:31 2005
From: dhawes at vt.edu (David Hawes)
Date: Wed, 2 Mar 2005 15:28:31 -0500
Subject: Odd error with sasl_interactive_bind_s
In-Reply-To: <1109794295.23261.48.camel@csdpc10.arlut.utexas.edu>
References: <200503021230.32194.dhawes@vt.edu> <1109794295.23261.48.camel@csdpc10.arlut.utexas.edu>
Message-ID: <200503021528.31896.dhawes@vt.edu>

Deepak,

Thank you for the patch and the explanation--I was working my way towards 
that, but it would have taken a bit longer to poinpoint it...  ;)

The patch works perfectly and my SASL EXTERNAL bind works as expected. 

Thanks again for the help.

dave

On Wednesday 02 March 2005 15:11, Deepak Giridharagopal wrote:
> Hi, Dave!
>
> I've reproduced your bug, and I've attached a patch that fixes the
> problem. It might interest you to know that this bug doesn't affect more
> recent versions of Python, for what that's worth. :)
>
> The long answer:
>
> On Wed, 2005-03-02 at 12:30 -0500, David Hawes wrote:
> > Traceback (most recent call last):
> >   File "sasl_bind.py", line 69, in ?
> >     l.sasl_interactive_bind_s("", sasl_auth)
> >   File "/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line 196,
> > in sasl_interactive_bind_s    return
> > self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,serverctrls,clie
> >ntctrls ,sasl_flags)
> >  File "/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line
> > 94, in _ldap_call
> >  result = func(*args,**kwargs)
> > TypeError: argument 5 must be impossible<bad format char>, not int
>
> Eek! This looks like a bug in the C code. The function that throws this
> error is PyArg_ParseTuple, a C function bundled with Python that takes
> Python objects and converts them to vanilla C-types.
>
> The offending bit looks to be lines 648-649 in LDAPObject.c:
>
> if (!PyArg_ParseTuple(args, "sOOOI", &who, &SASLObject, &serverctrls,
> &clientctrls, &sasl_flags ))
>     return NULL;
>
> The 'sasl_flags' variable is declared as an unsigned int, but it looks
> like we're trying to convert it using the "I" flag, which is meant to
> convert longs. Replacing that "I" with "i" tells Python to convert that
> argument to an int (rather than a long), and it seems to do the trick.
>
> More info on these arcane conversion flags (for the curious):
> http://docs.python.org/api/arg-parsing.html
>
> Don't you just love C programming? :)
>
> The fix makes Python 2.1.3 work again, and the fix doesn't appear to
> break anything for more recent versions of Python (which, as I said,
> don't seem to suffer from the problem).
>
> Can you try the patch and let me know if it fixes things for you?
> Thanks, Dave!
>
> Cheers!
> deepak
>
> --
> Deepak Giridharagopal
> Applied Research Laboratories
> University of Texas at Austin





From deepak at arlut.utexas.edu  Thu Mar  3 00:07:15 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Wed, 02 Mar 2005 17:07:15 -0600
Subject: Odd error with sasl_interactive_bind_s
In-Reply-To: <1109794295.23261.48.camel@csdpc10.arlut.utexas.edu>
References: <200503021230.32194.dhawes@vt.edu>
	 <1109794295.23261.48.camel@csdpc10.arlut.utexas.edu>
Message-ID: <1109804835.23261.73.camel@csdpc10.arlut.utexas.edu>

On Wed, 2005-03-02 at 14:11 -0600, Deepak Giridharagopal wrote:
> The 'sasl_flags' variable is declared as an unsigned int, but it looks
> like we're trying to convert it using the "I" flag, which is meant to
> convert longs. Replacing that "I" with "i" tells Python to convert that
> argument to an int (rather than a long), and it seems to do the trick.

Upon further research, it looks like in Python 2.3 (and later) the "I"
flag will *either* convert the argument to a long *or* an unsigned int.
In previous versions of Python, "I" will attempt to always convert to a
long (resulting in the TypeError).

I guess this definitively solves the mystery as to why the bug doesn't
occur in 2.3 and above...

So I've (slightly) re-worked the patch to examine what version of Python
is being used and react accordingly.

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldap_sasl_typerror_fix.patch
Type: text/x-patch
Size: 1256 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050302/ef5235d1/attachment.bin>

From michael at stroeder.com  Thu Mar  3 01:45:27 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 03 Mar 2005 01:45:27 +0100
Subject: Odd error with sasl_interactive_bind_s
In-Reply-To: <1109804835.23261.73.camel@csdpc10.arlut.utexas.edu>
References: <200503021230.32194.dhawes@vt.edu>	 <1109794295.23261.48.camel@csdpc10.arlut.utexas.edu> <1109804835.23261.73.camel@csdpc10.arlut.utexas.edu>
Message-ID: <42265E27.7030003@stroeder.com>

Deepak Giridharagopal wrote:
> 
> Upon further research, it looks like in Python 2.3 (and later) the "I"
> flag will *either* convert the argument to a long *or* an unsigned int.
> In previous versions of Python, "I" will attempt to always convert to a
> long (resulting in the TypeError).
> [..]
> So I've (slightly) re-worked the patch to examine what version of Python
> is being used and react accordingly.

No easy way to make it work without another #if ?
Please commit your patch.

Ciao, Michael.


From michael at stroeder.com  Fri Mar  4 12:13:11 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2005 12:13:11 +0100
Subject: Backward compability older Python versions
Message-ID: <422842C7.7010505@stroeder.com>

HI!

For various reasons it is difficult to support older versions of Python. 
Especially supporting 1.x is a pain with newer modules written in 
Python. Or there are some subtle changes regarding data types (long 
integers since 2.3 etc.).

Now the question is which versions of Python are still used by the 
python-ldap community and should be supported?

Personally I'd like to be drop support for any Python version earlier 
than 2.3. This would make it possible to use standard modules like sets 
and datetime which could make life easier.

Ciao, Michael.


From jens at dataflake.org  Fri Mar  4 12:54:32 2005
From: jens at dataflake.org (Jens Vagelpohl)
Date: Fri, 4 Mar 2005 12:54:32 +0100
Subject: Backward compability older Python versions
In-Reply-To: <42284A3C.4010001@stroeder.com>
References: <422842C7.7010505@stroeder.com> <20050304111956.GA30261@mail.librelogiciel.com> <42284A3C.4010001@stroeder.com>
Message-ID: <a3876d47722f893353ce35fcbcb319c0@dataflake.org>


On Mar 4, 2005, at 12:45, Michael Str?der wrote:
>> IIRC Python 2.1.3 is the standard version of Python included in 
>> Debian Woody which is still (unfortunately) the stable Debian release 
>> so please keep this in mind when you'll decide.
>
> Hmm, regarding Linux distributions also the versions of the OpenLDAP 
> libs come to mind. I'd like drop support for older OpenLDAP libs too 
> to get rid of all the #ifdef's spreaded around in the C source.

Where would you place the "cut-off"? Keep in mind that RH still ships 
that antiquated 2.0.27 with RH9/RHEL3...  If you mean dropping support 
for OL 1.x, by all means, just do it :)

jens





From michael at stroeder.com  Fri Mar  4 12:45:00 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2005 12:45:00 +0100
Subject: Backward compability older Python versions
In-Reply-To: <20050304111956.GA30261@mail.librelogiciel.com>
References: <422842C7.7010505@stroeder.com> <20050304111956.GA30261@mail.librelogiciel.com>
Message-ID: <42284A3C.4010001@stroeder.com>

Jerome Alet wrote:
> 
> On Fri, Mar 04, 2005 at 12:13:11PM +0100, Michael Str?der wrote:
> 
>>Now the question is which versions of Python are still used by the 
>>python-ldap community and should be supported?
>>
> 
> IIRC Python 2.1.3 is the standard version of Python included in 
> Debian Woody which is still (unfortunately) the stable Debian 
> release so please keep this in mind when you'll decide. 

Hmm, regarding Linux distributions also the versions of the OpenLDAP 
libs come to mind. I'd like drop support for older OpenLDAP libs too to 
get rid of all the #ifdef's spreaded around in the C source.

Ciao, Michael.


From michael at stroeder.com  Fri Mar  4 13:06:49 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2005 13:06:49 +0100
Subject: Backward compability older Python versions
In-Reply-To: <a3876d47722f893353ce35fcbcb319c0@dataflake.org>
References: <422842C7.7010505@stroeder.com> <20050304111956.GA30261@mail.librelogiciel.com> <42284A3C.4010001@stroeder.com> <a3876d47722f893353ce35fcbcb319c0@dataflake.org>
Message-ID: <42284F59.6020402@stroeder.com>

Jens Vagelpohl wrote:
> 
>> Hmm, regarding Linux distributions also the versions of the OpenLDAP 
>> libs come to mind. I'd like drop support for older OpenLDAP libs too 
>> to get rid of all the #ifdef's spreaded around in the C source.
> 
> Where would you place the "cut-off"? Keep in mind that RH still ships 
> that antiquated 2.0.27 with RH9/RHEL3...

Personally I think we would do Red Hat users a favor with forcing them 
to install 2.2 libs. Note that the OpenLDAP project itself dropped 
support for 2.0.x and 2.1.x.

>  If you mean dropping support 
> for OL 1.x, by all means, just do it :)

This already happened long ago...

Ciao, Michael.


From michael at stroeder.com  Fri Mar  4 13:12:22 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2005 13:12:22 +0100
Subject: Odd error with sasl_interactive_bind_s
In-Reply-To: <1109880492.23261.85.camel@csdpc10.arlut.utexas.edu>
References: <200503021230.32194.dhawes@vt.edu>	 <1109794295.23261.48.camel@csdpc10.arlut.utexas.edu>	 <1109804835.23261.73.camel@csdpc10.arlut.utexas.edu>	 <42265E27.7030003@stroeder.com> <1109880492.23261.85.camel@csdpc10.arlut.utexas.edu>
Message-ID: <422850A6.6030303@stroeder.com>

Deepak Giridharagopal wrote:
> On Thu, 2005-03-03 at 01:45 +0100, Michael Str?der wrote:
> 
>>No easy way to make it work without another #if ?
> 
> It took me a while to find it (I didn't know it existed!), but there is
> a function, Py_GetVersion,

Sorry, I meant a solution without checking the Python version at all.

> This patch is a little longer than the previous one, but it works just
> as well. Plus, this way we're doing a run-time check instead of a
> compile-time check.

If we have to check the Python version a compile-time check would be the 
preferred solution (see below why).

> This will let people upgrade to Python 2.3+ without
> having to recompile python-ldap.

Extension modules are not binary-compatible between media versions of 
Python. A module compiled for 2.2 cannot run under Python 2.3 without 
being rebuilt.

Ciao, Michael.


From deepak at arlut.utexas.edu  Thu Mar  3 21:08:12 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Thu, 03 Mar 2005 14:08:12 -0600
Subject: Odd error with sasl_interactive_bind_s
In-Reply-To: <42265E27.7030003@stroeder.com>
References: <200503021230.32194.dhawes@vt.edu>
	 <1109794295.23261.48.camel@csdpc10.arlut.utexas.edu>
	 <1109804835.23261.73.camel@csdpc10.arlut.utexas.edu>
	 <42265E27.7030003@stroeder.com>
Message-ID: <1109880492.23261.85.camel@csdpc10.arlut.utexas.edu>

On Thu, 2005-03-03 at 01:45 +0100, Michael Str?der wrote:
> No easy way to make it work without another #if ?

It took me a while to find it (I didn't know it existed!), but there is
a function, Py_GetVersion, that will give you a version string (similar
to sys.version). The third character is always the minor version number,
so it looks like we can use that as an alternative to the #if.

This patch is a little longer than the previous one, but it works just
as well. Plus, this way we're doing a run-time check instead of a
compile-time check. This will let people upgrade to Python 2.3+ without
having to recompile python-ldap.

I've attached the patch for posterity's sake, but I've gone ahead and
commited the change to CVS.

Good suggestion, Michael. :)

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldap_sasl_typerror_fix.patch
Type: text/x-patch
Size: 1621 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050303/098c3465/attachment.bin>

From michael at stroeder.com  Fri Mar  4 12:45:00 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2005 12:45:00 +0100
Subject: Backward compability older Python versions
In-Reply-To: <20050304111956.GA30261@mail.librelogiciel.com>
References: <422842C7.7010505@stroeder.com> <20050304111956.GA30261@mail.librelogiciel.com>
Message-ID: <42284A3C.4010001@stroeder.com>

Jerome Alet wrote:
> 
> On Fri, Mar 04, 2005 at 12:13:11PM +0100, Michael Str?der wrote:
> 
>>Now the question is which versions of Python are still used by the 
>>python-ldap community and should be supported?
>>
> 
> IIRC Python 2.1.3 is the standard version of Python included in 
> Debian Woody which is still (unfortunately) the stable Debian 
> release so please keep this in mind when you'll decide. 

Hmm, regarding Linux distributions also the versions of the OpenLDAP 
libs come to mind. I'd like drop support for older OpenLDAP libs too to 
get rid of all the #ifdef's spreaded around in the C source.

Ciao, Michael.




From mcicogni at libero.it  Fri Mar  4 14:29:36 2005
From: mcicogni at libero.it (Mauro Cicognini)
Date: Fri, 04 Mar 2005 14:29:36 +0100
Subject: Odd error with sasl_interactive_bind_s
In-Reply-To: <1109880492.23261.85.camel@csdpc10.arlut.utexas.edu>
References: <200503021230.32194.dhawes@vt.edu>	 <1109794295.23261.48.camel@csdpc10.arlut.utexas.edu>	 <1109804835.23261.73.camel@csdpc10.arlut.utexas.edu>	 <42265E27.7030003@stroeder.com> <1109880492.23261.85.camel@csdpc10.arlut.utexas.edu>
Message-ID: <422862C0.50707@libero.it>

Deepak Giridharagopal wrote:

>This patch is a little longer than the previous one, but it works just
>as well. Plus, this way we're doing a run-time check instead of a
>compile-time check. This will let people upgrade to Python 2.3+ without
>having to recompile python-ldap.
>
This would be very well, and a Good Thing, although I beg to differ - on 
Windows a different version of the binaries will always  be needed if 
changing minor version since extensions are linked to the Python DLL 
which is called python22.dll, python23.dll, python24.dll and so on.

Moreover, reading the code it appears to me that checking just the minor 
version means that as written it will only work within the 2.x branch. 
Of course there's no telling what will happen in the time coming, so 
this point can be moot, but I would advise for checking the major 
version also.
After all, there's still a sizable amount of old code around still using 
(actually, requiring!) Python 1.5.2...

Anyway, thanks for the great work, it is doing us a lot of good.

Mauro





From marc at msys.ch  Fri Mar  4 14:26:11 2005
From: marc at msys.ch (Marc Balmer)
Date: Fri, 04 Mar 2005 14:26:11 +0100
Subject: Backward compability older Python versions
In-Reply-To: <42284A3C.4010001@stroeder.com>
References: <422842C7.7010505@stroeder.com> <20050304111956.GA30261@mail.librelogiciel.com> <42284A3C.4010001@stroeder.com>
Message-ID: <422861F3.4070609@msys.ch>

Michael Str?der wrote:

>>
>> IIRC Python 2.1.3 is the standard version of Python included in Debian 
>> Woody which is still (unfortunately) the stable Debian release so 
>> please keep this in mind when you'll decide. 
> 
> 
> Hmm, regarding Linux distributions also the versions of the OpenLDAP 
> libs come to mind. I'd like drop support for older OpenLDAP libs too to 
> get rid of all the #ifdef's spreaded around in the C source.

If "they" still stick to old python versions, then they should probably
use an old python-ldap as well.  I'd rather like to see a recent 
python-ldap implementation using a recent python interpreter and recent 
openldap libraries.

python-ldap is not only used on Debian Woody so please keep this in mind 
as well when you'll decide...

Regards,
Marc Balmer

mbalmer at openbsd.org




From alet at librelogiciel.com  Fri Mar  4 14:32:17 2005
From: alet at librelogiciel.com (Jerome Alet)
Date: Fri, 4 Mar 2005 14:32:17 +0100
Subject: Backward compability older Python versions
In-Reply-To: <422861F3.4070609@msys.ch>
References: <422842C7.7010505@stroeder.com> <20050304111956.GA30261@mail.librelogiciel.com> <42284A3C.4010001@stroeder.com> <422861F3.4070609@msys.ch>
Message-ID: <20050304133217.GA31752@mail.librelogiciel.com>

On Fri, Mar 04, 2005 at 02:26:11PM +0100, Marc Balmer wrote:
> 
> If "they" still stick to old python versions, then they should probably
> use an old python-ldap as well.  I'd rather like to see a recent 
> python-ldap implementation using a recent python interpreter and recent 
> openldap libraries.
> 
> python-ldap is not only used on Debian Woody so please keep this in mind 
> as well when you'll decide...

No problem.

As far as I'm concerned and if the old versions are still available 
for people who need them, it's +1 as well. 

bye

Jerome Alet




From jens at dataflake.org  Fri Mar  4 14:00:05 2005
From: jens at dataflake.org (Jens Vagelpohl)
Date: Fri, 4 Mar 2005 14:00:05 +0100
Subject: Backward compability older Python versions
In-Reply-To: <422842C7.7010505@stroeder.com>
References: <422842C7.7010505@stroeder.com>
Message-ID: <5363c5c2f22532aba5230168963461fa@dataflake.org>

On Mar 4, 2005, at 12:13, Michael Str?der wrote:

> HI!
>
> For various reasons it is difficult to support older versions of 
> Python. Especially supporting 1.x is a pain with newer modules written 
> in Python. Or there are some subtle changes regarding data types (long 
> integers since 2.3 etc.).
>
> Now the question is which versions of Python are still used by the 
> python-ldap community and should be supported?
>
> Personally I'd like to be drop support for any Python version earlier 
> than 2.3. This would make it possible to use standard modules like 
> sets and datetime which could make life easier.

+1

As with the question of what OpenLDAP versions to support, I believe if 
you are clearly marking the change it should be legitimate to go ahead 
and do it. People with older OL/Python versions are advised to use 
previous python-ldap versions.

jens





From jens at dataflake.org  Fri Mar  4 13:13:16 2005
From: jens at dataflake.org (Jens Vagelpohl)
Date: Fri, 4 Mar 2005 13:13:16 +0100
Subject: Backward compability older Python versions
In-Reply-To: <42284F59.6020402@stroeder.com>
References: <422842C7.7010505@stroeder.com> <20050304111956.GA30261@mail.librelogiciel.com> <42284A3C.4010001@stroeder.com> <a3876d47722f893353ce35fcbcb319c0@dataflake.org> <42284F59.6020402@stroeder.com>
Message-ID: <d5f38f87727440fb92aceed3d136a847@dataflake.org>


On Mar 4, 2005, at 13:06, Michael Str?der wrote:
> Jens Vagelpohl wrote:
>>> Hmm, regarding Linux distributions also the versions of the OpenLDAP 
>>> libs come to mind. I'd like drop support for older OpenLDAP libs too 
>>> to get rid of all the #ifdef's spreaded around in the C source.
>> Where would you place the "cut-off"? Keep in mind that RH still ships 
>> that antiquated 2.0.27 with RH9/RHEL3...
>
> Personally I think we would do Red Hat users a favor with forcing them 
> to install 2.2 libs. Note that the OpenLDAP project itself dropped 
> support for 2.0.x and 2.1.x.

Personally, I *totally* share that opinion. I'm not so certain how well 
that would go over with all those people that are too scared/clueless 
or simply unwilling to go beyond their distro's own packages.

At the same time I think if you make sure to clearly mark this step 
(both in the docs ("If you use OL version X you can only use 
python-ldap version Y") as well as maybe by a new version number scheme 
(a 2.1 beta series comes to mind)) people should be satisfied. They 
will still complain, of course ;)

jens





From michael at stroeder.com  Fri Mar  4 13:06:49 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2005 13:06:49 +0100
Subject: Backward compability older Python versions
In-Reply-To: <a3876d47722f893353ce35fcbcb319c0@dataflake.org>
References: <422842C7.7010505@stroeder.com> <20050304111956.GA30261@mail.librelogiciel.com> <42284A3C.4010001@stroeder.com> <a3876d47722f893353ce35fcbcb319c0@dataflake.org>
Message-ID: <42284F59.6020402@stroeder.com>

Jens Vagelpohl wrote:
> 
>> Hmm, regarding Linux distributions also the versions of the OpenLDAP 
>> libs come to mind. I'd like drop support for older OpenLDAP libs too 
>> to get rid of all the #ifdef's spreaded around in the C source.
> 
> Where would you place the "cut-off"? Keep in mind that RH still ships 
> that antiquated 2.0.27 with RH9/RHEL3...

Personally I think we would do Red Hat users a favor with forcing them 
to install 2.2 libs. Note that the OpenLDAP project itself dropped 
support for 2.0.x and 2.1.x.

>  If you mean dropping support 
> for OL 1.x, by all means, just do it :)

This already happened long ago...

Ciao, Michael.




From deepak at arlut.utexas.edu  Fri Mar  4 19:29:57 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Fri, 04 Mar 2005 12:29:57 -0600
Subject: Odd error with sasl_interactive_bind_s
In-Reply-To: <422850A6.6030303@stroeder.com>
References: <200503021230.32194.dhawes@vt.edu>
	 <1109794295.23261.48.camel@csdpc10.arlut.utexas.edu>
	 <1109804835.23261.73.camel@csdpc10.arlut.utexas.edu>
	 <42265E27.7030003@stroeder.com>
	 <1109880492.23261.85.camel@csdpc10.arlut.utexas.edu>
	 <422850A6.6030303@stroeder.com>
Message-ID: <1109960997.23261.136.camel@csdpc10.arlut.utexas.edu>

On Fri, 2005-03-04 at 13:12 +0100, Michael Str?der wrote:
> Extension modules are not binary-compatible between media versions of 
> Python. A module compiled for 2.2 cannot run under Python 2.3 without 
> being rebuilt.

Hmmm, didn't realize that. I will now wave my magic wand and we'll all
pretend I never sent out that last message. :)

On Fri, 2005-03-04 at 14:29 +0100, Mauro Cicognini wrote: 
> Moreover, reading the code it appears to me that checking just the minor 
> version means that as written it will only work within the 2.x branch. 
> Of course there's no telling what will happen in the time coming, so 
> this point can be moot, but I would advise for checking the major 
> version also.

When Python 3000 comes out it will have python-ldap as part of the
standard library and our work will be done! ;) Checking the major
version is trivial to do; I just didn't include it as python-ldap won't
work with 1.x (right?), and I assumed that Python 3.x will require some
major structural changes in the entire codebase. I take your point,
though.

Does anyone have any objections to the attached patch, then?

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldap_sasl_typerror_fix.patch
Type: text/x-patch
Size: 1151 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050304/085ebd39/attachment.bin>

From deepak at arlut.utexas.edu  Fri Mar  4 20:00:08 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Fri, 04 Mar 2005 13:00:08 -0600
Subject: Backward compability older Python versions
In-Reply-To: <422842C7.7010505@stroeder.com>
References: <422842C7.7010505@stroeder.com>
Message-ID: <1109962808.23261.155.camel@csdpc10.arlut.utexas.edu>

On Fri, 2005-03-04 at 12:13 +0100, Michael Str?der wrote:
> For various reasons it is difficult to support older versions of Python. 
> Especially supporting 1.x is a pain with newer modules written in 
> Python. 

Python-ldap works with Python 1.x? The INSTALL doc says that 2.0+ is a
prerequisite. I ask because the patches I've thrown out there haven't
been tested on 1.x...

> Personally I'd like to be drop support for any Python version earlier 
> than 2.3. This would make it possible to use standard modules like sets 
> and datetime which could make life easier.

+1

Cheers!
deepak

--
Deepak Giridharagopal





From deepak at arlut.utexas.edu  Fri Mar  4 20:06:59 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Fri, 04 Mar 2005 13:06:59 -0600
Subject: Backward compability older Python versions
In-Reply-To: <d5f38f87727440fb92aceed3d136a847@dataflake.org>
References: <422842C7.7010505@stroeder.com>
	 <20050304111956.GA30261@mail.librelogiciel.com>
	 <42284A3C.4010001@stroeder.com>
	 <a3876d47722f893353ce35fcbcb319c0@dataflake.org>
	 <42284F59.6020402@stroeder.com>
	 <d5f38f87727440fb92aceed3d136a847@dataflake.org>
Message-ID: <1109963219.23261.161.camel@csdpc10.arlut.utexas.edu>

On Fri, 2005-03-04 at 13:13 +0100, Jens Vagelpohl wrote:
> At the same time I think if you make sure to clearly mark this step 
> (both in the docs ("If you use OL version X you can only use 
> python-ldap version Y") as well as maybe by a new version number scheme 
> (a 2.1 beta series comes to mind)) people should be satisfied. They 
> will still complain, of course ;)

+1 for the "2.1 beta series" suggestion. 

deepak

--
Deepak Giridharagopal





From michael at stroeder.com  Fri Mar  4 20:13:06 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2005 20:13:06 +0100
Subject: Backward compability older Python versions
In-Reply-To: <1109962808.23261.155.camel@csdpc10.arlut.utexas.edu>
References: <422842C7.7010505@stroeder.com> <1109962808.23261.155.camel@csdpc10.arlut.utexas.edu>
Message-ID: <4228B342.8080705@stroeder.com>

Deepak Giridharagopal wrote:
 > On Fri, 2005-03-04 at 12:13 +0100, Michael Str?der wrote:
 >
 > Python-ldap works with Python 1.x? The INSTALL doc says that 2.0+ is a
 > prerequisite.

Hmm, the low-level stuff could work with Python 1.x.

 > I ask because the patches I've thrown out there haven't
 > been tested on 1.x...

Nevermind. Many parts of recent python-ldap are not tested with Python 
1.x. And so far nobody complained at all.

Ciao, Michael.



From michael at stroeder.com  Fri Mar  4 20:15:01 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2005 20:15:01 +0100
Subject: Odd error with sasl_interactive_bind_s
In-Reply-To: <1109960997.23261.136.camel@csdpc10.arlut.utexas.edu>
References: <200503021230.32194.dhawes@vt.edu>	 <1109794295.23261.48.camel@csdpc10.arlut.utexas.edu>	 <1109804835.23261.73.camel@csdpc10.arlut.utexas.edu>	 <42265E27.7030003@stroeder.com>	 <1109880492.23261.85.camel@csdpc10.arlut.utexas.edu>	 <422850A6.6030303@stroeder.com> <1109960997.23261.136.camel@csdpc10.arlut.utexas.edu>
Message-ID: <4228B3B5.1080801@stroeder.com>

Deepak Giridharagopal wrote:
> On Fri, 2005-03-04 at 13:12 +0100, Michael Str?der wrote:
> 
>>Extension modules are not binary-compatible between media versions of 
>>Python. A module compiled for 2.2 cannot run under Python 2.3 without 
>>being rebuilt.
> 
> Hmmm, didn't realize that. I will now wave my magic wand and we'll all
> pretend I never sent out that last message. :)

Which message? ;-)

> Does anyone have any objections to the attached patch, then?

Seems to be perfect. Please commit.

Ciao, Michael.


From michael at stroeder.com  Fri Mar  4 20:18:19 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2005 20:18:19 +0100
Subject: Backward compability older Python versions
In-Reply-To: <d5f38f87727440fb92aceed3d136a847@dataflake.org>
References: <422842C7.7010505@stroeder.com> <20050304111956.GA30261@mail.librelogiciel.com> <42284A3C.4010001@stroeder.com> <a3876d47722f893353ce35fcbcb319c0@dataflake.org> <42284F59.6020402@stroeder.com> <d5f38f87727440fb92aceed3d136a847@dataflake.org>
Message-ID: <4228B47B.1040501@stroeder.com>

Jens Vagelpohl wrote:
> 
> At the same time I think if you make sure to clearly mark this step 
> (both in the docs ("If you use OL version X you can only use python-ldap 
> version Y") as well as maybe by a new version number scheme (a 2.1 beta 
> series comes to mind)) people should be satisfied.

The file CHANGES in CVS already mentions version 2.1.0. This will be a 
new-feature release. That's why I want to make a clear decision now 
whether to make a cut with some old compability stuff.

> They will still complain, of course ;)

That's for sure. ;-}

Ciao, Michael.


From fightplatetectonics at gmail.com  Fri Mar  4 21:03:14 2005
From: fightplatetectonics at gmail.com (Joe Pasko)
Date: Fri, 4 Mar 2005 13:03:14 -0700
Subject: python-ldap + webware + solaris odd problem
Message-ID: <232a5c23050304120325be96b@mail.gmail.com>

Hi All, 

I'm seeing a weird problem using python-ldap under solaris with
webware as the app-server.

The python-ldap modules works fine under Solaris and linux if run from
the command line, and fine as a .cgi under apache. When running under
webware on Solaris,  I'm getting a can't connect to ldap server error.

I've run this same code under webware on linux, and it works fine.

One of my first thoughts is solaris's linker, but I've added the
openldap lib dir to LD_LIBRARY_PATH and restarted webware...to the
same result.

Has anyone run into this?

I've tried  solaris 8, solaris 10, and suse 9, all with the same
results. Works under linux under webware, pukes on the bind under
solaris.

The traceback is:

File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line
183, in bind
    return self.simple_bind(who,cred)
  File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py",
line 169, in simple_bind
    return self._ldap_call(self._l.simple_bind,who,cred,serverctrls,clientctrls)
  File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py",
line 94, in _ldap_call
    result = func(*args,**kwargs)
SERVER_DOWN: {'desc': "Can't contact LDAP server"}


The servlet code is:


#

From michael at stroeder.com  Sat Mar  5 23:52:00 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Sat, 05 Mar 2005 23:52:00 +0100
Subject: python-ldap + webware + solaris odd problem
In-Reply-To: <232a5c23050304120325be96b@mail.gmail.com>
References: <232a5c23050304120325be96b@mail.gmail.com>
Message-ID: <422A3810.2020206@stroeder.com>

Joe Pasko wrote:
> 
> I've tried  solaris 8, solaris 10, and suse 9, all with the same
> results. Works under linux under webware, pukes on the bind under
> solaris.

Joe, unfortunately without knowing your system(s) I can only give some 
general hints:

Make sure the very same Python interpreter is used for webware and for 
your test programs using python-ldap.

Make sure there is no mess with the LDAP libraries shipped with Solaris 
(which can't be used with python-ldap).

Use arguments trace_level and trace_file for ldap.initialize() or 
ldap.open() to let python-ldap write a detailed trace log with all the 
args passed to its API.

> SERVER_DOWN: {'desc': "Can't contact LDAP server"}
 > [..]
>                self.l = ldap.open( 'MYHOST.mydomain.com', 389 )

Is the server running at ldap://MYHOST.mydomain.com:389 is really 
reachable by the Solaris system?

Ciao, Michael.


From fightplatetectonics at gmail.com  Sat Mar  5 00:27:20 2005
From: fightplatetectonics at gmail.com (Joe Pasko)
Date: Fri, 4 Mar 2005 16:27:20 -0700
Subject: Whoops premature send, mail python-ldap + webware + solaris odd problem
Message-ID: <232a5c230503041527790df15d@mail.gmail.com>

I started to snoop the traffic between the solaris client machine and
ldap server.

On successful ldap queries(cmd line python) the first two packets go
back and forth to the ldap server as expected.

   client  -> server
   client  <- server
   client -> server

On the webware based ldap requests I see the first three packets

   client -> server
   client -> server
   client  <- server

It's noteworthy that the second packet being sent in the failed
scenario is a bit smaller than the first packet.

Packet #1: ETHER:  Packet size = 66 bytes
Packet #2: ETHER:  Packet size = 54 bytes

So the $2 question is why is the python-ldap library under webware
sending two packets ?




From michael at stroeder.com  Sat Mar  5 23:54:22 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Sat, 05 Mar 2005 23:54:22 +0100
Subject: Whoops premature send, mail python-ldap + webware + solaris odd
 problem
In-Reply-To: <232a5c230503041527790df15d@mail.gmail.com>
References: <232a5c230503041527790df15d@mail.gmail.com>
Message-ID: <422A389E.3090707@stroeder.com>

Joe,

Joe Pasko wrote:
> I started to snoop the traffic between the solaris client machine and
> ldap server.
> [..]
> Packet #1: ETHER:  Packet size = 66 bytes
> Packet #2: ETHER:  Packet size = 54 bytes
> 
> So the $2 question is why is the python-ldap library under webware
> sending two packets ?

sorry, this information does not help to track down the problem at your 
site.

Ciao, Michael.


From fightplatetectonics at gmail.com  Mon Mar  7 18:26:19 2005
From: fightplatetectonics at gmail.com (Joe Pasko)
Date: Mon, 7 Mar 2005 10:26:19 -0700
Subject: python-ldap + webware + solaris odd problem
Message-ID: <232a5c2305030709261c69f838@mail.gmail.com>

Ok this is weird.

To recap: python-ldap is working fine under solaris 8 and 10 when run
either from the command line or as a cgi under apache.

Python-ldap is failing when run it under webware. Note python-ldap is
working just fine under webware when run under linux.

I've  traced the problem to something in the network land.

When running under webware + solaris :

The initial ldap request packet(SYN) is sent to the server, BUT packet
#2 is a RST(Tcp reset) sent from the client to the ldap server.

So the successful handshake looks like the typical TCP: Syn, SYN,ACK, etc seq.

Running under webware under solaris I get:

Client sends SYN -> ldap server
Client sends RST -> ldap server
Server sends SYN,ACK -> Client
Server sends RST,ACK -> Client

Anyone have thoughts on what might be causing the TCP Reset( RST ) to be sent?

I'm still trying to figure out why the behavior would be different
under webware than the command line or as a cgi.

All help Appreciated,

Joe.




From jens at dataflake.org  Mon Mar  7 18:54:59 2005
From: jens at dataflake.org (Jens Vagelpohl)
Date: Mon, 7 Mar 2005 18:54:59 +0100
Subject: python-ldap + webware + solaris odd problem
In-Reply-To: <232a5c2305030709261c69f838@mail.gmail.com>
References: <232a5c2305030709261c69f838@mail.gmail.com>
Message-ID: <fee719ce01ebf1de5b317fdc55c29d84@dataflake.org>


On Mar 7, 2005, at 18:26, Joe Pasko wrote:
> Anyone have thoughts on what might be causing the TCP Reset( RST ) to 
> be sent?
>
> I'm still trying to figure out why the behavior would be different
> under webware than the command line or as a cgi.

I doubt this is a python-ldap problem. If I'm not mistaken python-ldap 
does not by itself talk to the network (or issue any low-level network 
messages), it uses LDAP libraries which in turn talk to the network. I 
would assume that's where the problem is.

jens





From deepak at arlut.utexas.edu  Fri Mar 11 00:15:26 2005
From: deepak at arlut.utexas.edu (Deepak Giridharagopal)
Date: Thu, 10 Mar 2005 17:15:26 -0600
Subject: Please review and test preliminary support for LDAP controls
In-Reply-To: <4224CF7C.8020205@stroeder.com>
References: <4224CF7C.8020205@stroeder.com>
Message-ID: <1110496527.23261.245.camel@csdpc10.arlut.utexas.edu>

On Tue, 2005-03-01 at 21:24 +0100, Michael Str?der wrote:
> Anyway I'd appreciate every one's feedback whether the modifications in 
> class LDAPControl and the sub-module ldap.controls seems suitable. So 
> please bring your CVS working dir in sync and test. Thanks!

It looks like ldapobject.py invokes the EncodeControlTuples function for
some extended ldap operations, but not all of them. Ideally, every call
to "_ldap_call" that takes controls as parameters should be converting
LDAPControl arguments to tuples, right? I've attached a patch.

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldapcontrols_encondecontroltuples.patch
Type: text/x-patch
Size: 4804 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050310/76e1c46d/attachment.bin>

From michael at stroeder.com  Fri Mar 11 09:58:36 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 11 Mar 2005 09:58:36 +0100
Subject: Please review and test preliminary support for LDAP controls
In-Reply-To: <1110496527.23261.245.camel@csdpc10.arlut.utexas.edu>
References: <4224CF7C.8020205@stroeder.com> <1110496527.23261.245.camel@csdpc10.arlut.utexas.edu>
Message-ID: <42315DBC.8000603@stroeder.com>

Deepak Giridharagopal wrote:
> On Tue, 2005-03-01 at 21:24 +0100, Michael Str?der wrote:
> 
>>Anyway I'd appreciate every one's feedback whether the modifications in 
>>class LDAPControl and the sub-module ldap.controls seems suitable. So 
>>please bring your CVS working dir in sync and test. Thanks!
> 
> It looks like ldapobject.py invokes the EncodeControlTuples function for
> some extended ldap operations, but not all of them. Ideally, every call
> to "_ldap_call" that takes controls as parameters should be converting
> LDAPControl arguments to tuples, right?

Right! Sorry, forgot to modify all the other LDAPObject methods as well.

> I've attached a patch.

Please commit it.

Ciao, Michael.


From winstonwolff at cal.berkeley.edu  Tue Mar  8 17:20:59 2005
From: winstonwolff at cal.berkeley.edu (Winston Wolff)
Date: Tue, 8 Mar 2005 11:20:59 -0500
Subject: [Webware-discuss] Re: python-ldap + webware + solaris odd problem
In-Reply-To: <232a5c2305030709261c69f838@mail.gmail.com>
References: <232a5c2305030709261c69f838@mail.gmail.com>
Message-ID: <f6231989485e27562f78f4956fae9e21@cal.berkeley.edu>

This is bizzare.  I don't have any clues to help you, but I'm 
interested in what you find out.

One funny thing that Webware does is install a custom import hook.  It 
adds an import hook to track what modules have been imported, and then 
watches them to see if they have changed.  I have no idea if it is 
related.

-ww

On Mar 7, 2005, at 12:26 PM, Joe Pasko wrote:

> Ok this is weird.
>
> To recap: python-ldap is working fine under solaris 8 and 10 when run
> either from the command line or as a cgi under apache.
>
> Python-ldap is failing when run it under webware. Note python-ldap is
> working just fine under webware when run under linux.
>
> I've  traced the problem to something in the network land.
>
> When running under webware + solaris :
>
> The initial ldap request packet(SYN) is sent to the server, BUT packet
> #2 is a RST(Tcp reset) sent from the client to the ldap server.
>
> So the successful handshake looks like the typical TCP: Syn, SYN,ACK, 
> etc seq.
>
> Running under webware under solaris I get:
>
> Client sends SYN -> ldap server
> Client sends RST -> ldap server
> Server sends SYN,ACK -> Client
> Server sends RST,ACK -> Client
>
> Anyone have thoughts on what might be causing the TCP Reset( RST ) to 
> be sent?
>
> I'm still trying to figure out why the behavior would be different
> under webware than the command line or as a cgi.
>
> All help Appreciated,
>
> Joe.
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/webware-discuss
>
>
_________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com - learning by 
creating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2126 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20050308/944d8e45/attachment.bin>

From xenophon at irtnog.org  Wed Mar 16 23:21:14 2005
From: xenophon at irtnog.org (Matthew X. Economou)
Date: Wed, 16 Mar 2005 17:21:14 -0500
Subject: 100% CPU utilization in Zope after LDAP connection timeout
Message-ID: <B9638CACBA387E48927BB56B6A15550799E9@svr1.irtnog.org>

I think there's a problem with python-ldap on FreeBSD/alpha that
causes a thread with an LDAP connection to get stuck in a CLOSE_WAIT
state.  I am unsure how to further troubleshoot this problem.

After running properly for about an hour or two (including correctly
authenticating users), my Zope instance stops responding to HTTP
requests and begins consuming all available CPU time.  A back-trace in
GDB showed Zope spinning around a call to select(2) within the
OpenLDAP client library.  A packet capture of all of the LDAP traffic
generated by the Zope instance showed a FIN/ACK from Zope, the
corresponding ACK from the server, a FIN/ACK from the server, but
never the corresponding ACK from Zope; these LDAP connections persist
indefinitely in a CLOSE_WAIT state.  Using DeadlockDebugger and
threadtrace, I generated Python traceback dumps of the threads; these
are included below.

I see the same problem (LDAP connections stuck in CLOSE_WAIT) both
under Python 2.3 and Python 2.4.  I upgraded Python hoping that
improvements made to its threading implementation would correct what
appears to be a deadlock or race condition within python-ldap or its
caller.  Python 2.4 does seem to be better able to handle the
aftereffects of the race: Zope no longer becomes completely
unresponsive (e.g. the top-level ZMI works).

Other programs on my web server that use the OpenLDAP client libraries
are not exhibiting this behavior, e.g. Samba 3.0.11 (winbindd).

Specs:

Digital AlphaServer 2000 5/250
FreeBSD/alpha 5.3-RELEASE
Python 2.4
Zope 2.7.4
Plone 2.0.5

Threads traceback dump at 2005-03-15 16:12:55:

Thread 4871774208 (GET
/VirtualHostBase/http/web.irtnog.org:80/irtnog/VirtualHostRoot/Members/x
enophon/freebsd/install):
  File
"/usr/local/www/Zope/lib/python/ZServer/PubCore/ZServerPublisher.py",
line 23, in __init__
    response=response)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 384,
in publish_module
    environ, debug, request, response)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 175,
in publish_module_standard
    response = publish(request, module_name, after_list, debug=debug)
  File
"/usr/local/www/zope/Products/PlacelessTranslationService/PatchStringIO.
py", line 51, in new_publish
    x = Publish.old_publish(request, module_name, after_list, debug)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 101,
in publish
    request, bind=1)
  File "/usr/local/www/Zope/lib/python/ZPublisher/mapply.py", line 88,
in mapply
    if debug is not None: return debug(object,args,context)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 39,
in call_object
    result=apply(object,args) # Type s<cr> to step into published
object.
  File "/usr/local/www/zope/Products/CMFCore/PortalContent.py", line
116, in __call__
    return view()
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 306, in __call__
    return self._bindAndExec(args, kw, None)
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 343, in _bindAndExec
    return self._exec(bound_data, args, kw)
  File "/usr/local/www/zope/Products/CMFCore/FSPageTemplate.py", line
191, in _exec
    result = self.pt_render(extra_context=bound_names)
  File "/usr/local/www/zope/Products/CMFCore/FSPageTemplate.py", line
124, in pt_render
    result = FSPageTemplate.inheritedAttribute('pt_render')(
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/PageTemplate.py",
line 96, in pt_render
    tal=not source, strictinsert=0)()
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 190,
in __call__
    self.interpret(self.program)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 671,
in do_useMacro
    self.interpret(macro)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 409,
in do_optTag_tal
    self.do_optTag(stuff)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 394,
in do_optTag
    return self.no_tag(start, program)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 389,
in no_tag
    self.interpret(program)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 671,
in do_useMacro
    self.interpret(macro)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 460,
in do_setLocal_tal
    self.engine.setLocal(name, self.engine.evaluateValue(expr))
  File "/usr/local/www/Zope/lib/python/Products/PageTemplates/TALES.py",
line 221, in evaluate
    return expression(self)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/Expressions.py",
line 201, in __call__
    return self._eval(econtext)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/Expressions.py",
line 196, in _eval
    return render(ob, econtext.vars)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/Expressions.py",
line 95, in render
    ob = call_with_ns(ob.__render_with_namespace__, ns)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/ZRPythonExpr.py",
line 73, in call_with_ns
    return f(td)
  File "/usr/local/www/zope/Products/CMFCore/FSPythonScript.py", line
99, in __render_with_namespace__
    return Script.__render_with_namespace__(self, namespace)
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 320, in __render_with_namespace__
    return self._bindAndExec((), namevals, namespace)
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 343, in _bindAndExec
    return self._exec(bound_data, args, kw)
  File "/usr/local/www/zope/Products/CMFCore/FSPythonScript.py", line
160, in _exec
    result = apply(f, args, kw)
  File "Script (Python)", line 30, in listMetaTags
  File "/usr/local/www/zope/Products/CMFDefault/DublinCore.py", line
106, in Creator
    owner = self.getOwner()
  File "/usr/local/www/Zope/lib/python/AccessControl/Owned.py", line 94,
in getOwner
    user = udb.getUserById(oid, None)
  File
"/usr/local/www/zope/Products/GroupUserFolder/GroupUserFolder.py", line
336, in getUserById
    ret = self.getUser(id, __force_group_id__ = 1)
  File
"/usr/local/www/zope/Products/GroupUserFolder/GroupUserFolder.py", line
317, in getUser
    u = src.getUser(name)
  File "/var/www/zope/Products/LDAPUserFolder/LDAPUserFolder.py", line
783, in getUser
    user = self.getUserByAttr(self._login_attr, name, pwd, cache=1)
  File "/var/www/zope/Products/LDAPUserFolder/LDAPUserFolder.py", line
714, in getUserByAttr
    user_roles, user_dn, user_attrs = self._lookupuserbyattr(
  File "/var/www/zope/Products/LDAPUserFolder/LDAPUserFolder.py", line
305, in _lookupuserbyattr
    , bind_pwd=bind_pwd
  File "/var/www/zope/Products/LDAPUserFolder/LDAPDelegate.py", line
318, in search
    connection = self.connect(bind_dn=bind_dn, bind_pwd=bind_pwd)
  File "/var/www/zope/Products/LDAPUserFolder/LDAPDelegate.py", line
195, in connect
    conn.simple_bind_s(user_dn, user_pwd)
  File "/var/www/zope/Products/LDAPUserFolder/SharedResource.py", line
110, in __call__
    self._lock.acquire()
  File "/usr/local/lib/python2.4/threading.py", line 100, in acquire
    rc = self.__block.acquire(blocking)

Thread 4913403904 (GET
/VirtualHostBase/http/web.irtnog.org:80/irtnog/VirtualHostRoot/Members/x
enophon/freebsd/winbind):
  File
"/usr/local/www/Zope/lib/python/ZServer/PubCore/ZServerPublisher.py",
line 23, in __init__
    response=response)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 384,
in publish_module
    environ, debug, request, response)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 175,
in publish_module_standard
    response = publish(request, module_name, after_list, debug=debug)
  File
"/usr/local/www/zope/Products/PlacelessTranslationService/PatchStringIO.
py", line 51, in new_publish
    x = Publish.old_publish(request, module_name, after_list, debug)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 101,
in publish
    request, bind=1)
  File "/usr/local/www/Zope/lib/python/ZPublisher/mapply.py", line 88,
in mapply
    if debug is not None: return debug(object,args,context)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 39,
in call_object
    result=apply(object,args) # Type s<cr> to step into published
object.
  File "/usr/local/www/zope/Products/CMFCore/PortalContent.py", line
116, in __call__
    return view()
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 306, in __call__
    return self._bindAndExec(args, kw, None)
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 343, in _bindAndExec
    return self._exec(bound_data, args, kw)
  File "/usr/local/www/zope/Products/CMFCore/FSPageTemplate.py", line
191, in _exec
    result = self.pt_render(extra_context=bound_names)
  File "/usr/local/www/zope/Products/CMFCore/FSPageTemplate.py", line
124, in pt_render
    result = FSPageTemplate.inheritedAttribute('pt_render')(
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/PageTemplate.py",
line 96, in pt_render
    tal=not source, strictinsert=0)()
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 190,
in __call__
    self.interpret(self.program)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 671,
in do_useMacro
    self.interpret(macro)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 409,
in do_optTag_tal
    self.do_optTag(stuff)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 394,
in do_optTag
    return self.no_tag(start, program)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 389,
in no_tag
    self.interpret(program)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 671,
in do_useMacro
    self.interpret(macro)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 460,
in do_setLocal_tal
    self.engine.setLocal(name, self.engine.evaluateValue(expr))
  File "/usr/local/www/Zope/lib/python/Products/PageTemplates/TALES.py",
line 221, in evaluate
    return expression(self)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/Expressions.py",
line 201, in __call__
    return self._eval(econtext)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/Expressions.py",
line 196, in _eval
    return render(ob, econtext.vars)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/Expressions.py",
line 95, in render
    ob = call_with_ns(ob.__render_with_namespace__, ns)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/ZRPythonExpr.py",
line 73, in call_with_ns
    return f(td)
  File "/usr/local/www/zope/Products/CMFCore/FSPythonScript.py", line
99, in __render_with_namespace__
    return Script.__render_with_namespace__(self, namespace)
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 320, in __render_with_namespace__
    return self._bindAndExec((), namevals, namespace)
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 343, in _bindAndExec
    return self._exec(bound_data, args, kw)
  File "/usr/local/www/zope/Products/CMFCore/FSPythonScript.py", line
160, in _exec
    result = apply(f, args, kw)
  File "Script (Python)", line 30, in listMetaTags
  File "/usr/local/www/zope/Products/CMFDefault/DublinCore.py", line
106, in Creator
    owner = self.getOwner()
  File "/usr/local/www/Zope/lib/python/AccessControl/Owned.py", line 94,
in getOwner
    user = udb.getUserById(oid, None)
  File
"/usr/local/www/zope/Products/GroupUserFolder/GroupUserFolder.py", line
336, in getUserById
    ret = self.getUser(id, __force_group_id__ = 1)
  File
"/usr/local/www/zope/Products/GroupUserFolder/GroupUserFolder.py", line
317, in getUser
    u = src.getUser(name)
  File "/var/www/zope/Products/LDAPUserFolder/LDAPUserFolder.py", line
783, in getUser
    user = self.getUserByAttr(self._login_attr, name, pwd, cache=1)
  File "/var/www/zope/Products/LDAPUserFolder/LDAPUserFolder.py", line
714, in getUserByAttr
    user_roles, user_dn, user_attrs = self._lookupuserbyattr(
  File "/var/www/zope/Products/LDAPUserFolder/LDAPUserFolder.py", line
305, in _lookupuserbyattr
    , bind_pwd=bind_pwd
  File "/var/www/zope/Products/LDAPUserFolder/LDAPDelegate.py", line
318, in search
    connection = self.connect(bind_dn=bind_dn, bind_pwd=bind_pwd)
  File "/var/www/zope/Products/LDAPUserFolder/LDAPDelegate.py", line
195, in connect
    conn.simple_bind_s(user_dn, user_pwd)
  File "/var/www/zope/Products/LDAPUserFolder/SharedResource.py", line
112, in __call__
    return self._callable(*args, **kw)
  File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line
760, in simple_bind_s
    return SimpleLDAPObject.simple_bind_s(self,*args,**kwargs)
  File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line
175, in simple_bind_s
    msgid = self.simple_bind(who,cred,serverctrls,clientctrls)
  File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line
169, in simple_bind
    return
self._ldap_call(self._l.simple_bind,who,cred,serverctrls,clientctrls)
  File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line
91, in _ldap_call
    self._ldap_object_lock.acquire()

Thread 4913401856 (GET
/VirtualHostBase/http/web.irtnog.org:80/irtnog/VirtualHostRoot/Members/x
enophon/freebsd/winbind):
  File
"/usr/local/www/Zope/lib/python/ZServer/PubCore/ZServerPublisher.py",
line 23, in __init__
    response=response)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 384,
in publish_module
    environ, debug, request, response)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 175,
in publish_module_standard
    response = publish(request, module_name, after_list, debug=debug)
  File
"/usr/local/www/zope/Products/PlacelessTranslationService/PatchStringIO.
py", line 51, in new_publish
    x = Publish.old_publish(request, module_name, after_list, debug)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 101,
in publish
    request, bind=1)
  File "/usr/local/www/Zope/lib/python/ZPublisher/mapply.py", line 88,
in mapply
    if debug is not None: return debug(object,args,context)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 39,
in call_object
    result=apply(object,args) # Type s<cr> to step into published
object.
  File "/usr/local/www/zope/Products/CMFCore/PortalContent.py", line
116, in __call__
    return view()
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 306, in __call__
    return self._bindAndExec(args, kw, None)
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 343, in _bindAndExec
    return self._exec(bound_data, args, kw)
  File "/usr/local/www/zope/Products/CMFCore/FSPageTemplate.py", line
191, in _exec
    result = self.pt_render(extra_context=bound_names)
  File "/usr/local/www/zope/Products/CMFCore/FSPageTemplate.py", line
124, in pt_render
    result = FSPageTemplate.inheritedAttribute('pt_render')(
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/PageTemplate.py",
line 96, in pt_render
    tal=not source, strictinsert=0)()
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 190,
in __call__
    self.interpret(self.program)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 671,
in do_useMacro
    self.interpret(macro)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 409,
in do_optTag_tal
    self.do_optTag(stuff)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 394,
in do_optTag
    return self.no_tag(start, program)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 389,
in no_tag
    self.interpret(program)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 671,
in do_useMacro
    self.interpret(macro)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 460,
in do_setLocal_tal
    self.engine.setLocal(name, self.engine.evaluateValue(expr))
  File "/usr/local/www/Zope/lib/python/Products/PageTemplates/TALES.py",
line 221, in evaluate
    return expression(self)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/Expressions.py",
line 201, in __call__
    return self._eval(econtext)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/Expressions.py",
line 196, in _eval
    return render(ob, econtext.vars)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/Expressions.py",
line 95, in render
    ob = call_with_ns(ob.__render_with_namespace__, ns)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/ZRPythonExpr.py",
line 73, in call_with_ns
    return f(td)
  File "/usr/local/www/zope/Products/CMFCore/FSPythonScript.py", line
99, in __render_with_namespace__
    return Script.__render_with_namespace__(self, namespace)
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 320, in __render_with_namespace__
    return self._bindAndExec((), namevals, namespace)
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 343, in _bindAndExec
    return self._exec(bound_data, args, kw)
  File "/usr/local/www/zope/Products/CMFCore/FSPythonScript.py", line
160, in _exec
    result = apply(f, args, kw)
  File "Script (Python)", line 30, in listMetaTags
  File "/usr/local/www/zope/Products/CMFDefault/DublinCore.py", line
106, in Creator
    owner = self.getOwner()
  File "/usr/local/www/Zope/lib/python/AccessControl/Owned.py", line 94,
in getOwner
    user = udb.getUserById(oid, None)
  File
"/usr/local/www/zope/Products/GroupUserFolder/GroupUserFolder.py", line
336, in getUserById
    ret = self.getUser(id, __force_group_id__ = 1)
  File
"/usr/local/www/zope/Products/GroupUserFolder/GroupUserFolder.py", line
317, in getUser
    u = src.getUser(name)
  File "/var/www/zope/Products/LDAPUserFolder/LDAPUserFolder.py", line
783, in getUser
    user = self.getUserByAttr(self._login_attr, name, pwd, cache=1)
  File "/var/www/zope/Products/LDAPUserFolder/LDAPUserFolder.py", line
714, in getUserByAttr
    user_roles, user_dn, user_attrs = self._lookupuserbyattr(
  File "/var/www/zope/Products/LDAPUserFolder/LDAPUserFolder.py", line
305, in _lookupuserbyattr
    , bind_pwd=bind_pwd
  File "/var/www/zope/Products/LDAPUserFolder/LDAPDelegate.py", line
318, in search
    connection = self.connect(bind_dn=bind_dn, bind_pwd=bind_pwd)
  File "/var/www/zope/Products/LDAPUserFolder/LDAPDelegate.py", line
219, in connect
    , op_timeout=getter('op_timeout')
  File "/var/www/zope/Products/LDAPUserFolder/LDAPDelegate.py", line
292, in _connect
    connection.simple_bind_s(user_dn, user_pwd)
  File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line
760, in simple_bind_s
    return SimpleLDAPObject.simple_bind_s(self,*args,**kwargs)
  File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line
176, in simple_bind_s
    self.result(msgid,all=1,timeout=self.timeout)
  File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line
399, in result
    res_type,res_data,res_msgid = self.result2(msgid,all,timeout)
  File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line
405, in result2
    return self._ldap_call(self._l.result2,msgid,all,timeout)
  File "/usr/local/lib/python2.4/site-packages/ldap/ldapobject.py", line
94, in _ldap_call
    result = func(*args,**kwargs)

Thread 4913399808 (GET
/VirtualHostBase/http/web.irtnog.org:80/irtnog/VirtualHostRoot/Members/x
enophon/freebsd/install):
  File
"/usr/local/www/Zope/lib/python/ZServer/PubCore/ZServerPublisher.py",
line 23, in __init__
    response=response)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 384,
in publish_module
    environ, debug, request, response)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 175,
in publish_module_standard
    response = publish(request, module_name, after_list, debug=debug)
  File
"/usr/local/www/zope/Products/PlacelessTranslationService/PatchStringIO.
py", line 51, in new_publish
    x = Publish.old_publish(request, module_name, after_list, debug)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 101,
in publish
    request, bind=1)
  File "/usr/local/www/Zope/lib/python/ZPublisher/mapply.py", line 88,
in mapply
    if debug is not None: return debug(object,args,context)
  File "/usr/local/www/Zope/lib/python/ZPublisher/Publish.py", line 39,
in call_object
    result=apply(object,args) # Type s<cr> to step into published
object.
  File "/usr/local/www/zope/Products/CMFCore/PortalContent.py", line
116, in __call__
    return view()
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 306, in __call__
    return self._bindAndExec(args, kw, None)
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 343, in _bindAndExec
    return self._exec(bound_data, args, kw)
  File "/usr/local/www/zope/Products/CMFCore/FSPageTemplate.py", line
191, in _exec
    result = self.pt_render(extra_context=bound_names)
  File "/usr/local/www/zope/Products/CMFCore/FSPageTemplate.py", line
124, in pt_render
    result = FSPageTemplate.inheritedAttribute('pt_render')(
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/PageTemplate.py",
line 96, in pt_render
    tal=not source, strictinsert=0)()
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 190,
in __call__
    self.interpret(self.program)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 671,
in do_useMacro
    self.interpret(macro)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 409,
in do_optTag_tal
    self.do_optTag(stuff)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 394,
in do_optTag
    return self.no_tag(start, program)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 389,
in no_tag
    self.interpret(program)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 671,
in do_useMacro
    self.interpret(macro)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 234,
in interpret
    handlers[opcode](self, args)
  File "/usr/local/www/Zope/lib/python/TAL/TALInterpreter.py", line 460,
in do_setLocal_tal
    self.engine.setLocal(name, self.engine.evaluateValue(expr))
  File "/usr/local/www/Zope/lib/python/Products/PageTemplates/TALES.py",
line 221, in evaluate
    return expression(self)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/Expressions.py",
line 201, in __call__
    return self._eval(econtext)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/Expressions.py",
line 196, in _eval
    return render(ob, econtext.vars)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/Expressions.py",
line 95, in render
    ob = call_with_ns(ob.__render_with_namespace__, ns)
  File
"/usr/local/www/Zope/lib/python/Products/PageTemplates/ZRPythonExpr.py",
line 73, in call_with_ns
    return f(td)
  File "/usr/local/www/zope/Products/CMFCore/FSPythonScript.py", line
99, in __render_with_namespace__
    return Script.__render_with_namespace__(self, namespace)
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 320, in __render_with_namespace__
    return self._bindAndExec((), namevals, namespace)
  File "/usr/local/www/Zope/lib/python/Shared/DC/Scripts/Bindings.py",
line 343, in _bindAndExec
    return self._exec(bound_data, args, kw)
  File "/usr/local/www/zope/Products/CMFCore/FSPythonScript.py", line
160, in _exec
    result = apply(f, args, kw)
  File "Script (Python)", line 30, in listMetaTags
  File "/usr/local/www/zope/Products/CMFDefault/DublinCore.py", line
106, in Creator
    owner = self.getOwner()
  File "/usr/local/www/Zope/lib/python/AccessControl/Owned.py", line 94,
in getOwner
    user = udb.getUserById(oid, None)
  File
"/usr/local/www/zope/Products/GroupUserFolder/GroupUserFolder.py", line
336, in getUserById
    ret = self.getUser(id, __force_group_id__ = 1)
  File
"/usr/local/www/zope/Products/GroupUserFolder/GroupUserFolder.py", line
317, in getUser
    u = src.getUser(name)
  File "/var/www/zope/Products/LDAPUserFolder/LDAPUserFolder.py", line
783, in getUser
    user = self.getUserByAttr(self._login_attr, name, pwd, cache=1)
  File "/var/www/zope/Products/LDAPUserFolder/LDAPUserFolder.py", line
714, in getUserByAttr
    user_roles, user_dn, user_attrs = self._lookupuserbyattr(
  File "/var/www/zope/Products/LDAPUserFolder/LDAPUserFolder.py", line
305, in _lookupuserbyattr
    , bind_pwd=bind_pwd
  File "/var/www/zope/Products/LDAPUserFolder/LDAPDelegate.py", line
318, in search
    connection = self.connect(bind_dn=bind_dn, bind_pwd=bind_pwd)
  File "/var/www/zope/Products/LDAPUserFolder/LDAPDelegate.py", line
195, in connect
    conn.simple_bind_s(user_dn, user_pwd)
  File "/var/www/zope/Products/LDAPUserFolder/SharedResource.py", line
110, in __call__
    self._lock.acquire()
  File "/usr/local/lib/python2.4/threading.py", line 100, in acquire
    rc = self.__block.acquire(blocking)

End of dump

-- 
"The challenge of a moral life is to do nothing that requires
forgiveness."  - Roger Ebert in his review of _The Woodsman_





From michael at stroeder.com  Wed Mar 16 23:51:58 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 16 Mar 2005 23:51:58 +0100
Subject: 100% CPU utilization in Zope after LDAP connection timeout
In-Reply-To: <B9638CACBA387E48927BB56B6A15550799E9@svr1.irtnog.org>
References: <B9638CACBA387E48927BB56B6A15550799E9@svr1.irtnog.org>
Message-ID: <4238B88E.5030803@stroeder.com>

Matthew X. Economou wrote:
> I think there's a problem with python-ldap on FreeBSD/alpha that
> causes a thread with an LDAP connection to get stuck in a CLOSE_WAIT
> state.  I am unsure how to further troubleshoot this problem.

Which OpenLDAP client lib version are you using?

Did you build python-ldap against OpenLDAP's libldap_r? This is strongly
recommended for multi-threaded client apps.

> Digital AlphaServer 2000 5/250

Which version of python-ldap are you using? There were some fixes in
python-ldap 2.0.4 for 64-bit platforms.

Could you please try to reproduce this problem without Zope? Maybe some
small multi-threaded client app sending similar LDAP requests to the server?

Ciao, Michael.



From xenophon at irtnog.org  Thu Mar 17 13:51:30 2005
From: xenophon at irtnog.org (Matthew X. Economou)
Date: Thu, 17 Mar 2005 07:51:30 -0500
Subject: 100% CPU utilization in Zope after LDAP connection timeout
Message-ID: <B9638CACBA387E48927BB56B6A15550799EA@svr1.irtnog.org>

Michael,

I installed python-ldap 2.0.6 on Python 2.4 and using OpenLDAP 2.2.23,
all of which came from the FreeBSD ports tree.  According to ldd(1),
python-ldap's helper library links to the reentrant versions of the
OpenLDAP client libraries:

    /usr/local/lib/python2.4/site-packages/_ldap.so:
        libldap_r-2.2.so.7 => /usr/local/lib/libldap_r-2.2.so.7
        liblber-2.2.so.7 => /usr/local/lib/liblber-2.2.so.7
        libssl.so.3 => /usr/lib/libssl.so.3
        libcrypto.so.3 => /lib/libcrypto.so.3

I traced the Zope process with ktrace(8).  There are a number of calls
to poll(2) and the SIGPROF signal handler (which resets itself,
apparently, as I see follow-up calls to gettimeofday(2) and
sigprocmask(2)).  These calls repeat.  I believe SIGPROF is used by the
threading implementation.

I attached to the Zope instance with GDB.  While it doesn't list any
threads (command "info threads"), GDB gives me the following backtrace:

(gdb) bt
#0  0x00000001601bd320 in _get_curthread () from /usr/lib/libc_r.so.5
#1  0x00000001601c1be4 in _thread_leave_cancellation_point () from
/usr/lib/libc_r.so.5
#2  0x00000001601b70e8 in select () from /usr/lib/libc_r.so.5
#3  0x0000000160ca4644 in ldap_int_select () from
/usr/local/lib/libldap_r-2.2.so.7
#4  0x0000000160c8c9a4 in wait4msg () from
/usr/local/lib/libldap_r-2.2.so.7
#5  0x0000000160c8c440 in ldap_result () from
/usr/local/lib/libldap_r-2.2.so.7
#6  0x0000000160c5ce50 in l_ldap_result2 () from
/usr/local/lib/python2.3/site-packages/_ldap.so
#7  0x00000001200cf9ac in PyCFunction_Call ()
#8  0x00000001200186f4 in PyObject_Call ()
#9  0x0000000120080228 in PyEval_GetFuncDesc ()
#10 0x000000012007c7a8 in PyEval_EvalCode ()
#11 0x000000012007dcb8 in PyEval_EvalCodeEx ()

> Could you please try to reproduce this problem without Zope? Maybe
> some small multi-threaded client app sending similar LDAP requests
> to the server?

I wish I knew enough Python to write a few test cases of my own.  I will
try.

Best wishes,
Matthew

-- 
"The challenge of a moral life is to do nothing that requires
forgiveness."  - Roger Ebert in his review of _The Woodsman_




From richm at netscape.net  Mon Feb 21 20:28:04 2005
From: richm at netscape.net (Richard Megginson)
Date: Mon, 21 Feb 2005 12:28:04 -0700
Subject: Native python LDAP?
In-Reply-To: <421A1AB7.7040907@stroeder.com>
References: <42139D35.7050500@netscape.net> <421A1AB7.7040907@stroeder.com>
Message-ID: <421A3644.4030107@netscape.net>

michael at stroeder.com wrote:

> Rich,
>
> nice to see you here. Sorry for following up so late. I'm swamped with 
> orga stuff so this rather long response took a while...
>
> Rich Megginson wrote:
>
>> Has anyone ever thought about doing a native (not based on ldap sdk 
>> binaries) python LDAP client?
>
>
> Yes, every now and then I'm thinking about this. In fact the 
> LDAPObject wrapper class was the first step towards that. Modules 
> ldap.schema, ldif and ldapurl are pure Python by purpose. I wanted to 
> reduce dependencies on LDAP C SDKs whereever I could...
>
> Actually there is 'ldaptor' which is a pure-Python LDAP implementation 
> based on Twisted. But the web site is very unclear, no docs, no 
> release history, no response from the author to my request of working 
> together, and last not least a strong dependency on Twisted. :-(

Interesting . . .

>
> There are various good reasons for reimplementing python-ldap from the 
> ground up.
>
> The RFC1823-style API still looks through the LDAPObject class letting 
> application code look very unpythonic.

Would definitely prefer to have a Python object model instead of a C API 
model.

>
> The data types returned from and passed to LDAPObject methods are not 
> specific to python-ldap:
> - list of dicts for search results

However, it is nice to be able to be able to expose those data 
structures in pure python for other applications.

> - no clear distinction between search results and search continuations
> - raw lists for change records
> etc.
>
> With LDAPControls we cannot stay away from messing with BER any 
> longer. Therefore we could reimplement much of the LDAP protocol stuff 
> following a nice object model.

Right.

>
> Compiling the various SDKs is a mess on some platforms (e.g. building 
> OpenLDAP libs on Win32). The binaries are often behind the current 
> release although some people are really doing great work providing 
> up-to-date pre-built binaries.

Right.  The Mozilla LDAP C SDK is more Windows friendly (since it is in 
Mozilla and Thunderbird).

>
> Licensing situation not suitable for contributing python-ldap to 
> Python's standard lib.
>
> etc.
>
>> Something like Net::LDAP (which is a very nice object model, even 
>> though it's perl).
>
>
> Don't know this since I never used Perl. If it's really a good object 
> model we could simply borrow from it.

You should definitely take a look at it, and the way it keeps the object 
model throughout. the various layers.
http://cpan.uwinnipeg.ca/module/Net::LDAP
and especialy the ASN.1 parser:
http://cpan.uwinnipeg.ca/module/Convert::ASN1

>
>> It depends on several modules being available.
>
>
> Yes, that's where the sadness begins...
>
>> For example, is there a python ASN.1 parser?
>
>
> The short answer: No there's no standard ASN.1 / BER / DER module for 
> Python which could just be imported by python-ldap without any 
> licensing and installation hassles.
>
> The long answer:
>
> There are some BER modules in SNMP modules. Don't know how to solve 
> the licensing issues.
>
> In web2ldap I'm using a slightly modified version of pisces.asn1 which 
> is under old CNRI license. The author planned to work out a better 
> license with CNRI but got stuck.
>
> => It boils down to developing a ASN.1 module and contribute it to 
> Python's standard libs (following licensing advice by PSF from the 
> very beginning).
>
>> Most everything else is already available in python - sockets, ssl, etc.
>
>
> Hmm, SSL support in Python's standard lib is very basic. AFAIK there's 
> no proper certificate and CRL checking at all. And there's also SASL, 
> Kerberos, etc. to think about.

I'm not sure if native python SSL support is best.  Perhaps there are 
wrappers around openssl or Mozilla NSS (which has much better support 
for CRL, OSCP, etc.).  Maybe the best thing to do would be to use SWIG 
to generate wrappers.  Just like in perl - I'm not aware of a native 
Perl SSL implementation - just wrappers around openssl.  Not sure about 
SASL either, but it seems that there would be a general need for a SASL 
module in python.  Or again, a wrapper around cyrus sasl.

As you can probably tell, I have a lot of experience with perl :-)  But 
very little with python, but I have come to realize the power and 
usefulness of python over perl for these sorts of applications.

>
> Off course I'd be willing to put work into it. But it would need 
> several developers to reach the same functional level as today's 
> python-ldap within a reasonable time frame.

Sure.

>
> Let's discuss design goals...mine are:
>
> Let's call the module 'ldap2'.
>
> 'ldap2' should go into Python's standard lib in the long run.
>
> Drop back-ward compabilty to 'ldap'. One could try to implement a 
> compability class API later but this should not be a first-time 
> requirement which then turns out to be an obstacle for a clean object 
> model.
>
> Drop support for Python versions prior 2.3 (because of sets, datetime 
> and various other modules)
>
> Add support for Unicode whereever suitable.

That sounds like the right things to do.

>
> ....to be continued...
>
> Ciao, Michael.
>
>
> 

From alet at librelogiciel.com  Thu Mar 31 14:06:46 2005
From: alet at librelogiciel.com (Jerome Alet)
Date: Thu, 31 Mar 2005 14:06:46 +0200
Subject: problem with the case of attributes' names
Message-ID: <20050331120646.GI13761@mail.librelogiciel.com>

Hello,

I encounter some problems with IBM Directory Server and python-ldap

The same app which works just fine with OpenLDAP breaks with IDS
because, it seems, of a problem with the case of attributes' names.

For example, IDS will return things like "objectclass" while
OpenLDAP will return "objectClass", and this seems to cause some
problems when retrieving and/or modifying attributes

Could this be a bug in IDS ?

Is there some rule on how to correctly handle this ?

Should apps expect attributes names in any case or not ?

Shouldn't ldap.modlist handle this automatically (not sure if it
does or not) when updating existing attributes ?

Does python-ldap do something special about name's case or not ?

Thanks in advance for any information on this subject.

Jerome Alet




From michael at stroeder.com  Thu Mar 31 15:33:26 2005
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 31 Mar 2005 15:33:26 +0200
Subject: problem with the case of attributes' names
In-Reply-To: <20050331120646.GI13761@mail.librelogiciel.com>
References: <20050331120646.GI13761@mail.librelogiciel.com>
Message-ID: <424BFC26.2070607@stroeder.com>

Jerome Alet wrote:
> 
> The same app which works just fine with OpenLDAP breaks with IDS
> because, it seems, of a problem with the case of attributes' names.
> 
> For example, IDS will return things like "objectclass" while
> OpenLDAP will return "objectClass", and this seems to cause some
> problems when retrieving and/or modifying attributes

Your application has to deal with it
(and with more weird alias issues).

> Could this be a bug in IDS ?

No, it isn't.

> Should apps expect attributes names in any case or not ?

Attribute type descriptions should be handled case-insensitive.

> Shouldn't ldap.modlist handle this automatically (not sure if it
> does or not) when updating existing attributes ?

It can handle this automagically if you use ldap.cidict for the entry
dictionaries passed to ldap.modlist.modifyModlist().

> Does python-ldap do something special about name's case or not ?

python-ldap mainly provides ldap.cidict which a dictionary class with
case-insensitive strings as keys.

Another more sophisticated solution is undocumented class
ldap.schema.models.Entry. But have to implement full schema support for
making real use of it.

Ciao, Michael.



From alet at librelogiciel.com  Thu Mar 31 19:17:30 2005
From: alet at librelogiciel.com (Jerome Alet)
Date: Thu, 31 Mar 2005 19:17:30 +0200
Subject: problem with the case of attributes' names
In-Reply-To: <424BFC26.2070607@stroeder.com>
References: <20050331120646.GI13761@mail.librelogiciel.com> <424BFC26.2070607@stroeder.com>
Message-ID: <20050331171730.GA22753@mail.librelogiciel.com>

Hi,

On Thu, Mar 31, 2005 at 03:33:26PM +0200, Michael Str?der wrote:
> 
> Your application has to deal with it
> (and with more weird alias issues).
> ... 
> > Shouldn't ldap.modlist handle this automatically (not sure if it
> > does or not) when updating existing attributes ?
> 
> It can handle this automagically if you use ldap.cidict for the entry
> dictionaries passed to ldap.modlist.modifyModlist().

Am I right in thinking that each time I use search_s() I should
transform the result this way so that the app doesn't care :

--- CUT ---    
result = server.search_s(base, scope, fiterexp, attributes)
if result :
    result = [ (dn, ldap.cidict.cidict(attrs)) for (dn, attrs) in result ]
--- CUT ---    
        
> > Does python-ldap do something special about name's case or not ?
> 
> python-ldap mainly provides ldap.cidict which a dictionary class with
> case-insensitive strings as keys.

OK, so if I always transform the search results with the above code,
and if I directly use these transformed results when calling 
modifyModlist() for both old and new entries, all should be fine ?

Do I understand correctly ?

If yes, then this is just great news :-)

(sorry, no more access to an ldap server for today, I can't test this
until tomorrow)

thanks all for your help

Jerome Alet