python-ldap-dev — discussion among developers

Re: TLS context

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

Jacek Konieczny wrote:
> 
> eg.:
> 
> ldap.set_option("tls_cacertfile","file")
> 
> against:
> 
> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"file")

I also vote for the 2nd option.

Ciao, Michael.

Re: TLS context

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

On Mon, 12 Nov 2001, Jacek Konieczny typed thusly:

> ldap.set_option("tls_cacertfile","file")
>
> against:
>
> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"file")
>
> The first solution is shorter to use, the second is more like OpenLDAP C
> API. Which one should I use? If it is to be separated from "local"
> options (implemented as attribute) then IMHO the second would be better.
> Currently I have the first one implemented, but it is easy to change.

the latter is better: lets you catch errors in python faster (same trick
used in Xt)

you might also like to intern the strings so you can use == in C.

> > You're welcome to throw away any code not needed when compiling
> > against OpenLDAP 2.x libs. E.g. I already removed autoconf stuff
> > from CVS. If someone needs that he/she can check out the tagged old
> > version.
> OK. So I will do it. I will add "#error" for LDAP_API_VERSION < 2000

:)

d
-- 
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               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Re: TLS context

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

On Mon, Nov 12, 2001 at 11:59:37AM +0100, Michael Str=F6der wrote:
>=20
> Well, if the TLS options are global they should be handled globally.
> Therefore any global option must not be wrapped by an attribute of
> the LDAP connection object. The application programmer has to deal
> with it.
The problem is, that some of the options can be used globally and
locally. Eg. LDAP_OPT_X_TLS.
But we can handle those two cases separately.

Currently I handle the global options as strings (like it was for local
options implemented as attributes). But maybe it would be better to
handle them as constants.

eg.:

ldap.set_option("tls_cacertfile","file")

against:

ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"file")

The first solution is shorter to use, the second is more like OpenLDAP C
API. Which one should I use? If it is to be separated from "local"
options (implemented as attribute) then IMHO the second would be better.
Currently I have the first one implemented, but it is easy to change.

> You're welcome to throw away any code not needed when compiling
> against OpenLDAP 2.x libs. E.g. I already removed autoconf stuff
> from CVS. If someone needs that he/she can check out the tagged old
> version.
OK. So I will do it. I will add "#error" for LDAP_API_VERSION < 2000

It will be easier to extend the module then.

Greets,
        Jacek

Re: TLS context

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

Jacek Konieczny wrote:
> 
> On Sun, Nov 11, 2001 at 03:20:06PM +0100, Michael Ströder wrote:
> > > I have not yet checked if TLS options all global or connection-specific.
> >
> > I would assume that TLS/SSL options are connection-specific since
> > you might have different trusted root CA certs, etc.
> 
> I have checked this and it turned out, that mose TLS options are global,
> and cannot be set per LDAPObject.
> To support global options (which can eventualy be available as object
> options) I have moved part of setattr and getattr of LDAPObject to other
> functions, which can also be used without object for setting global
> options.

Well, if the TLS options are global they should be handled globally.
Therefore any global option must not be wrapped by an attribute of
the LDAP connection object. The application programmer has to deal
with it.

> Do we really need suport for OpenLDAP < 2.x?

No. It was decided ages ago that we drop support for OpenLDAP 1.x,
Netscape SDK and Novell SDK if we have something stable working with
OpenLDAP 2.x.

> Now python-ldap compiled with OpenLDAP1 and python-ldap compiled with
> OpenLDAP2 are so different as they are different modules. And the code
> is quite hard to maintain.

You're welcome to throw away any code not needed when compiling
against OpenLDAP 2.x libs. E.g. I already removed autoconf stuff
from CVS. If someone needs that he/she can check out the tagged old
version.

> It was long time ago, when OpenLDAP2 was experimental.

Yes.

Ciao, Michael.

Re: TLS context

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

On Sun, Nov 11, 2001 at 03:20:06PM +0100, Michael Str=F6der wrote:
> > I have not yet checked if TLS options all global or connection-specific.
>=20
> I would assume that TLS/SSL options are connection-specific since
> you might have different trusted root CA certs, etc.

