python-ldap-dev — discussion among developers

Re: SASL/GSSAPI problems

[Hans A. <Han...@ep...>]

[to list and OP]

On Saturday 30 October 2004 02:07, Wido Depping wrote:
> Hi All,
> some users of Luma ( http://luma.sf.net ) have problems with binding
> to a directory using the SASL/GSSAPI method. All these people have a
> working Kerberos environment and using SASL/MD5 work flawlessly.
> Here's the output they get from the console:
>
> SASL/GSSAPI authentication started
> Error during LDAP bind request
> Reason: {'info': 'SASL(0): successful result: ', 'desc': 'Local error'}

This error is most likely due to a wrong setup of kerberos <-> LDAP, and has 
probably nothing to do with python-ldap. The luma users might look at 

http://www.bayour.com/LDAPv3-HOWTO.html

which is a great HOWTO for setting up a working ldap server with GSSAPI 
authentication. It also explains the reasons for a 'local error'. BTW, it was 
some time ago that I last looked at python-ldap, but I think that it still is 
built on top of the openldap-libraries. So SASL/GSSAPI will work only if it 
also works using ldapsearch (and vice versa(?)).

Hans

SASL/GSSAPI problems

[Wido D. <wid...@gm...>]

Hi All,
some users of Luma ( http://luma.sf.net ) have problems with binding
to a directory using the SASL/GSSAPI method. All these people have a
working Kerberos environment and using SASL/MD5 work flawlessly.
Here's the output they get from the console:

SASL/GSSAPI authentication started
Error during LDAP bind request
Reason: {'info': 'SASL(0): successful result: ', 'desc': 'Local error'}

Unfortunately I'm not able to test this myself since it would take to
much time to set up such an environment. And currently I'm busy with
my exams.
For integrating SASL support into Luma I used the example code from
python-ldap. Here is the 'bind()' function from Luma and maybe you
have an idea what is going wrong:

def bind(self):
        try:
            urlschemeVal = "ldap"
            if self.serverMeta.tls:
                urlschemeVal = "ldaps"
              
            whoVal = None
            credVal = None
            if not (self.serverMeta.bindAnon):
                whoVal = self.serverMeta.bindDN
                credVal = self.serverMeta.bindPassword
                
            url = ldapurl.LDAPUrl(urlscheme=urlschemeVal, 
                hostport = self.serverMeta.host + ":" +
str(self.serverMeta.port),
                dn = self.serverMeta.baseDN, who = whoVal,
                cred = credVal)
            
            self.ldapServerObject = ldap.initialize(url.initializeUrl())
            self.ldapServerObject.protocol_version = 3
            
            if self.serverMeta.bindAnon:
                self.ldapServerObject.simple_bind()
            elif self.serverMeta.authMethod == u"Simple":
                self.ldapServerObject.simple_bind(whoVal, credVal)
            elif u"SASL" in self.serverMeta.authMethod:
                sasl_cb_value_dict = None
                if not u"GSSAPI" in self.serverMeta.authMethod:
                    sasl_cb_value_dict =
{ldap.sasl.CB_AUTHNAME:whoVal, ldap.sasl.CB_PASS:credVal}
                    
                sasl_mech = None
                if self.serverMeta.authMethod == u"SASL Plain":
                    sasl_mech = "PLAIN"
                elif self.serverMeta.authMethod == u"SASL CRAM-MD5":
                    sasl_mech = "CRAM-MD5"
                elif self.serverMeta.authMethod == u"SASL DIGEST-MD5":
                    sasl_mech = "DIGEST-MD5"
                elif self.serverMeta.authMethod == u"SASL Login":
                    sasl_mech = "LOGIN"
                elif self.serverMeta.authMethod == u"SASL GSSAPI":
                    sasl_mech = "GSSAPI"
                    
                sasl_auth = ldap.sasl.sasl(sasl_cb_value_dict,sasl_mech)
                self.ldapServerObject.sasl_interactive_bind_s("", sasl_auth)
                
        except ldap.LDAPError, e:
            print "Error during LDAP bind request"
            print "Reason: " + str(e)


Maybe someone with a Kerberos environment can test Luma. So far I'm
pretty lost what is going on.

mfg.
  Wido
-- 
Wido Depping
ICQ: 51303067    AIM: wido3379
Jabber: wi...@ja...
Blog: http://widoww.blogspot.com

python-ldap on OS X 10.3

[Kyle M. <ky...@kl...>]

 
Hi, I'm trying to compile and install python-ldap-2.0.3 and 2.0.4 on Mac
OS X 10.3, but I seem to be getting some errors, and nothing ends up
getting installed. The weirdest part about this is that I originally had
this working just fine not even a week ago with version 2.0.3. If I
uncompress the older (2.0.3) version and try to install, I still get the
following:
 
 
root@localhost:~ # python setup.py install
extra_compile_args: 
extra_objects: 
include_dirs: /usr/local/openldap-REL_ENG_2_1/include /usr/include/sasl
/usr/local/sasl/include/sasl
library_dirs: /usr/local/openldap-REL_ENG_2_1/lib /usr/lib/sasl
/usr/local/sasl/lib
libs: ldap_r lber sasl2 ssl crypto
running install
running build
running build_py
file Lib/ldap.py (for module ldap) not found
file Lib/ldap/schema.py (for module ldap.schema) not found
file Lib/ldap.py (for module ldap) not found
file Lib/ldap/schema.py (for module ldap.schema) not found
running build_ext
building '_ldap' extension
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
-mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall
-Wstrict-protoo
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
-mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall
-Wstrict-protoo
Modules/LDAPObject.c:20:18: sasl.h: No such file or directory
Modules/LDAPObject.c:492: error: parse error before "sasl_interact_t"
Modules/LDAPObject.c:494: warning: function declaration isn't a
prototype
Modules/LDAPObject.c: In function `interaction':
Modules/LDAPObject.c:495: error: `interact' undeclared (first use in
this function)
Modules/LDAPObject.c:495: error: (Each undeclared identifier is reported
only once
Modules/LDAPObject.c:495: error: for each function it appears in.)
Modules/LDAPObject.c:498: error: `SASLObject' undeclared (first use in
this function)
Modules/LDAPObject.c:495: warning: unused variable `dflt'
Modules/LDAPObject.c: In function `py_ldap_sasl_interaction':
Modules/LDAPObject.c:546: error: `sasl_interact_t' undeclared (first use
in this function)
Modules/LDAPObject.c:546: error: `interact' undeclared (first use in
this function)
Modules/LDAPObject.c:549: error: `SASL_CB_LIST_END' undeclared (first
use in this function)
Modules/LDAPObject.c: In function `l_ldap_sasl_interactive_bind_s':
Modules/LDAPObject.c:562: warning: unused variable `cred'
Modules/LDAPObject.c:569: warning: unused variable `version'
Modules/LDAPObject.c:571: warning: unused variable `defaults'
error: command 'gcc' failed with exit status 1
 
 
 
