From adam.goucher at hp.com  Mon Jan  5 19:06:36 2004
From: adam.goucher at hp.com (Goucher, Adam)
Date: Mon, 5 Jan 2004 13:06:36 -0500
Subject: Hanging during ldaps
Message-ID: <CDD0CF4B4F7CDC4DAF137745F859219B044DF11F@troexc01.americas.cpqcorp.net>

I'm trying to use python-ldap to connect to an iplanet 5.1 ldap.
Connecting via ldap:// works, but the script is hanging when connecting
through ldaps://. Can anyone see what I am doing wrong?

<script>
import ldap
ldap.set_option(ldap.OPT_DEBUG_LEVEL, 5)

# build our uri
uri = "ldaps://ldap_host:6360"

# connect to the ldap server
p_handle = ldap.initialize(uri)
p_handle.protocol_version = ldap.VERSION3

# bind
p_handle.simple_bind("cn=directory manager", "*****")

# search so we know we are connected
p_search = p_handle.search("", ldap.SCOPE_BASE, "objectclass=*")
p_return = p_handle.result(p_search)
res_type, res_values = p_return
print res_values
</script>

<output>
ldap_create
ldap_url_parse_ext(ldaps://ldap_host:6360)
ldap_bind
ldap_simple_bind
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection
ldap_int_open_connection
ldap_connect_to_host: TCP ldap_host:6360
ldap_new_socket: 1904
ldap_prepare_socket: 1904
ldap_connect_to_host: Trying ldap_ip:6360
ldap_connect_timeout: fd: 1904 tm: -1 async: 0
ldap_ndelay_on: 1904
ldap_ndelay_off: 1904
ldap_open_defconn: successful
ldap_send_server_request
ldap_search_ext
put_filter: "objectclass=*"
put_filter: default
put_simple_filter: "objectclass=*"
ldap_send_initial_request
ldap_send_server_request
ldap_result msgid 2
ldap_chkResponseList for msgid=2, all=1
ldap_chkResponseList for msgid=2, all=1
ldap_int_select
</ouput>

I am using python 2.3.2 for windows, and the python-ldap module found at
http://www.zope.org/Members/volkerw/LdapWin32.dsdfs 

______________________________
Adam Goucher
Testing Group
HP OpenView Select Access
Hewlett-Packard
901 King St W.
Toronto, Ontario
M5V 3H5

Phone: +1-416-309-5208
Fax: +1-416-309-4406 




From cderr at simons-rock.edu  Mon Jan  5 19:22:15 2004
From: cderr at simons-rock.edu (charlie derr)
Date: Mon, 05 Jan 2004 13:22:15 -0500
Subject: Hanging during ldaps
In-Reply-To: <CDD0CF4B4F7CDC4DAF137745F859219B044DF11F@troexc01.americas.cpqcorp.net>
References: <CDD0CF4B4F7CDC4DAF137745F859219B044DF11F@troexc01.americas.cpqcorp.net>
Message-ID: <3FF9AB57.4050904@simons-rock.edu>

My first guess would be to use port 636 instead of 6360 -- if that 
doesn't work, I'd next try leaving the port specification off entirely 
(start_tls should encrypt traffic on port 389 if the server is 
configured correctly).

	good luck,
		~c


Goucher, Adam wrote:
> I'm trying to use python-ldap to connect to an iplanet 5.1 ldap.
> Connecting via ldap:// works, but the script is hanging when connecting
> through ldaps://. Can anyone see what I am doing wrong?
> 
> <script>
> import ldap
> ldap.set_option(ldap.OPT_DEBUG_LEVEL, 5)
> 
> # build our uri
> uri = "ldaps://ldap_host:6360"
> 
> # connect to the ldap server
> p_handle = ldap.initialize(uri)
> p_handle.protocol_version = ldap.VERSION3
> 
> # bind
> p_handle.simple_bind("cn=directory manager", "*****")
> 
> # search so we know we are connected
> p_search = p_handle.search("", ldap.SCOPE_BASE, "objectclass=*")
> p_return = p_handle.result(p_search)
> res_type, res_values = p_return
> print res_values
> </script>
> 
> <output>
> ldap_create
> ldap_url_parse_ext(ldaps://ldap_host:6360)
> ldap_bind
> ldap_simple_bind
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection
> ldap_int_open_connection
> ldap_connect_to_host: TCP ldap_host:6360
> ldap_new_socket: 1904
> ldap_prepare_socket: 1904
> ldap_connect_to_host: Trying ldap_ip:6360
> ldap_connect_timeout: fd: 1904 tm: -1 async: 0
> ldap_ndelay_on: 1904
> ldap_ndelay_off: 1904
> ldap_open_defconn: successful
> ldap_send_server_request
> ldap_search_ext
> put_filter: "objectclass=*"
> put_filter: default
> put_simple_filter: "objectclass=*"
> ldap_send_initial_request
> ldap_send_server_request
> ldap_result msgid 2
> ldap_chkResponseList for msgid=2, all=1
> ldap_chkResponseList for msgid=2, all=1
> ldap_int_select
> </ouput>
> 
> I am using python 2.3.2 for windows, and the python-ldap module found at
> http://www.zope.org/Members/volkerw/LdapWin32.dsdfs 
> 
> ______________________________
> Adam Goucher
> Testing Group
> HP OpenView Select Access
> Hewlett-Packard
> 901 King St W.
> Toronto, Ontario
> M5V 3H5
> 
> Phone: +1-416-309-5208
> Fax: +1-416-309-4406 
> 
> 
> 

From adam.goucher at hp.com  Mon Jan  5 19:25:27 2004
From: adam.goucher at hp.com (Goucher, Adam)
Date: Mon, 5 Jan 2004 13:25:27 -0500
Subject: Hanging during ldaps
Message-ID: <CDD0CF4B4F7CDC4DAF137745F859219B044DF123@troexc01.americas.cpqcorp.net>

6360 is the correct port for this server (we have multiple servers using
various ports on that machine).

-adam

-----Original Message-----
From: charlie derr [mailto:cderr at simons-rock.edu] 
Sent: Monday, January 05, 2004 1:22 PM
To: Goucher, Adam
Cc: python-ldap-dev at lists.sourceforge.net
Subject: Re: Hanging during ldaps


My first guess would be to use port 636 instead of 6360 -- if that 
doesn't work, I'd next try leaving the port specification off entirely 
(start_tls should encrypt traffic on port 389 if the server is 
configured correctly).

	good luck,
		~c


Goucher, Adam wrote:
> I'm trying to use python-ldap to connect to an iplanet 5.1 ldap. 
> Connecting via ldap:// works, but the script is hanging when 
> connecting through ldaps://. Can anyone see what I am doing wrong?
> 
> <script>
> import ldap
> ldap.set_option(ldap.OPT_DEBUG_LEVEL, 5)
> 
> # build our uri
> uri = "ldaps://ldap_host:6360"
> 
> # connect to the ldap server
> p_handle = ldap.initialize(uri)
> p_handle.protocol_version = ldap.VERSION3
> 
> # bind
> p_handle.simple_bind("cn=directory manager", "*****")
> 
> # search so we know we are connected
> p_search = p_handle.search("", ldap.SCOPE_BASE, "objectclass=*") 
> p_return = p_handle.result(p_search) res_type, res_values = p_return
> print res_values
> </script>
> 
> <output>
> ldap_create
> ldap_url_parse_ext(ldaps://ldap_host:6360)
> ldap_bind
> ldap_simple_bind
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection
> ldap_int_open_connection
> ldap_connect_to_host: TCP ldap_host:6360
> ldap_new_socket: 1904
> ldap_prepare_socket: 1904
> ldap_connect_to_host: Trying ldap_ip:6360
> ldap_connect_timeout: fd: 1904 tm: -1 async: 0
> ldap_ndelay_on: 1904
> ldap_ndelay_off: 1904
> ldap_open_defconn: successful
> ldap_send_server_request
> ldap_search_ext
> put_filter: "objectclass=*"
> put_filter: default
> put_simple_filter: "objectclass=*"
> ldap_send_initial_request
> ldap_send_server_request
> ldap_result msgid 2
> ldap_chkResponseList for msgid=2, all=1
> ldap_chkResponseList for msgid=2, all=1
> ldap_int_select
> </ouput>
> 
> I am using python 2.3.2 for windows, and the python-ldap module found 
> at http://www.zope.org/Members/volkerw/LdapWin32.dsdfs
> 
> ______________________________
> Adam Goucher
> Testing Group
> HP OpenView Select Access
> Hewlett-Packard
> 901 King St W.
> Toronto, Ontario
> M5V 3H5
> 
> Phone: +1-416-309-5208
> Fax: +1-416-309-4406
> 
> 
> 

From mcicogni at libero.it  Mon Jan  5 19:51:59 2004
From: mcicogni at libero.it (Mauro Cicognini)
Date: Mon, 05 Jan 2004 19:51:59 +0100
Subject: Hanging during ldaps
In-Reply-To: <CDD0CF4B4F7CDC4DAF137745F859219B044DF11F@troexc01.americas.cpqcorp.net>
References: <CDD0CF4B4F7CDC4DAF137745F859219B044DF11F@troexc01.americas.cpqcorp.net>
Message-ID: <3FF9B24F.40303@libero.it>

Goucher, Adam wrote:

>I'm trying to use python-ldap to connect to an iplanet 5.1 ldap.
>Connecting via ldap:// works, but the script is hanging when connecting
>through ldaps://. Can anyone see what I am doing wrong?
>
><script>
>import ldap
>ldap.set_option(ldap.OPT_DEBUG_LEVEL, 5)
>
># build our uri
>uri = "ldaps://ldap_host:6360"
>
># connect to the ldap server
>p_handle = ldap.initialize(uri)
>p_handle.protocol_version = ldap.VERSION3
>
># bind
>p_handle.simple_bind("cn=directory manager", "*****")
>
># search so we know we are connected
>p_search = p_handle.search("", ldap.SCOPE_BASE, "objectclass=*")
>  
>
This call looks strange to me: iPlanet has always wanted a real base 
there (i.e., no "" as you possibly could using Active Directory, but a 
correct search base for your server like "dc=ldapserver, dc=acme, 
dc=com" or similar).

If you say it does work using plain LDAP, however, this cannot be the 
reason for your script hanging, still I'm amazed it does, the RFC 
clearly states that you must explicitly set the search base and iPlanet 
have always prided themselves in being standards compliant (not like 
that other major software vendor ;-)

>p_return = p_handle.result(p_search)
>res_type, res_values = p_return
>print res_values
></script>
>
><output>
>ldap_create
>ldap_url_parse_ext(ldaps://ldap_host:6360)
>ldap_bind
>ldap_simple_bind
>ldap_sasl_bind
>ldap_send_initial_request
>ldap_new_connection
>ldap_int_open_connection
>ldap_connect_to_host: TCP ldap_host:6360
>ldap_new_socket: 1904
>ldap_prepare_socket: 1904
>ldap_connect_to_host: Trying ldap_ip:6360
>ldap_connect_timeout: fd: 1904 tm: -1 async: 0
>ldap_ndelay_on: 1904
>ldap_ndelay_off: 1904
>ldap_open_defconn: successful
>ldap_send_server_request
>ldap_search_ext
>put_filter: "objectclass=*"
>put_filter: default
>put_simple_filter: "objectclass=*"
>ldap_send_initial_request
>ldap_send_server_request
>ldap_result msgid 2
>ldap_chkResponseList for msgid=2, all=1
>ldap_chkResponseList for msgid=2, all=1
>ldap_int_select
></ouput>
>
>I am using python 2.3.2 for windows, and the python-ldap module found at
>http://www.zope.org/Members/volkerw/LdapWin32.dsdfs 
>  
>
I don't know this module, however you might want to give a try to my 
Win32 binary of Python-LDAP, you can find it at 
http://www.siosistemi.it/~mcicogni/ at the beginning of the page under 
"Python stuff".
Beware, your mileage may vary.

If this doesn't work, either, it *might* be that your server isn't 
configured correctly (i.e., TLS Certificates and such): do other LDAPS 
client work?

Mauro






From adam.goucher at hp.com  Mon Jan  5 20:05:26 2004
From: adam.goucher at hp.com (Goucher, Adam)
Date: Mon, 5 Jan 2004 14:05:26 -0500
Subject: Hanging during ldaps
Message-ID: <CDD0CF4B4F7CDC4DAF137745F859219B044DF12F@troexc01.americas.cpqcorp.net>

> ># search so we know we are connected
> >p_search = p_handle.search("", ldap.SCOPE_BASE, "objectclass=*")
> >  
> >
> This call looks strange to me: iPlanet has always wanted a real base 
> there (i.e., no "" as you possibly could using Active 
> Directory, but a 
> correct search base for your server like "dc=ldapserver, dc=acme, 
> dc=com" or similar).
> 
> If you say it does work using plain LDAP, however, this cannot be the 
> reason for your script hanging, still I'm amazed it does, the RFC 
> clearly states that you must explicitly set the search base 
> and iPlanet 
> have always prided themselves in being standards compliant (not like 
> that other major software vendor ;-)

I have found that "" and an actual basename are two different items with
pretty much all directory servers I have used. Searching against "" will
return information about the server in general (such as the vendor and
version) whereas searching against a proper basename gives you site
specific information
 
> I don't know this module, however you might want to give a try to my 
> Win32 binary of Python-LDAP, you can find it at 
> http://www.siosistemi.it/~mcicogni/ at the beginning of the 
> page under 
> "Python stuff".
> Beware, your mileage may vary.

Same problem, but a newer build, thanks. :)

> If this doesn't work, either, it *might* be that your server isn't 
> configured correctly (i.e., TLS Certificates and such): do 
> other LDAPS 
> client work?

Yes, I can login with different client to the ssl port. Is there a TLS
FAQ kicking around somewhere? I keep seeing it used interchangeably with
SSL but don't know anything about it.

-adam




From michael at stroeder.com  Mon Jan  5 22:31:07 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 05 Jan 2004 22:31:07 +0100
Subject: Hanging during ldaps
In-Reply-To: <CDD0CF4B4F7CDC4DAF137745F859219B044DF11F@troexc01.americas.cpqcorp.net>
References: <CDD0CF4B4F7CDC4DAF137745F859219B044DF11F@troexc01.americas.cpqcorp.net>
Message-ID: <3FF9D79B.8070507@stroeder.com>

Goucher, Adam wrote:
> I'm trying to use python-ldap to connect to an iplanet 5.1 ldap.

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

> Connecting via ldap:// works, but the script is hanging when connecting
> through ldaps://. Can anyone see what I am doing wrong?

Just guessing since you did not mention what "is hanging" means and you did 
not provide a Python traceback: You have to tell where to find the CA's 
certificate by calling

ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,path_to_cacert_file) or 
ldap.set_option(ldap.OPT_X_TLS_CACERTDIR,path_of_cacert_dir).

See Demo/initialize.py.

> I am using python 2.3.2 for windows, and the python-ldap module found at
> http://www.zope.org/Members/volkerw/LdapWin32.dsdfs 

Does this binary really have support for LDAP over SSL?

Ciao, Michael.


From michael at stroeder.com  Mon Jan  5 22:38:51 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 05 Jan 2004 22:38:51 +0100
Subject: Hanging during ldaps
In-Reply-To: <3FF9B24F.40303@libero.it>
References: <CDD0CF4B4F7CDC4DAF137745F859219B044DF11F@troexc01.americas.cpqcorp.net> <3FF9B24F.40303@libero.it>
Message-ID: <3FF9D96B.2060006@stroeder.com>

Mauro Cicognini wrote:
 > Goucher, Adam wrote:
 >
 >>
 >> # search so we know we are connected
 >> p_search = p_handle.search("", ldap.SCOPE_BASE, "objectclass=*")
 >>
 > This call looks strange to me: iPlanet has always wanted a real base
 > there (i.e., no "" as you possibly could using Active Directory, but a
 > correct search base for your server like "dc=ldapserver, dc=acme,
 > dc=com" or similar).

Since the search scope is base it would grab the server's Root DSE where you 
can read some configuration data, e.g. attribute'namingContexts'. This is 
almost a perfectly LDAPv3 compliant search request. Well, the filter string 
"objectclass=*" is *not* correct according to RFC2254. Please use 
"(objectclass=*)" since it could cause some strange effects with buggy LDAP 
servers.

Side note: Make sure you use SunONE Directory Server 5.1SP2 or newer to 
avoid running into other strange bugs! But that's another story... ;-)

Ciao, Michael.



From mcicogni at libero.it  Mon Jan  5 22:31:19 2004
From: mcicogni at libero.it (Mauro Cicognini)
Date: Mon, 05 Jan 2004 22:31:19 +0100
Subject: Hanging during ldaps
In-Reply-To: <CDD0CF4B4F7CDC4DAF137745F859219B044DF12F@troexc01.americas.cpqcorp.net>
References: <CDD0CF4B4F7CDC4DAF137745F859219B044DF12F@troexc01.americas.cpqcorp.net>
Message-ID: <3FF9D7A7.8020007@libero.it>

Goucher, Adam wrote:

>I have found that "" and an actual basename are two different items with
>pretty much all directory servers I have used. Searching against "" will
>return information about the server in general (such as the vendor and
>version) whereas searching against a proper basename gives you site
>specific information
>  
>
Aha. I'll try that.

>Yes, I can login with different client to the ssl port. Is there a TLS
>FAQ kicking around somewhere? I keep seeing it used interchangeably with
>SSL but don't know anything about it.
>
TLS and SSL are in fact different beasts, TLS being a superset of SSL 
but different enough to warrant a name change. Certificates should work 
interchangeably, since most of the differences should be in how the 
peers negotiate crypto algorithms for the asymmetric and symmetric 
parts. However, it's tricky stuff and I wouldn't be surprised that 
communication is stalling because client & server can't find a common 
algorithm or a cert isn't "right" or something.

I'm at a loss here, but I know there are some TLS/SSL tools that will 
allow you to kinda "debug" what's going on (I definitely saw a reference 
to one on the Netscape site).
You could also try firing up a Linux box, install Python and Python-LDAP 
and see what happens (the Linux build is much more solid and widely tested).

Mauro






From michael at stroeder.com  Mon Jan  5 22:42:58 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 05 Jan 2004 22:42:58 +0100
Subject: Hanging during ldaps
In-Reply-To: <3FF9D7A7.8020007@libero.it>
References: <CDD0CF4B4F7CDC4DAF137745F859219B044DF12F@troexc01.americas.cpqcorp.net> <3FF9D7A7.8020007@libero.it>
Message-ID: <3FF9DA62.3070702@stroeder.com>

Mauro Cicognini wrote:
> 
> I'm at a loss here, but I know there are some TLS/SSL tools that will 
> allow you to kinda "debug" what's going on

openssl s_client -connect ldap_host:6360 ...

Ciao, Michael.


From mcicogni at libero.it  Mon Jan  5 22:42:58 2004
From: mcicogni at libero.it (Mauro Cicognini)
Date: Mon, 05 Jan 2004 22:42:58 +0100
Subject: Hanging during ldaps
In-Reply-To: <3FF9D96B.2060006@stroeder.com>
References: <CDD0CF4B4F7CDC4DAF137745F859219B044DF11F@troexc01.americas.cpqcorp.net> <3FF9B24F.40303@libero.it> <3FF9D96B.2060006@stroeder.com>
Message-ID: <3FF9DA62.7060304@libero.it>

Michael Str?der wrote:

> Please use "(objectclass=*)" since it could cause some strange effects 
> with buggy LDAP servers.

Second that! I had missed it, but definitely omitting the parentheses 
does cause no end of problems.

Still, if your script does work without encryption, I agree with Michael 
that your problem probably rests in the SSL/TLS configuration.

Mauro






From michael at stroeder.com  Mon Jan  5 23:32:06 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 05 Jan 2004 23:32:06 +0100
Subject: Hanging during ldaps
In-Reply-To: <CDD0CF4B4F7CDC4DAF137745F859219B044DF160@troexc01.americas.cpqcorp.net>
References: <CDD0CF4B4F7CDC4DAF137745F859219B044DF160@troexc01.americas.cpqcorp.net>
Message-ID: <3FF9E5E6.1040009@stroeder.com>

Goucher, Adam wrote:
> 
> ldap.LDAPError: {'errnum': -1}

Hmm, I'm clueless here. Might be the Win32 binary of python-ldap.
Sorry, can't say anything about that.

Ciao, Michael.


From adam.goucher at hp.com  Mon Jan  5 23:02:02 2004
From: adam.goucher at hp.com (Goucher, Adam)
Date: Mon, 5 Jan 2004 17:02:02 -0500
Subject: Hanging during ldaps
Message-ID: <CDD0CF4B4F7CDC4DAF137745F859219B044DF160@troexc01.americas.cpqcorp.net>

> Just guessing since you did not mention what "is hanging" 
> means and you did 
> not provide a Python traceback: You have to tell where to 
> find the CA's 
> certificate by calling
> 
> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,path_to_cacert_file) or 
> ldap.set_option(ldap.OPT_X_TLS_CACERTDIR,path_of_cacert_dir).

Using openssl's s_client it shows that the connection is doing TLS 1.0. Consequently, I tried to do exactly as is suggested and received the following.

Traceback (most recent call last):
  File "c:\temp\ads.py", line 3, in ?
    ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, "c:\temp\unicert.cer")
  File "C:\Python23\Lib\site-packages\ldap\functions.py", line 104, in set_option
    _ldap_function_call(_ldap.set_option,option,invalue)
  File "C:\Python23\Lib\site-packages\ldap\__init__.py", line 62, in _ldap_function_call
    result = apply(func,args,kwargs)
ldap.LDAPError: {'errnum': -1}

And the cert itself is pem encoded.

-adam



From adam.goucher at hp.com  Tue Jan 13 16:46:17 2004
From: adam.goucher at hp.com (Goucher, Adam)
Date: Tue, 13 Jan 2004 10:46:17 -0500
Subject: Changing password in Active Directory
Message-ID: <CDD0CF4B4F7CDC4DAF137745F859219B044DF5AA@troexc01.americas.cpqcorp.net>

I gave up for the moment on getting ldaps working on win32 and moved to
solaris with some success. Thought I would share some code for resetting
passwords in Active Directory (which isnt as straight forward as it
seems). I had initially tried to use ldap.modlist to make the modlist,
but it kept trying to do an add, when you need to do a replace in the
case where you bind as administrator (which I am).

 # assumptions:
 # a) its active directory
 # b) you've bound to the ssl port
 # c) you've bound as administrator
 # d) your connection is called ldap_handle
 account_dn = "cn=adam,ou=test,dc=ads"
 password = "foo"
 password_attr = "unicodePwd"
 unicode_step1 = unicode("\"" + password + "\"", "iso-8859-1")
 unicode_step2 = unicode_step1.encode("utf-16-le")
 password_value = unicode_step2
 mods = [(ldap.MOD_REPLACE, password_attr, [password_value])]
 ldap_handle.modify(account_dn, mods)

Thought it might be handy to have this able to be found by the mailing
list search.

______________________________
Adam Goucher
Testing Group
HP OpenView Select Access
Hewlett-Packard
901 King St W.
Toronto, Ontario
M5V 3H5

Phone: +1-416-309-5208
Fax: +1-416-309-4406 




From michael at stroeder.com  Sat Jan 17 00:06:04 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Sat, 17 Jan 2004 00:06:04 +0100
Subject: Can't search exchange 2003 ldap server
In-Reply-To: <1074293654.18979.204.camel@localhost>
References: <1074293654.18979.204.camel@localhost>
Message-ID: <40086E5C.2030107@stroeder.com>

Roach, Mark R. wrote:
> 
>   File "/tmp/python-ldap-1.9.999.pre04/debian/tmp/usr/lib/python2.1/site-packages/ldap/__init__.py", line 31, in _ldap_call
> ldap.OPERATIONS_ERROR: {'desc': 'Operations error', 'info': '00000000: LdapErr: DSID-0C0905FF, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece'}

Seems you're using an outdated Debian package. This version had some issues. 
Please try whether the current version solves your problem.

Also it's of interest which version of the OpenLDAP libs python-ldap is 
using on your system. Please upgrade to latest OpenLDAP 2.1.x especially if 
still OpenLDAP 2.0.x is around.

Ciao, Michael.


From mrroach at cimplify.net  Fri Jan 16 23:54:14 2004
From: mrroach at cimplify.net (Roach, Mark R.)
Date: Fri, 16 Jan 2004 17:54:14 -0500
Subject: Can't search exchange 2003 ldap server
Message-ID: <1074293654.18979.204.camel@localhost>

I am having trouble searching an exchange 2003 ldap server. I can use
ldapsearch just fine against exchange, but python-ldap gives me a
strange error: Here is an example of what I get. Does anyone have any
suggestions?

>>> l = ldap.open('10.13.1.11', 389)
>>> l.protocol_version = 3
>>> l.simple_bind_s('service_smtp at cimplify.net', 'password')
>>> l.search_s('dc=cimplify, dc=net', ldap.SCOPE_SUBTREE, 'mail=mrroach at cimplify.net', ['cn'])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/tmp/python-ldap-1.9.999.pre04/debian/tmp/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line 410, in search_s
  File "/tmp/python-ldap-1.9.999.pre04/debian/tmp/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line 414, in search_st
  File "/tmp/python-ldap-1.9.999.pre04/debian/tmp/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line 355, in result
  File "/tmp/python-ldap-1.9.999.pre04/debian/tmp/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line 59, in _ldap_call
  File "/tmp/python-ldap-1.9.999.pre04/debian/tmp/usr/lib/python2.1/site-packages/ldap/__init__.py", line 31, in _ldap_call
ldap.OPERATIONS_ERROR: {'desc': 'Operations error', 'info': '00000000: LdapErr: DSID-0C0905FF, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece'}

I know that the parameters are correct: as I say, the following works fine:
ldapsearch -h 10.13.1.15 -x -W -D "service_smtp at cimplify.net" \
	-b dc=cimplify,dc=net "mail=mrroach at cimplify.net"

Thanks for any suggestions you can offer.

-Mark Roach





From marc_carrion at yahoo.es  Mon Jan 19 15:40:03 2004
From: marc_carrion at yahoo.es (Marc Carrion)
Date: Mon, 19 Jan 2004 06:40:03 -0800 (PST)
Subject: how to unsubscribe?
Message-ID: <20040119144003.67282.qmail@web11905.mail.yahoo.com>

  Thanks,
        Marc


=====
......\|||/................................................
      (. .)
-oOOo---0---oOOo-------
|marc_carrion at yahoo.es|
|   ooO  Ooo          |
----( )--( )-----------
     ()  ()

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus




From python at soltec.net  Thu Jan 15 21:50:54 2004
From: python at soltec.net (Chris)
Date: Thu, 15 Jan 2004 14:50:54 -0600
Subject: Issues with OpenLDAP 2.2.4
Message-ID: <1074199853.4163.200.camel@int-82.soltec.net>

I'm upgrading from OpenLDAP 2.1.22 to 2.2.4. Unfortunately, when I
rebuilt python-ldap I got a compile error in Modules/errors.c because
the definition of NUM_LDAP_ERRORS was negative, as it turns out the
ldap.h from 2.2.4 defines the API errors as negative numbers now, so the
problem here is obvious, Modules/errors.c reads:

#define NUM_LDAP_ERRORS		LDAP_REFERRAL_LIMIT_EXCEEDED+1
static PyObject* errobjects[ NUM_LDAP_ERRORS ];

When on my system ldap.h defines LDAP_REFERRAL_LIMIT_EXCEEDED as -17. So
I changed this to a positive number hoping my problem would be solved,
and my scripts just seg fault when an error is being returned. Further
looking into Modules/errors.c indicates to me that everything should be
fine so long as the array size I choose for errobjects is large enough
to accomodate all the error values it's populated with, but even with a
large enough value I get seg faults. Any help would be greatly
appreciated.

Thanks in advance,
Chris D.





From michael at stroeder.com  Tue Jan 20 11:37:57 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 20 Jan 2004 11:37:57 +0100
Subject: Issues with OpenLDAP 2.2.4
In-Reply-To: <1074199853.4163.200.camel@int-82.soltec.net>
References: <1074199853.4163.200.camel@int-82.soltec.net>
Message-ID: <400D0505.1060201@stroeder.com>

Chris wrote:
> I'm upgrading from OpenLDAP 2.1.22 to 2.2.4. Unfortunately, when I
> rebuilt python-ldap I got a compile error in Modules/errors.c because
> the definition of NUM_LDAP_ERRORS was negative, as it turns out the
> ldap.h from 2.2.4 defines the API errors as negative numbers now, so the
> problem here is obvious, Modules/errors.c reads:

Thanks for catching this.
Please bring your CVS working dir in sync and test.

Ciao, Michael.


From jojo at brainbot.com  Mon Jan 26 16:44:38 2004
From: jojo at brainbot.com (Johannes Beigel)
Date: Mon, 26 Jan 2004 16:44:38 +0100
Subject: Noisy output with SASL-Authentication
Message-ID: <401535E6.8000704@brainbot.com>

Hello.

I use python-ldap with SASL/Digest-MD5 authentication. With each 
sasl_bind_s() I get output like:

   SASL/DIGEST-MD5 authentication started
   SASL username: admin at gandalf
   SASL SSF: 128
   SASL installing layers

Is there a way to suppress this output (maybe with some option, I can 
set with set_option())?

Thanks in advance,
jojo.





From michael at stroeder.com  Mon Jan 26 17:41:59 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 26 Jan 2004 17:41:59 +0100
Subject: Noisy output with SASL-Authentication
In-Reply-To: <401535E6.8000704@brainbot.com>
References: <401535E6.8000704@brainbot.com>
Message-ID: <40154357.6040903@stroeder.com>

Johannes Beigel wrote:
> 
> I use python-ldap with SASL/Digest-MD5 authentication. With each 
> sasl_bind_s() I get output like:
> 
>   SASL/DIGEST-MD5 authentication started
>   SASL username: admin at gandalf
>   SASL SSF: 128
>   SASL installing layers

Post your code.

Watch out for:
ldap.initialize(... , trace_level=) and 
ldap.set_option(ldap.OPT_DEBUG_LEVEL, ... )

Ciao, Michael.


From michael at stroeder.com  Thu Jan 29 20:52:59 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 29 Jan 2004 20:52:59 +0100
Subject: Noisy output with SASL-Authentication
In-Reply-To: <4018E202.5070509@brainbot.com>
References: <401535E6.8000704@brainbot.com> <40154357.6040903@stroeder.com> <4018E202.5070509@brainbot.com>
Message-ID: <4019649B.3090101@stroeder.com>

Johannes Beigel wrote:

 >
 >   self.ldap = ldap.initialize(uri, trace_level=0)
 >   self.ldap.set_option(ldap.OPT_DEBUG_LEVEL, 0)


Try to set this globally not only in your LDAPObject instance:

ldap.set_option(ldap.OPT_DEBUG_LEVEL, 0)

Ciao, Michael.



From jojo at brainbot.com  Thu Jan 29 11:35:46 2004
From: jojo at brainbot.com (Johannes Beigel)
Date: Thu, 29 Jan 2004 11:35:46 +0100
Subject: Noisy output with SASL-Authentication
In-Reply-To: <40154357.6040903@stroeder.com>
References: <401535E6.8000704@brainbot.com> <40154357.6040903@stroeder.com>
Message-ID: <4018E202.5070509@brainbot.com>

Hi.

Michael Str?der wrote:
> Johannes Beigel wrote:
>> I use python-ldap with SASL/Digest-MD5 authentication. With each 
>> sasl_bind_s() I get output like:
>>
>>   SASL/DIGEST-MD5 authentication started
>>   SASL username: admin at gandalf
>>   SASL SSF: 128
>>   SASL installing layers
> Post your code.

Sorry, I forgot. The relevant code snippet is this:

   self.ldap = ldap.initialize(uri)
   sasl = ldap.sasl.digest_md5(ADMIN_WITH_REALM, ADMIN_PW)
   self.ldap.sasl_bind_s(ADMIN_DN, sasl)

After reading your mail, I also tried the following lines instead of the 
simple call to ldap.initialize() without a change in the output of the 
program:

   self.ldap = ldap.initialize(uri, trace_level=0)
   self.ldap.set_option(ldap.OPT_DEBUG_LEVEL, 0)

But I guess, 0 is the default value for OPT_DEBUG_LEVEL and trace_level 
anyway. (For trace_level this is documented in python-ldap documentation.)

Ciao,
jojo.




From gwidion at mpc.com.br  Sun Feb  1 16:09:02 2004
From: gwidion at mpc.com.br (Joao S. O. Bueno)
Date: Sun, 1 Feb 2004 13:09:02 -0200
Subject: Noisy output with SASL-Authentication
In-Reply-To: <4018E202.5070509@brainbot.com>
References: <401535E6.8000704@brainbot.com> <40154357.6040903@stroeder.com> <4018E202.5070509@brainbot.com>
Message-ID: <200402011309.02982.gwidion@mpc.com.br>

Hi there,

I apologize to posting this usage message to the devel list, but 
it is my most handy resource right now:

Which is the best way to check if a given connection is still alive? 
Maybe try a search with SCOPE_BASE in a node, and check for a time 
out? I'd need it not to be expensive to the ldap server, neither to 
delay the thread.

Regards,

	JS
	-><-






From michael at stroeder.com  Mon Feb  2 08:20:32 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 02 Feb 2004 08:20:32 +0100
Subject: LDAP connection alive?
In-Reply-To: <200402011309.02982.gwidion@mpc.com.br>
References: <401535E6.8000704@brainbot.com> <40154357.6040903@stroeder.com> <4018E202.5070509@brainbot.com> <200402011309.02982.gwidion@mpc.com.br>
Message-ID: <401DFA40.5070409@stroeder.com>

Joao S. O. Bueno wrote:
> 
> I apologize to posting this usage message to the devel list, but 
> it is my most handy resource right now:

It's the only mailing list for python-ldap. So you're welcome to post here. 
But please use an appropriate subject line for your own topic. Thanks.

> Which is the best way to check if a given connection is still alive?
> Maybe try a search with SCOPE_BASE in a node, and check for a time 
> out? I'd need it not to be expensive to the ldap server, neither to 
> delay the thread.

When I'm doing LDAP programming coaching this is a frequently asked question.

My answer is always: Don't do it. It's a bad habit. Implement proper 
reconnecting instead.

BTW: That's what ldap.ldapobject.ReconnectLDAPObject is for. But you have to 
understand what you're doing. And you have to understand the security 
implications of storing credentials in the ReconnectLDAPObject instance 
especially when pickling the instance on disk.

Ciao, Michael.


From jojo at brainbot.com  Mon Feb  2 11:32:12 2004
From: jojo at brainbot.com (Johannes Beigel)
Date: Mon, 02 Feb 2004 11:32:12 +0100
Subject: Noisy output with SASL-Authentication
In-Reply-To: <4019649B.3090101@stroeder.com>
References: <401535E6.8000704@brainbot.com> <40154357.6040903@stroeder.com> <4018E202.5070509@brainbot.com> <4019649B.3090101@stroeder.com>
Message-ID: <401E272C.9050105@brainbot.com>

Hi.

[Sorry about the delay in my responses, but I'm only part-time working 
in my company and I don't read my email every day.]

Michael Str?der wrote:
> Try to set this globally not only in your LDAPObject instance:
> 
> ldap.set_option(ldap.OPT_DEBUG_LEVEL, 0)

Makes no difference (same output). I tried to set the option at 
different places (before and after initialize()/digest_md5()/
sasl_bind_s(), but that yields all the same result).

I use python-ldap, OpenLDAP and libsasl on a Debian (woody/sid) system. 
Maybe libsasl is compiled with debugging output turned on there? I also 
noticed the option "-Q" to enable "SASL quiet mode" in the tool 
ldapsearch. Without this flag, ldapsearch produces the same output as my 
Python program.

Another question regarding SASL: Is there a python-ldap build for 
windows with SASL-support? (Or: Are there any precompiled versions of 
the Cyrus SASL library?)

Ciao,
jojo.




From mcicogni at libero.it  Mon Feb  2 13:47:51 2004
From: mcicogni at libero.it (Mauro Cicognini)
Date: Mon, 02 Feb 2004 13:47:51 +0100
Subject: Noisy output with SASL-Authentication
In-Reply-To: <401E272C.9050105@brainbot.com>
References: <401535E6.8000704@brainbot.com> <40154357.6040903@stroeder.com> <4018E202.5070509@brainbot.com> <4019649B.3090101@stroeder.com> <401E272C.9050105@brainbot.com>
Message-ID: <401E46F7.5000507@libero.it>

Johannes Beigel wrote:

> Another question regarding SASL: Is there a python-ldap build for 
> windows with SASL-support? (Or: Are there any precompiled versions of 
> the Cyrus SASL library?) 

I should have one, if you're interested, but absolutely untested.

Mauro






From michael at stroeder.com  Tue Feb  3 18:44:49 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 03 Feb 2004 18:44:49 +0100
Subject: Noisy output with SASL-Authentication
In-Reply-To: <401E272C.9050105@brainbot.com>
References: <401535E6.8000704@brainbot.com> <40154357.6040903@stroeder.com> <4018E202.5070509@brainbot.com> <4019649B.3090101@stroeder.com> <401E272C.9050105@brainbot.com>
Message-ID: <401FDE11.2000306@stroeder.com>

Johannes Beigel wrote:
> Maybe libsasl is compiled with debugging output turned on there? I also 
> noticed the option "-Q" to enable "SASL quiet mode" in the tool 
> ldapsearch. Without this flag, ldapsearch produces the same output as my 
> Python program.

Well, on my system I don't have such a noisy SASL debugging output. Even
when I compiled it myself. So maybe it's your local SASL installation. Maybe
you have time to dig into the OpenLDAP sources to find out what this -Q
switch really does. We can then decide whether it's feasible to expose that
in python-ldap.

Ciao, Michael.


From michael at stroeder.com  Wed Feb  4 19:34:13 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 04 Feb 2004 19:34:13 +0100
Subject: subtree searches stopped working -- I am really stuck
In-Reply-To: <4020E64A.5050802@mpc.com.br>
References: <4020E64A.5050802@mpc.com.br>
Message-ID: <40213B25.9060600@stroeder.com>

Joao S. O. Bueno wrote:
> 
> I am here developing my stuff when suddenly yesterday (ok, after an 
> unexpected -related or not - reboot) ,all my python ldap Subtree 
> searches return an empty result.

If it "suddenly" stopped working I guess this has nothing to do with
python-ldap. I'd rather expect the DB and/or the indexes of the LDAP server 
to be corrupted during the crash.

> I also could not find in the docs information about the options that are 
> available via get/set options.

Hmm, you could look into the man pages of the OpenLDAP libs.

Ciao, Michael.



From gwidion at mpc.com.br  Wed Feb  4 13:32:10 2004
From: gwidion at mpc.com.br (Joao S. O. Bueno)
Date: Wed, 04 Feb 2004 10:32:10 -0200
Subject: subtree searches stopped working -- I am really stuck
Message-ID: <4020E64A.5050802@mpc.com.br>

Hi all, hi Mike....

I am here developing my stuff when suddenly yesterday (ok, after an 
unexpected -related or not - reboot) ,all my python ldap Subtree 
searches return an empty result.

I am here unable to proceed with my work while I look for the possible 
causes for that.
I am using the 1.9.99pre-14 debian package. If this is a known issue (or 
a non issue that canbe prevented by option/cache control), I  like to know.

I also could not find in the docs information about the options that are 
available via get/set options.

Thanks

	JS
	-><-





From michael at stroeder.com  Sat Feb  7 12:56:17 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Sat, 07 Feb 2004 12:56:17 +0100
Subject: Segmentation fault
In-Reply-To: <4B98F891-58AF-11D8-AD38-0030657040B2@mat.ethz.ch>
References: <4B98F891-58AF-11D8-AD38-0030657040B2@mat.ethz.ch>
Message-ID: <4024D261.4070405@stroeder.com>

Marc Petitmermet wrote:
> 
> but when using 
> my development system with python-2.1.3, python-ldap-2.0.0pre19, 
> openldap-2.1.23, openssl-0.9.7c i get a segmentation fault:

It works for me with Python 2.3 and Python 2.1.3, python-ldap-2.0.0pre19, 
OpenLDAP libs 2.1.26 (self-compiled), openssl-0.9.7b-71 (RPM of SuSE Linux 9.0).

Guess it's a local installation error on your system. Please make sure to 
re-build and re-install all packages in this order:
- OpenSSL
- OpenLDAP
- Python
- python-ldap

Also make sure to have properly adjusted setup.cfg and invoked setup.py with 
the right Python executable.

Ciao, Michael.


From petitmermet at mat.ethz.ch  Fri Feb  6 15:18:11 2004
From: petitmermet at mat.ethz.ch (Marc Petitmermet)
Date: Fri, 6 Feb 2004 15:18:11 +0100
Subject: Segmentation fault
Message-ID: <4B98F891-58AF-11D8-AD38-0030657040B2@mat.ethz.ch>

dear list members

i have the python code below (from initialize.py) to test ldap 
connection over ssh to an external ldap-server.

on my production system with python-2.1.3, python-ldap-2.0.0pre06, 
openldap-2.1.12, openssl-0.9.7c i get a correct output. but when using 
my development system with python-2.1.3, python-ldap-2.0.0pre19, 
openldap-2.1.23, openssl-0.9.7c i get a segmentation fault:

*** ldaps://x.x.xx:636 - SimpleLDAPObject.set_option ((17, 3),{})
*** ldaps://x.x.xx:636 - SimpleLDAPObject.set_option ((17, 3),{})
*** ldaps://x.x.xx:636 - SimpleLDAPObject.bind (('', '', 128),{})
ldap_bind
ldap_simple_bind
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection
ldap_int_open_connection
ldap_connect_to_host: x.x.xx
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying xxx.xxx.xx.xxx:636
ldap_connect_timeout: fd: 3 tm: -1 async: 0
ldap_ndelay_on: 3
ldap_is_sock_ready: 3
ldap_ndelay_off: 3
ldap_int_sasl_open: host=x.x.xx
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 1, subject: xx 
emailAddress=xx at x.x.xx, issuer: xx emailAddress=xx at x.x.xx
TLS trace: SSL_connect:SSLv3 read server certificate A
TLS trace: SSL_connect:SSLv3 read server done A
TLS trace: SSL_connect:SSLv3 write client key exchange A
TLS trace: SSL_connect:SSLv3 write change cipher spec A
TLS trace: SSL_connect:SSLv3 write finished A
TLS trace: SSL_connect:SSLv3 flush data
TLS trace: SSL_connect:SSLv3 read finished A
Segmentation fault

can anybody tell me how to solve this? i don't think that this can be 
ignored. i guess that this is also the cause for my problems with the 
latest LDAPUserFolder which i wanted to use with zope.

thanks in advance for any hints.
regards,
marc



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

test code:

import sys,ldap

# Set debugging level
ldap.set_option(ldap.OPT_DEBUG_LEVEL,255)
ldapmodule_trace_level = 1
ldapmodule_trace_file = sys.stderr

print
"""##################################################################
    # LDAPv3 connection over SSL
    ##################################################################
"""

# Create LDAPObject instance (one single line command below)
l = ldap.initialize(
       'ldaps://x.x.xx:636',
       trace_level=ldapmodule_trace_level,
       trace_file=ldapmodule_trace_file)
# Set LDAP protocol version used
l.protocol_version=ldap.VERSION3
# Try a bind to provoke failure if protocol version is not supported
l.bind_s('','',ldap.AUTH_SIMPLE)
# Close connection
l.unbind_s()





From michael at stroeder.com  Thu Feb 12 16:06:29 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 12 Feb 2004 16:06:29 +0100
Subject: python-ldap segfault at binding time
In-Reply-To: <20040212145143.GB22329@mail.librelogiciel.com>
References: <20040212145143.GB22329@mail.librelogiciel.com>
Message-ID: <402B9675.3080704@stroeder.com>

Hi Jerome,

you can reach the python-ldap developers on the list 
python-ldap-dev at lists.sourceforge.net. It's worth to subscribe to it. It's 
low-volume.

Jerome Alet wrote:
> 
> I'm the author of a python-written print quota and accounting 
> solution named PyKota, [..]  this software uses python-ldap (of course)
> 
> Two people reported segfaults to me at binding time under 
> RedHat 9 (with Python 2.2)
> 
> The attached program repeatedly crashes with a segfault 
> during the simple_bind_s() call on users' machines

Well, this is most likely caused by outdated versions of OpenSSL, OpenLDAP 
libs, SASL libs or maybe even outdated python-ldap itself or a library mix.

People experiencing seg faults should build/reinstall recent versions of 
their installed software in the following order:
- OpenSSL
- Cyrus-SASL
- OpenLDAP
- Python
- python-ldap

> Unfortunately I don't use RedHat, but Debian instead, and I must
> confess I didn't notice such a problem so far.

RedHat 9 is known to still ship with a very outdated version of OpenLDAP.

Ciao, Michael.


From paul at subsignal.org  Sun Feb 15 16:31:27 2004
From: paul at subsignal.org (paul k)
Date: Sun, 15 Feb 2004 16:31:27 +0100
Subject: help on subschema
Message-ID: <402F90CF.2050907@subsignal.org>

Hi all,
how do I query the servers subschema entry  for supported objectclasses? 
Searching like:

conn.search_s('cn=subschema',ldap.SCOPE_SUBTREE, '(objectclass=*)')

returns ldap.NO_SUCH_OBJECT. I cannot firute out how to get operational 
attributes.I looked at ldap.schema.subentry.SubSchema but could not 
figure out how to use it.

thanks
  Paul




From michael at stroeder.com  Mon Feb 16 10:43:36 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 16 Feb 2004 10:43:36 +0100
Subject: help on subschema
In-Reply-To: <402F90CF.2050907@subsignal.org>
References: <402F90CF.2050907@subsignal.org>
Message-ID: <403090C8.2000600@stroeder.com>

paul k wrote:
> Hi all,
> how do I query the servers subschema entry  for supported objectclasses? 

See Demo/schema.py.

> Searching like:
> 
> conn.search_s('cn=subschema',ldap.SCOPE_SUBTREE, '(objectclass=*)')
 > returns ldap.NO_SUCH_OBJECT.

The sub schema sub entry is not always located in cn=subschema. You have to 
query the operational attribute subschemaSubentry for the DN holding the sub 
schema sub entry. That's what ldap.LDAPObject.search_subschemasubentry_s() 
is for.

Note that each part of the DIT can have its own separate sub schema sub 
entry! You have to query subschemaSubentry at each and every DN you're 
working with. Therefore you have to implement some kind of caching of sub 
schema instances to make it efficient.

I know the whole schema stuff is completely undocumented. But have a look at 
Demo/schema.py. That should make things more clear.

Ciao, Michael.


From alet at librelogiciel.com  Wed Feb 18 15:49:08 2004
From: alet at librelogiciel.com (Jerome Alet)
Date: Wed, 18 Feb 2004 15:49:08 +0100
Subject: explicit vs implicit attributes names
Message-ID: <20040218144907.GD10897@mail.librelogiciel.com>

Hi,

I'd want to retrieve complete LDAP entries from my server,
including createTimestamp and modifyTimestamp (where available)

But if I pass None as the attributes to retrieve, I only
receive attributes which I've created myself, not "server"'s
attributes like the two mentionned above.

I have to explicitely pass all attributes names + "createTimestamp"
and al, and I find this completely inconvenient.

Is there a simple solution to not have to explicitely name all
attributes ?

Thanks in advance

Jerome Alet
-- 
"Now that I'm connected to the Internet, everybody seems 
to know that I've got a small dick." - Me.




From michael at stroeder.com  Wed Feb 18 18:04:37 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 18 Feb 2004 18:04:37 +0100
Subject: explicit vs implicit attributes names
In-Reply-To: <20040218144907.GD10897@mail.librelogiciel.com>
References: <20040218144907.GD10897@mail.librelogiciel.com>
Message-ID: <40339B25.20703@stroeder.com>

Jerome Alet wrote:
> 
> I'd want to retrieve complete LDAP entries from my server,
> including createTimestamp and modifyTimestamp (where available)

These are so-called operational attributes.

> But if I pass None as the attributes to retrieve, I only
> receive attributes which I've created myself, not "server"'s
> attributes like the two mentionned above.

This is not really a python-ldap issue.

> I have to explicitely pass all attributes names + "createTimestamp"
> and al, and I find this completely inconvenient.

Maybe ['*',"createTimestamp"] helps.

> Is there a simple solution to not have to explicitely name all
> attributes ?

OpenLDAP supports draft-zeilenga-ldap-opattrs which enable you to request 
all operational attributes with ['+']. All user and operational attributes 
can be retrieved from an OpenLDAP server with ['*','+']. This does not work 
for other LDAP servers which do not support draft-zeilenga-ldap-opattrs.

Furthermore expect all weird things to happen with various LDAP server 
products. E.g. Domino/LDAP does not process ['*'] properly. Not sure whether 
they fixed it during the last year...

Ciao, Michael.


From michael at stroeder.com  Wed Mar 10 18:57:35 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 10 Mar 2004 18:57:35 +0100
Subject: Problem with OpenLDAP 2.2: Macro add_int_r() in constants.c?!?
Message-ID: <404F570F.6000606@stroeder.com>

HI!

David, please take note of this!

What was the rationale of having this macro in constants.c?
What are "reversibles" in this context?

#define add_int_r(d, name)                                              \
         {                                                               \
             long v = LDAP_##name;                                       \
             PyObject *i = PyInt_FromLong( v );                          \
             PyObject *s = PyString_FromString( #name );                 \
             PyDict_SetItem( d, s, s );                                  \
             PyDict_SetItem( reverse, i, s );                            \
             PyDict_SetItem( forward, s, i );                            \
             Py_DECREF(i);                                               \
             Py_DECREF(s);                                               \
             /* printf("%s -> %ld\n", #name, v );  */                    \
         }

[..]

         /* reversibles */

         zero = PyInt_FromLong( 0 );
         PyDict_SetItem( reverse, zero, Py_None );
         Py_DECREF( zero );

         add_int_r(d,RES_BIND);
         add_int_r(d,RES_SEARCH_ENTRY);
         add_int_r(d,RES_SEARCH_RESULT);
         add_int_r(d,RES_MODIFY);
         add_int_r(d,RES_ADD);
         add_int_r(d,RES_DELETE);
         add_int_r(d,RES_MODRDN);
         add_int_r(d,RES_COMPARE);
         add_int(d,RES_ANY);

         add_int_r(d,RES_SEARCH_REFERENCE);
         add_int_r(d,RES_EXTENDED);
         add_int_r(d,RES_UNSOLICITED);

It seems to map some integers from ldap.h to strings with the constant's 
name. For some unknown reason this does not work with OpenLDAP 2.2 libs 
anymore. E.g. there are integers returned by l_ldap_result() as result type 
and this breaks ldap.async or other code which trys to evaluate the result 
type as string.

I have a working solution without add_int_r() which might be 
backward-compatible if one strictly uses constants. This looks like a good 
compromise for me.

Any comments?

Ciao, Michael.


From michael at stroeder.com  Wed Mar 10 20:45:05 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 10 Mar 2004 20:45:05 +0100
Subject: Problem with OpenLDAP 2.2: Macro add_int_r() in constants.c?!?
In-Reply-To: <404F570F.6000606@stroeder.com>
References: <404F570F.6000606@stroeder.com>
Message-ID: <404F7041.4080902@stroeder.com>

Michael Str?der wrote:
> 
> I have a working solution without add_int_r() which might be 
> backward-compatible if one strictly uses constants. This looks like a 
> good compromise for me.

I've committed this solution to CVS. Please test if your code using 
python-ldap makes use of result types (e.g. see source of ldap.async).

Ciao, Michael.


From d at adaptive-enterprises.com.au  Thu Mar 11 07:20:12 2004
From: d at adaptive-enterprises.com.au (David Leonard)
Date: Thu, 11 Mar 2004 16:20:12 +1000
Subject: Problem with OpenLDAP 2.2: Macro add_int_r() in constants.c?!?
References: <404F570F.6000606@stroeder.com>
Message-ID: <004801c40730$ff966ed0$1000640a@numen>

Michael

The reason for having l_ldap_result convert from int to string, was purely
that it made the returned tuple easier to inspect visually.
Also, the reason for the introduction of 'same-named' symbols
(ldap.RES_BIND="RES_BIND") is to catch typos (cf the __slots__ hack, or
X11's resource string constants starting with 'XtN'). The forward and
reverse dictionaries are artifacts of this strange system.

You are right that removing the translation and changing the 'constants' to
numbers would break anyone's code that used string literals.
I have no idea why OpenLDAP2.2 breaks it now.

An alternate (and more high-level) approach would be to create a Result
class, and have l_ldap_result return instances of Result (instead of a
tuple). Using __getitem__ you could make it backward-compatible with the
extant tuples. Also, using __repr__ you could have Result instances make
sense when printed interactively. Then, because there is no need to have
special strings in the result, you could change all the RES_ constants to be
integers and that would much better match ldap.h. Backward-compat with
people's code that used string literals would still be a problem, but
wouldn't be hard to fix. Further, with this instance-instead-of-tuple
approach, an opportunity arises for metaclasses and mixins etc. It could
make OO-zealots very happy :)

d

----- Original Message -----
From: "Michael Str?der" <michael at stroeder.com>
To: <python-ldap-dev at lists.sourceforge.net>
Sent: Thursday, March 11, 2004 3:57 AM
Subject: Problem with OpenLDAP 2.2: Macro add_int_r() in constants.c?!?


> HI!
>
> David, please take note of this!
>
> What was the rationale of having this macro in constants.c?
> What are "reversibles" in this context?
>
> #define add_int_r(d, name)                                              \
>          {                                                               \
>              long v = LDAP_##name;                                       \
>              PyObject *i = PyInt_FromLong( v );                          \
>              PyObject *s = PyString_FromString( #name );                 \
>              PyDict_SetItem( d, s, s );                                  \
>              PyDict_SetItem( reverse, i, s );                            \
>              PyDict_SetItem( forward, s, i );                            \
>              Py_DECREF(i);                                               \
>              Py_DECREF(s);                                               \
>              /* printf("%s -> %ld\n", #name, v );  */                    \
>          }
>
> [..]
>
>          /* reversibles */
>
>          zero = PyInt_FromLong( 0 );
>          PyDict_SetItem( reverse, zero, Py_None );
>          Py_DECREF( zero );
>
>          add_int_r(d,RES_BIND);
>          add_int_r(d,RES_SEARCH_ENTRY);
>          add_int_r(d,RES_SEARCH_RESULT);
>          add_int_r(d,RES_MODIFY);
>          add_int_r(d,RES_ADD);
>          add_int_r(d,RES_DELETE);
>          add_int_r(d,RES_MODRDN);
>          add_int_r(d,RES_COMPARE);
>          add_int(d,RES_ANY);
>
>          add_int_r(d,RES_SEARCH_REFERENCE);
>          add_int_r(d,RES_EXTENDED);
>          add_int_r(d,RES_UNSOLICITED);
>
> It seems to map some integers from ldap.h to strings with the constant's
> name. For some unknown reason this does not work with OpenLDAP 2.2 libs
> anymore. E.g. there are integers returned by l_ldap_result() as result
type
> and this breaks ldap.async or other code which trys to evaluate the result
> type as string.
>
> I have a working solution without add_int_r() which might be
> backward-compatible if one strictly uses constants. This looks like a good
> compromise for me.
>
> Any comments?
>
> Ciao, Michael.
>
>
> 

From michael at stroeder.com  Thu Mar 11 08:57:58 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 11 Mar 2004 08:57:58 +0100
Subject: Problem with OpenLDAP 2.2: Macro add_int_r() in constants.c?!?
In-Reply-To: <004801c40730$ff966ed0$1000640a@numen>
References: <404F570F.6000606@stroeder.com> <004801c40730$ff966ed0$1000640a@numen>
Message-ID: <40501C06.7080207@stroeder.com>

David Leonard wrote:
> 
> The reason for having l_ldap_result convert from int to string, was purely
> that it made the returned tuple easier to inspect visually.

I already dropped it. Bring your CVS dir in sync.

> You are right that removing the translation and changing the 'constants' to
> numbers would break anyone's code that used string literals.

Well, this seems a minor issue to me. I fixed mine. Using constants is also 
more robust against typos.

> An alternate (and more high-level) approach would be to create a Result
> class, and have l_ldap_result return instances of Result (instead of a
> tuple). Using __getitem__ you could make it backward-compatible with the
> extant tuples. Also, using __repr__ you could have Result instances make
> sense when printed interactively.

I already thought about changing all this mess with l_ldap_result() and 
define different classes for the result types. I could do lots of these 
things in ldap.ldapobject.LDAPObject wrapper class but maintaining the C 
code is a major PITA for me.

We should strip down l_ldap_result() to be a really dumb wrapper around 
OpenLDAP's ldap_result() and do the backward-compatible rest in 
LDAPObject.result().

> you could change all the RES_ constants to be
> integers and that would much better match ldap.h.

Already done. Since the C code is still a big mystery to me and it highly 
depends on API decisions of the OpenLDAP folks I'm generally trying to make 
it as lean as possible stripping everything away and eventually reimplement 
it in the Python wrapper modules.

Ciao, Michael.


From michael at stroeder.com  Wed Mar 17 20:04:24 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 17 Mar 2004 20:04:24 +0100
Subject: Wrapped OpenLDAP's ldap_whoami_s()
Message-ID: <4058A138.3020108@stroeder.com>

HI!

Can someone please review function l_ldap_whoami_s() in LDAPObject.c 
especially for memory leaks regarding result. I wonder whether a 
Py_INCREF(result) is needed.

Others interested in SASL bind should also try and test this new method.

Thanks.

Ciao, Michael.

-------- Original Message --------
Subject: CVS: python-ldap
Date: Mon, 15 Mar 2004 02:26:00 -0800
From: Michael Str?der <stroeder at users.sourceforge.net>
Reply-To: python-ldap-dev at lists.sourceforge.net
To: python-ldap-commits at lists.sourceforge.net

CVSROOT:	/cvsroot/python-ldap
Module name:	python-ldap
Changes by:	stroeder	2004/03/15 02:26:00

Modified files:
	.              : CHANGES
	Lib/ldap       : ldapobject.py
	Modules        : LDAPObject.c

Log message:
Wrapped OpenLDAP's ldap_whoami_s()


From michael at stroeder.com  Fri Mar 19 10:13:56 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 19 Mar 2004 10:13:56 +0100
Subject: ANN: python-ldap-2.0.0pre20
In-Reply-To: <E5C9494D-7981-11D8-AD21-0030657040B2@mat.ethz.ch>
References: <405A3085.7030503@stroeder.com> <E5C9494D-7981-11D8-AD21-0030657040B2@mat.ethz.ch>
Message-ID: <405AB9D4.5010605@stroeder.com>

Marc Petitmermet wrote:
> warning: build_py: file Lib/ldap.py (for module ldap) not found
> warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) not  
> found

Item 6. on http://python-ldap.sourceforge.net/faq.shtml:

Q: During build there are warning messages displayed telling Lib/ldap.py and 
Lib/ldap/schema.py are not found:

warning: build_py: file Lib/ldap.py (for module ldap) not found
warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) not found

A: ldap and ldap.schema are both module packages (directories containing 
various sub-modules). The messages above are falsely produced by DistUtils. 
Don't worry about it.

> Modules/options.c:150: warning: unused variable `doubleval'

You can ignore that.

> ImportError:  
> /usr/local/python/Python-2.1.3/lib/python2.1/site-packages/_ldap.so:  
> undefined symbol: EVP_idea_cbc

Hmm, any chance that your OpenSSL upgrade/installation went wrong?

Ciao, Michael.


From petitmermet at mat.ethz.ch  Fri Mar 19 09:46:22 2004
From: petitmermet at mat.ethz.ch (Marc Petitmermet)
Date: Fri, 19 Mar 2004 09:46:22 +0100
Subject: ANN: python-ldap-2.0.0pre20
In-Reply-To: <405A3085.7030503@stroeder.com>
References: <405A3085.7030503@stroeder.com>
Message-ID: <E5C9494D-7981-11D8-AD21-0030657040B2@mat.ethz.ch>

> python-ldap-2.0.0pre20

i tried to build this version. i see the follwing errors:

[snip]
warning: build_py: file Lib/ldap.py (for module ldap) not found
warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) not  
found
[snip]
Modules/options.c:150: warning: unused variable `doubleval'

after installing and importing ldap into the python console:

Python 2.1.3 (#1, Feb  3 2004, 11:45:24)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "copyright", "credits" or "license" for more information.
 >>> import ldap
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File  
"/usr/local/python/Python-2.1.3/lib/python2.1/site-packages/ldap/ 
__init__.py", line 21, in ?
     from _ldap import *
ImportError:  
/usr/local/python/Python-2.1.3/lib/python2.1/site-packages/_ldap.so:  
undefined symbol: EVP_idea_cbc

any ideas how to solve this "EVP_idea_cbc" problem?

regards,
marc

python-2.1.3, python-ldap-2.0.0pre20, openldap-2.1.23, openssl-0.9.7c





From petitmermet at mat.ethz.ch  Fri Mar 19 10:48:28 2004
From: petitmermet at mat.ethz.ch (Marc Petitmermet)
Date: Fri, 19 Mar 2004 10:48:28 +0100
Subject: ANN: python-ldap-2.0.0pre20
In-Reply-To: <405AB9D4.5010605@stroeder.com>
References: <405A3085.7030503@stroeder.com> <E5C9494D-7981-11D8-AD21-0030657040B2@mat.ethz.ch> <405AB9D4.5010605@stroeder.com>
Message-ID: <92DD33EC-798A-11D8-AD21-0030657040B2@mat.ethz.ch>

>> ImportError:   
>> /usr/local/python/Python-2.1.3/lib/python2.1/site-packages/_ldap.so:   
>> undefined symbol: EVP_idea_cbc
>
> Hmm, any chance that your OpenSSL upgrade/installation went wrong?

o.k. i installed the latest version of openssl-0.9.7d (compiled and  
tested without errors). then i removed python-ldap from site-package  
and reinstalled it. now, the above error is gone but there is a problem  
with ldap_whoami_s.

Python 2.1.3 (#1, Feb  3 2004, 11:45:24)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "copyright", "credits" or "license" for more information.
 >>> import ldap
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File  
"/usr/local/python/Python-2.1.3/lib/python2.1/site-packages/ldap/ 
__init__.py", line 21, in ?
     from _ldap import *
ImportError:  
/usr/local/python/Python-2.1.3/lib/python2.1/site-packages/_ldap.so:  
undefined symbol: ldap_whoami_s


regards,
marc




From michael at stroeder.com  Fri Mar 19 11:13:19 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 19 Mar 2004 11:13:19 +0100
Subject: ANN: python-ldap-2.0.0pre20
In-Reply-To: <92DD33EC-798A-11D8-AD21-0030657040B2@mat.ethz.ch>
References: <405A3085.7030503@stroeder.com> <E5C9494D-7981-11D8-AD21-0030657040B2@mat.ethz.ch> <405AB9D4.5010605@stroeder.com> <92DD33EC-798A-11D8-AD21-0030657040B2@mat.ethz.ch>
Message-ID: <405AC7BF.5000508@stroeder.com>

Marc Petitmermet wrote:
> ImportError:  
> /usr/local/python/Python-2.1.3/lib/python2.1/site-packages/_ldap.so:  
> undefined symbol: ldap_whoami_s

Please make sure that recent OpenLDAP shared libs are used. You claimed to 
have 2.1.23 installed. This should work.

What's the output of

/usr/local/python/Python-2.1.3/lib/python2.1/site-packages/_ldap.so

Maybe some ancient OpenLDAP libs shipped with your Red Hat systems are used?

Ciao, Michael.


From petitmermet at mat.ethz.ch  Fri Mar 19 11:35:51 2004
From: petitmermet at mat.ethz.ch (Marc Petitmermet)
Date: Fri, 19 Mar 2004 11:35:51 +0100
Subject: ANN: python-ldap-2.0.0pre20
In-Reply-To: <405AC7BF.5000508@stroeder.com>
References: <405A3085.7030503@stroeder.com> <E5C9494D-7981-11D8-AD21-0030657040B2@mat.ethz.ch> <405AB9D4.5010605@stroeder.com> <92DD33EC-798A-11D8-AD21-0030657040B2@mat.ethz.ch> <405AC7BF.5000508@stroeder.com>
Message-ID: <3168BE28-7991-11D8-B7A3-0030657040B2@mat.ethz.ch>

> Please make sure that recent OpenLDAP shared libs are used. You  
> claimed to have 2.1.23 installed. This should work.

o.k. compiled and installed the latest version openldap-2.1.25 without  
errors. then i removed python-ldap from site-package and reinstalled  
it.

> Maybe some ancient OpenLDAP libs shipped with your Red Hat systems are  
> used?

because of our special setup where we need different versions of the  
same packages i always define the paths in setup.cfg of pyhton-ldap:

library_dirs = /usr/local/openldap/openldap-2.1.25/lib  
/usr/local/openssl/openssl-0.9.7d/lib
include_dirs = /usr/local/openldap/openldap-2.1.25/include  
/usr/local/openssl/openssl-0.9.7d/include

> Maybe some ancient OpenLDAP libs shipped with your Red Hat systems are  
> used?

this should not be the case with the above setup.

the problem with ldap_whoami_s still persists:

Python 2.1.3 (#1, Feb  3 2004, 11:45:24)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "copyright", "credits" or "license" for more information.
 >>> import ldap
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File  
"/usr/local/python/Python-2.1.3/lib/python2.1/site-packages/ldap/ 
__init__.py", line 21, in ?
     from _ldap import *
ImportError:  
/usr/local/python/Python-2.1.3/lib/python2.1/site-packages/_ldap.so:  
undefined symbol: ldap_whoami_s


> What's the output of
> /usr/local/python/Python-2.1.3/lib/python2.1/site-packages/_ldap.so

%> /usr/local/python/Python-2.1.3/lib/python2.1/site-packages/_ldap.so
    Segmentation fault

regards,
marc




From michael at stroeder.com  Mon Mar 22 09:56:20 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 22 Mar 2004 09:56:20 +0100
Subject: ANN: python-ldap-2.0.0pre20
In-Reply-To: <3168BE28-7991-11D8-B7A3-0030657040B2@mat.ethz.ch>
References: <405A3085.7030503@stroeder.com> <E5C9494D-7981-11D8-AD21-0030657040B2@mat.ethz.ch> <405AB9D4.5010605@stroeder.com> <92DD33EC-798A-11D8-AD21-0030657040B2@mat.ethz.ch> <405AC7BF.5000508@stroeder.com> <3168BE28-7991-11D8-B7A3-0030657040B2@mat.ethz.ch>
Message-ID: <405EAA34.2050508@stroeder.com>

Marc Petitmermet wrote:
>> Please make sure that recent OpenLDAP shared libs are used. You  
>> claimed to have 2.1.23 installed. This should work.
> 
> o.k. compiled and installed the latest version openldap-2.1.25 without  
> errors. then i removed python-ldap from site-package and reinstalled it.

Ok.

> because of our special setup where we need different versions of the  
> same packages i always define the paths in setup.cfg of pyhton-ldap:
> 
> library_dirs = /usr/local/openldap/openldap-2.1.25/lib  
> /usr/local/openssl/openssl-0.9.7d/lib
> include_dirs = /usr/local/openldap/openldap-2.1.25/include  
> /usr/local/openssl/openssl-0.9.7d/include

This is only for the build.

>> Maybe some ancient OpenLDAP libs shipped with your Red Hat systems 
>> are  used?
> 
> this should not be the case with the above setup.

Even with setup.cfg as above you still have to set LD_LIBRARY_PATH or adjust 
/etc/ld.so.conf.

>> What's the output of
>> /usr/local/python/Python-2.1.3/lib/python2.1/site-packages/_ldap.so
> 
> %> /usr/local/python/Python-2.1.3/lib/python2.1/site-packages/_ldap.so
>    Segmentation fault

If invoking

ldd /usr/local/python/Python-2.1.3/lib/python2.1/site-packages/_ldap.so

seg faults your local system setup is really broken.

Ciao, Michael.


From petitmermet at mat.ethz.ch  Tue Mar 23 09:18:56 2004
From: petitmermet at mat.ethz.ch (Marc Petitmermet)
Date: Tue, 23 Mar 2004 09:18:56 +0100
Subject: ANN: python-ldap-2.0.0pre20
In-Reply-To: <405EAA34.2050508@stroeder.com>
References: <405A3085.7030503@stroeder.com> <E5C9494D-7981-11D8-AD21-0030657040B2@mat.ethz.ch> <405AB9D4.5010605@stroeder.com> <92DD33EC-798A-11D8-AD21-0030657040B2@mat.ethz.ch> <405AC7BF.5000508@stroeder.com> <3168BE28-7991-11D8-B7A3-0030657040B2@mat.ethz.ch> <405EAA34.2050508@stroeder.com>
Message-ID: <BACEFF50-7CA2-11D8-BB1F-0030657040B2@mat.ethz.ch>

> Even with setup.cfg as above you still have to set LD_LIBRARY_PATH or 
> adjust /etc/ld.so.conf.

oh, man. i'm stupid. why didn't i thought of this? now, i can import 
your module without problems. thanks for the great help.

regards,
marc




From michael at stroeder.com  Wed Mar 24 21:44:03 2004
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 24 Mar 2004 21:44:03 +0100
Subject: Changes with simple and SASL binds
Message-ID: <4061F313.9060903@stroeder.com>

HI!

Please take note of modifications to binding code in ldap.ldapobject and 
Modules/LDAPObject.c (see file CHANGES attached below) and bring your CVS 
working tree in sync and test!

Thanks for testing.

Also note that I rather dropped support for building with OpenLDAP 2.0 libs 
since 2.0 is not maintained anymore.

Ciao, Michael.



From mkur at poczta.gazeta.pl  Sat Mar 27 02:37:28 2004
From: mkur at poczta.gazeta.pl (Michal Kurowski)
Date: Sat, 27 Mar 2004 02:37:28 +0100
Subject: Sun ONE v5.2 build
Message-ID: <20040327013728.GB540@calvados>

Hi,

It seems I am supposed to give up and change a directory server ;-).
I have Sun ONE v5.2 on a Solaris 9 and I need to build python-ldap
against it. 

Many places on the web suggest it actually can be done but at the 
moment I stumbled on  "ldap_schema.h" include file - absent in SO 
and supposedly present in OpenLDAP install.

I'd be really greatfull if anyone with such config could share his/her
experiences.

I use gcc 3.3.1 and python-ldap-2.0.0pre20.
Thanks,

-- 
Michal Kurowski
<mkur at poczta.gazeta.pl>





From michael at stroeder.com  Sat Mar 27 09:20:47 2004
From: michael at stroeder.com (=?ISO-8859-2?Q?Michael_Str=F6der?=)
Date: Sat, 27 Mar 2004 09:20:47 +0100
Subject: Sun ONE v5.2 build
In-Reply-To: <20040327013728.GB540@calvados>
References: <20040327013728.GB540@calvados>
Message-ID: <4065395F.4010603@stroeder.com>

Michal Kurowski wrote:
> 
> It seems I am supposed to give up and change a directory server ;-).
> I have Sun ONE v5.2 on a Solaris 9 and I need to build python-ldap
> against it. 

You cannot build recent python-ldap with Netscape/Sun libs, you need the 
OpenLDAP 2.1+ libs for that. Off course you can use python-ldap to query a 
SunONE server.

> I use gcc 3.3.1 and python-ldap-2.0.0pre20.

You can build and install the OpenLDAP libs in a completely separate 
directory without the server demons.

./configure --prefix=/usr/local/openldap --disable-slapd --disable-slurpd

Depending whether you need SASL and/or SSL/StartTLS you have to build and 
install Cyrus-SASL and/or OpenSSL before that.

And then adjust python-ldap's setup.cfg to match the prefix above.

library_dirs = /usr/local/openldap/lib
include_dirs = /usr/local/openldap/include

Ciao, Michael.