python-ldap-dev — discussion among developers

Re: SASL response is not a SASL BindRequest

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

Stuart Bishop wrote:
> Out of the OSX box I'm getting:
 > [..]
> ldap.AUTH_UNKNOWN: {'info': 'SASL(-4): no mechanism available: No worthy 
> mechs found', 'desc': 'Unknown authentication method'}

A wild guess: The SASL plugin libs on this box are not found...

> I've also got a Redhat 7.2 box I can test from, but the RPM installed
> OpenLDAP is coredumping when I attempt to SASL auth against the ldap
> server,

This sounds like a library mix. You have to build python-ldap with exactly 
the libs the OpenLDAP client libs were built with. Check with ldd _ldap 
which shared libs are dynamically linked.

See output of ldd _ldap on my box.

$ ldd /usr/lib/python2.2/site-packages/_ldap.so
         libldap_r.so.2 => 
/usr/local/openldap-REL_ENG_2_1/lib/libldap_r.so.2 (0x40010000)
         liblber.so.2 => /usr/local/openldap-REL_ENG_2_1/lib/liblber.so.2 
(0x40052000)
         libsasl2.so.2 => /usr/local/cyrus-sasl/lib/libsasl2.so.2 (0x40060000)
         libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40084000)
         libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x400b5000)
         libc.so.6 => /lib/libc.so.6 (0x4018b000)
         libresolv.so.2 => /lib/libresolv.so.2 (0x402a9000)
         libdl.so.2 => /lib/libdl.so.2 (0x402bb000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

> so I don't think python-ldap has much chance :-)

Well, it works with *your* server from my box.

Ciao, Michael.

Re: problem with python-ldap (it's very impotant please)

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

walid aoudi wrote:
> i have 3 versions of python installed on my pc, i
> don't want to erase anyone but i would know how to
> make python 2.1.3 intercept the python-ldap libraries,

Each Python interpreter has its own directory site-packages/ in the Python 
library dir where the extension modules go. You have to invoke setup.py with 
the exactly the Python interpreter you want to use python-ldap with.

Example (to be really sure the full path is given here):
/usr/bin/python2.2 setup.py build
/usr/bin/python2.2 setup.py install

You can check by typing
/usr/bin/python2.2 -c "import ldap;print ldap.__version__"

So if you wanna use python-ldap in three local installations of Python you 
have to build and install it three times, each time invoking setup.py with 
the Python executable.

 > is it with the setup.cfg file ?

You have to manually tweak setup.cfg to reflect how OpenLDAP libs and 
additional packages needed by the OpenLDAP libs were built (e.g. OpenSSL, 
Cyrus-SASL) and where they are installed.

Ciao, Michael.

problem with python-ldap (it's very impotant please)

[<aou...@ya...>]

i installed python 2.1.3 (i already have in my machine
python 1.5 and python 2.1.1)and open-ldap-2.1.17.
i installed python-ldap2.0.0pre07 ,i think it's ok
but when i launch python from the shell i have this :
sh-2.05# python
Python 2.1.3 (#1, Apr 10 2003, 14:04:31) 
[GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)]
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/lib/python2.1/site-packages/ldap/__init__.py",
line 21, in ?
    from _ldap import *
ImportError: /lib/libcrypt.soP: shared object not open
>>> import _ldap
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: `&#65533;crypt.so: shared object not open
>>> 
In the other hand when I launch python 2.1 everything
is ok,so i think the problems comes from the fact that
i have 3 versions of python installed on my pc, i
don't want to erase anyone but i would know how to
make python 2.1.3 intercept the python-ldap libraries,
is it with the setup.cfg file ?
please help me 
thanks in advance

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Re: SASL response is not a SASL BindRequest

[Stuart B. <stu...@co...>]

Finally got a chance to get back onto this... sorry if anyone was=20
waiting.

On Saturday, April 12, 2003, at 02:44  AM, Michael Str=F6der wrote:

> I think I found the error. Do you have by any chance (like me) a=20
> library mix of Cyrus-SASL 1.x and 2.x on your system?

I might have on one of the original test machines (old laptop since=20
upgraded).
Current test box is OSX 10.2.5 with:
		cyrus-sasl-2.1.12 (installed via fink package manager)
		openldap 2.1.16 (installed via fink package manager)

Out of the OSX box I'm getting:

Traceback (most recent call last):
   File "t.py", line 10, in ?
     l.sasl_bind_s("", auth)
   File "/sw/lib/python2.3/site-packages/ldap/ldapobject.py", line 157,=20=

in sasl_bind_s
     return self._ldap_call(self._l.sasl_bind_s,who,auth)
   File "/sw/lib/python2.3/site-packages/ldap/ldapobject.py", line 87,=20=

in _ldap_call
     result =3D apply(func,args,kwargs)
ldap.AUTH_UNKNOWN: {'info': 'SASL(-4): no mechanism available: No=20
worthy mechs found', 'desc': 'Unknown authentication method'}

I've also got a Redhat 7.2 box I can test from, but the RPM installed
OpenLDAP is coredumping when I attempt to SASL auth against the ldap
server, so I don't think python-ldap has much chance :-)

Test script is just Demo/sasl_bind.py with a tweaked LDAP URL and=20
password.

--=20
Stuart Bishop <ze...@sh...>
http://shangri-la.dropbear.id.au/

Re: problem installing and runnig normally python-ldap with more than 1 version of python

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

walid aoudi wrote:
> i installed python 2.1.3 (i already have in my machine
> python 1.5 and python 2.1.1)and open-ldap-2.1.17.
> i installed python-ldap-1.10.alpha3 ,i think it's ok

What does that mean? Did you compile it from source or did you install a 
binary package? Please give more information.

1. Today python-ldap-1.10.alpha3 is completely unsupported (I removed it 
from project release area on the Sourceforge site right now).

2. python-ldap-1.10.alpha3 needs the old OpenLDAP 1.x libs (see item 7. on 
http://python-ldap.sourceforge.net/faq.shtml).

3. I believe most basic functionality of the current version of python-ldap 
2.0.0pre08 should still work with Python 1.5.x. But I'm not sure.

Ciao, Michael.

problem installing and runnig normally python-ldap with more than 1 version of python

[<aou...@ya...>]

i installed python 2.1.3 (i already have in my machine
python 1.5 and python 2.1.1)and open-ldap-2.1.17.
i installed python-ldap-1.10.alpha3 ,i think it's ok
but when i launch python from the shell i have this :
sh-2.05# python
Python 2.1.3 (#1, Apr 10 2003, 14:04:31) 
[GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)]
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/lib/python2.1/site-packages/ldap/__init__.py",
line 21, in ?
    from _ldap import *
ImportError: /lib/libcrypt.soP: shared object not open
>>> import _ldap
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: `&#65533;crypt.so: shared object not open
>>> 

i think the problems comes from the fact that i have 3
versions of python installed on my pc, i don't want to
erase anyone but i would know how to make python 2.1.3
intercept the python-ldap libraries, is it with the 
setup.cfg file ?
please help me 
thanks in advance


___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

problem with python ldap

[<aou...@ya...>]

i have  python 2.1.3 pythonldap 2.0.0pre0.7 and i have
this message when i try to import ldap :
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/local/lib/python2.1/site-packages/ldap/__init__.py",
line 21, in ?
    from _ldap import *
ImportError: /lib/libcrypt.soP: shared object not open

please tell me what to do and is that why i have on my
Zope some products like LDAPUserFolder that are broken ?

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Re: ANN: python-ldap-2.0.0pre08

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

Peter Hawkins wrote:
 >
 > Incidentally, the link given on the python-ldap download page ...
 > ... for the Debian unstable distribution is wrong. It should now be:
 > http://packages.debian.org/unstable/python/python-ldap.html

/bin/done

Ciao, Michael.

Re: ANN: python-ldap-2.0.0pre08

[<pe...@ha...>]

Hi...
On Fri, Apr 11, 2003 at 03:43:17PM -0700, Joe Little wrote:
> python-ldap RPMS to match this version have also been posted, in their  
> usual location.

As have Debian packages - they will migrate through the mirror network
soon.

Incidentally, the link given on the python-ldap download page ...
http://python-ldap.sourceforge.net/download.shtml

... for the Debian unstable distribution is wrong. It should now be:
http://packages.debian.org/unstable/python/python-ldap.html

(Debian just created a python section of its archive specifically for
python programs/modules. Python-ldap has been moved into this section).

=)
Peter

> 
> On Friday, April 11, 2003, at 06:32 AM, Michael Ströder wrote:
> 
> >HI!
> >
> >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).
> >
> >Download link:
> >http://prdownloads.sourceforge.net/python-ldap/python-ldap- 
> >2.0.0pre08.tar.gz?download
> >
> >Changes since 2.0.0pre07:
> >
> >ldap.schema:
> >* For backward compability with Python versions prior to 2.2
> >  Lib/ldap/schema/tokenizer.py and Lib/ldap/schema/models.py use
> >  (()) instead of tuple() for creating empty tuples.
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by: Etnus, makers of TotalView, The  
> >debugger for complex code. Debugging C/C++ programs can leave you  
> >feeling lost and disoriented. TotalView can help you find your way.  
> >Available on major UNIX and Linux platforms. Try it free. > www.etnus.com
> >_______________________________________________
> >Python-LDAP-dev mailing list
> >Pyt...@li...
> >https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
> 

Re: ANN: python-ldap-2.0.0pre08

[Joe L. <jl...@op...>]

python-ldap RPMS to match this version have also been posted, in their =20=

usual location.

On Friday, April 11, 2003, at 06:32 AM, Michael Str=F6der wrote:

> HI!
>
> 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).
>
> Download link:
> http://prdownloads.sourceforge.net/python-ldap/python-ldap-=20
> 2.0.0pre08.tar.gz?download
>
> Changes since 2.0.0pre07:
>
> ldap.schema:
> * For backward compability with Python versions prior to 2.2
>   Lib/ldap/schema/tokenizer.py and Lib/ldap/schema/models.py use
>   (()) instead of tuple() for creating empty tuples.
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The =20
> debugger for complex code. Debugging C/C++ programs can leave you =20
> feeling lost and disoriented. TotalView can help you find your way. =20=