-Kyle Mott
 
 

ANN: python-ldap-2.0.4

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

Find a new pre-release of python-ldap:

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

python-ldap provides an object-oriented API to access LDAP directory
servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for
that purpose. Additionally it contains modules for other LDAP-related
stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema).

----------------------------------------------------------------
Released 2.0.4 2004-10-27

Changes since 2.0.3:

Modules/:
* Applied some fixes for 64-bit platforms to LDAPObject.c
* Constants ldap.TLS_AVAIL and ldap.SASL_AVAIL will indicate
   whether python-ldap was built with support for SSL/TLS
   and/or SASL

setup.py and Modules/:
* Applied some fixes for building under Win32

Re: Batch Input with Python-Ldap

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

Christian Klinger wrote:
> 
> I have a question about adding a large numbers of users to ldap with 
> python_ldap!

This seems not specific to python-ldap. I will try to answer though.

> I think the problem is the second part of the script. I put every member 
> in the group ENMS!
> If I run the script without part two it runs 5 Minuts with it runs much 
> longer.

Depending on the machine running the LDAP client you could try to build a 
list of all users and pass this list to l.modify_s(gdn,..). Then you would 
only send one big modify request instead of a modify request for each user.

> Is this the right way to make an batch import?
> Do you have any tips to make it faster?
> I test it with 50.000 User but in production there should be 500.000 - 
> Is this a problem?

Generally speaking group entries with more than 1000 member attribute values 
does not scale very well. The exact limit varies depending on the LDAP 
server product and configuration. I'd avoid that. You should really think 
about it. But that's more a question of LDAP directory design in general and 
hence more suitable to be asked in a general LDAP forum.

Ciao, Michael.

Batch Input with Python-Ldap