I have checked this and it turned out, that mose TLS options are global,
and cannot be set per LDAPObject.=20
To support global options (which can eventualy be available as object
options) I have moved part of setattr and getattr of LDAPObject to other
functions, which can also be used without object for setting global
options.

Here is (working) fragment of python-ldap program:

import ldap
ldap.set_option("tls_require_cert",1)
ldap.set_option("tls_cacertfile","my_cacerts.pem")
l=3Dldap.initialize("https://some.ldap.server")
l.tls=3Dldap.TLS_HARD
l.bind("","")

Should I commit the changes (as soon as I polish them a bit more)?
And is there any way to make it work like this?:

ldap.tls_require_cert=3D1

It is easy for object (that is the way it is done for LDAPObject), but
is there any way to implement this in module?

And one more thing:

Do we really need suport for OpenLDAP < 2.x?
Now python-ldap compiled with OpenLDAP1 and python-ldap compiled with
OpenLDAP2 are so different as they are different modules. And the code
is quite hard to maintain.
It was long time ago, when OpenLDAP2 was experimental.

Greets,
        Jacek

Re: TLS context

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

On Sun, Nov 11, 2001 at 08:24:34PM +0100, Michael Str=F6der wrote:
> Jacek Konieczny wrote:
> >=20
> > import ldap
> > l=3Dldap.initialize("ldaps://some.ldap.server")
> > l.bind("","")
> > ...
>=20
> I really wonder how a validation of the server certificate is done
> in this case...
In this case no validation is made. Some validation would be probably
done if l.tls_* flags were set between ldap.initialize() and l.bind().

Greets,
        Jacek

Re: TLS context

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

Jacek Konieczny wrote:
> 
> import ldap
> l=ldap.initialize("ldaps://some.ldap.server")
> l.bind("","")
> ...

I really wonder how a validation of the server certificate is done
in this case...

Ciao, Michael.

Re: TLS context

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

On Sun, Nov 11, 2001 at 03:20:06PM +0100, Michael Str=F6der wrote:
> Keep the name ldap.initialize().=20
That is what I have done.

> That makes it easy to find it in
> ldap.h. BTW: Support for ldapi:// (local domain socket) should be
> possible with this either.
I think so.

> I'd also appreciate if you could manage to use ldap_r and wrap it in
> such a way that python-ldap is re-entrant. Do you think that's
> feasible?=20
I don't have any experience with threads. I may try, but I could make it
wrong.

> My module ldapthreadlock is just a weird work-around with
> some serious deficiencies.

> Does the OpenLDAP API expose a call-back interface to implement CRL
> checking and such?
It doesn't seem so. There is no trace of any CRL handling in ldap.h nor
i the openldap sources.
But I hope they will fix it soon.

Greets,
        Jacek

Re: TLS context

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

Jacek Konieczny wrote:
> 
> On Sun, Nov 11, 2001 at 08:26:57PM +1000, David Leonard wrote:
> > Can you give an example of what a python program might look like
> > using these?
> 
> The only thing I implemented and tested now is the ldap.initialize().

This whole stuff including your Python examples looks reasonable to
me.

> You can use ldap.init() instead of ldap.initialize(). ldap.open()
> should not be used as it is depreciated, and it won't work for LDAP over
> SSL (as connection would be open before tls options are set).

Keep the name ldap.initialize(). That makes it easy to find it in
ldap.h. BTW: Support for ldapi:// (local domain socket) should be
possible with this either.

I'd also appreciate if you could manage to use ldap_r and wrap it in
such a way that python-ldap is re-entrant. Do you think that's
feasible? My module ldapthreadlock is just a weird work-around with
some serious deficiencies.

> I have not yet checked if TLS options all global or connection-specific.

I would assume that TLS/SSL options are connection-specific since
you might have different trusted root CA certs, etc.

Does the OpenLDAP API expose a call-back interface to implement CRL
checking and such?

Ciao, Michael.

TODO list python-ldap

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

HI!

Please have a look at the current TODO file of python-ldap:
------------------- snip -------------------
General:
- Define common license for all modules