> Available on major UNIX and Linux platforms. Try it free. > =
www.etnus.com
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: SASL response is not a SASL BindRequest

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

Stuart Bishop wrote:
> 
> Traceback (most recent call last):
>   File "tldap.py", line 54, in ?
>     l.sasl_bind_s(login_dn,auth)
>   File  "/usr/local/stow/python-2.3/lib/python2.3/site-packages/ldap/ 
> ldapobject.py", line 162, in sasl_bind_s
>     return self._ldap_call(self._l.sasl_bind_s,who,auth)
>   File  "/usr/local/stow/python-2.3/lib/python2.3/site-packages/ldap/ 
> ldapobject.py", line 94, in _ldap_call
>     result = apply(func,args,kwargs)
> ldap.LOCAL_ERROR: {'desc': 'Local error'}

I think I found the error. Do you have by any chance (like me) a library mix 
of Cyrus-SASL 1.x and 2.x on your system?

This issue can be solved by editing setup.cfg and using setup.py checked in 
recently. I've tested it against the test server you mentioned in a personal 
e-mail.

Please bring your CVS working tree in sync and test!

Ciao, Michael.

ANN: python-ldap-2.0.0pre08

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

HI!

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

Download link:
http://prdownloads.sourceforge.net/python-ldap/python-ldap-2.0.0pre08.tar.gz?download