[Christian K. <ckl...@no...>]

Hello List

I have a question about adding a large numbers of users to ldap with 
python_ldap!
I think the problem is the second part of the script. I put every member 
in the group ENMS!
If I run the script without part two it runs 5 Minuts with it runs much 
longer.

Is this the right way to make an batch import?
Do you have any tips to make it faster?
I test it with 50.000 User but in production there should be 500.000 - 
Is this a problem?

thx Christian


----snip----
for x in range(50000)
    cn=x+basedn
    try:
       l.add_s(dn,[("objectclass",        ["person",]),
                        ("sn",                [cn]),
                        ("cn",                [cn]),
                        ("userpassword",      [pw]),
                       ])
    except ldap.LDAPError, e1:
        err = "DN: %s,  FEHLER: %s, BESCHREIBUNG: %s \n" 
%(dn,e1[0]['desc'],e1[0]['info'])

    try:
        gdn = "cn=ENMS,%s" %(str(orgu))
        l.modify_s(gdn,
                      [(ldap.MOD_ADD,'uniqueMember',dn)]
                  )
    except ldap.LDAPError, e1:
        err = "DN: %s,  FEHLER: %s, BESCHREIBUNG: %s \n" 
%(dn,e1[0]['desc'],e1[0]['info'])

----snip----

Re: LDAP Password Modify Extended Operation

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

Jens Vagelpohl wrote:
>>
>>> I'm trying to gauge whether this should be the default under-the-hood 
>>> way of changing passwords from my own Zope-related products.
>>
>> Probably not.
> 
> Thanks Michael. Looks like for my code it's still more viable to 
> "hand-encode" passwords than to test for and utilize the extended 
> operation.

Probably yes.

LDAP Password Modify Extended Operation is mainly interesting if you're 
deploying SASL with an external password store and the 'user' name value is 
not a distinguished name.

Ciao, Michael.

Re: LDAP Password Modify Extended Operation (was: ANN: python-ldap-2.0.3)

[Jens V. <je...@da...>]

>> Question: Is the Password Modify Extended Operation a generally 
>> supported LDAP operation or is it only on a few server 
>> implementations (I know OpenLDAP has it)?
>
> You can find out by looking at attribute supportedExtension in the 
> RootDSE. The OID 1.3.6.1.4.1.1466.20037 as attribute value indicates 
> that the LDAP server supports Password Modify Extended Operation. Note 
> that this attribute might be subject to access control.
>
> Currently the only LDAP server I know of which supports this is 
> OpenLDAP.
>
>> I'm trying to gauge whether this should be the default under-the-hood 
>> way of changing passwords from my own Zope-related products.
>
> Probably not.

Thanks Michael. Looks like for my code it's still more viable to 
"hand-encode" passwords than to test for and utilize the extended 
operation.

jens

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

Jens Vagelpohl			je...@ze...
Software Engineer			Zope - done medium rare
Zetwork GmbH				http://www.zetwork.com/

LDAP Password Modify Extended Operation (was: ANN: python-ldap-2.0.3)

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

Jens Vagelpohl wrote:
>> * Added support for LDAP Password Modify Extended Operation
>>   (see RFC 3062)
> 
> Question: Is the Password Modify Extended Operation a generally 
> supported LDAP operation or is it only on a few server implementations 
> (I know OpenLDAP has it)?

You can find out by looking at attribute supportedExtension in the RootDSE. 
The OID 1.3.6.1.4.1.1466.20037 as attribute value indicates that the LDAP 
server supports Password Modify Extended Operation. Note that this attribute 
might be subject to access control.

Currently the only LDAP server I know of which supports this is OpenLDAP.

> I'm trying to gauge whether this should be the 
> default under-the-hood way of changing passwords from my own 
> Zope-related products.

Probably not.

Ciao, Michael.

Re: ANN: python-ldap-2.0.3

[Jens V. <je...@da...>]

> * Added support for LDAP Password Modify Extended Operation
>   (see RFC 3062)
>
> Demo/:
> * Added passwd_ext_op.py
>
> Modules/:
> * Added l_ldap_passwd() in LDAPObject.c
>
> Lib/:
> * Added methods passwd() and passwd_s() to
>   ldap.ldapobject.LDAPObject

Question: Is the Password Modify Extended Operation a generally 
supported LDAP operation or is it only on a few server implementations 
(I know OpenLDAP has it)? I'm trying to gauge whether this should be 
the default under-the-hood way of changing passwords from my own 
Zope-related products.

