python-ldap-dev — discussion among developers

Re: TLS context

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

Damnit.. your right. I did my build on a virgin redhat 7.2 box with include=
d
OpenLDAP 2.0.11 and not my version of the packages. Treats me right. a beta
OpenLDAP 2.0.19 RPM sailed right through. Does anyone know where this is
fixed so that I can log it?


On 1/1/02 5:31 PM, "Michael Str=F6der" <mi...@st...> wrote:

> Joe Little wrote:
>>=20
>> [..] was starting to get my python-ldap RPM back into shape.
>> Well, I see that configure is now gone in lieu of setup.py (distutils) i=
n
>> the latest CVS version. Simple enough. However, doing a test "make" brou=
ght
>> up this TLS context stuff that I see came up a bit ago here.
>> Specifically, a make fails with "LDAP_OPT_X_TLS_CTX" undeclared in
>> Modules/constants.c (203).
>=20
> You probably have to upgrade your OpenLDAP 2 libs. (That's what I
> had to do.)
>=20
>> From the discussion, it would appear code must
>> first declare this,
>=20
> I think you have to define all the certificate-related stuff before
> you do a LDAP over SSL connect by calling
> ldap.initialize('ldaps://..') or before calling method start_tls_s()
> of an existing LDAPObject instance.
>=20
> I did not test it very well up to now.
>=20
> Ciao, Michael.
>=20
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: TLS context

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

Joe Little wrote:
> 
> [..] was starting to get my python-ldap RPM back into shape.
> Well, I see that configure is now gone in lieu of setup.py (distutils) in
> the latest CVS version. Simple enough. However, doing a test "make" brought
> up this TLS context stuff that I see came up a bit ago here.
> Specifically, a make fails with "LDAP_OPT_X_TLS_CTX" undeclared in
> Modules/constants.c (203).

You probably have to upgrade your OpenLDAP 2 libs. (That's what I
had to do.)

> From the discussion, it would appear code must
> first declare this,

I think you have to define all the certificate-related stuff before
you do a LDAP over SSL connect by calling
ldap.initialize('ldaps://..') or before calling method start_tls_s()
of an existing LDAPObject instance.

I did not test it very well up to now.

Ciao, Michael.

Re: TLS context

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

On 11/12/01 7:01 AM, "Michael Str=F6der" <mi...@st...> wrote:

> Jacek Konieczny wrote:
>>=20
>> eg.:
>>=20
>> ldap.set_option("tls_cacertfile","file")
>>=20
>> against:
>>=20
>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"file")
>=20
> I also vote for the 2nd option.
>=20
> Ciao, Michael.
>=20
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

After a long departure (illness in the family), I'm finally returning to th=
e
various projects that I was dabbling in. I'm about to make use of
python-ldap and was starting to get my python-ldap RPM back into shape.
Well, I see that configure is now gone in lieu of setup.py (distutils) in
the latest CVS version. Simple enough. However, doing a test "make" brought
up this TLS context stuff that I see came up a bit ago here.

Specifically, a make fails with "LDAP_OPT_X_TLS_CTX" undeclared in
Modules/constants.c (203). From the discussion, it would appear code must
first declare this, but the error smacks of an incomplete implementation as
this is just the c-library and I gather that one would define it in the
runtime. I'm not fully clued in yet, but am I missing something here?=20

Re: Python parts of module ldap

[<don...@ma...>]

Michael,

System is a Suse Linux install on a S390 VM!

donal@myVMbox:~ > uname -a
Linux myVMbox 2.2.16 #1 SMP Wed Nov 8 10:57:03 GMT 2000 s390 unknown

The tweak below sorted the problem.  Nice one.
Regards

Donal

>-- Original Message --
>Date: Fri, 28 Dec 2001 20:17:34 +0100
>From: Michael Str=F6der <mi...@st...>
>Reply-To: mi...@st...
>To: don...@ma...
>Cc: python-ldap-dev <pyt...@li...>
>Subject: Re: Python parts of module ldap
>
>
>don...@ma... wrote:
>> 
>> ImportError: /usr/local/lib/libldap.so.2: undefined symbol: res_query
>
>On which system are you building python-ldap?
>
>I believe you have to explicitly link libresolv.
>Tweak setup.cfg to contain this line:
>
>libs =3D lber ldap resolv
>
>Ciao, Michael.

Re: Python parts of module ldap

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

don...@ma... wrote:
> 
> ImportError: /usr/local/lib/libldap.so.2: undefined symbol: res_query

On which system are you building python-ldap?

I believe you have to explicitly link libresolv.
Tweak setup.cfg to contain this line:

libs = lber ldap resolv

Ciao, Michael.

Re: Python parts of module ldap

[<don...@ma...>]

Hey there,

I'm having a similar problem at the moment...

OpenLDAP 2.0.18 (openldap-stable-20011102.tgz)
CVS copy of python-ldap (checked out today in the past 4 hours)
Linux box

trying to do a simple open and getting:
-------------------------------------------------------
Traceback (most recent call last):
  File "./ldap_connect", line 7, in ?
    import _ldap
ImportError: /usr/local/lib/libldap.so.2: undefined symbol: res_query
-------------------------------------------------------

What I'm guessing is that the CVS copy I checked out isn't stable, or is
calling something that no longer exists in OpenLDAP libs or something...

Can someone confirm this is likely to be the problem... If you need more
details just shout... :)
Thanks

Donal

>-- Original Message --
>From: Michael Str=F6der <mi...@st...>
>Reply-To: mi...@st...
>To: "Jeffrey C. Ollie" <je...@ol...>
>Cc: python-ldap-dev <pyt...@li...>
>Subject: Re: Python parts of module ldap
>Date: Sat, 15 Dec 2001 23:35:48 +0100
>
>
>"Jeffrey C. Ollie" wrote:
>> 
>> On Sat, Dec 15, 2001 at 09:31:25PM +0100, Michael Str=F6der wrote:
>> > Jacek Konieczny wrote:
>> > >
>> > > On Sat, Dec 15, 2001 at 09:03:44PM +0100, Michael Str=F6der wrote:=

>> > > > After checking in some of my modules below Lib/ldap/ I noticed
a
>> > > > serious drawback:
>> > > > All modules are dependent on availability of OpenLDAP 2 libs if
>> > > > located under Lib/ldap/ because of the "from _ldap import *" don=
e
>in
>> > > > Lib/ldap/__init__.py.
>> > > >
>> > > [...]
>> > > >
>> > > > Any opinions?
>> > >
>> > > Maybe you could put "from _ldap import *" in some "try:/except:"
block.
>> >
>> > I already thought of that. But this makes error reports about
>> > importing problems somewhat harder. E.g. if linking of shared libs
>> > fails it's much more useful to have the original traceback instead
>> > of e.g. a NameError exception afterwards. That's not good style.
>> 
>> What about something like:
>> 
>> import sys
>> _ldap_import_exception =3D (None, None, None)
>> try:
>>     from _ldap import *
>> except ImportError:
>>     _ldap_import_exception =3D sys.exc_info()
>
>Well, then it's easier to tell somebody to do a
>
>$ python -c "import _ldap"
>
>to track down problems.
>
>Another issue I forgot to mention so far is that I can't reuse
>constants of _ldap if importing it fails. I have to define them
>separately anyway.
>
>Hmm, I think I will stick with a separate module package.
>
>Ciao, Michael.
>
>_______________________________________________
>Python-LDAP-dev mailing list
>Pyt...@li...
>https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Wrapped ldap_explode_rdn()

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

HI!

in functions.c I've wrapped ldap_explode_rdn().

It works like this:

