python-ldap-dev — discussion among developers

Re: referrals

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

Jerome Alet wrote:
> On Wed, Apr 07, 2004 at 12:38:27AM +0200, Michael Str=F6der wrote:
>=20
>>Jerome Alet wrote:
>>
>>>I wanted to know if special coding is needed to support referrals ?=20
>>
>>Yes.
 >
 > Ouch ! That's short !

Yes, since your mileage may vary.

>>>Is there some code example somewhere on how to deal with them ?
>>
>>I don't have simple code snippet around.

You could try to let the OpenLDAP libs handle the referral by setting:

ldap.set_option(ldap.OPT_REFERRALS,1)

Note that referral handling in OpenLDAP libs is considered to be broken.

You could try to handle the referral by catching the exception ldap.REFER=
RAL=20
which contains the LDAP URL of the referred LDAP entry/server:

ldap.set_option(ldap.OPT_REFERRALS,0)

You can dig into the source code of web2ldap to find out how I'm doing it=
=2E=20
Try to provoke the same situation with web2ldap to see what happens.=20
web2ldap asks for a new login when following a referral.

> Yes, this is the case. So tell me if I understand correctly :
>=20
>   - My app tries to do the modification to the server it is bound to,
>     which is the slave.
>    =20
>   - This fails AND automatic referral handling is not activated because=
  =20
>     I've not coded anything special to handle referrals.
>    =20
>   - Then the exception is about authentication because stronger
>     credentials would be needed to write to the slave.
>    =20
> Am I correct ?

Not sure since this depends on server configuration. You have to find out=
=20
yourself what really happens in your environment.

Ciao, Michael.

Re: ldap.sasl.gssapi example?

[Gavin D. <gdo...@an...>]

Yes, running as the same user. Here's the detailed dump:

ldap_interactive_sasl_bind_s: user selected: GSSAPI
ldap_int_sasl_bind: GSSAPI
ldap_new_connection
ldap_int_open_connection
ldap_connect_to_host: ldap4.anim.dreamworks.com
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.4.141:389
ldap_connect_timeout: fd: 3 tm: -1 async: 0
ldap_ndelay_on: 3
ldap_is_sock_ready: 3
ldap_ndelay_off: 3
ldap_err2string                  <--- failure
ldap_free_connection
ldap_send_unbind
ldap_free_connection: act

Do I need to put any more information in the ldap.sasl.gssapi() object?

Michael Str=F6der wrote:
> Gavin Doughtie wrote:
>=20
>> I'm running the Python script from an interactive shell, and I have a=20
>> Kerberos ticket. So far, everything is running as me with my tickets.=20
>> As far as the Python script having access -- well, as far as I can=20
>> understand things it *should* have access via the native sasl library=20
>> which, using GSSAPI, should go grab my ticket and present it to the=20
>> LDAP server.
>=20
>=20
> Running as the same user?
>=20
>> However, I think either the sasl_bind_interactive method is broken or=20
>> I'm not giving it the right information.
>=20
>=20
> Hmm, maybe it's broken. Please raise debug level set with=20
> ldap.set_option(ldap.OPT_DEBUG_LEVEL,0). Maybe this gives some hints.
>=20
> Ciao, Michael.

--=20
Gavin Doughtie
DreamWorks SKG
(818) 695-3821

Re: ldap.sasl.gssapi example?

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

Gavin Doughtie wrote:
> I'm running the Python script from an interactive shell, and I have a 
> Kerberos ticket. So far, everything is running as me with my tickets. As 
> far as the Python script having access -- well, as far as I can 
> understand things it *should* have access via the native sasl library 
> which, using GSSAPI, should go grab my ticket and present it to the LDAP 
> server.

Running as the same user?

> However, I think either the sasl_bind_interactive method is 
> broken or I'm not giving it the right information.

Hmm, maybe it's broken. Please raise debug level set with 
ldap.set_option(ldap.OPT_DEBUG_LEVEL,0). Maybe this gives some hints.

Ciao, Michael.

Re: ldap.sasl.gssapi example?

[Gavin D. <gdo...@an...>]

I'm running the Python script from an interactive shell, and I have a=20
Kerberos ticket. So far, everything is running as me with my tickets. As=20
far as the Python script having access -- well, as far as I can=20
understand things it *should* have access via the native sasl library=20
which, using GSSAPI, should go grab my ticket and present it to the LDAP=20
server. However, I think either the sasl_bind_interactive method is=20
broken or I'm not giving it the right information.