jens

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

Jens Vagelpohl			je...@ze...
Software Engineer			Zope - done medium rare
Zetwork GmbH				http://www.zetwork.com/

ANN: python-ldap-2.0.3

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

Find a new pre-release of python-ldap:

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

python-ldap provides an object-oriented API to access LDAP directory
servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for
that purpose. Additionally it contains modules for other LDAP-related
stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema).

----------------------------------------------------------------
Released 2.0.3 2004-10-06

Changes since 2.0.2:

* Added support for LDAP Password Modify Extended Operation
   (see RFC 3062)

Demo/:
* Added passwd_ext_op.py

Modules/:
* Added l_ldap_passwd() in LDAPObject.c

Lib/:
* Added methods passwd() and passwd_s() to
   ldap.ldapobject.LDAPObject

Re: Global Bind Timeout

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

Kai,

sorry for answering late.

Steverding, Kai wrote:
> Now  i have the
> problem, that the client hangs for about 3 minutes if the servers istn't
> available. (eg the server reboots,so there is no connection refused or
> something like that).

I simulated this by using a firewall rule dropping IP packets.

> I'd like to throw an error if the server-bind doesn't
> work after 20 seconds or so. I found the timeout for result, but nothing
> about a "bind-timeout". What can i do ?

Use something like this for setting the network timeout before the simple bind:

     l = LDAPObject(ldap_url.initializeUrl())
     l.protocol_version = 3
     l.network_timeout = 2.5 # connect timeout 2500 msec
     l.simple_bind_s()

Note that the l.simple_bind_s() raises the LDAPError exception 
ldap.SERVER_DOWN, not ldap_url.initializeUrl().

The behaviour might only work with recent python-ldap (2.0.0pre14+ according 
to CHANGES) and OpenLDAP libs (tested on my system with python-ldap 2.0.2 
and OpenLDAP 2.2.17 libs).

Ciao, Michael.

Global Bind Timeout

[Steverding, K. <ste...@gw...>]

I want to write a monitor for a ldap server in python. Now  i have the
problem, that the client hangs for about 3 minutes if the servers istn't
available. (eg the server reboots,so there is no connection refused or
something like that). I'd like to throw an error if the server-bind doesn't
work after 20 seconds or so. I found the timeout for result, but nothing
about a "bind-timeout". What can i do ?

Kai

Re: segmentation fault on redhat enterprise linux

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

Christian Guenther wrote:
> 
> I have a bunch of python and shell scripts that manage my 150+ users  
> and groups in ldap and
> generate necessary links and aliases for them. The scripts used to work  
> perfectly on RedHat 9
> and also on Debian 3 - they even workm on my Apple Powerbook under Mac  
> OS X Panther.

Well, which versions of OpenLDAP and cyrus-sasl do you have on these systems?

>     RedHat Enterprise Linux ES 3
>     Python 2.0.2
>     Openldap 2.0.27
>     OpenSSL 0.9.7a
>     cyrus sasl 2.1.15

RedHat's support for OpenLDAP is bad.
I'd recommend to upgrade cyrus-sasl and OpenLDAP libs.

Note that libldap_r is not available for OpenLDAP 2.0.x. Please make sure 
your setup.cfg reflects this.

>     kernel 2.0.23 with XFS support - self compiled

2.0? Why such an old kernel?

>     python-ldap 2.0.2 compiled from tarball

What's the output of

# ldd /usr/lib/python2.0/site-packages/_ldap.so

Ciao, Michael.

segmentation fault on redhat enterprise linux

[Christian G. <chr...@am...>]

Hi List,

I have a bunch of python and shell scripts that manage my 150+ users  
and groups in ldap and
generate necessary links and aliases for them. The scripts used to work  
perfectly on RedHat 9
and also on Debian 3 - they even workm on my Apple Powerbook under Mac  
OS X Panther.
However since we switched over to RedHat Enterprise Linux 3, I'm having  
diffculties.
Whenever I try to use one of my scripts they just die with a signal 11.  
The error is reproducable
in the python shell as well. I do a

	import ldap
	l = ldap.initialize("ldap://my.ldap.server")
	l.simple_bind_s()

and receive a segmentation fault.