$ python2.2 
Python 2.2 (#1, Dec 24 2001, 16:35:00) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> import ldap
>>> ldap.explode_rdn('cn=Michael Str...@st...')
['cn=Michael Stroeder', 'mai...@st...']
>>> 

Ciao, Michael.

Re: Stripped LDAPObject.c

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

Michael Ströder wrote:
> 
> I've stripped all *_doc strings and almost all *_s() methods from
> LDAPObject.c. Also removed the deprecated Kerberos stuff completely.

Since I now hopefully solved all the backwards compability issues
with ldapobject.py I'd like to check in the radically stripped
Modules/LDAPObject.c.

Any objections against that?

Ciao, Michael.

Re: Stripped LDAPObject.c

[Jacek K. <ja...@bn...>]

On Sat, Dec 22, 2001 at 04:14:51PM +0100, Michael Str=F6der wrote:
> Hmm, maybe python-ldap sits on top of the wrong LDAP C lib? We
> currently do not have Win32 support and it's not thread-safe.
>=20
> In opposite iPlanet C SDK (see
> http://www.mozilla.org/directory/csdk.html) is known to be
> thread-safe and is available on various platforms. Unfortunately the
> API of the LDAP C SDKs diverged some much that it's unpossible to
> #ifdef the differences. It's a decision for either one of those.

I was looking for some other API, but it seems they all have
weird/commercial licenses. And I wouldn't like to have pay for some
license to use python-ldap.
When I tried to download iPlanet SDK, I was asked to agree to lincense
which allowed me to use it just for 60 days or something.

Greets,
        Jacek

Re: Stripped LDAPObject.c

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

Jacek Konieczny wrote:
> 
> AFAIK OpenLDAP, even in libldap_r is not very therad-safe.

Kurt Zeilenga wrote that the application has to take care of some
data structures. In our case this could be the C wrapper module.
Don't you think it would be feasible for at least some LDAP
operation methods?

> And libldap_r is missing some functions.

Which ones?

> IMHO we should not touch this
> unless it will be officialy supported and known to work without
> problems.

Yes, maybe it's too early.

Hmm, maybe python-ldap sits on top of the wrong LDAP C lib? We
currently do not have Win32 support and it's not thread-safe.

In opposite iPlanet C SDK (see
http://www.mozilla.org/directory/csdk.html) is known to be
thread-safe and is available on various platforms. Unfortunately the
API of the LDAP C SDKs diverged some much that it's unpossible to
#ifdef the differences. It's a decision for either one of those.

Ciao, Michael.

Re: Stripped LDAPObject.c

[Jacek K. <ja...@bn...>]

On Sat, Dec 22, 2001 at 03:01:38PM +0100, Michael Str=F6der wrote:
> I'm also very much in favour of looking into how to use OpenLDAP 2's
> libldap_r to check if we could build a thread-safe python-ldap C
> wrapper.=20
AFAIK OpenLDAP, even in libldap_r is not very therad-safe. And
libldap_r is missing some functions. IMHO we should not touch this
unless it will be officialy supported and known to work without
problems.

Greets,
        Jacek

Re: New wrapper-class ldap.ldapobject.LDAPObject and stripping down _ldap.LDAPObject.c

[Jacek K. <ja...@bn...>]

On Sat, Dec 22, 2001 at 02:48:46PM +0100, Michael Str=F6der wrote:
> > I have already commited the fixed. I hope there are no more such
> > "typos".
>=20
> Any general comments about this approach?

It seems like a very good idea.

Greets,
        Jacek

Re: Stripped LDAPObject.c

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

David Leonard wrote:
> 
> i note you left in simple_bind_s() probably because from my reading of
> the openldap source code, it shows that some complicated things happen at
> the end of it that don't happen in simple_bind() ... i had a quick
> skim and couldn't see the others doing much more ...

I glanced over ldap_simple_bind_s() of
openldap-HEAD/ldap/libraries/libldap/sbind.c. It just looks like a
simple wrapper around ldap_sasl_bind_s() (see below). Hmm, we could
do the same in ldapobject.c once ldap_sasl_bind() is wrapped.

I'm also very much in favour of looking into how to use OpenLDAP 2's
libldap_r to check if we could build a thread-safe python-ldap C
wrapper. A global thread lock is sometimes annoying (e.g. if
ldap.open()/initialize() takes very long). Anyone willing to do
this? Another advantage of a very short LDAPObject.c is that these
kind of jobs get easier.

Ciao, Michael.

-------------------------------- snip
--------------------------------
int
ldap_simple_bind_s( LDAP *ld, LDAP_CONST char *dn, LDAP_CONST char
*passwd )
{
	struct berval cred;

	Debug( LDAP_DEBUG_TRACE, "ldap_simple_bind_s\n", 0, 0, 0 );

	if ( passwd != NULL ) {
		cred.bv_val = (char *) passwd;
		cred.bv_len = strlen( passwd );
	} else {
		cred.bv_val = "";
		cred.bv_len = 0;
	}

	return ldap_sasl_bind_s( ld, dn, LDAP_SASL_SIMPLE, &cred,
		NULL, NULL, NULL );
}
-------------------------------- snip
--------------------------------

Re: New wrapper-class ldap.ldapobject.LDAPObject and stripping down _ldap.LDAPObject.c

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

Jacek Konieczny wrote:
> 
> On Fri, Dec 21, 2001 at 03:24:14PM +0100, Michael Ströder wrote:
> > I've checked in the Python wrapper module ldap.ldapobject and
> > removed module ldapthreading.
> [...]
> >
> > Please test and give feedback!
> 
> I found two bugs, which made my pydibr refuse to work:

Thanks for testing and fixing it!

> I have already commited the fixed. I hope there are no more such
> "typos".

Any general comments about this approach?

Ciao, Michael.

Re: Stripped LDAPObject.c

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

David Leonard wrote:
> 
> i note you left in simple_bind_s()

??? No, I didn't.

> probably because from my reading of
> the openldap source code, it shows that some complicated things happen at
> the end of it that don't happen in simple_bind()

Ooops. I have to check that.

> however, i do see how having a python-level wrapper is a good thing
> (allows subclassing, locks, custom tracing)

BTW: Shall the tread lock always be used or should we really have a
keyword parameter in open()/initialize()? Anyway I will check in
some code in ldapobject.py today to make sure it works without
thread support in the local Python installation.

Ciao, Michael.

Removing __doc__ strings from LDAPObject.c (was: Wrapped ldap_rename..)

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

David Leonard wrote:
> 
> On Fri, 21 Dec 2001, Michael Ströder typed thusly:
> 
> > David Leonard wrote:
> > > looks good... we'll make you a C hacker out of you yet, michael!
> >
> > Definitely not. Heh, you did not see my Python wrapper module for
> > LDAPObject yet. ;-)
> >
> > I really plan to remove all __doc__ strings and *_s()/*_st() methods
> > from LDAPObject.c. Will be *much* shorter and hopefully easier to
> > maintain afterwards.
> 
> hmmm...  would be nice to have the doc strings in a separate file - maybe
> autogenerated... but is probably easier to leave them where they are to
> meet the python-ish coding standard (unless that standard has changed?)

The __doc__ strings should be where the methods used by the
applications are. IMHO that's Lib/ldap/ldapobject.py. IMO
applications should not directly import _ldap anymore.

The current __doc__ strings are quite longish anyway. I shortened
some of them, others need an overhaul. E.g. pydoc generates working
web links to RFCs and recognizes URLs => it would be possible to
link to the python-ldap HTML docs and RFCs directly. Hmm,
documentation...

Ciao, Michael.

Re: Stripped LDAPObject.c

[David L. <dav...@it...>]

hmmm, i'm not sure if i am completely comfortable with this

are the removed foo_s() functions really handled in the underlying library =
as a
call to foo() followed by ldap_result()?

i note you left in simple_bind_s() probably because from my reading of
the openldap source code, it shows that some complicated things happen at
the end of it that don't happen in simple_bind() ... i had a quick
skim and couldn't see the others doing much more ...

however, i do see how having a python-level wrapper is a good thing
(allows subclassing, locks, custom tracing)

d

On Fri, 21 Dec 2001, Michael Str=F6der typed thusly:

> HI!
>
> I've stripped all *_doc strings and almost all *_s() methods from
> LDAPObject.c. Also removed the deprecated Kerberos stuff completely.
>
> _ldap.so was 14kB smaller on my system (comparison after invoking
> strip). I also believe that it will be far easier to maintain the
> module now since there's not so much code subject to e.g. memory
> leaks etc. anymore.
>
> I did not check it in so far although it seems to work for me.
> Please check the attached C source and give feedback. Especially
> review and test the rename() and url_search() methods.
>
> For using all the *_s() methods you will need module
> Lib/ldap/ldapobject.py. So make sure your CVS tree is up-to-date.
>
> Ciao, Michael.

--=20
David Leonard                           Dav...@it...
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13E=
A0FC8

Stripped LDAPObject.c

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

HI!

I've stripped all *_doc strings and almost all *_s() methods from
LDAPObject.c. Also removed the deprecated Kerberos stuff completely.

_ldap.so was 14kB smaller on my system (comparison after invoking
strip). I also believe that it will be far easier to maintain the
module now since there's not so much code subject to e.g. memory
leaks etc. anymore.

I did not check it in so far although it seems to work for me.
Please check the attached C source and give feedback. Especially
review and test the rename() and url_search() methods.

For using all the *_s() methods you will need module
Lib/ldap/ldapobject.py. So make sure your CVS tree is up-to-date.

Ciao, Michael.

Re: New wrapper-class ldap.ldapobject.LDAPObject and stripping down _ldap.LDAPObject.c

[Jacek K. <ja...@bn...>]

On Fri, Dec 21, 2001 at 03:24:14PM +0100, Michael Str=F6der wrote:
> I've checked in the Python wrapper module ldap.ldapobject and
> removed module ldapthreading.
[...]
>=20
> Please test and give feedback!

I found two bugs, which made my pydibr refuse to work:
- get_option() instead of set_option() in one place
- and intialize() instead of initialize() in another

I have already commited the fixed. I hope there are no more such
"typos".

Greets,
        Jacek

Re: New wrapper-class ldap.ldapobject.LDAPObject and stripping down _ldap.LDAPObject.c

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

Michael Ströder wrote:
> 
> I'm currently implementing a Python wrapper module ldap.LDAPObject
> around _ldap.LDAPObject based on work already done in
> ldapthreading.LDAPObject.

I've checked in the Python wrapper module ldap.ldapobject and
removed module ldapthreading.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Lib/ldap/ldapobject.py

When doing

import ldap
l=ldap.open()

the new module is automagically used.

Please test and give feedback!

Ciao, Michael.

New wrapper-class ldap.ldapobject.LDAPObject and stripping down _ldap.LDAPObject.c

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

Lorenzo,

thanks for your feedback and suggestions.

>         def mod_rdn(dn, newrdn, delete=1):
>                 _ldap.rename(dn,newrdn,None,delete)

I'm currently implementing a Python wrapper module ldap.LDAPObject
around _ldap.LDAPObject based on work already done in
ldapthreading.LDAPObject.

This allows to implement optional parameter handling without mucking
with the C code at all.

The class wrapper will have the following benefits:
- LDAPObject's to act as real Python class without having to
implement
  Pythonic behaviour in LDAPObject.c.
- Solely use the async C module methods if available. This allows
  to throw out all the boring and hard to maintain code from
LDAPObject.c 
  repeatedly calling *_s() functions of the OpenLDAP libs.
- __doc__ strings more pydoc friendly.
- Using a threadlock to serialize LDAP calls is just setting an
optional
  key-word parameter when calling functions open() or initialize().
- Easier to maintain.
- Produce trace output of LDAP calls.

Feedback appreciated! Especially all interested folks should review
ldapthreading.LDAPObject.result(). From my own experience with
web2ldap it seems to work smoothly but please do code reviews!

>    Even better, if newsuperior is made optional and defaulted to NULL,
>    the user can simply forget about mod_rdn in the long term and choose
>    between:
>         rename(dn, newrdn)
>         rename(dn, newrdn, newsuperior)

At the moment I'm not sure how LDAPv2 servers are dealing with it.
We'll see.

> 2. You are overlooking client/server controls, which I agree to keep as NULLs
>    now, but I think should in the long term get implemented and at least
>    documented as an expected API, being it like

Yes. But unfortunately I'm not a C programmer. I have no idea how to
implement LDAP controls. C hackers should jump-on-in.

Ciao, Michael.

Wrapped ldap_rename() and ldap_rename_s()

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

HI!

Although being a real C illiterate it seems that I managed to wrap
ldap_rename() and ldap_rename_s() found in OpenLDAP 2 libs. See
(expired) ID draft-ietf-ldapext-ldap-c-api.

Please test it! It's somewhat likely that I did something wrong.

See diffs:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Modules/LDAPObject.c.diff?r1=1.23&r2=1.24

Also added Demo/rename.py. Note: rename() only works with LDAPv3
servers.

Ciao, Michael.

Re: SASL support

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

Keith Jackson wrote:
> 
> I noticed in the TODO file that SASL support still needs to be added. Is
> anyone currently working on this? I'm going to need to be able to do a
> sasl_bind for a project, so if no one is working on this I might try to
> do it over xmas.

Please go for it.

Ciao, Michael.

SASL support

[Keith J. <krj...@lb...>]

Hi All,
I noticed in the TODO file that SASL support still needs to be added. Is 
anyone currently working on this? I'm going to need to be able to do a 
sasl_bind for a project, so if no one is working on this I might try to 
do it over xmas.
Comments?
--keith
----------------------------------------------------------------
Keith R. Jackson                        KRJ...@lb...
Grid Technology Group			(510) 486-4401
Lawrence Berkeley National Laboratory  	http://www-itg.lbl.gov/~kjackson/

Re: [patch] Demo/simplebrowse.py fixes/enhancemnts

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

Paul Sokolovsky wrote:
> 
> DL> Now, I don't fully understand X.500 so maybe someone else knows a way of
> DL> properly defining and implementing "cd .."?
> 
>     I understand that it's not that simple, but it's just the demo and
> my hack likely fixed it a bit and added some feature ;-) . I don't
> think it's a big problem anyway - yes, some intermediate levels may
> not exist, but don't you want to see corresponding exception with
> your own eyes?

If the parent entry does not exist you either have to catch
ldap.NO_SUCH_OBJECT or handle a referral. I see no problem either.

Ciao, Michael.