Michael Str=F6der wrote:
> Gavin Doughtie wrote:
>=20
>> I need to use Kerberos authentication through GSSAPI to talk to our=20
>> LDAP server.
>=20
>=20
> I don't have personal experience with such a setup.
>=20
>>  I have a valid Kerberos ticket granting ticket, and I can use the=20
>> ldapadd utility to accomplish what I want on the server in question,
>> [..]
>> ldap.LOCAL_ERROR: {'desc': 'Local error'}
>=20
>=20
> Just guessing:
>=20
> Is the Python script running as the same user as your ldapadd test?
>=20
> Does the Python script have access to the Kerberos ticket?
>=20
> Ciao, Michael.

--=20
Gavin Doughtie
DreamWorks SKG

Re: ldap.sasl.gssapi example?

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

Gavin Doughtie wrote:
> I need to use Kerberos authentication through GSSAPI to talk to our LDAP 
> server.

I don't have personal experience with such a setup.

>  I have a valid Kerberos ticket granting ticket, and I can use 
> the ldapadd utility to accomplish what I want on the server in question,
> [..]
> ldap.LOCAL_ERROR: {'desc': 'Local error'}

Just guessing:

Is the Python script running as the same user as your ldapadd test?

Does the Python script have access to the Kerberos ticket?

Ciao, Michael.

Re: referrals

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

Jerome Alet wrote:
> 
> I wanted to know if special coding is needed to support referrals ? 

Yes.

> Is there some code example somewhere on how to deal with them ?

I don't have simple code snippet around.

> When doing a modify_s() on a slave server, here's the exception
> an user of my software obtains :

In a master-slave replication scenario the slave server is probably 
read-only for applications.

Ciao, Michael.

ldap.sasl.gssapi example?

[Gavin D. <gdo...@an...>]

I'm having fits with ldap.sasl, and was wondering if perhaps I was just 
suffering from a conceptual gap. Maybe there's some sample code 
someplace that I couldn't find with google?

I need to use Kerberos authentication through GSSAPI to talk to our LDAP 
server.  I have a valid Kerberos ticket granting ticket, and I can use 
the ldapadd utility to accomplish what I want on the server in question, 
so I know that my account is properly provisioned.

Code looks like this:

     l = ldap.open('ldapserver.dreamworks.com')
     auth = ldap.sasl.gssapi()
     l.sasl_interactive_bind_s('', auth)

traceback like this:

     l.sasl_interactive_bind_s('', auth)
   File "/usr/local/lib/python2.3/site-packages/ldap/ldapobject.py", 
line 196, in sasl_interactive_bind_s
     return 
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,serverctrls,clientctrls)
   File "/usr/local/lib/python2.3/site-packages/ldap/ldapobject.py", 
line 94, in _ldap_call
     result = func(*args,**kwargs)
ldap.LOCAL_ERROR: {'desc': 'Local error'}


-- 
Gavin Doughtie
DreamWorks SKG

ANN: python-ldap-2.0.0pre21

[<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).

Changes:
Wrapped OpenLDAP's ldap_whoami_s(). Fixed incompability with OpenLDAP 2.2
libs. Code cleaning.

----------------------------------------------------------------
Released 2.0.0pre21 2004-03-29

Changes since 2.0.0pre20:

setup.py:
* runtime_library_dirs is set

Modules/:
* (Hopefully) fixed building with OpenLDAP 2.2 libs in errors.c
* Removed meaningless repr() function from LDAPObject.c
* Removed setting LDAP_OPT_PROTOCOL_VERSION in l_ldap_sasl_bind_s()
* Modified string handling via berval instead of *char
   in l_ldap_compare_ext() makes it possible to compare attribute
   values with null chars.
* Wrapped ldap_sasl_bind() for simple binds instead of ldap_bind()
   since 1. the latter is marked deprecated and 2. ldap_sasl_bind()
   allows password credentials with null chars.
* Removed unused sources linkedlist.c and linkedlist.h
* Function l_ldap_whoami_s() only added if built against
   OpenLDAP 2.1.x+ libs (should preserve compability with 2.0 libs)

