python-ldap-dev — discussion among developers

Re: using python-ldap with twisted ?

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

jea...@ac... wrote:
> 
>    Does anyone has some examples of using python-ldap with twisted ?

I never worked with Twisted. Are you talking about use of the async LDAP
operation methods and hiw to dispatch results.

There's also a package called 'ldaptor' which is a LDAPv3 implementation
based on Twisted. Never used and I don't know anything about the
project's status.

Ciao, Michael.

Re: python-ldap and mac os x tiger, missing symbols

[Bethany J. H. <be...@pi...>]

interesting.  i also heard this:

"You need to un-define _XOPEN_SOURCE and _POSIX_C_SOURCE in order to 
successfully compile python sources on Tiger. Also, you need to use a 
build of Python that was configured on Tiger (either our 2.3 port or a 
2.4.1 configured on Tiger)."

I'm trying 2.4.1 out now.  What a bummer.  Thanks!
	bjh

On May 13, 2005, at 6:48 PM, Jens Vagelpohl wrote:

>
> On May 14, 2005, at 01:34, Bethany Jane Hanson wrote:
>
>> The same thing compiles just fine on mac os x 10.3.x.  I'm including 
>> the same libraries on both compiles.
>
> Tiger has quite a few issues compiling certain things. For one, I have 
> not found a way to compile Python 2.3.5 on it at all. 2.4.1 works 
> fine. And python-ldap built with Python 2.4.1 works. But building for 
> the system-python in /usr/bin fails with problems like the ones you 
> saw.
>
> jens

using python-ldap with twisted ?

[<jea...@ac...>]

Bonjour,

    Does anyone has some examples of using python-ldap with twisted ?
Thanks.

Re: python-ldap and mac os x tiger, missing symbols

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

On May 14, 2005, at 01:34, Bethany Jane Hanson wrote:

> The same thing compiles just fine on mac os x 10.3.x.  I'm  
> including the same libraries on both compiles.

Tiger has quite a few issues compiling certain things. For one, I  
have not found a way to compile Python 2.3.5 on it at all. 2.4.1  
works fine. And python-ldap built with Python 2.4.1 works. But  
building for the system-python in /usr/bin fails with problems like  
the ones you saw.

jens

python-ldap and mac os x tiger, missing symbols

[Bethany J. H. <be...@pi...>]

Hi!  I'm trying to compile python-ldap (2.0.7) on mac os x 10.4.0.  It 
appears to be failing on missing symbols:
ld: Undefined symbols:
_ldap_attributetype_free
_ldap_matchingrule_free
_ldap_objectclass_free
_ldap_str2attributetype
_ldap_str2matchingrule
_ldap_str2objectclass
_ldap_str2syntax
_ldap_syntax_free

The same thing compiles just fine on mac os x 10.3.x.  I'm including 
the same libraries on both compiles.

I heard a rumor that this might be a known issue and easily solved 
through some magic gcc flag.  However, I haven't found anything on the 
net that would tell me what magic gcc flag this would be.  Do you guys 
know anything about this?  Thanks!
	bjh

Re: problem with ldap_sasl_bind

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

Ali Fawaz wrote:
> 
> l.sasl_interactive_bind_s("uid=afawaz,cn=users,dc=arteris,dc=net","Mona3592")
> [..]
> AttributeError: 'str' object has no attribute 'mech'

The second argument is not a string. Please have a look at files
Demo/sasl_bind.py and Lib/ldap/sasl.py in the source distribution.

Ciao, Michael.

problem with ldap_sasl_bind

[Ali F. <lee...@ho...>]

Hi,
I have a problem when I am trying to use ldap_sasl_bind

Traceback (most recent call last):
  File "test.py", line 33, in ?

l.sasl_interactive_bind_s("uid=afawaz,cn=users,dc=arteris,dc=net","Mona3592")
  File
"/home/afawaz/download/python-ldap-2.0.7/build/lib.linux-i686-2.3/ldap/ldapobject.py", 

line 196, in sasl_interactive_bind_s
    return
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls),sasl_flags)
  File
"/home/afawaz/download/python-ldap-2.0.7/build/lib.linux-i686-2.3/ldap/ldapobject.py", 

line 94, in _ldap_call
    result = func(*args,**kwargs)
AttributeError: 'str' object has no attribute 'mech'