Changes since 2.0.0pre07:

ldap.schema:
* For backward compability with Python versions prior to 2.2
   Lib/ldap/schema/tokenizer.py and Lib/ldap/schema/models.py use
   (()) instead of tuple() for creating empty tuples.

Re: Patch to replace tuple() with tuple([])

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

Peter Hawkins wrote:
> 
> Attached is a patch against 2.0.0pre07 which replaces instances of tuple()
> with tuple([]). This is necessary since tuple() is not valid under
> python 2.1.

I've updated Lib/ldap/schema/tokenizer.py and Lib/ldap/schema/models.py to 
use (()) instead of tuple() for creating empty tuples.

Please test!

Ciao, Michael.

Re: Patch to replace tuple() with tuple([])

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

Peter Hawkins wrote:
 >
 > Attached is a patch against 2.0.0pre07 which replaces instances of tuple()
 > with tuple([]). This is necessary since tuple() is not valid under
 > python 2.1.

Arrgh! Good catch!

Hmm, does (()) work under 2.1? Might be faster than tuple([]).

 > Could you please apply this? I realise that you may think python 2.1 is
 > old/deprecated, but it seems like not much work is required to keep it
 > functional for a little bit longer

I'm trying to support Python 2.0 or above. Not sure about 1.5.x though.