Modules/
- Completion of start_tls_s() with SSL context
- Support for LDAP over SSL
- Look into OpenLDAP 2's lib ldap_r to make python-ldap re-entrant
- Support for SASL bind
- Support for VLV control
- Support for server-side sorting control
- Wrap ldap_explode_rdn
- Support for binding with in DSA control mode

Lib/
- Remove obsolete/unsupported modules
- LDAPv3 schema support (BNF parser needed)
- Add ldapurl module from web2ldap
- LDIF parser for replication logs
- DSML support

------------------- snip -------------------

If you have some spare cycles and want to contribute please jump on
in.

I'm also planning to contribute some of my modules implemented for
web2ldap (see pylib/ldaputil/ of recent web2ldap snapshot) to
python-ldap with a more liberal license. Please check these modules
and comment.

We should agree on a commonly used license. At the moment the
license is undefined and some modules have different license. I
relaxed the license of my ldif module which was strict GPL.

Ciao, Michael.

Re: TLS context

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

On Sun, Nov 11, 2001 at 08:26:57PM +1000, David Leonard wrote:
> Can you give an example of what a python program might look like
> using these?

The only thing I implemented and tested now is the ldap.initialize().
This works like that (this will start LDAP over SSL connection):

import ldap
l=ldap.initialize("ldaps://some.ldap.server")
l.bind("","")
...

I am currently testing those options (OpenLDAP API is not documented
very well).

I think it would work like this (using StartTLS):

import ldap
l=ldap.initialize("ldap://some.ldap.server")
l.tls_cacert_file="cacert.pem"
l.tls_cert_file="mycert.pem"
l.tls_key_file="mykey.pem"
l.tls_require_cert=1
l.start_tls_s()
l.bind("mydn","mypasswd")

Using LDAP over SSL it whould be:
import ldap
l=ldap.initialize("ldaps://some.ldap.server")
l.tls_cacert_file="cacert.pem"
l.tls_cert_file="mycert.pem"
l.tls_key_file="mykey.pem"
l.tls_require_cert=1
l.bind("mydn","mypasswd")

You can use ldap.init() instead of ldap.initialize(). ldap.open() 
should not be used as it is depreciated, and it won't work for LDAP over
SSL (as connection would be open before tls options are set).

It seems some of OpenLDAP options (eg. LDAP_OPT_DEBUG_LEVEL) are global
flags, not specific to any LDAPObject. So we need some interface to set
those for whole ldap module. I don't know how to implement this.
Should it be some function like ldap.set_option(), or a global variable
set like attribute of LDAPObject. Is ther C interface for such thing?
I have not yet checked if TLS options all global or connection-specific.

Greets,
        Jacek

TLS context

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

Hi,

I was looking at the code to see how should make the support for TLS
context.
IMHO using the areguments for ldap_start_tls_s would be quite
complicated, and would probably require some low-level SSL coding.
But it seems it can be done using OpenLDAP options such as:
LDAP_OPT_X_TLS_CTX
LDAP_OPT_X_TLS_CACERTFILE
LDAP_OPT_X_TLS_CACERTDIR
LDAP_OPT_X_TLS_CERTFILE
LDAP_OPT_X_TLS_KEYFILE
LDAP_OPT_X_TLS_REQUIRE_CERT
LDAP_OPT_X_TLS_CIPHER_SUITE
LDAP_OPT_X_TLS_RANDOM_FILE
LDAP_OPT_X_TLS_NEVER
LDAP_OPT_X_TLS_HARD
LDAP_OPT_X_TLS_DEMAND
LDAP_OPT_X_TLS_ALLOW
LDAP_OPT_X_TLS_TRY

This can be done by extending getattr/setattr functions.
Of course many not TLS-related options can (and IMHO should) be added.

One more thing, which IMHO should be added is ldap_initialize()
function, which can be used to connect to LDAP server using its URI.
It would also handle ldaps:// URIs.

Should I do all/part of these?

Greets,
        Jacek

Commited patches for OpenLDAP 2.0 libs

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

HI!

I've commited the patches provided by Konstantin and Steffen for
building against OpenLDAP 2.0.x libs.

Grab it. Test it!

Ciao, Michael.

Re: Updates for OpenLDAP >= 2.0.12

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