ldap.ldapobject:
* LDAPObject.bind() only allows simple binds since Kerberos V4
   binds of LDAPv2 are not supported anymore. An assert statement
   was added to make the coder aware of that.
* Renamed former LDAPObject.sasl_bind_s() to
   LDAPObject.sasl_interactive_bind_s() since it wraps OpenLDAP's
   ldap_sasl_interactive_bind_s()

Re: Sun ONE v5.2 build

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

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.

Sun ONE v5.2 build

[Michal K. <mk...@po...>]

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
<mk...@po...>

Changes with simple and SASL binds

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

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.

----------------------------------------------------------------
Released 2.0.0pre21 2004-03-xx

Changes since 2.0.0pre20:

Modules/:
* Removed meaningless repr() function from LDAPObject.c
* Removed setting LDAP_OPT_PROTOCOL_VERSION in l_ldap_sasl_bind_s()
* Modified string handling via berval instead of *char
   in l_ldap_compare_ext() makes it possible to compare attribute
   values with null chars.
* Wrapped ldap_sasl_bind() for simple binds instead of ldap_bind()
   since 1. the latter is marked deprecated and 2. ldap_sasl_bind()
   allows password credentials with null chars.

ldap.ldapobject:
* LDAPObject.bind() only allows simple binds since Kerberos V4
   binds of LDAPv2 are not supported anymore. An assert statement
   was added to make the coder aware of that.
* Renamed former LDAPObject.sasl_bind_s() to
   LDAPObject.sasl_interactive_bind_s() since it wraps OpenLDAP's
   ldap_sasl_interactive_bind_s()

Re: ANN: python-ldap-2.0.0pre20

[Marc P. <pet...@ma...>]

> 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

Re: ANN: python-ldap-2.0.0pre20

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

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.

Re: ANN: python-ldap-2.0.0pre20

[Marc P. <pet...@ma...>]

> 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

Re: ANN: python-ldap-2.0.0pre20

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

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.

Re: ANN: python-ldap-2.0.0pre20

[Marc P. <pet...@ma...>]

>> 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

Re: ANN: python-ldap-2.0.0pre20

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

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.

Re: ANN: python-ldap-2.0.0pre20

[Marc P. <pet...@ma...>]

> 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

ANN: python-ldap-2.0.0pre20

[<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).

Changes:
Wrapped OpenLDAP's ldap_whoami_s(). Fixed incompability with OpenLDAP 2.2 
libs. Code cleaning.

----------------------------------------------------------------
Released 2.0.0pre20 2004-03-xx

Changes since 2.0.0pre19:

Modules/:
* Removed doc strings from functions.c
* Removed probably unused wrapper function l_ldap_dn2ufn() since
   ldap_dn2ufn() is deprecated in OpenLDAP 2.1+
* Removed wrapper function l_ldap_is_ldap_url().
* Removed macro add_int_r() from constants.c since it caused
   incompability issues with OpenLDAP 2.2 libs
   (Warning: all result types are Integers now! Use the constants!)
* New wrapper function l_ldap_whoami_s()

ldap.ldapobject:
* New wrapper method LDAPObject.whoami_s()

ldap.functions:
* Removed is_ldap_url(). The more general function
   ldapurl.isLDAPUrl() should be used instead.

ldap.sasl:
* Added class cram_md5 (for SASL mech CRAM-MD5)

ldap.async:
* Use constants for search result types (see note about
   add_int_r() above).

Wrapped OpenLDAP's ldap_whoami_s()

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

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 <str...@us...>
Reply-To: pyt...@li...
To: pyt...@li...

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()

Re: Problem with OpenLDAP 2.2: Macro add_int_r() in constants.c?!?

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

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.

Re: Problem with OpenLDAP 2.2: Macro add_int_r() in constants.c?!?

[David L. <d...@ad...>]

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" <mi...@st...>
To: <pyt...@li...>
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.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>
>

Re: Problem with OpenLDAP 2.2: Macro add_int_r() in constants.c?!?

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

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

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

Ciao, Michael.

Problem with OpenLDAP 2.2: Macro add_int_r() in constants.c?!?

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

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.

query

[gipson1 <gi...@in...>]

i cannot import  ldap from python,should i configure any search path such that all the libraries are includedIndiatimes Email now powered by APIC Advantage. Help! 
HelpClick onthe image to chat with me