here is my code
import ldap
l = ldap.open("ldapserver")
l.sasl_interactive_bind_s("uid=id,cn=users,dc=company,dc=net","")

do you have idea's thanks for help
Alain

Re: Escaping of binary characters

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

Jens Vagelpohl wrote:
> 
> But then again, even if he could use the DN, I suppose the real  problem
> is that you cannot "round trip" the value. You can't just  grab it from
> a search result and use it to formulate another query,  even if you send
> it through ldap.escape_filter_chars, if I understand  the problem
> correctly.

After all it seems to me the idea of "the right" implementation of
ldap.escape_filter_chars() is broken. Basically one has to escape the
assertion value based on subschema knowledge (the LDAPSyntax here).

Note: I'm rather scared of escaping all chars by default since it could
also break interoperability with some badly implemented LDAP servers.

My suggestion for a workaround is to add both implementations and let
the application developer decide which to use. We could make the
differences clear in the __doc__ string.

This could be achieved by a flag passed as arg to ldap.escape_filter_chars()

def escape_filter_chars(assertion_value,escape_all_chars=0):

A schema-aware application could simply set this flag if it determines
that the assertion attribute has a syntax which is not human-readable.

Ciao, Michael.

Re: Escaping of binary characters

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

On May 11, 2005, at 18:52, Michael Str=F6der wrote:

> Mark Hammond wrote:
>
>> I don't actually have neat sample code - I'm observing this inside =20=

>> Zope.
>>
>
> Is this a publicly available Zope component like LDAPUserFolder?

Yes, Mark uses that truly brilliant piece of software ;)



> Do you store the objectGUID to reference the single entry later?
>
> Does this reference has to survive renaming of the entry?
> If no, why don't you use the DN of the entry for a base level =20
> search later?

That's an excellent question. Mark, is that what you are trying to =20
do, identify one specific entry by using the objectGUID?

But then again, even if he could use the DN, I suppose the real =20
problem is that you cannot "round trip" the value. You can't just =20
grab it from a search result and use it to formulate another query, =20
even if you send it through ldap.escape_filter_chars, if I understand =20=

the problem correctly.

jens

Re: Escaping of binary characters

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

Mark Hammond wrote:
> 
> I don't actually have neat sample code - I'm observing this inside Zope.

Is this a publicly available Zope component like LDAPUserFolder?

> However, what happens is:
> 
> * We query for the attribute 'objectGUID'.  We get back a 16 byte string - a
> raw binary representation of the 128-bit GUID.  This part works fine - we
> get the binary value from LDAP correctly.

Just curious because I'm always interested to learn anything people are
doing via LDAP:

Do you store the objectGUID to reference the single entry later?

Does this reference has to survive renaming of the entry?
If no, why don't you use the DN of the entry for a base level search later?

> * Later, we call search_s with a filter string '(objectGUID={string})',
> after calling escape_filter_chars with the exact value as previously
> fetched.  The filter fails, but succeeds with my implementation of
> escape_filter_chars.

Is this code specific for Active Directory (seems so to me)? Or does
your code has to work with any LDAP server with a configurable unique
and DN-independent attribute similar to objectGUID (e.g. entryUUID comes
to mind for OpenLDAP 2.2+)?

IMHO searching with the exact objectGUID returns exactly one entry
anyway. Therefore you could also use the entry's DN and retrieve the
entry with a base level search.

Well, I still didn't get the point of why you need a octet string
objectGUID in a search filter.

> it should read:
> 
> if c < ' ' or c > '~' or c in "\\*()":
> 
> which includes some extra punctuation. As far as I can tell, that
> will leave all 'printable' characters alone and should leave things
> as readable (even if slightly different than) the current
> implementation

Hmm, if I got you right this still escapes NON-ASCII chars which
otherwise could be displayed as UTF-8 encoded Unicode chars.

I'm also afraid this significantly slows down this function which is
probably not a big deal in most applications.

Ciao, Michael.

Re: Escaping of binary characters

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

Mark Hammond wrote:
> 	I'm using python-ldap in conjunction with Zope and the LDAPUserFolder
> product to talk to a Windows Active Directory server.  One of the objects I
> am trying to fetch via LDAP is objectGUID - a binary value.

Can you please provide sample Python code so I can see what you really
want to achieve? Are you searching entries by objectGUID assertion values?

> It seems to me that the current implementation of
> ldap.filters.escape_filter_chars is too conservative in choosing the
> characters to escape.