Jacek Konieczny wrote:
> 
> I would like to have it commited as soon as possible, so I can work on
> TLS support without mixing things :-)

I'd appreciate if you could implement the missing parameters of
start_tls_s() which passes a SSL context (trusted root certs, CRL
checking, etc.).

Ciao, Michael.

Re: Some questions (status,SSL,Unicode)

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

Jacek Konieczny wrote:
> 
> On Thu, Nov 08, 2001 at 03:15:57PM +0100, Michael Ströder wrote:
> > See item 1 on http://python-ldap.sourceforge.net/faq.shtml ;-).
> >
> > > 2. What about SSL/TLS/STARTTLS support? I realy need encrypted
> > > connection to LDAP server.
> >
> > Patches for using StartTLS were provided but not landed in CVS yet.
> > Also the implementation was somewhat incomplete since it lacks
> > support for setting up a local SSL context (trusted root CA certs,
> > CRL handling etc.).
> Could you send me those patches, please?
> So I won't duplicate work when I start doing this.

See attachment.

Ciao, Michael.

Updates for OpenLDAP >= 2.0.12

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

Hi,

current python-ldap won't work with OpenLDAP >= 2.0.21. 

Here is part of CHANGES file from OpenLDAP sources:

OpenLDAP 2.0.12 Release
        ...
        Removed -lldap UFN search support
        ...

python-ldap uses those UFN search functions which are not included in
openldap libraries any more, so it crashes with "unresolved sybol" when
used.

Below is a patch, which removes (in fact makes conditional) support for
UFN search in python-ldap. 
It seems that autoconf support is broken, and I don't know how to check
things like existence of some function with setup.py, so the only way
to activate UFN search again is to '#define UFN_SEARCH'.

I would like to have it commited as soon as possible, so I can work on
TLS support without mixing things :-)

Greets,
        Jacek

Index: setup.cfg
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/setup.cfg,v
retrieving revision 1.2
diff -u -r1.2 setup.cfg
--- setup.cfg	2001/05/16 02:26:00	1.2
+++ setup.cfg	2001/11/10 18:56:43
@@ -1,6 +1,6 @@
 [_ldap]
 class = OpenLDAP2
-library_dirs = /usr/local/lib
-include_dirs = /usr/local/include
+library_dirs = /usr/lib
+include_dirs = /usr/include
 ; libs = lber ldap
 
Index: Modules/LDAPObject.c
===================================================================

RCS file: /cvsroot/python-ldap/python-ldap/Modules/LDAPObject.c,v
retrieving revision 1.11
diff -u -r1.11 LDAPObject.c
--- Modules/LDAPObject.c	2001/06/06 23:40:04	1.11
+++ Modules/LDAPObject.c	2001/11/10 18:56:57
@@ -1451,6 +1451,7 @@
 
 /* ldap_search_s == ldap_search_st */
 
+#ifdef UFN_SEARCH
 /* ldap_ufn_search_c */
 
 /* ldap_ufn_search_ct */
@@ -1534,6 +1535,7 @@
 "\tSee the LDAP library manual pages for more information on these\n"
 "\t`user-friendly name' functions.";
 
+#endif /* UFN_SEARCH */
 /* ldap_sort_entries */
 
 /* ldap_url_search */
@@ -1688,9 +1690,11 @@
     {"search",		(PyCFunction)l_ldap_search,		METH_VARARGS,	doc_search},	
     {"search_s",	(PyCFunction)l_ldap_search_st,		METH_VARARGS,	doc_search},	
     {"search_st",	(PyCFunction)l_ldap_search_st,		METH_VARARGS,	doc_search},	
+#ifdef UFN_SEARCH
     {"ufn_search_s",	(PyCFunction)l_ldap_ufn_search_s,	METH_VARARGS,	doc_ufn},
     {"ufn_setfilter",	(PyCFunction)l_ldap_ufn_setfilter,	METH_VARARGS,	doc_ufn},
     {"ufn_setprefix",	(PyCFunction)l_ldap_ufn_setprefix,	METH_VARARGS,	doc_ufn},