Ciao, Michael.

Patch to replace tuple() with tuple([])

[<pe...@ha...>]

Hi...

Attached is a patch against 2.0.0pre07 which replaces instances of tuple()
with tuple([]). This is necessary since tuple() is not valid under
python 2.1.

For example, under python 2.1:

 >>> print tuple()
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
 TypeError: tuple() takes exactly 1 argument (0 given)
 >>> print tuple([])
 ()
 >>>

Under python 2.2:

 >>> print tuple()
 ()
 >>> print tuple([])
 ()
 >>>


Could you please apply this? I realise that you may think python 2.1 is
old/deprecated, but it seems like not much work is required to keep it
functional for a little bit longer (ideally, I'd like it to work until
the next debian release).

=)
Peter

Re: [rcardenes@debian.org: Re: Bug#179108: ldap_initialize patch]

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

Ricardo Javier Cardenes wrote:
> 
> Ok. Now I've checked deeply :-)

Great. I didn't get a response on the openldap-users list up to now...

> So, ldap_initialize(&ldp, NULL) is the same (to all effects) that
> ldap_initialize(&ldp, "ldap://localhost/").

Well, this could be achieved by just patching ldap.initialize() or 
LDAPObject.__init__(). There might be valid reasons to do so. I'll think 
about it.

> Of course, that doesn't explain my previous problems with LDAP lookups
 > [..]
> Oddly enough, I've those problems no more :-?

Glad to hear that. ;-)

>>>Of course, if Michael has a more deep view of OpenLDAP internals than I
> 
> Note that I wasn't looking for any type of offence. I regretted about
> this particular statement after sending the mail.

No problem at all.

>>No, I don't have more insight. In fact I'm not very familiar with the C 
>>part of python-ldap which is hard to maintain for me since David Leonard 
>>does not have time to spent anymore. Contributions welcome (e.g. support 
>>for extended controls).
> 
> Mmh... I can help if you need someone doing the C part. I'm somewhat
> experienced dealing with C/C++ extending/embedding Python :-)

I'd really appreciate your help. Look at the TODO file.

> Anyway, this is not a problem now.

So Peter can close the Debian bug and we'll meet at the python-ldap-dev list...

Ciao, Michael.