This implementation simply trys to preserve a human-readable form of the
search filter as much as possible.

> I have provided a sample implementation at
> http://sourceforge.net/support/tracker.php?aid=1193271 - the patch there
> escapes all non-printable characters.

I saw this but I won't accept the patch. Although not technically wrong
it has the disadvantage that search filters won't be human-readable
anymore (which is very handy for debugging).

But actually nothing forces you to use python-ldap's helper function
ldap.filter.escape_filter_chars(). You can simply use your own
implementation in your code. You could even substitute python-ldap's
implementation by initially overwriting it

import ldap.filter
ldap.filter.escape_filter_chars = my_funky_escape_filter_chars

>  Once this patch is in place, I can
> query this binary objectGUID attribute,

Again I don't exactly understand what you're trying to achieve.

Ciao, Michael.

Escaping of binary characters

[Mark H. <mha...@sk...>]

Hi,
	I'm using python-ldap in conjunction with Zope and the LDAPUserFolder
product to talk to a Windows Active Directory server.  One of the objects I
am trying to fetch via LDAP is objectGUID - a binary value.

It seems to me that the current implementation of
ldap.filters.escape_filter_chars is too conservative in choosing the
characters to escape.

For example, escape_filter_chars("\x01") currently returns "\x01" (ie, the
value as passed in), where it would be better if it returned "\\01" (ie 3
characters in total).  I believe this still conforms to RFC2254.

I have provided a sample implementation at
http://sourceforge.net/support/tracker.php?aid=1193271 - the patch there
escapes all non-printable characters.  Once this patch is in place, I can
query this binary objectGUID attribute, and all other testing appears to
work fine (as you would expect though - most of my testing involves
printable characters ;).  The existing tests all still pass (but I struggled
to create a test-case that failed.)

As a side-note, I did test extended characters (and saw this in your recent
archives).  An extended character entered in the Windows ADSI UI is
reflected correctly in my browser via Zope.  I'd say this is a good
indication that the utf-8 escaping is working correctly.

Thanks,

Mark

Re: encodings while modify AD with linux-client

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

Ingo Steuwer wrote:
> 
> modlist=[(ldap.MOD_REPLACE,"description",[u"hallöle".encode('ISO-8859-1')])]
> lo.modify_s("CN=moreusers,CN=Users,%s"%ldap_base,modlist)

LDAPv3 mandates use of Unicode with UTF-8 encoding. You are accessing
Active Directory via its LDAPv3 interface. Hence it expects UTF-8.

> It is documented that Active Directory uses ISO-8859-1 and not utf8 (like 
> Openldap an others). 

I doubt that. Well, depends on what "Active Directory uses ISO-8859-1"
really means...

But the charset of the internal storage of AD is not relevant when
accessing it through LDAPv3.

> So, is this a python-ldap or openldap-problem

Nope. The applications using python-ldap are responsible to provide the
proper charset and encoding at the API level.

> (I know, great chanceto start an AD-Flamewar)?

(Not at all.)

> Any experiences/solutions?

I've tried it. It works for me with UTF-8.

Ciao, Michael.

Re: encodings while modify AD with linux-client

[Ingo S. <st...@un...>]

OK, got it -- but it was't obvious...:

modlist=3D[(ldap.MOD_REPLACE,"description","hall=F6le".decode('latin').enco=
de('utf8'))]

Greetings
Ingo

Am Dienstag, 3. Mai 2005 09:41 schrieb Ingo Steuwer:
> Am Montag, 2. Mai 2005 20:22 schrieb Michael Str=F6der:
> > Ingo Steuwer wrote:
> > > modlist=3D[(ldap.MOD_REPLACE,"description",[u"hall=F6le".encode('ISO-=
8859-1
> > >') ])] lo.modify_s("CN=3Dmoreusers,CN=3DUsers,%s"%ldap_base,modlist)
> >
> > LDAPv3 mandates use of Unicode with UTF-8 encoding. You are accessing
> > Active Directory via its LDAPv3 interface. Hence it expects UTF-8.
> >
> > > It is documented that Active Directory uses ISO-8859-1 and not utf8
> > > (like Openldap an others).
> >
> > I doubt that. Well, depends on what "Active Directory uses ISO-8859-1"
> > really means...
>
> This was mentioned in a documentation of a python-ldap-based tool a can't
> find anymore... google stuff.
>
> > But the charset of the internal storage of AD is not relevant when
> > accessing it through LDAPv3.
> >
> > > So, is this a python-ldap or openldap-problem
> >
> > Nope. The applications using python-ldap are responsible to provide the
> > proper charset and encoding at the API level.
>
> [..]
>
> > I've tried it. It works for me with UTF-8.
>
> Just to be sure: You tried it which way? My experiences are that
> python-ldap doesn't allow the use of unicode in a modlist (see Exception =
in
> my first mail, "expected a string in the list"). Which python-version do
> you use?
>
> Furthermore it seems to me that python-ldap does not use unicode internal=
y.
> If I read from AD I get unicode strings which are handled by python like
> Latin --  which means I have to convert them like "unicode(value,'utf8')".
> I expected that modlist will need also unicode as normal strings but that
> will give me the other conversion-exception ("ordinal not in range(128)").
>
> Regards
> Ingo Steuwer
>
> > Ciao, Michael.

=2D-=20
Ingo Steuwer       st...@un...         fon: +49 421 22 232- 0
Entwicklung        Linux for Your Business
Univention GmbH    http://www.univention.de/     fax: +49 421 22 232-99

Re: encodings while modify AD with linux-client

[Ingo S. <st...@un...>]

Am Montag, 2. Mai 2005 20:22 schrieb Michael Str=F6der:
> Ingo Steuwer wrote:
> > modlist=3D[(ldap.MOD_REPLACE,"description",[u"hall=F6le".encode('ISO-88=
59-1')
> >])] lo.modify_s("CN=3Dmoreusers,CN=3DUsers,%s"%ldap_base,modlist)
>
> LDAPv3 mandates use of Unicode with UTF-8 encoding. You are accessing
> Active Directory via its LDAPv3 interface. Hence it expects UTF-8.
>
> > It is documented that Active Directory uses ISO-8859-1 and not utf8 (li=
ke
> > Openldap an others).
>
> I doubt that. Well, depends on what "Active Directory uses ISO-8859-1"
> really means...

This was mentioned in a documentation of a python-ldap-based tool a can't f=
ind=20
anymore... google stuff.

> But the charset of the internal storage of AD is not relevant when
> accessing it through LDAPv3.
>
> > So, is this a python-ldap or openldap-problem
>
> Nope. The applications using python-ldap are responsible to provide the
> proper charset and encoding at the API level.
>
[..]
>
> I've tried it. It works for me with UTF-8.

Just to be sure: You tried it which way? My experiences are that python-lda=
p=20
doesn't allow the use of unicode in a modlist (see Exception in my first=20
mail, "expected a string in the list"). Which python-version do you use?

=46urthermore it seems to me that python-ldap does not use unicode internal=
y. If=20
I read from AD I get unicode strings which are handled by python like Latin=
=20
=2D-  which means I have to convert them like "unicode(value,'utf8')". I=20
expected that modlist will need also unicode as normal strings but that wil=
l=20
give me the other conversion-exception ("ordinal not in range(128)").

Regards
Ingo Steuwer

> Ciao, Michael.

=2D-=20
Ingo Steuwer       st...@un...         fon: +49 421 22 232- 0
Entwicklung        Linux for Your Business
Univention GmbH    http://www.univention.de/     fax: +49 421 22 232-99

encodings while modify AD with linux-client

[Ingo S. <st...@un...>]

Hello

I've got some encoding-trouble accessing Active Directory with python-ldap=
=20
(slightly modified 2.0.6) on linux (openldap-client 2.1.30).

I can modify a container-description using umlauts without an Error/Excepti=
on:

[..]
lo.simple_bind_s(login_dn, login_pw)

modlist=3D[(ldap.MOD_REPLACE,"description",[u"hall=F6le".encode('ISO-8859-1=
')])]
lo.modify_s("CN=3Dmoreusers,CN=3DUsers,%s"%ldap_base,modlist)
[..]

Search for this container or view it in windows will result the description=
=20
"hallle" (umlauts are "cutted"). Using an different encoding (different fro=
m=20
ISo-8859-1/Latin) will result in an exception, like this one with unicode:

  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 298, in=
=20
modify_s
    msgid =3D self.modify(dn,modlist)
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 295, in=
=20
modify
    return self.modify_ext(dn,modlist,None,None)
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 268, in=
=20
modify_ext
    return=20
self._ldap_call(self._l.modify_ext,dn,modlist,serverctrls,clientctrls)
  File "/usr/lib/python2.3/site-packages/ldap/ldapobject.py", line 94, in=20
_ldap_call
    result =3D func(*args,**kwargs)
TypeError: ('expected a string in the list', u'hal\xf6le')

It is documented that Active Directory uses ISO-8859-1 and not utf8 (like=20
Openldap an others).=20

So, is this a python-ldap or openldap-problem (I know, great chanceto start=
 an=20
AD-Flamewar)? Any experiences/solutions?

Thanks!

Ingo Steuwer

=2D-=20
Ingo Steuwer       st...@un...         fon: +49 421 22 232- 0
Entwicklung        Linux for Your Business
Univention GmbH    http://www.univention.de/     fax: +49 421 22 232-99

ANN: python-ldap-2.0.7

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

Find a new 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.7 2005-04-29

Changes since 2.0.6:

* Added preliminary support for sending LDAP controls
  with a request.
  Contributors:
  - Deepak Giridharagopal
  - Ingo Steuwer
  (Receiving controls in LDAP results still not supported.)

Modules:
* LDAPObject.c: removed l_ldap_manage_dsa_it()
* LDAPObject.c: Added missing #ifdef around l_ldap_passwd()
  for compability with older OpenLDAP libs.

Lib:/
* New algorithm in ldap.schema.tokenizer.split_tokens()
  contributed by Wido Depping which is more robust
  when parsing very broken schema elements
  (e.g. Oracle's OID).
* Fixed argument list (position of timeout) when calling
  LDAPObject.search_ext_s() from search_st() and search_s().
* LDAPObject.search_ext_s() correctly calls search_ext_s() now.
* Re-implemented LDAPObject.manage_dsa_it() without calling _ldap.

Re: examples

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

On Apr 22, 2005, at 18:21, Fabio Marcone wrote:

> Hi!
>
> I'm a newbie of python and ldap.
>
> Deleting and search are ok, but I don't understand how to use modify 
> and add.

Please see the docs here:

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

jens

examples

[Fabio M. <fab...@du...>]

Hi!

I'm a newbie of python and ldap. 

Deleting and search are ok, but I don't understand how to use modify and add.


I tried to study source but without results.

Can anyone give me a full example using modify and add?

Thanks very much,
Fabio

-- 
Dott. Fabio Marcone

2T srl
Telefono   +39 - 0871- 540154    
Fax           +39 - 0871- 571594   
Indirizzo  Viale B. Croce 573, 66013 Chieti Scalo (CH)

Re: caching

[Jerome A. <al...@li...>]

On Wed, Apr 20, 2005 at 07:17:39PM +0200, Michael Ströder wrote:
> 
> Note that the caching in OpenLDAP client libs was considered broken.
> That's why the wrapper code for making OpenLDAP's client-side caching
> available to python-ldap was removed.

I thought about python-ldap specific code, by modifying the 
search methods and invalidating modified entries in the 
add/modify/delete methods

> > if yes, I'm ok to try to do it.
> 
> I'd go for sub-classing LDAPObject and hook into method search_ext_s().

Just what I thought at first glance.

> Issues which come to mind:
> * There can be lots of subtle details to consider which might lead to
> different search results (e.g. access control, the ManageDSAIT controls,
> etc.)
> * take care of flushing the right objects from your cache when modifying
> entries
> * for security reasons flush your whole cache when (re-)binding on a
> given LDAP connection
> 
> I'm sure there are more issues...

Well, if I've got the time, I'll give it a try next week.

bye

Jerome Alet

Re: caching

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

Jerome Alet wrote:
> 
> is there some caching mechanism in python-ldap ?

No.

> if not wouldn't it be desirable to have one ?

Maybe. It really depends...

Note that the caching in OpenLDAP client libs was considered broken.
That's why the wrapper code for making OpenLDAP's client-side caching
available to python-ldap was removed.

> if yes, I'm ok to try to do it.

I'd go for sub-classing LDAPObject and hook into method search_ext_s().
Well, caching for async search operations does not really make sense
anyway.

Issues which come to mind:
* There can be lots of subtle details to consider which might lead to
different search results (e.g. access control, the ManageDSAIT controls,
etc.)
* take care of flushing the right objects from your cache when modifying
entries
* for security reasons flush your whole cache when (re-)binding on a
given LDAP connection

I'm sure there are more issues...

Ciao, Michael.

caching

[Jerome A. <al...@li...>]

Hi there,

while browsing the python-ldap documentation I couldn't find any way 
to have python-ldap do some optional caching of retrieved datas. 

is there some caching mechanism in python-ldap ?

if not wouldn't it be desirable to have one ?

if yes, I'm ok to try to do it.

please tell

bye

Jerome Alet

Trouble compiling python-ldap: LDAP_SASL_QUIET

[<Pau...@mn...>]

I hit an error when trying to build python-ldap. The first error 
encountered:

     Modules/LDAPObject.c:574: error: `LDAP_SASL_QUIET' undeclared (first 
use in this function)

I am using Cyrus SASL on Solaris 9 SPARC 64-bit.  I had to compile Cyrus 
with the switch "--with-des=no" due to an error I was not able to resolve. 
 I am hoping this is not the cause. Any ideas?

Thanks,

Paul.

Compilation output:
=================================================================
mnbweb6 # python setup.py build
extra_compile_args:
extra_objects:
include_dirs: /usr/local/openldap-OPENLDAP_REL_ENG_2_2/include 
/usr/local/sasl/include/sasl /usr/include/sasl /usr/local/include/sasl
library_dirs: /usr/local/openldap-OPENLDAP_REL_ENG_2_2/lib 
/usr/local/sasl/lib /usr/local/lib/sasl2
libs: ldap_r lber ssl crypto sasl2
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
/usr/local/bin/gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -fPIC -DHAVE_LIBLDAP_R -DHAVE_SASL -DHAVE_TLS 
-DLDAPMODULE_VERSION=2.0.6 -IModules 
-I/usr/local/openldap-OPENLDAP_REL_ENG_2_2/include 
-I/usr/local/sasl/include/sasl -I/usr/include/sasl 
-I/usr/local/include/sasl -I/usr/local/include/sasl 
-I/usr/local/include/python2.3 -c Modules/LDAPObject.c -o 
build/temp.solaris-2.9-sun4u-2.3/Modules/LDAPObject.o
In file included from Modules/LDAPObject.c:20:
/usr/local/include/sasl/sasl.h:343: warning: function declaration isn't a 
prototype
Modules/LDAPObject.c: In function `interaction':
Modules/LDAPObject.c:497: warning: unused variable `dflt'
Modules/LDAPObject.c: In function `l_ldap_sasl_interactive_bind_s':
Modules/LDAPObject.c:574: error: `LDAP_SASL_QUIET' undeclared (first use 
in this function)
Modules/LDAPObject.c:574: error: (Each undeclared identifier is reported 
only once
Modules/LDAPObject.c:574: error: for each function it appears in.)
Modules/LDAPObject.c:593: warning: implicit declaration of function 
`ldap_sasl_interactive_bind_s'
Modules/LDAPObject.c:564: warning: unused variable `cred'
Modules/LDAPObject.c:571: warning: unused variable `version'
Modules/LDAPObject.c:573: warning: unused variable `defaults'
Modules/LDAPObject.c: In function `l_ldap_start_tls_s':
Modules/LDAPObject.c:901: warning: implicit declaration of function 
`ldap_start_tls_s'
Modules/LDAPObject.c: In function `l_ldap_passwd':
Modules/LDAPObject.c:1003: warning: implicit declaration of function 
`ldap_passwd'
Modules/LDAPObject.c: At top level:
Modules/LDAPObject.c:980: warning: `l_ldap_passwd' defined but not used
error: command '/usr/local/bin/gcc' failed with exit status 1

Re: Help

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

sudhi ndra wrote:
> 
> ldd:
> /usr/local/src/openldap-2.2.24/libraries/libldap_r: No
> such file or directory

/usr/local/src/openldap-2.2.24/libraries/libldap_r is the source
directory of libldap_r. Did you install OpenLDAP with 'make install'?

> My setup.cfg sent as attachment

The directories set with directive library_dirs are pointing to the
source directories. This will likely not work. OpenLDAP is not properly
installed.

Ciao, Michael.

Re: Help

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

sudhindra aswathanarayana wrote:
> 
> ImportError: libldap_r-2.2.so.7: cannot open shared
> object file: No such file or directory

Similar to item 11. on http://python-ldap.sourceforge.net/faq.shtml

Ciao, Michael.