+#endif /* UFN_SEARCH */
     {"url_search_s",	(PyCFunction)l_ldap_url_search_st,	METH_VARARGS,	doc_url_search},	
     {"url_search_st",	(PyCFunction)l_ldap_url_search_st,	METH_VARARGS,	doc_url_search},	
 #if defined(FILENO_SUPPORTED)

Re: Some questions (status,SSL,Unicode)

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

Jacek Konieczny wrote:
> 
> 1. Is the project alive?

See item 1 on http://python-ldap.sourceforge.net/faq.shtml ;-).

> 2. What about SSL/TLS/STARTTLS support? I realy need encrypted
> connection to LDAP server.

Patches for using StartTLS were provided but not landed in CVS yet.
Also the implementation was somewhat incomplete since it lacks
support for setting up a local SSL context (trusted root CA certs,
CRL handling etc.).

> 3. What about Unicode? All strings with non-ascii characters are
> encoded as Unicode in a directory and returned as UTF-8 from LDAP
> search. It seems reasonable to store them as Unicode objects in python,
> but It would require python-ldap to know some details about schema.
> I think python-ldap should be just simple interface to LDAP, and the
> application should be responsible for interpreting the results.

Yes. The low-level C wrapper module in python-ldap should not handle
Unicode objects. It should pass strings not knowing if these are
text strings or binary blobs.

> If it is necessery I can help with developing python-ldap, as it is very
> important to me.

You're welcome to help.

> I am using Linux with openldap-2.0.18, so I could test
> it only on this platform.

There are various public LDAP servers.

> BTW. My browser is working now, but only supports anonymous browsing of
> LDAP directory and has no editing capabilities.

You might wanna check out
http://python-ldap.sourceforge.net/apps.shtml to learn more about
what login and editing capabilities mean by looking at existing
code.

Ciao, Michael.

Some questions (status,SSL,Unicode)

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

Hi,

I am new to the list. I have some questions about python-ldap. I have
not found answers for them in the archives, so I am asking here...