Re: [rcardenes@debian.org: Re: Bug#179108: ldap_initialize patch]

[Ricardo J. C. <ri...@co...>]

On Sun, Apr 06, 2003 at 05:33:16PM +0200, Michael Ströder wrote:

> >Passing a NULL argument to ldap_initialize, you prevent this code from
> >running (excerpt from ldap_initialize/OpenLDAP 2.0.27):
> >
> >        if (url != NULL) {
> >                rc = ldap_set_option(ld, LDAP_OPT_URI, url);
> >                if ( rc != LDAP_SUCCESS ) {
> >                        ldap_ld_free(ld, 1, NULL, NULL);
> >                        return rc;
> >                }
> >        }
> >
> >I haven't checked deeply, but it seems to deactivate further URI
> >checkins, making the LDAP library assume that you want to connect to a
> >local LDAP server.
> 
> What does local exactly mean? I guess the LDAP URI is taken from ldap.conf 
> if uri is NULL. Is that right? If yes, I have to admit that I have some 
> objections to introduce (implicit) support for ldap.conf in python-ldap.

Ok. Now I've checked deeply :-) Note that I wasn't thinking of speaking
truth, but just making some guesses looking at ldap_initialize and my
practical experience (in fact, I was expecting to be corrected, as I
couldn't explain the strange behaviour). Now, there's how this works:

   * If you pass some string as "url" to ldap_initialize, then it
     calls ldap_set_option and sets LDAP_INT_GLOBAL_OPT()->ldo_defludp
     with "url" (or "urls", if you have more than one).
   * If you pass NULL as "url" to ldap_initialize, it doesn't call
     ldap_set_option, and so you get the default value. If we look at
     libraries/libldap/init.c:

      void ldap_int_initialize_global_options(...) {
         ...
         ...
            ldap_url_parselist(&gopts->ldo_defludp, "ldap://localhost/");
         ...
         ...
      }

     This (if I've read ldap_url_parselist well) loads
     "ldap://localhost/" as the default value.

So, ldap_initialize(&ldp, NULL) is the same (to all effects) that
ldap_initialize(&ldp, "ldap://localhost/"). Of course, that doesn't
explain my previous problems with LDAP lookups (again, that problems
_seemed_ as DNS lookup timeouts, I'm not 100% sure).

Oddly enough, I've those problems no more :-? in any of the three
machines I've tried, including two of them which were showing thatu
problem. I know that both of them was upgraded to Debian Testing
recently, so I can't provide info about OpenLDAP versions. :-/

> Well, at some point you have to make a DNS lookup. Where does the speed up 
> come from?

I still don't know (now I'm more confused). Any:

   ldapsearch -h SOME_NAME_FOR_LOCAL_LDAP_HOST ...........

made me wait several seconds until some timeout (even "localhost"),
while:

   ldapsearch  ............

didn't. But now that I think about it, I'm not the only admin on those
machines, and maybe someone played tricks with /etc/ldap/ldap.conf

> Or do you suspect the OpenLDAP libs to do reverse lookups in the URL 
> checking?
>
> Did you compile your OpenLDAP with --enable-wrappers (TCP wrapper support)? 
> This could cause reverse lookups on the server's side. Not sure if it also 
> has an effect on the client libs.

That's what I was suspecting the first time, but I discarded it. A
change in client side's options shouldn't affect server's behaviour on
doing reverses.

In fact, haven't read more deeply the library code I was thinking at
that moment on some kind of "direct access" (ie: UNIX sockets vs. TCP
sockets).

> >Anyway, there's no reason to not been able to send a NULL as URL
> >argument to ldap_initialize, since the API _does_ recognize it as a
> >valid argument
> 
> I have some plans to let python-ldap be just a wrapper above other APIs 
> (e.g. ADSI on Win32 or maybe a pure Python version). Therefore there MUST 
> be a good rationale to change semantics of the uri argument of 
> ldap.initialize() or introduce a dependency on OpenLDAP's ldap.conf.

Well, a NULL url seems to mean "get the default server URL, whatever
it is", and it seems like a reasonable semantic, since you can't define
default arguments on C callables. Anyway, looking at current OpenLDAP
stable implementation (2.0.27, as I said), the library sets some internal
defaults (including ldo_defludp = "http://localhost/") before looking into
ldap.conf (no ldap.conf dependency at all).

> >Of course, if Michael has a more deep view of OpenLDAP internals than I

Note that I wasn't looking for any type of offence. I regretted about
this particular statement after sending the mail.

> No, I don't have more insight. In fact I'm not very familiar with the C 
> part of python-ldap which is hard to maintain for me since David Leonard 
> does not have time to spent anymore. Contributions welcome (e.g. support 
> for extended controls).

Mmh... I can help if you need someone doing the C part. I'm somewhat
experienced dealing with C/C++ extending/embedding Python :-)

> >I can keep applying patches.
> 
> Instead you could derive from ldap.ldapobject.LDAPObject and do the host 
> lookup once(!) in the __init__() method passing an IP address to underlying 
> _ldap.initialize(). Or better rewrite your LDAP applications to keep 
> persistent connections. See ldap.ldapobject.ReconnectLDAPObject for a 
> pickable version of LDAPObject.

The actual lookup is delayed until ldap_bind :-), and I dit it twice.
Anyway, this is not a problem now.

> Ciao, Michael.

Regards,
	Ricardo

Re: [rcardenes@debian.org: Re: Bug#179108: ldap_initialize patch]

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

Peter Hawkins wrote:
>>
> Q: "Why you want to pass a NULL argument to ldap_initialize?"
> 
> Short answer: Because you _can_ do it (at least in C)

I have to admit that I'm not in favour of following everything that is 
possible with the OpenLDAP C API. Note that the C API is considered to be 
highly flawed (see postings on OpenLDAP lists). Especially this particular 
feature could cause some FAQs. Before accepting a patch I would really like 
to understand the background issues.

> Long answer:
> 
> Passing a NULL argument to ldap_initialize, you prevent this code from
> running (excerpt from ldap_initialize/OpenLDAP 2.0.27):
> 
>         if (url != NULL) {
>                 rc = ldap_set_option(ld, LDAP_OPT_URI, url);
>                 if ( rc != LDAP_SUCCESS ) {
>                         ldap_ld_free(ld, 1, NULL, NULL);
>                         return rc;
>                 }
>         }
> 
> I haven't checked deeply, but it seems to deactivate further URI
> checkins, making the LDAP library assume that you want to connect to a
> local LDAP server.

What does local exactly mean? I guess the LDAP URI is taken from ldap.conf 
if uri is NULL. Is that right? If yes, I have to admit that I have some 
objections to introduce (implicit) support for ldap.conf in python-ldap.

I posted a message to ope...@Op... to find out......

> It seems to help on some scenarios involving broken
> DNS configs, and it probably (again, I haven't checked) speeds up
> initial bindings even at good configured DNS places, as you don't need to
> make lookups

Well, at some point you have to make a DNS lookup. Where does the speed up 
come from?

> It makes difference for me
> (severals seconds waiting for the lookup to timeout -> 0 seconds passing
> NULL), since I cannot modify those (possibly) broken DNS records.

Maybe it's me but I still don't get it. If you have a DNS name of an LDAP 
server you're trying to connect the lookup for the IP address has to be 
done. If DNS entries are completely broken and you already know the IP 
address you can pass this to ldap.initialize().

Or do you suspect the OpenLDAP libs to do reverse lookups in the URL checking?

Did you compile your OpenLDAP with --enable-wrappers (TCP wrapper support)? 
This could cause reverse lookups on the server's side. Not sure if it also 
has an effect on the client libs.

> Anyway, there's no reason to not been able to send a NULL as URL
> argument to ldap_initialize, since the API _does_ recognize it as a
> valid argument

I have some plans to let python-ldap be just a wrapper above other APIs 
(e.g. ADSI on Win32 or maybe a pure Python version). Therefore there MUST be 
a good rationale to change semantics of the uri argument of 
ldap.initialize() or introduce a dependency on OpenLDAP's ldap.conf.

>(in fact OpenLDAP's client
> tools use NULL as the default argument to ldap_initialize if you don't
> specify -h or -H).

I guess that's where ldap.conf is used.

> Of course, if Michael has a more deep view of OpenLDAP internals than I

No, I don't have more insight. In fact I'm not very familiar with the C part 
of python-ldap which is hard to maintain for me since David Leonard does not 
have time to spent anymore. Contributions welcome (e.g. support for extended 
controls).

> I can keep applying patches.

Instead you could derive from ldap.ldapobject.LDAPObject and do the host 
lookup once(!) in the __init__() method passing an IP address to underlying 
_ldap.initialize(). Or better rewrite your LDAP applications to keep 
persistent connections. See ldap.ldapobject.ReconnectLDAPObject for a 
pickable version of LDAPObject.

Ciao, Michael.

new 2.0.0pre7 RPMS builds

[Joe L. <jl...@op...>]

I've placed RedHat 7.3 and 8.0 SRPMS/RPMS up on ftp.open-it.org (same 
place as currently linked to on the python-ldap site). These are built 
using the latest code and the same build recipe. Therefore, please test 
and report any problems you may have.

ANN: python-ldap-2.0.0pre07

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

HI!

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

Download link:
http://prdownloads.sourceforge.net/python-ldap/python-ldap-2.0.0pre07.tar.gz?download

Changes since 2.0.0pre06:

LDAPObject.c:
   * Wrapped OpenLDAP's ldap_search_ext()
   * Removed empty __doc__ strings
   * Removed fileno
   * Removed all stuff related to caching in OpenLDAP libs

ldap.ldapobject:
   * Fixed SASL rebind in ldap.ldapobject.ReconnectLDAPObject
   * use search_ext() instead ldap_search()
   * new class attribute timeout for setting a global time-out
     value for all synchronous operations

ldap.schema:
* Fixed two typos in ldap.schema.models
* Some attempts to improve performance of parser/tokenizer
* Completely reworked to have separate OID dictionaries for
   the different schema element classes
* Fixed the Demo/schema*.py to reflect changes to ldap.schema

Documentation updates and various __doc__ string modifications.

ldapurl:
   * Removed all Unicode stuff from module ldapurl
   * Consistent URL encoding in module ldapurl

ldif:
   * Removed ldif.FileWriter
   * Proper handling of FILL (see RFC 2849)

Re: MatchingRuleUse

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

Jerry Lee wrote:
> 
> I've been working with ldap.schema.models and came across a problem with 
> MatchingRuleUse.
> 
> suppose that:
> 
> attrClass = MatchingRuleUse
> oids = self.schema.listall(attrClass)
> 
> for oid in oids :
>   object = self.schema.get_obj(attrClass, oid)
>   if not isinstance(object, attrClass):
>      print "Ooopsie!!!!!!!!!!!!!!!!!!!!!!!!!"
>      print attrClass.schema_attribute + '  ***    ' + 
> object.schema_attribute
> 
> 
> What happens is I hit the 'if' for every OID.
> 
> That is, the call to get_obj returns an object of class MatchingRule 
> instead of MatchingRuleUse.

Please test(!) ldap.schema from CVS since I reworked it today to maintain 
separate dictionaries for each schema element class.

Ciao, Michael.

Re: Feature Requests item #707547 (ldap_count_entries)

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

Ludovico Magnocavallo wrote:
> 
> I'm stuck at trying to generate employee count for each ou, and here's where
> I got to asking to add support for ldap_count_entries. Retrieving employees
> for every ou takes too long, I only need a count. Our current C programs use
> ldap_count_entries.

After looking into RFC 2251, man-page of ldap_count_entries and 
draft-ietf-ldapext-ldap-c-api I have some doubts that ldap_count_entries() 
can count *all* results of search without actually receiving *all* the results.

I'd really like to see some snippets of your C code. Especially the 
parameters you pass to ldap_result().

Ciao, Michael.

Re: SASL response is not a SASL BindRequest

[Stuart B. <stu...@co...>]

On Monday, March 24, 2003, at 12:50  AM, Michael Str=F6der wrote:

> Stuart Bishop wrote:
> >
> > I'm getting stuck with SASL authentication - I believe my code is
> > correct so
> > I'd like to get an opinion on if the bug lies with my code,=20
> python-ldap
> > pre6
> > or CommuniGate Pro (the LDAP server). I can bind using =
bind_simple_s.
>
> Are you sure that CommuniGate Pro is an LDAPv3 server and supports=20
> SASL bind? Can you please check the rootDSE for attributes=20
> supportedSASLMechanisms.

The root advertises digest-md5, cram-md5 and ntlm in=20
supportedSASLMechanisms.
supportedLDAPversion is [2,3]

>
> >     login_dn =3D 'uid=3Dzen,cn=3Dcommongroundpublishing.com,o=3DCommon=
=20
> Ground'
> >     password =3D 'secret'
> >
> >     l =3D ldap.open('localhost')
> >     auth =3D ldap.sasl.digest_md5(login_dn,password)
>
> Note that a SASL user name is normally something like uid@realm.

I've tried changing that and am still getting the same error from both=20=

the
client and the server logs.

I'm also getting similar problems using ldapsearch from openldap, so it
looks like a problem with openldap, cyrus-sasl or communigate and not a
python-ldap issue. I suspect CommuniGate Pro, as I've tried installs of
openldap on two difference platforms now so I'll take it to their forum.

--=20
Stuart Bishop <stu...@co...>

Re: Feature Requests item #707547 (ldap_count_entries)

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

Michael Str=F6der wrote:
>=20
>  From the examples I saw OpenLDAP's ldap_count_entries() is typically=20
> used right before ldap_first_entry(). Is that right? Does=20
> ldap_count_entries() consume anything from the results returned?
>=20
> Unfortunately the call of ldap_first_entry() in python-ldap is hidden i=
n=20
> LDAPmessage_to_python() (see Modules/message.c) which in turn is called=
=20
> by the already overloaded l_ldap_result() (see Modules/LDAPObject.c).=20
> Changing anything here would result in a incompatible API change.

To rephrase my answer: Unfortunately ldap_count_entries() has to be calle=
d=20
*after* ldap_result() and *before* ldap_first_entry().

> Now if ldap_count_entries() does not consume anything from the results =

> returned we could try to implement a solution for the following=20
> (fictious) Python code using async search:

Forget about that.

Ciao, Michael.

Re: Feature Requests item #707547 (ldap_count_entries)

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

Ludovico,

1. as I said on this list many times C programmers are needed for 
python-ldap to extend the C extension stuff under Modules/. Are you willing 
to contribute?

2. If you are willing to contribute to python-ldap please bring your local 
CVS tree in sync.

Ludovico Magnocavallo wrote:
> 
> I'm stuck at trying to generate employee count for each ou, and here's where
> I got to asking to add support for ldap_count_entries.

 From the examples I saw OpenLDAP's ldap_count_entries() is typically used 
right before ldap_first_entry(). Is that right? Does ldap_count_entries() 
consume anything from the results returned?

Unfortunately the call of ldap_first_entry() in python-ldap is hidden in 
LDAPmessage_to_python() (see Modules/message.c) which in turn is called by 
the already overloaded l_ldap_result() (see Modules/LDAPObject.c). Changing 
anything here would result in a incompatible API change.

Now if ldap_count_entries() does not consume anything from the results 
returned we could try to implement a solution for the following (fictious) 
Python code using async search:

# Start async search, save message ID returned by OpenLDAP API
msgid = l.search(...)
# Get number of entries in search result
entry_count = l.count_entries(msgid)
# Get number of search continuations in search result
ref_count = l.count_references(msgid)
# Get the search results
res = l.result(msgid)

Does that look sensible to you?

> Unfortunately I don't know C/C++ enough to help,

Welcome to the club... :-(

Ciao, Michael.