My environment looks like:

	RedHat Enterprise Linux ES 3
	Python 2.0.2
	Openldap 2.0.27
	OpenSSL 0.9.7a
	cyrus sasl 2.1.15

	kernel 2.0.23 with XFS support - self compiled

	python-ldap 2.0.2 compiled from tarball

If anyone could pleeeeease help me,

	chris

------------------------------------------------------------------------ 
----------
  Unix was not designed to stop you from doing stupid things,
  because that would also stop you from doing clever things.
------------------------------------------------------------------------ 
----------


Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder 
diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte 
sofort den Absender und vernichten Sie diese Mail. 
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser 
Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. 
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and destroy this 
e-mail. Any unauthorised copying, disclosure or distribution of the
material in this e-mail is strictly forbidden.

ANN: python-ldap-2.0.1

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

Find a new pre-release of python-ldap:

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

python-ldap provides an object-oriented API to access LDAP directory
servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for
that purpose. Additionally it contains modules for other LDAP-related
stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema).

----------------------------------------------------------------
Released 2.0.2 2004-07-29

Changes since 2.0.1:

Modules:
* Fixed detecting appropriate OpenLDAP libs version for
   determining whether ldap_whoami_s() is available or not.
   This fixes build problems with OpenLDAP libs 2.1.0 up
   to 2.1.12.

Re: ldap_whoami_s availability in OpenLDAP libs

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

Bernard Gardner wrote:
> 
> I just tried to build python-ldap-2.0.1 against OpenLDAP 2.1.11 and found
> out that this isn't quite right. The patch below seems to fix it.

Added your patch to CVS. Thanks a lot for submitting it.

Ciao, Michael.

Re: ldap_explode_dn is broken

[<yo...@em...>]

Actually it is not that clear from the RFC=2E It seems that future versi=
ons of OpenLdap will accept such a DN like that but will return then (in=
 searches) with the EQUALs escaped=2E

Thank you for the replies=2E

----- Original Message -----
From=3A Michael Str=F6der =3Cmichael=40stroeder=2Ecom=3E
Date=3A Friday=2C July 16=2C 2004 10=3A49 am
Subject=3A Re=3A ldap=5Fexplode=5Fdn is broken

=3E yoel=40emet=2Eco=2Eil wrote=3A
=3E =3E =

=3E =3E Please note that ldap=5Fexplode=5Fdn is broken in recent minor =

=3E versions of
=3E =3E OpenLdap (it worked properly with 2=2E2=2E6 bot not with 2=2E2=2E=
13/14)=2E =

=3E For DN
=3E =3E parts with multipe EQUALS (=27=3D=27) the C library returns NULL=
 =

=3E regardless of
=3E =3E the content of the DN=2E Python-ldap raises an exception=2E
=3E =

=3E Testing=2E=2E=2E
=3E =

=3E =3E=3E=3E from ldap import explode=5Fdn
=3E =3E=3E=3E explode=5Fdn(=27cn=3DMichael Stroeder=2Cdc=3Dstroeder=2Cdc=
=3Dde=27)
=3E =5B=27cn=3DMichael Stroeder=27=2C =27dc=3Dstroeder=27=2C =27dc=3Dde=27=
=5D
=3E =3E=3E=3E explode=5Fdn(=27cn=3DMichael =3D Stroeder=27)
=3E Traceback (most recent call last)=3A
=3E   File =22=3Cstdin=3E=22=2C line 1=2C in =3F
=3E   File =22/usr/lib/python2=2E3/site-packages/ldap/functions=2Epy=22=2C=
 line =

=3E 117=2C in =

=3E explode=5Fdn
=3E     return =5Fldap=5Ffunction=5Fcall(=5Fldap=2Eexplode=5Fdn=2Cdn=2Cn=
otypes)
=3E   File =22/usr/lib/python2=2E3/site-packages/ldap/functions=2Epy=22=2C=
 line =

=3E 57=2C in =

=3E =5Fldap=5Ffunction=5Fcall
=3E     result =3D func(*args=2C**kwargs)
=3E ldap=2ELDAPError=3A (11=2C =27Resource temporarily unavailable=27)
=3E =3E=3E=3E explode=5Fdn(=27cn=3DMichael =5C=3D Stroeder=27)
=3E =5B=27cn=3DMichael =5C=5C3D Stroeder=27=5D
=3E =3E=3E=3E
=3E =

=3E All cases look good to me=2E=2E=2E
=3E =

=3E =3E Exaples of such DNs=3A cn=3Duid=3Dyoel=5Fo=3Dorg=2Co=3Dorg
=3E =

=3E This is not a valid DN anyway=2E It looks like produced by an =

=3E erronous =

=3E application=2E
=3E =

=3E =3E=3E=3E explode=5Fdn(=27cn=3Duid=3Dyoel=5Fo=3Dorg=2Co=3Dorg=27)
=3E Traceback (most recent call last)=3A
=3E   File =22=3Cstdin=3E=22=2C line 1=2C in =3F
=3E   File =22/usr/lib/python2=2E3/site-packages/ldap/functions=2Epy=22=2C=
 line =

=3E 117=2C in =

=3E explode=5Fdn
=3E     return =5Fldap=5Ffunction=5Fcall(=5Fldap=2Eexplode=5Fdn=2Cdn=2Cn=
otypes)
=3E   File =22/usr/lib/python2=2E3/site-packages/ldap/functions=2Epy=22=2C=
 line =

=3E 57=2C in =

=3E =5Fldap=5Ffunction=5Fcall
=3E     result =3D func(*args=2C**kwargs)
=3E ldap=2ELDAPError=3A (2=2C =27No such file or directory=27)
=3E =

=3E Well=2C the error message is misleading I have to admit=2E But that =

=3E ldap=2Eexplode=5Fdn() fails here is correct=2E
=3E =

=3E The equal sign =27=3D=27 has to be escaped with a back-slash =27=5C=27=
=2E See =

=3E RFC2253 or =

=3E draft-ietf-ldapbis-dn=2E
=3E =

=3E =3E=3E=3E explode=5Fdn(=27cn=3Duid=5C=3Dyoel=5Fo=5C=3Dorg=2Co=3Dorg=27=
)
=3E =5B=27cn=3Duid=5C=5C3Dyoel=5Fo=5C=5C3Dorg=27=2C =27o=3Dorg=27=5D
=3E =3E=3E=3E
=3E =

=3E Ciao=2C Michael=2E
=3E =

=3E 

Re: Possible bug results in 'Encoding Error' on Tru64 5.1A..

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

Mike D'Errico wrote:
> On Tue, 13 Jul 2004, Michael Str=F6der wrote:
>=20
>>I found in CHANGES of OpenLDAP 2.2.15 Engineering (currently only avail=
able
>>as branch OPENLDAP_REL_ENG_2_2 in OpenLDAP's CVS):
>>
>>         Fixed libldap sasl_encode 64-bit bug (ITS#3054,3212)
>=20
> This is very interesting indeed.. Unfortunatly I've just tried recompil=
ing
> the module using this cvs version of openldap, but it doesn't see to ha=
ve
> fixed anything...

There's another new line in CHANGES which seems to be interesting for thi=
s=20
issue. Please check if it's already in your CVS working dir:

         Fixed libldap SASL re-encode bug

If it's new please recompile and test again. There also have been added a=
=20
bunch of other fixes (see Kurt's message below).

Ciao, Michael.

-------- Original Message --------
Subject: OPENLDAP_REL_ENG_2_2, please test
Date: Fri, 16 Jul 2004 13:00:21 -0700
From: Kurt D. Zeilenga <Ku...@Op...>
To: ope...@Op...

I've incorporated many significant changes from HEAD
into 2.2, including those to back-bdb to address
various database/locking issues.  Please test.

Also, please check if I've incorporated everything
needing to get released and nothing which shouldn't
be released.

Thanks, Kurt

Re: ldap_explode_dn is broken

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

yo...@em... wrote:
> 
> Please note that ldap_explode_dn is broken in recent minor versions of
> OpenLdap (it worked properly with 2.2.6 bot not with 2.2.13/14). For DN
> parts with multipe EQUALS ('=') the C library returns NULL regardless of
> the content of the DN. Python-ldap raises an exception.

Testing...

 >>> from ldap import explode_dn
 >>> explode_dn('cn=Michael Stroeder,dc=stroeder,dc=de')
['cn=Michael Stroeder', 'dc=stroeder', 'dc=de']
 >>> explode_dn('cn=Michael = Stroeder')
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/lib/python2.3/site-packages/ldap/functions.py", line 117, in 
explode_dn
     return _ldap_function_call(_ldap.explode_dn,dn,notypes)
   File "/usr/lib/python2.3/site-packages/ldap/functions.py", line 57, in 
_ldap_function_call
     result = func(*args,**kwargs)
ldap.LDAPError: (11, 'Resource temporarily unavailable')
 >>> explode_dn('cn=Michael \= Stroeder')
['cn=Michael \\3D Stroeder']
 >>>

All cases look good to me...

> Exaples of such DNs: cn=uid=yoel_o=org,o=org

This is not a valid DN anyway. It looks like produced by an erronous 
application.

 >>> explode_dn('cn=uid=yoel_o=org,o=org')
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/lib/python2.3/site-packages/ldap/functions.py", line 117, in 
explode_dn
     return _ldap_function_call(_ldap.explode_dn,dn,notypes)
   File "/usr/lib/python2.3/site-packages/ldap/functions.py", line 57, in 
_ldap_function_call
     result = func(*args,**kwargs)
ldap.LDAPError: (2, 'No such file or directory')

Well, the error message is misleading I have to admit. But that 
ldap.explode_dn() fails here is correct.

The equal sign '=' has to be escaped with a back-slash '\'. See RFC2253 or 
draft-ietf-ldapbis-dn.

 >>> explode_dn('cn=uid\=yoel_o\=org,o=org')
['cn=uid\\3Dyoel_o\\3Dorg', 'o=org']
 >>>

Ciao, Michael.

Re: ldap_explode_dn is broken

[Jens V. <je...@da...>]

On Jul 16, 2004, at 12:53 AM, yo...@em... wrote:

> Hello,
>
> Please note that ldap_explode_dn is broken in recent minor versions of 
> OpenLdap (it worked properly with 2.2.6 bot not with 2.2.13/14). For 
> DN parts with multipe EQUALS ('=') the C library returns NULL 
> regardless of the content of the DN. Python-ldap raises an exception.
>
> Exaples of such DNs: cn=uid=yoel_o=org,o=org

IMHO a DN where one element has an extra "=" in it, for whatever 
reason, is just plain broken. Don't do it.

jens

ldap_explode_dn is broken

[<yo...@em...>]

Hello, 

Please note that ldap_explode_dn is broken in recent minor versions of OpenLdap (it worked properly with 2.2.6 bot not with 2.2.13/14). For DN parts with multipe EQUALS ('=') the C library returns NULL regardless of the content of the DN. Python-ldap raises an exception.

Exaples of such DNs: cn=uid=yoel_o=org,o=org

Yoel

Re: Server and Client Controls

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

Francesco Del Degan wrote:
> 
> I'm interested in using extended controls (simplePagedResults and
> ServerSort in specific) within a search, but i've notice that this is
> notImplemented yet...

Yes, still on TODO list.

> What is state of it?

There's currently no one working on it.

> Will be a next release feature?

If someone jumps on in...

> I've read python-ldap source (i have also a mid knowledge of openldap
> code) and i'm would to contribute to this part.

Well, the question is how to do it. I'd like to model controls (and extended 
operations) as Python classes and pass them into the LDAP operation methods. 
Note that controls can be passed with any LDAP operation like add, modify 
etc. That's what the _ext methods are for.

BTW: The OpenLDAP lib itself provides helper functions for creating these 
controle. But I'm not sure whether that's a clean design to use them. Maybe 
with a Python wrapper class above them...

Ciao, Michael.

Server and Client Controls

[Francesco D. D. <fde...@li...>]

Hi all...

I'm interested in using extended controls (simplePagedResults and
ServerSort in specific) within a search, but i've notice that this is
notImplemented yet...

What is state of it? Will be a next release feature?

I've read python-ldap source (i have also a mid knowledge of openldap
code) and i'm would to contribute to this part.

Regards...
FrancescoDD

Re: Possible bug results in 'Encoding Error' on Tru64 5.1A..

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

Mike D'Errico wrote:
> 
> I've been debugging the problem all morning and all signs point towards
> the openldap itself.. perhaps there's another 64 bit issue that I've
> uncovered. I'll keep working on this and let you all know if I trace this
> problem back towards the python-ldap module.

You can (globally) turn on logging in the OpenLDAP lib itself when using 
python-ldap:

ldap.set_option(ldap.OPT_DEBUG_LEVEL,255)

255 is just a wild guess.

You can also turn on logging at the OpenLDAP server's side. You could even 
choose a log level which dumps the raw BER data received in requests from 
LDAP clients.

Ciao, Michael.