1. Is the project alive? The mailing list and CVS logs make me think it
is dead :-(

2. What about SSL/TLS/STARTTLS support? I realy need encrypted
connection to LDAP server.

3. What about Unicode? All strings with non-ascii characters are
encoded as Unicode in a directory and returned as UTF-8 from LDAP
search. It seems reasonable to store them as Unicode objects in python,
but It would require python-ldap to know some details about schema.
I think python-ldap should be just simple interface to LDAP, and the
application should be responsible for interpreting the results.

I am currently working on LDAP browser with curses interface. I need
such thing for managing users and such on my servers.
To make the browser (I want to use python for that) I need
python bindings to LDAP. So I use python-ldap (ver. 1.10alpha3-1).

If it is necessery I can help with developing python-ldap, as it is very
important to me. I am using Linux with openldap-2.0.18, so I could test
it only on this platform.

BTW. My browser is working now, but only supports anonymous browsing of
LDAP directory and has no editing capabilities.

Greets,
	Jacek

ADV: Multi Million Dollar Business Opportunity coming to Australia

[Dennis P. <cr...@us...>]

Good day!

Would you like to earn an additional $100,000 a year and more, part time? 
USA DIRECT WORLDWIDE invites you to review our complete turnkey 
International Marketing Plan.

Our company, already successful in the United States, Canada, Hong Kong, 
Japan, and Taiwan, now offers you the "Once in a Lifetime Opportunity" to 
benefit from our business launch opening in Australia.

This is not a get-rich-quick money making scheme, but a genuine business 
opportunity.
Please click to find out more: 
http://www.usadirectworldwide.com/prelaunch.asp?cg=10006

Warmest Regards,

Dennis Porter
Director of International Development

Should you not wish to be contacted at this email address again, please click
this link: http://www.usadirectworldwide.com/unsub.asp

Re: Undefined Symbol?

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

jf...@se... wrote:
> 
> server = ldap.open('myhost',636)
> server.version = ldap.VERSION3
> server.start_tls_s()
> server.simple_bind_s("hidden","hidden")
> [..]
> ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"}

Took me also a while to figure this one out. The CN attribute in the
server's certificate has to be EXACTLY the same like the host name
you're using when calling ldap.open(). Check that.

Note that since there's no certificate validation in place this
patch does not provide protection against MITM-attacks. It has
experimental status and shouldn't be used in a productive
environment.

Ciao, Michael.

Re: How to generally handle exceptions?

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

Nick Bower wrote:
> 
> thanks - i was having trouble knowing where this "desc" field was.  so i
> se now that it is:
> 
> except _ldap.LDAPError, e
>   print 'Your error is ' + e[0]['desc']
> 
> thanks for the help.

Sometimes you can't rely on the exact data structure with e.args
being a dictionary of the form {'desc':'','info':''}. I'd also
recommend to display the info field. E.g. recent versions of
OpenLDAP 2 give more information about schema violation which is
useful for the user.

Maybe it's overkill how web2ldap does it but take the snippet below
as food for thought. Note that web2ldap trys to also handle older
versions of python-ldap floating around:

LDAPError = ldap.LDAPError

[..]

    except LDAPError,e:
      if __debug__:
        w2lapp.core.log_exception(errfile,sid,command,form,ls,env)
      try:
        if type(e.args[0])==type({}):
          ErrMsg = '%s: %s' %
(e.args[0]['desc'],e.args[0].get('info',''))
        elif type(e.args[0])==type(1):
          ErrMsg = 'Error Code: %d<br />Error description: %s' % (
            e.args[0],e.args[1]
          )
        else:
          ErrMsg = str(e.args)
      except TypeError:
        ErrMsg = str(e.args)
      except IndexError:
        ErrMsg = str(e.args)
      w2lapp.gui.ExceptionMsg(
        sid,outf,form,ls,'LDAP exception',ErrMsg
      )

[..]

Ciao, Michael.

Re: How to generally handle exceptions?

[Nick B. <ni...@br...>]

thanks - i was having trouble knowing where this "desc" field was.  so i
se now that it is:

except _ldap.LDAPError, e
  print 'Your error is ' + e[0]['desc']

thanks for the help.

nick

Michael Str=F6der wrote:
>=20
> Nick Bower wrote:
> >
> > Is there any possible way to tell what exception has been raised in
> > python-ldap without catching every single possibile type of
> > _ldap.LDAPError?
> >
> > It would be really nice in example included in the python-ldap
> > documentation if an exception was caught in the following general way=
:
> >
> > try:
> >   <connect, bind and search, as is currently shown>
> > except:
> >   <display type of exception and its description>
> >
> > at the moment, there is no example code with exceptions in the
> > documentation or distribution and i can't figure out how to catch one
> > from the exception references provided without trying to catch every
> > single possibility.
>=20
> import ldap
>=20
> try:
>     <connect, bind and search, as is currently shown>
> except ldap.LDAPError,e:
>     print repr(e)
>=20
> Well, exception instances are not really implemented completely
> pythonic but it's a start.
>=20
> Ciao, Michael.

--=20
Nick Bower, Intranet Developer
ni...@br...

Brainstorm
388 - 396 Oxford St
London W1N 9EH
United Kingdom
Tel 020 7074 7000
Mob 0790 5405 443
Fax 020 7074 7070

http://www.brainstorm.co.uk

Re: How to generally handle exceptions?

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

Nick Bower wrote:
> 
> Is there any possible way to tell what exception has been raised in
> python-ldap without catching every single possibile type of
> _ldap.LDAPError?
> 
> It would be really nice in example included in the python-ldap
> documentation if an exception was caught in the following general way:
> 
> try:
>   <connect, bind and search, as is currently shown>
> except:
>   <display type of exception and its description>
> 
> at the moment, there is no example code with exceptions in the
> documentation or distribution and i can't figure out how to catch one
> from the exception references provided without trying to catch every
> single possibility.

import ldap

try:
    <connect, bind and search, as is currently shown>
except ldap.LDAPError,e:
    print repr(e)

Well, exception instances are not really implemented completely
pythonic but it's a start.

Ciao, Michael.

RE: Undefined Symbol?

[<jf...@se...>]

Hello,

I am now trying to get an SSL connection working with my OpenLDAP 2.0.11
slapd server, and have run into problems again :(

I run my slapd with "-h ldaps:///" so that it runs ONLY over SSL, this
means it listens on port 636.

Here's my bit of code:

server =3D ldap.open('myhost',636)
server.version =3D ldap.VERSION3
server.start_tls_s()
server.simple_bind_s("hidden","hidden")

And here's the result:

Traceback (most recent call last):
  File "urds.py", line 5, in ?
    server.start_tls_s()
ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"}

Here's what my slapd, with maximum logging (1), has to say about that:

Oct 23 10:38:57 grumbler slapd[5627]: connection_get(9): got connid=3D4=20
Oct 23 10:38:57 grumbler slapd[5627]: connection_read(9): checking for
input on id=3D4=20
Oct 23 10:38:57 grumbler slapd[5627]: connection_read(9): TLS accept error
error=3D-1 id=3D4, closing=20
Oct 23 10:38:57 grumbler slapd[5627]: connection_closing: readying conn=3D4
sd=3D9 for close=20
Oct 23 10:38:57 grumbler slapd[5627]: connection_close: conn=3D4 sd=3D9=20

Unfortunately, not very helpfull!

Any ideas? I successfully connect to this server using Perl and various
tools.  I compiled my pyton-ldap from CVS and patched with all the patches
in the original "starttls" message from the list.

One thing: It would me nice ot have a central place where to get patches
and so on, took me a while to figure out where to get them, and even now,
I'm not allways sure which patch does what!

Thanks again!
J.F.


On Mon, 22 Oct 2001, Jean-Fran=E7ois Doyon wrote:

> Hello,
>=20
> OK, never mind, I eventually figured it out :) Turns out the patches are
> hidden inside the RPM's !
>=20
> I had to do some manual work since I wanted it to work with Python 2.1, b=
ut
> now I'm not getting any errors ...
>=20
> I'm looking forward to trying it out :)
>=20
> Thanks for the contribution!
>=20
> Jean-Fran=E7ois Doyon
> Carbon IT
> http://methane.org
> Tel.: (819) 827-9997
> Fax : (819) 827-6653
>=20
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> jf...@se...
> Sent: October 22, 2001 5:01 PM
> To: Michael Str=F6der
> Cc: pyt...@li...
> Subject: Re: Undefined Symbol?
>=20
> Michael,
>=20
> I did see it, unfortunately, I'm not sure WHERE to find these patches,
> they don't seem to be in the CVS tree! Also, the README in the CVS says i=
t
> was tested again OpenLDAP 2.0 and Python 2.0 ... Which is pretty damn
> close to what I'm using (Python 2.1.1 with OpenLDAP 2.0.17, although the
> files say 2.0.11 for some reason).
>=20
> Maybe I'll try the RPM's :) I just like hacking things myself!
>=20
> Thanks!
> J.F.
>=20
>=20
>=20
> On Mon, 22 Oct 2001, Michael [iso-8859-1] Str=F6der wrote:
>=20
> > jf...@se... wrote:
> > >
> > >
> > > I just installed OpenLDAP 2.0.17 and the CVS version of python-ldap,
> >
> > See item 3 on http://python-ldap.sourceforge.net/faq.shtml
> >
> > Note that applying patches to python-ldap is experimental.
> >
> > Ciao, Michael.
> >
> > _______________________________________________
> > Python-LDAP-dev mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
> >
>=20
>=20
>=20
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>=20
>=20
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>=20

Re: How to generally handle exceptions?

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

Nick,

try this:
-----------------------------------------------------------
    try:
        <connect, bind and search, as is currently shown>
    except Exception, e:
        print 'Error! %s' % e
-----------------------------------------------------------

Regards

Donal Hunt


Nick Bower wrote:
> 
> Is there any possible way to tell what exception has been raised in
> python-ldap without catching every single possibile type of
> _ldap.LDAPError?
> 
> It would be really nice in example included in the python-ldap
> documentation if an exception was caught in the following general way:
> 
> try:
>   <connect, bind and search, as is currently shown>
> except:
>   <display type of exception and its description>
> 
> at the moment, there is no example code with exceptions in the
> documentation or distribution and i can't figure out how to catch one
> from the exception references provided without trying to catch every
> single possibility.
> 
> thanks alot, nick.
> 
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev