From jlittle at open-it.org Sun Apr 6 07:40:31 2003 From: jlittle at open-it.org (Joe Little) Date: Sat, 5 Apr 2003 21:40:31 -0800 Subject: new 2.0.0pre7 RPMS builds Message-ID: <47836B37-67F2-11D7-B45C-0003931A4574@open-it.org> 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. From michael at stroeder.com Sun Apr 6 17:33:16 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 06 Apr 2003 17:33:16 +0200 Subject: [rcardenes@debian.org: Re: Bug#179108: ldap_initialize patch] In-Reply-To: <20030405235536.GA1495@hawkins.emu.id.au> References: <20030405235536.GA1495@hawkins.emu.id.au> Message-ID: <3E9048BC.5010701@stroeder.com> 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 openldap-software at OpenLDAP.org 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. From ricardo at conysis.com Thu Apr 10 18:25:47 2003 From: ricardo at conysis.com (Ricardo Javier Cardenes) Date: Thu, 10 Apr 2003 17:25:47 +0100 Subject: [rcardenes@debian.org: Re: Bug#179108: ldap_initialize patch] In-Reply-To: <3E9048BC.5010701@stroeder.com> References: <20030405235536.GA1495@hawkins.emu.id.au> <3E9048BC.5010701@stroeder.com> Message-ID: <20030410162547.GA26648@midgard.heimy.org> 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 From michael at stroeder.com Thu Apr 10 22:43:51 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 10 Apr 2003 22:43:51 +0200 Subject: [rcardenes@debian.org: Re: Bug#179108: ldap_initialize patch] In-Reply-To: <20030410162547.GA26648@midgard.heimy.org> References: <20030405235536.GA1495@hawkins.emu.id.au> <3E9048BC.5010701@stroeder.com> <20030410162547.GA26648@midgard.heimy.org> Message-ID: <3E95D787.40508@stroeder.com> 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. From peter at hawkins.emu.id.au Fri Apr 11 13:23:19 2003 From: peter at hawkins.emu.id.au (Peter Hawkins) Date: Fri, 11 Apr 2003 21:23:19 +1000 Subject: Patch to replace tuple() with tuple([]) Message-ID: <20030411112319.GA17695@hawkins.emu.id.au> 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 "", 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 -------------- next part -------------- diff -urN Lib.old/ldap/schema/models.py Lib/ldap/schema/models.py --- Lib.old/ldap/schema/models.py 2003-04-11 21:17:07.000000000 +1000 +++ Lib/ldap/schema/models.py 2003-04-11 21:17:26.000000000 +1000 @@ -57,7 +57,7 @@ return '' def key_list(self,key,values,sep=' ',quoted=0): - assert type(values)==type(tuple()),TypeError("values has to be of ListType") + assert type(values)==type(tuple([])),TypeError("values has to be of ListType") if not values: return '' if quoted: @@ -91,14 +91,14 @@ """ schema_attribute = 'objectClasses' token_defaults = { - 'NAME':tuple(), + 'NAME':tuple([]), 'DESC':(None,), 'OBSOLETE':None, - 'SUP':tuple(), + 'SUP':tuple([]), 'STRUCTURAL':None, 'AUXILIARY':None, 'ABSTRACT':None, - 'MUST':tuple(), + 'MUST':tuple([]), 'MAY':() } @@ -115,13 +115,13 @@ self.kind = 1 elif d['AUXILIARY']!=None: self.kind = 2 - assert type(self.names)==type(tuple()) + assert type(self.names)==type(tuple([])) assert self.desc is None or type(self.desc)==type('') assert type(self.obsolete)==type(0) and (self.obsolete==0 or self.obsolete==1) - assert type(self.sup)==type(tuple()) + assert type(self.sup)==type(tuple([])) assert type(self.kind)==type(0) - assert type(self.must)==type(tuple()) - assert type(self.may)==type(tuple()) + assert type(self.must)==type(tuple([])) + assert type(self.may)==type(tuple([])) return # ObjectClass.__init__() def __str__(self): @@ -172,10 +172,10 @@ """ schema_attribute = 'attributeTypes' token_defaults = { - 'NAME':tuple(), + 'NAME':tuple([]), 'DESC':(None,), 'OBSOLETE':None, - 'SUP':tuple(), + 'SUP':tuple([]), 'EQUALITY':(None,), 'ORDERING':(None,), 'SUBSTR':(None,), @@ -217,9 +217,9 @@ except KeyError: raise self.usage = AttributeUsage.get(d['USAGE'][0],0) - assert type(self.names)==type(tuple()) + assert type(self.names)==type(tuple([])) assert self.desc is None or type(self.desc)==type('') - assert type(self.sup)==type(tuple()),'attribute sup has type %s' % (type(self.sup)) + assert type(self.sup)==type(tuple([])),'attribute sup has type %s' % (type(self.sup)) assert type(self.obsolete)==type(0) and (self.obsolete==0 or self.obsolete==1) assert type(self.single_value)==type(0) and (self.single_value==0 or self.single_value==1) assert type(self.no_user_mod)==type(0) and (self.no_user_mod==0 or self.no_user_mod==1) @@ -295,7 +295,7 @@ """ schema_attribute = 'matchingRules' token_defaults = { - 'NAME':tuple(), + 'NAME':tuple([]), 'DESC':(None,), 'OBSOLETE':None, 'SYNTAX':(None,), @@ -306,7 +306,7 @@ self.desc = d['DESC'][0] self.obsolete = d['OBSOLETE']!=None self.syntax = d['SYNTAX'][0] - assert type(self.names)==type(tuple()) + assert type(self.names)==type(tuple([])) assert self.desc is None or type(self.desc)==type('') assert type(self.obsolete)==type(0) and (self.obsolete==0 or self.obsolete==1) assert self.syntax is None or type(self.syntax)==type('') @@ -334,10 +334,10 @@ """ schema_attribute = 'matchingRuleUse' token_defaults = { - 'NAME':tuple(), + 'NAME':tuple([]), 'DESC':(None,), 'OBSOLETE':None, - 'APPLIES':tuple(), + 'APPLIES':tuple([]), } def _set_attrs(self,l,d): @@ -345,10 +345,10 @@ self.desc = d['DESC'][0] self.obsolete = d['OBSOLETE']!=None self.applies = d['APPLIES'] - assert type(self.names)==type(tuple()) + assert type(self.names)==type(tuple([])) assert self.desc is None or type(self.desc)==type('') assert type(self.obsolete)==type(0) and (self.obsolete==0 or self.obsolete==1) - assert type(self.applies)==type(tuple()) + assert type(self.applies)==type(tuple([])) return # MatchingRuleUse.__init__() def __str__(self): diff -urN Lib.old/ldap/schema/tokenizer.py Lib/ldap/schema/tokenizer.py --- Lib.old/ldap/schema/tokenizer.py 2003-04-11 21:17:07.000000000 +1000 +++ Lib/ldap/schema/tokenizer.py 2003-04-11 21:17:45.000000000 +1000 @@ -66,7 +66,7 @@ if i References: <20030411112319.GA17695@hawkins.emu.id.au> Message-ID: <3E96A8BB.9040602@stroeder.com> 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. From michael at stroeder.com Fri Apr 11 13:42:24 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 11 Apr 2003 13:42:24 +0200 Subject: Patch to replace tuple() with tuple([]) In-Reply-To: <20030411112319.GA17695@hawkins.emu.id.au> References: <20030411112319.GA17695@hawkins.emu.id.au> Message-ID: <3E96AA20.3090400@stroeder.com> 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. From michael at stroeder.com Thu Apr 10 22:43:51 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 10 Apr 2003 22:43:51 +0200 Subject: [rcardenes@debian.org: Re: Bug#179108: ldap_initialize patch] In-Reply-To: <20030410162547.GA26648@midgard.heimy.org> References: <20030405235536.GA1495@hawkins.emu.id.au> <3E9048BC.5010701@stroeder.com> <20030410162547.GA26648@midgard.heimy.org> Message-ID: <3E95D787.40508@stroeder.com> 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. From michael at stroeder.com Fri Apr 11 18:44:05 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 11 Apr 2003 18:44:05 +0200 Subject: SASL response is not a SASL BindRequest In-Reply-To: References: Message-ID: <3E96F0D5.7050805@stroeder.com> 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. From jlittle at open-it.org Sat Apr 12 00:43:17 2003 From: jlittle at open-it.org (Joe Little) Date: Fri, 11 Apr 2003 15:43:17 -0700 Subject: ANN: python-ldap-2.0.0pre08 In-Reply-To: <3E96C404.3030304@stroeder.com> Message-ID: python-ldap RPMS to match this version have also been posted, in their usual location. 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. > > > > > From peter at hawkins.emu.id.au Sat Apr 12 01:41:32 2003 From: peter at hawkins.emu.id.au (Peter Hawkins) Date: Sat, 12 Apr 2003 09:41:32 +1000 Subject: ANN: python-ldap-2.0.0pre08 In-Reply-To: References: <3E96C404.3030304@stroeder.com> Message-ID: <20030411234132.GA2041@hawkins.emu.id.au> 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. > > > > > > > > > > From michael at stroeder.com Sat Apr 12 13:52:21 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 12 Apr 2003 13:52:21 +0200 Subject: ANN: python-ldap-2.0.0pre08 In-Reply-To: <20030411234132.GA2041@hawkins.emu.id.au> References: <3E96C404.3030304@stroeder.com> <20030411234132.GA2041@hawkins.emu.id.au> Message-ID: <3E97FDF5.1090909@stroeder.com> 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. From aoudiwalid at yahoo.fr Mon Apr 14 15:52:20 2003 From: aoudiwalid at yahoo.fr (=?iso-8859-1?q?walid=20aoudi?=) Date: Mon, 14 Apr 2003 15:52:20 +0200 (CEST) Subject: problem with python ldap Message-ID: <20030414135220.31196.qmail@web20902.mail.yahoo.com> 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 "", 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 ? From aoudiwalid at yahoo.fr Tue Apr 15 17:08:57 2003 From: aoudiwalid at yahoo.fr (=?iso-8859-1?q?walid=20aoudi?=) Date: Tue, 15 Apr 2003 17:08:57 +0200 (CEST) Subject: problem installing and runnig normally python-ldap with more than 1 version of python Message-ID: <20030415150857.57988.qmail@web20908.mail.yahoo.com> 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 "", 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 "", line 1, in ? ImportError: `�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 From michael at stroeder.com Tue Apr 15 17:36:29 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 15 Apr 2003 17:36:29 +0200 Subject: problem installing and runnig normally python-ldap with more than 1 version of python In-Reply-To: <20030415150857.57988.qmail@web20908.mail.yahoo.com> References: <20030415150857.57988.qmail@web20908.mail.yahoo.com> Message-ID: <3E9C26FD.4030606@stroeder.com> 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. From michael at stroeder.com Thu Apr 17 18:30:11 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 17 Apr 2003 18:30:11 +0200 Subject: problem with python-ldap (it's very impotant please) In-Reply-To: <20030417083009.79659.qmail@web20903.mail.yahoo.com> References: <20030417083009.79659.qmail@web20903.mail.yahoo.com> Message-ID: <3E9ED693.7010100@stroeder.com> 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. From aoudiwalid at yahoo.fr Thu Apr 17 10:30:09 2003 From: aoudiwalid at yahoo.fr (=?iso-8859-1?q?walid=20aoudi?=) Date: Thu, 17 Apr 2003 10:30:09 +0200 (CEST) Subject: problem with python-ldap (it's very impotant please) Message-ID: <20030417083009.79659.qmail@web20903.mail.yahoo.com> 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 "", 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 "", line 1, in ? ImportError: `�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 From stuart.b at commonground.com.au Thu Apr 17 09:38:02 2003 From: stuart.b at commonground.com.au (Stuart Bishop) Date: Thu, 17 Apr 2003 17:38:02 +1000 Subject: SASL response is not a SASL BindRequest In-Reply-To: <3E96F0D5.7050805@stroeder.com> Message-ID: <84D28E3C-70A7-11D7-A7C1-000A95A06FC6@commonground.com.au> Finally got a chance to get back onto this... sorry if anyone was waiting. On Saturday, April 12, 2003, at 02:44 AM, Michael Str?der wrote: > 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? I might have on one of the original test machines (old laptop since 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, 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, in _ldap_call result = apply(func,args,kwargs) ldap.AUTH_UNKNOWN: {'info': 'SASL(-4): no mechanism available: No 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 password. -- Stuart Bishop http://shangri-la.dropbear.id.au/ From michael at stroeder.com Thu Apr 17 18:34:47 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 17 Apr 2003 18:34:47 +0200 Subject: SASL response is not a SASL BindRequest In-Reply-To: <84D28E3C-70A7-11D7-A7C1-000A95A06FC6@commonground.com.au> References: <84D28E3C-70A7-11D7-A7C1-000A95A06FC6@commonground.com.au> Message-ID: <3E9ED7A7.8040500@stroeder.com> 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. From asoyeur at ac-toulouse.fr Fri Apr 18 10:28:27 2003 From: asoyeur at ac-toulouse.fr (Alain Soyeur) Date: Fri, 18 Apr 2003 10:28:27 +0200 Subject: mandrake9.1 install problem Message-ID: <200304181028.27894.asoyeur@ac-toulouse.fr> I used python-ldap without problems on a mandrake 9.0 distribution with redhat rpms (option --nodeps), but this does not work anymore with mandrake 9.1. I tried to compile python-ldap-2.0.0pre08.tar.gz, modified setup.cfg : library_dirs = /usr/lib libs = ldap lber resolv but I get this message with python setup.py build: running install running build running build_py warning: build_py: file Lib/ldap.py (for module ldap) not found warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) not found I tried an install with python setup.py install, but when I use my old scripts, they don't work anymore, with errors like : NameError: global name 'SCOPE_SUBTREE' is not defined ... Anyone has an experience with mandrake 9.1 ? -- Alain Soyeur Lyc?e Fermat Toulouse http://asoyeur.free.fr From michael at stroeder.com Fri Apr 18 14:18:26 2003 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Fri, 18 Apr 2003 14:18:26 +0200 Subject: mandrake9.1 install problem In-Reply-To: <200304181028.27894.asoyeur@ac-toulouse.fr> References: <200304181028.27894.asoyeur@ac-toulouse.fr> Message-ID: <3E9FED12.7090204@stroeder.com> Alain Soyeur wrote: > I used python-ldap without problems Which version? > warning: build_py: file Lib/ldap.py (for module ldap) not found > warning: build_py: file Lib/ldap/schema.py (for module ldap.schema) not found These two messages are no problem. It's just an issue with the DistUtils not properly recognizing the module packages. > I tried an install with python setup.py install, but when I use my old > scripts, they don't work anymore, with errors like : > NameError: global name 'SCOPE_SUBTREE' is not defined Please try the following: $ python -c "import ldap; print ldap.SCOPE_SUBTREE" 2 Ciao, Michael. From stuart.b at commonground.com.au Sat Apr 19 03:20:30 2003 From: stuart.b at commonground.com.au (Stuart Bishop) Date: Sat, 19 Apr 2003 11:20:30 +1000 Subject: SASL response is not a SASL BindRequest In-Reply-To: <3E9ED7A7.8040500@stroeder.com> Message-ID: <1C3A9FAC-7205-11D7-9B20-000A95A06FC6@commonground.com.au> On Friday, April 18, 2003, at 02:34 AM, Michael Str?der wrote: > 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... Yup. Turns out that runtime libraries support via distutils is broken in Python 2.2 under OS X. Python 2.3a2 is working fine, and I've got a bug report open to fix the distutils problem in any future 2.2.x release. Looking good. Thanks for your help on this Michael :-) -- Stuart Bishop http://shangri-la.dropbear.id.au/ From cavok at filibusta.crema.unimi.it Sat Apr 19 22:39:03 2003 From: cavok at filibusta.crema.unimi.it (Domenico Andreoli) Date: Sat, 19 Apr 2003 22:39:03 +0200 Subject: Bug#175710: python-ldap modlist patch In-Reply-To: <20030404105306.GB4399@hawkins.emu.id.au> References: <20030404105306.GB4399@hawkins.emu.id.au> Message-ID: <20030419203903.GA8920@filibusta.crema.unimi.it> hi Michael, the patch you are referring to is already in the python-ldap version i'm using and the problem is right in the "modlist.append((ldap.MOD_DELETE,attrtype,None))". the error i get is from deletion of an inexistent entry. i attached an example to reproduce the bug. cheers cavok On Fri, Apr 04, 2003 at 08:53:06PM +1000, Peter Hawkins wrote: > Well, I'm not sure but I think I already fixed this in a different way: > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Lib/ldap/modlist.py.diff?r1=1.11&r2=1.12 > > Comment: > "Replace an attribute value by deleting it completely and re-add the whole > attribute value list. This is necessary to make it work with attributes for > which no matching rules are implemented. The caveat is that it might trigger > mor attribute indexing depending on LDAP server implementation." > -----[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 From cavok at filibusta.crema.unimi.it Sun Apr 20 01:50:36 2003 From: cavok at filibusta.crema.unimi.it (Domenico Andreoli) Date: Sun, 20 Apr 2003 01:50:36 +0200 Subject: Bug#175710: python-ldap modlist patch In-Reply-To: <20030419203903.GA8920@filibusta.crema.unimi.it> References: <20030404105306.GB4399@hawkins.emu.id.au> <20030419203903.GA8920@filibusta.crema.unimi.it> Message-ID: <20030419235036.GA15111@filibusta.crema.unimi.it> of course i forgot the attachment.. On Sat, Apr 19, 2003 at 10:39:03PM +0200, Domenico Andreoli wrote: > hi Michael, > > the patch you are referring to is already in the python-ldap version i'm > using and the problem is right in the "modlist.append((ldap.MOD_DELETE,attrtype,None))". > the error i get is from deletion of an inexistent entry. > > i attached an example to reproduce the bug. > > cheers > cavok > > On Fri, Apr 04, 2003 at 08:53:06PM +1000, Peter Hawkins wrote: > > Well, I'm not sure but I think I already fixed this in a different way: > > > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Lib/ldap/modlist.py.diff?r1=1.11&r2=1.12 > > > > Comment: > > "Replace an attribute value by deleting it completely and re-add the whole > > attribute value list. This is necessary to make it work with attributes for > > which no matching rules are implemented. The caveat is that it might trigger > > mor attribute indexing depending on LDAP server implementation." > > -----[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -------------- next part -------------- #! /usr/bin/python import ldap, ldap.modlist uri = "ldap://localhost" binddn = "cn=admin,dc=localnet" passwd = "secret" dn = "uid=fake,dc=localnet" def make_entry(s): return { "objectClass" : [ "top", "person" ], "cn" : [ "Domenico" ], "sn" : [ "Andreoli" ], "description" : [ s ] } l = ldap.initialize(uri) l.bind_s(binddn, passwd, ldap.AUTH_SIMPLE) try: entry = make_entry("something") modlist = ldap.modlist.addModlist(entry) l.add_s(dn, modlist) entry_old = entry entry = make_entry(None) modlist = ldap.modlist.modifyModlist(entry_old, entry) l.modify_s(dn, modlist) entry_old = entry entry = make_entry("something") modlist = ldap.modlist.modifyModlist(entry_old, entry) # print modlist l.modify_s(dn, modlist) # ooops except: l.delete_s(dn) l.unbind_s() raise From michael at stroeder.com Sun Apr 20 11:54:52 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 20 Apr 2003 11:54:52 +0200 Subject: Bug#175710: python-ldap modlist patch In-Reply-To: <20030419203903.GA8920@filibusta.crema.unimi.it> References: <20030404105306.GB4399@hawkins.emu.id.au> <20030419203903.GA8920@filibusta.crema.unimi.it> Message-ID: <3EA26E6C.6000903@stroeder.com> Domenico Andreoli wrote: > hi Michael, > > the patch you are referring to is already in the python-ldap version i'm > using and the problem is right in the "modlist.append((ldap.MOD_DELETE,attrtype,None))". > the error i get is from deletion of an inexistent entry. > > i attached an example to reproduce the bug. 1. Note that your code does not work with OpenLDAP 2.1.x since this version does stricter error checking on entry data: ldap.NAMING_VIOLATION: {'info': "naming attribute 'uid' is not present in entry", 'desc': 'Naming violation'} 2. Strictly spoken you are creating an invalid entry with entry = make_entry(None) The attribute value list of attribute 'description' is simply [ None ] which is filtered in modifyModlist() to []. But it means that the attribute is assumed to be existent in the old_entry. Non-existent attributes should not appear in the entry data at all. Note: The diffing in modifyModlist() loops over new_entry.keys(). Whether an attribute is present in old_entry is determined by existence of the attribute type name in the dictionary's keys. Ciao, Michael. From cavok at filibusta.crema.unimi.it Sun Apr 20 18:13:11 2003 From: cavok at filibusta.crema.unimi.it (Domenico Andreoli) Date: Sun, 20 Apr 2003 18:13:11 +0200 Subject: Bug#175710: python-ldap modlist patch In-Reply-To: <3EA26E6C.6000903@stroeder.com> References: <20030404105306.GB4399@hawkins.emu.id.au> <20030419203903.GA8920@filibusta.crema.unimi.it> <3EA26E6C.6000903@stroeder.com> Message-ID: <20030420161311.GA17206@filibusta.crema.unimi.it> hi Michael, On Sun, Apr 20, 2003 at 11:54:52AM +0200, Michael Str?der wrote: > 1. Note that your code does not work with OpenLDAP 2.1.x since this version > does stricter error checking on entry data: > > ldap.NAMING_VIOLATION: {'info': "naming attribute 'uid' is not present in > entry", 'desc': 'Naming violation'} > please change the dn to whatever works for you, the problem is not here. > 2. Strictly spoken you are creating an invalid entry with > > entry = make_entry(None) > > The attribute value list of attribute 'description' is simply [ None ] > which is filtered in modifyModlist() to []. But it means that the attribute > is assumed to be existent in the old_entry. Non-existent attributes should > not appear in the entry data at all. > if you state that non-existent attributes should be left out, my standing point is, of course, wrong and all this discussion is a non-sense. then, please note that your code is inconsistent with your affirmation because of the last check ("elif old_value and not new_value"). here you are explicitly checking whether new_value does not exist and then whether the corresponding attribute is non-existent. > Note: The diffing in modifyModlist() loops over new_entry.keys(). Whether > an attribute is present in old_entry is determined by existence of the > attribute type name in the dictionary's keys. > this is the point. None is threated as "null-string" (and then filtered) if found in new_value and as "present" if found in old_value. this is not a problem unless it is the only item of the list (like in my case). indeed "if [None]" evaluates to true, while "if []" evaluates to false. if you filtered also old_value, you would handle perfectly the case of non-existent attributes. the choice is yours. > Ciao, Michael. > ciao :) domenico -----[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 From michael at stroeder.com Sun Apr 20 19:37:25 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 20 Apr 2003 19:37:25 +0200 Subject: Bug#175710: python-ldap modlist patch In-Reply-To: <20030420161311.GA17206@filibusta.crema.unimi.it> References: <20030404105306.GB4399@hawkins.emu.id.au> <20030419203903.GA8920@filibusta.crema.unimi.it> <3EA26E6C.6000903@stroeder.com> <20030420161311.GA17206@filibusta.crema.unimi.it> Message-ID: <3EA2DAD5.5@stroeder.com> Domenico Andreoli wrote: > > On Sun, Apr 20, 2003 at 11:54:52AM +0200, Michael Str?der wrote: > >>1. Note that your code does not work with OpenLDAP 2.1.x since this >>version >>does stricter error checking on entry data: >> >>ldap.NAMING_VIOLATION: {'info': "naming attribute 'uid' is not present in >>entry", 'desc': 'Naming violation'} > > please change the dn to whatever works for you, I did. > the problem is not here. Just for the records: The entry MUST contain uid attribute with recent OpenLDAP 2.1.x which does stricter checking than e.g. OpenLDAP 2.0.x. >>2. Strictly spoken you are creating an invalid entry with >> >>entry = make_entry(None) >> >>The attribute value list of attribute 'description' is simply [ None ] >>which is filtered in modifyModlist() to []. But it means that the >>attribute >>is assumed to be existent in the old_entry. Non-existent attributes should >>not appear in the entry data at all. > > if you state that non-existent attributes should be left out, my standing > point is, of course, wrong and all this discussion is a non-sense. Yes, non-existent attributes should be left out. > then, please note that your code is inconsistent with your affirmation > because of the last check ("elif old_value and not new_value"). here > you are explicitly checking whether new_value does not exist and then > whether the corresponding attribute is non-existent. I will check that. >>Note: The diffing in modifyModlist() loops over new_entry.keys(). Whether >>an attribute is present in old_entry is determined by existence of the >>attribute type name in the dictionary's keys. > > this is the point. None is threated as "null-string" (and then filtered) > if found in new_value and as "present" if found in old_value. this is > not a problem unless it is the only item of the list (like in my case). > > indeed "if [None]" evaluates to true, while "if []" evaluates to false. > > if you filtered also old_value, you would handle perfectly the case of > non-existent attributes. the choice is yours. I will check whether it's feasible to filter() old_value. I had some problems with broken iPlanet DS 5.1 (prior SP1) which returned [] as attribute value in search results. Additionally I've learned in the mean-time that some attributes might hold empty strings (e.g. attributes of DirectoryString syntax). Therefore using filter(None,valuelist) might be problematic anyway and might be dropped completely from modifyModList(). => you're safe if your code leaves out non-existent attributes completely. For a complete solution modifyModList() would have to look at the schema to use the appropriate matching rules... Ciao, Michael. From michael at stroeder.com Sun Apr 20 20:05:32 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 20 Apr 2003 20:05:32 +0200 Subject: Bug#175710: python-ldap modlist patch In-Reply-To: <3EA2DAD5.5@stroeder.com> References: <20030404105306.GB4399@hawkins.emu.id.au> <20030419203903.GA8920@filibusta.crema.unimi.it> <3EA26E6C.6000903@stroeder.com> <20030420161311.GA17206@filibusta.crema.unimi.it> <3EA2DAD5.5@stroeder.com> Message-ID: <3EA2E16C.9040608@stroeder.com> Michael Str?der wrote: > I will check whether it's feasible to filter() old_value. I had some > problems with broken iPlanet DS 5.1 (prior SP1) which returned [] as > attribute value in search results. > > Additionally I've learned in the mean-time that some attributes might > hold empty strings (e.g. attributes of DirectoryString syntax). > Therefore using filter(None,valuelist) might be problematic anyway and > might be dropped completely from modifyModList(). > => you're safe if your code leaves out non-existent attributes completely. I've checked in a new version with the following change: -------------------------- snip -------------------------- ldap.modlist: * modifyModlist(): Only None is filtered from attribute value lists, '' is preserved as valid attribute value. But filtering applies to old_value and new_value now. -------------------------- snip -------------------------- Please test! Ciao, Michael. From michael at stroeder.com Wed Apr 23 15:47:16 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 23 Apr 2003 15:47:16 +0200 Subject: Bug#175710: python-ldap modlist patch In-Reply-To: <20030423113535.GA15743@filibusta.crema.unimi.it> References: <20030404105306.GB4399@hawkins.emu.id.au> <20030419203903.GA8920@filibusta.crema.unimi.it> <3EA26E6C.6000903@stroeder.com> <20030420161311.GA17206@filibusta.crema.unimi.it> <3EA2DAD5.5@stroeder.com> <3EA2E16C.9040608@stroeder.com> <20030423113535.GA15743@filibusta.crema.unimi.it> Message-ID: <3EA69964.6070006@stroeder.com> Domenico Andreoli wrote: > On Sun, Apr 20, 2003 at 08:05:32PM +0200, Michael Str?der wrote: > >>I've checked in a new version with the following change: >> > > where did you checked the stuff in? i'm looking at the sourceforge CVS > repository but i still do not see any change :( Aaargh! Sorry. Done now. Ciao, Michael. From cavok at filibusta.crema.unimi.it Wed Apr 23 13:35:35 2003 From: cavok at filibusta.crema.unimi.it (Domenico Andreoli) Date: Wed, 23 Apr 2003 13:35:35 +0200 Subject: Bug#175710: python-ldap modlist patch In-Reply-To: <3EA2E16C.9040608@stroeder.com> References: <20030404105306.GB4399@hawkins.emu.id.au> <20030419203903.GA8920@filibusta.crema.unimi.it> <3EA26E6C.6000903@stroeder.com> <20030420161311.GA17206@filibusta.crema.unimi.it> <3EA2DAD5.5@stroeder.com> <3EA2E16C.9040608@stroeder.com> Message-ID: <20030423113535.GA15743@filibusta.crema.unimi.it> On Sun, Apr 20, 2003 at 08:05:32PM +0200, Michael Str?der wrote: > > I've checked in a new version with the following change: > where did you checked the stuff in? i'm looking at the sourceforge CVS repository but i still do not see any change :( -----[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 From michael at stroeder.com Tue Apr 29 10:47:33 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 29 Apr 2003 10:47:33 +0200 Subject: Win32 anyone? Message-ID: <3EAE3C25.2000909@stroeder.com> HI! Once again I'd like to ask whether anybody has built a native Win32 version of recent python-ldap. Would be nice to have a maintainer for Win32 binaries. Ciao, Michael. From michael at stroeder.com Tue Apr 29 10:47:33 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 29 Apr 2003 10:47:33 +0200 Subject: Win32 anyone? Message-ID: <3EAE3C25.2000909@stroeder.com> HI! Once again I'd like to ask whether anybody has built a native Win32 version of recent python-ldap. Would be nice to have a maintainer for Win32 binaries. Ciao, Michael. From michael at stroeder.com Tue Apr 29 19:28:50 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 29 Apr 2003 19:28:50 +0200 Subject: Win32 anyone? In-Reply-To: <3EAEB474.4010708@siosistemi.it> References: <3EAE3C25.2000909@stroeder.com> <3EAEB474.4010708@siosistemi.it> Message-ID: <3EAEB652.3080508@stroeder.com> Mauro Cicognini wrote: > Michael Str?der wrote: > >> Once again I'd like to ask whether anybody has built a native Win32 >> version of recent python-ldap. Would be nice to have a maintainer for >> Win32 binaries. > > Hmm, given the low to very-low level of win32 traffic on the list, I > might even ask if there's any interest for it. There is! Otherwise I wouldn't ask. > Anyway, for all it's worth, I volounteer to be the win32 maintainer, Great. > Anyway, if anyone's interested, I can provide a native windows installer > for python-ldap, packaged with the python dist tools. Yes, please build one for Python 2.2.x. You can send the files to me and I'll add it to the file release system on SourceForge. Not sure if it's necessary to have a complete Windows installer though. How much effort is this for you? Can it be automated to some extent? If it's much work I'd like to make a next release with some small enhancements/fixes before you start the build. Ciao, Michael. From mcicogni at siosistemi.it Tue Apr 29 19:20:52 2003 From: mcicogni at siosistemi.it (Mauro Cicognini) Date: Tue, 29 Apr 2003 19:20:52 +0200 Subject: Win32 anyone? In-Reply-To: <3EAE3C25.2000909@stroeder.com> References: <3EAE3C25.2000909@stroeder.com> Message-ID: <3EAEB474.4010708@siosistemi.it> Michael Str?der wrote: > HI! > > Once again I'd like to ask whether anybody has built a native Win32 > version of recent python-ldap. Would be nice to have a maintainer for > Win32 binaries. > > Ciao, Michael. Hmm, given the low to very-low level of win32 traffic on the list, I might even ask if there's any interest for it. Anyway, for all it's worth, I volounteer to be the win32 maintainer, since it appears I'm almost the only one using python-ldap under windows :-) Still, I'm sorry I can't participate in the devel discussions; given the very low amount of time I have for this job I prefer to wait for stable (or almost-stable) versions before I attempt a native compile under windows. Anyway, if anyone's interested, I can provide a native windows installer for python-ldap, packaged with the python dist tools. Mauro From mengelhart at katahdinsoftware.com Thu May 1 17:46:20 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Thu, 1 May 2003 11:46:20 -0400 Subject: determining if bind successful Message-ID: <0DE6A13A-7BEC-11D7-8EB0-000393A48A3C@katahdinsoftware.com> Hi - Is there anything in the API that will let you determine whether a particular users login was successful or not? I'm using simple_bind to bind a user but it appears that if you type in anything, it will accept but just not give access rights. I want to be able to display a web page after a user tries to login that says "Username/Password were incorrect. please try again." Thanks Mike From michael at stroeder.com Thu May 1 18:03:09 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 01 May 2003 18:03:09 +0200 Subject: determining if bind successful In-Reply-To: <0DE6A13A-7BEC-11D7-8EB0-000393A48A3C@katahdinsoftware.com> References: <0DE6A13A-7BEC-11D7-8EB0-000393A48A3C@katahdinsoftware.com> Message-ID: <3EB1453D.5080806@stroeder.com> Michael Engelhart wrote: > > Is there anything in the API that will let you determine whether a > particular users login was successful or not? I'm using simple_bind to > bind a user but it appears that if you type in anything, it will accept > but just not give access rights. I want to be able to display a web > page after a user tries to login that says "Username/Password were > incorrect. please try again." Mainly if simple_bind_s(who,cred) was successful with a non-empty password in cred the "login" was successful. Otherwise one of the following exceptions is usually raised: ldap.INVALID_CREDENTIALS ldap.INAPPROPRIATE_AUTH Note the "usual" in the sentence above. Details depend very much on your LDAP server (which one?). Many weird things out there... Ciao, Michael. From michael at stroeder.com Thu May 1 18:34:42 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 01 May 2003 18:34:42 +0200 Subject: determining if bind successful In-Reply-To: <1E0921C4-7BF0-11D7-9E4F-000393A48A3C@katahdinsoftware.com> References: <1E0921C4-7BF0-11D7-9E4F-000393A48A3C@katahdinsoftware.com> Message-ID: <3EB14CA2.40505@stroeder.com> Michael Engelhart wrote: > Hmm. OK - well below are the relevant snippets from LDAPWrapper class. > When I pass in a valid dn for "user" and an incorrect password, it still > binds. It appears to bind as a user that has no privileges but it > doesn't throw an exception. Strange. Maybe some problems with ACLs (check http://www.openldap.org/faq/data/cache/189.html)? Below's a test I did with my local server. 1. ldap.INVALID_CREDENTIALS is raised if the password provided does not match value of attribute 'userPassword'. 2. ldap.INAPPROPRIATE_AUTH is raised if entry does not have attribute 'userPassword' at all. 3. It only binds in the case the password matches. Best bet is trying to reproduce the same behaviour with OpenLDAP's ldapsearch and ask on the openldap-software mailing list. Ciao, Michael. ------------------------------- snip ------------------------------- >>> import ldap >>> l=ldap.initialize('ldap://localhost:1390') >>> l.simple_bind_s('uid=anna,ou=Testing,dc=stroeder,dc=com','wrong password') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/ldap/ldapobject.py", line 435, in simple_bind_s self.bind_s(who,passwd,_ldap.AUTH_SIMPLE) File "/usr/lib/python2.2/site-packages/ldap/ldapobject.py", line 154, in bind_s self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.2/site-packages/ldap/ldapobject.py", line 334, in result return self._ldap_call(self._l.result,msgid,all,timeout) File "/usr/lib/python2.2/site-packages/ldap/ldapobject.py", line 90, in _ldap_call result = func(*args,**kwargs) ldap.INVALID_CREDENTIALS: {'info': '', 'desc': 'Invalid credentials'} >>> l.simple_bind_s('cn=Michael Stroeder,ou=Testing,dc=stroeder,dc=com','wrong password') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/ldap/ldapobject.py", line 435, in simple_bind_s self.bind_s(who,passwd,_ldap.AUTH_SIMPLE) File "/usr/lib/python2.2/site-packages/ldap/ldapobject.py", line 154, in bind_s self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.2/site-packages/ldap/ldapobject.py", line 334, in result return self._ldap_call(self._l.result,msgid,all,timeout) File "/usr/lib/python2.2/site-packages/ldap/ldapobject.py", line 90, in _ldap_call result = func(*args,**kwargs) ldap.INAPPROPRIATE_AUTH: {'info': '', 'desc': 'Inappropriate authentication'} >>> l.simple_bind_s('uid=anna,ou=Testing,dc=stroeder,dc=com','anna') >>> From michael at stroeder.com Thu May 1 18:35:31 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 01 May 2003 18:35:31 +0200 Subject: determining if bind successful In-Reply-To: <1E0921C4-7BF0-11D7-9E4F-000393A48A3C@katahdinsoftware.com> References: <1E0921C4-7BF0-11D7-9E4F-000393A48A3C@katahdinsoftware.com> Message-ID: <3EB14CD3.20704@stroeder.com> Michael Engelhart wrote: > class LDAPWrapper: > > def __init__(self, user="", password=""): > try: > self.server = ldap.open("127.0.0.1") > self.server.simple_bind(user, password) Note also that 'user' has to be a complete DN of an existing entry! Ciao, Michael. From mengelhart at katahdinsoftware.com Thu May 1 18:15:25 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Thu, 1 May 2003 12:15:25 -0400 Subject: determining if bind successful In-Reply-To: <3EB1453D.5080806@stroeder.com> Message-ID: <1E0921C4-7BF0-11D7-9E4F-000393A48A3C@katahdinsoftware.com> Hmm. OK - well below are the relevant snippets from LDAPWrapper class. When I pass in a valid dn for "user" and an incorrect password, it still binds. It appears to bind as a user that has no privileges but it doesn't throw an exception. I'm running openldap 2.1 on Mac OS X 10.2.5 if that makes a difference. Are the OpenLDAP settings that override this behavior that I can adjust. It's very odd to me that it wouldn't "always" throw an exception or what's the point of the authentication step! :-) Thanks Mike class LDAPWrapper: def __init__(self, user="", password=""): try: self.server = ldap.open("127.0.0.1") self.server.simple_bind(user, password) except ldap.LDAPError, e: print "general LDAP error ", e except ldap.INVALID_CREDENTIALS, e: print "Invalid Credentials", e except ldap.INAPPROPRIATE_AUTH, e: print "Inappropriate Auth", e On Thursday, May 1, 2003, at 12:03 PM, Michael Str?der wrote: > Michael Engelhart wrote: >> Is there anything in the API that will let you determine whether a >> particular users login was successful or not? I'm using simple_bind >> to bind a user but it appears that if you type in anything, it will >> accept but just not give access rights. I want to be able to display >> a web page after a user tries to login that says "Username/Password >> were incorrect. please try again." > > Mainly if simple_bind_s(who,cred) was successful with a non-empty > password in cred the "login" was successful. Otherwise one of the > following exceptions is usually raised: > > ldap.INVALID_CREDENTIALS > > ldap.INAPPROPRIATE_AUTH > > Note the "usual" in the sentence above. Details depend very much on > your LDAP server (which one?). Many weird things out there... > > Ciao, Michael. > > > > From michael at stroeder.com Thu May 1 20:20:02 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 01 May 2003 20:20:02 +0200 Subject: Module dsml Message-ID: <3EB16552.1030700@stroeder.com> HI! I've checked in a new stand-alone module called dsml (file Lib/dsml.py) which generates and parses DSMLv1 based on SAX parser in Python's standard lib. Since this is my first attempt implementing something XML-ish feedback of XML gurus is highly appreciated. I'm not sure whether DSMLv1 still makes sense though. http://www.dsml.org seems to be non-existent. :-/ Ciao, Michael. From mengelhart at katahdinsoftware.com Wed May 7 19:41:02 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Wed, 7 May 2003 13:41:02 -0400 Subject: authentication - no errors In-Reply-To: <6E1FEF31-7C07-11D7-96C9-000393A48A3C@katahdinsoftware.com> Message-ID: <122977DC-80B3-11D7-8DCF-000393A48A3C@katahdinsoftware.com> I'm still losing my mind with why my python-ldap won't throw authentication errors when invalid passwords are passed I removed all my openldap data from the /var/db/openldap directories and subdirectories and created a basic slapd.conf file as shown here: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema pidfile /var/run/slapd.pid argsfile /var/run/slapd.args allows bind_v2 schemacheck off database ldbm suffix "o=number1customer.com" rootdn "cn=Directory Manager,o=number1customer.com" rootpw secret directory /var/db/openldap/openldap-data/number1customer.com/ cachesize 1000000 dbcachesize 10000000 index uid,cn,sn,givenName pres,eq,sub sizelimit 20000 access to * by self write by dn="cn=Directory Manager,o=number1customer.com" write by * none Then did this code import ldap try: l = ldap.open("127.0.0.1") # you should set this to ldap.VERSION2 if you're using a v2 directory l.protocol_version = ldap.VERSION2 username = "cn=bogus-cn, o=wrongcompany.com" password = "sjadfkjasfjkl" l.simple_bind(username, password) print "got here" except ldap.LDAPError, e: print e This output "got here" with no exceptions. I still can't figure out how to force python-ldap to throw an exception upon entering an invalid dn or password or combination thereof. Any help would be greatly appreciated. This is definitely a python-ldap issue because when I try and do an ldapsearch on the command line it gives an error message saying that the dn or password is invalid. Any help or ideas of where to look would be greatly appreciated. I'm running this on Mac OS X (Darwin). Everything else works perfectly. Mike From michael at stroeder.com Wed May 7 20:02:28 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 07 May 2003 20:02:28 +0200 Subject: authentication - no errors In-Reply-To: <122977DC-80B3-11D7-8DCF-000393A48A3C@katahdinsoftware.com> References: <122977DC-80B3-11D7-8DCF-000393A48A3C@katahdinsoftware.com> Message-ID: <3EB94A34.7000005@stroeder.com> Michael Engelhart wrote: > I'm still losing my mind with why my python-ldap won't throw > authentication errors when invalid passwords are passed Hmm... > I still can't figure out how > to force python-ldap to throw an exception upon entering an invalid dn > or password or combination thereof. You don't have to force python-ldap to throw the exception. If the error code returned by the LDAP server is non-zero there is always an appropriate LDAPError exception raised. > This is definitely a > python-ldap issue because when I try and do an ldapsearch on the command > line it gives an error message saying that the dn or password is invalid. I doubt that. Check whether you _ldap.so uses the right OpenLDAP libs. Ciao, Michael. From michael at stroeder.com Wed May 7 20:08:00 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 07 May 2003 20:08:00 +0200 Subject: authentication - no errors In-Reply-To: <122977DC-80B3-11D7-8DCF-000393A48A3C@katahdinsoftware.com> References: <122977DC-80B3-11D7-8DCF-000393A48A3C@katahdinsoftware.com> Message-ID: <3EB94B80.7070909@stroeder.com> Michael Engelhart wrote: > l = ldap.open("127.0.0.1") BTW: Another nice feature for finding errors is python-ldap's tracing. Try with: l = ldap.open("127.0.0.1",trace_level=2) Ciao, Michael. From mengelhart at katahdinsoftware.com Wed May 7 20:17:09 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Wed, 7 May 2003 14:17:09 -0400 Subject: authentication - no errors In-Reply-To: <3EB94A34.7000005@stroeder.com> Message-ID: <1DBABA8A-80B8-11D7-B9A5-000393A48A3C@katahdinsoftware.com> how do I tell if it's using the "right" libraries? I'm using pre06 and built it against the only libraries that are on my Mac OS X box which comes with openldap 2.0.x libs installed. Maybe I did build it incorrectly??? thanks Mike On Wednesday, May 7, 2003, at 02:02 PM, Michael Str?der wrote: > Michael Engelhart wrote: >> I'm still losing my mind with why my python-ldap won't throw >> authentication errors when invalid passwords are passed > > Hmm... > >> I still can't figure out how to force python-ldap to throw an >> exception upon entering an invalid dn or password or combination >> thereof. > > You don't have to force python-ldap to throw the exception. If the > error code returned by the LDAP server is non-zero there is always an > appropriate LDAPError exception raised. > >> This is definitely a python-ldap issue because when I try and do an >> ldapsearch on the command line it gives an error message saying that >> the dn or password is invalid. > > I doubt that. > > Check whether you _ldap.so uses the right OpenLDAP libs. > > Ciao, Michael. > From michael at stroeder.com Wed May 7 23:44:16 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 07 May 2003 23:44:16 +0200 Subject: authentication - no errors In-Reply-To: <1DBABA8A-80B8-11D7-B9A5-000393A48A3C@katahdinsoftware.com> References: <1DBABA8A-80B8-11D7-B9A5-000393A48A3C@katahdinsoftware.com> Message-ID: <3EB97E30.8010001@stroeder.com> Michael Engelhart wrote: > how do I tell if it's using the "right" libraries? Under Linux there's ldd. Not sure about Mac OS X though. On my Linux system it looks like this: $ 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 (0x40059000) libsasl2.so.2 => /usr/local/cyrus-sasl/lib/libsasl2.so.2 (0x40067000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4008b000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x400bc000) libc.so.6 => /lib/libc.so.6 (0x40192000) libresolv.so.2 => /lib/libresolv.so.2 (0x402b0000) libdl.so.2 => /lib/libdl.so.2 (0x402c2000) libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0x402c5000) libasn1.so.5 => /usr/lib/libasn1.so.5 (0x402fc000) libroken.so.9 => /usr/lib/libroken.so.9 (0x4031e000) libcom_err.so.1 => /usr/lib/libcom_err.so.1 (0x40330000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40334000) libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40365000) > I'm using pre06 Please always try with latest and greatest (python-ldap 2.0.0pre11 at the moment). But I'm pretty sure that's not your problem. > and > built it against the only libraries that are on my Mac OS X box which > comes with openldap 2.0.x libs installed. Exact version of OpenLDAP? Note that OpenLDAP 2.0.x is not actively maintained anymore. > Maybe I did build it incorrectly??? Please post setup.cfg. Ciao, Michael. From michael at stroeder.com Wed May 7 20:08:00 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 07 May 2003 20:08:00 +0200 Subject: authentication - no errors In-Reply-To: <122977DC-80B3-11D7-8DCF-000393A48A3C@katahdinsoftware.com> References: <122977DC-80B3-11D7-8DCF-000393A48A3C@katahdinsoftware.com> Message-ID: <3EB94B80.7070909@stroeder.com> Michael Engelhart wrote: > l = ldap.open("127.0.0.1") BTW: Another nice feature for finding errors is python-ldap's tracing. Try with: l = ldap.open("127.0.0.1",trace_level=2) Ciao, Michael. From michael at stroeder.com Wed May 7 23:44:16 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 07 May 2003 23:44:16 +0200 Subject: authentication - no errors In-Reply-To: <1DBABA8A-80B8-11D7-B9A5-000393A48A3C@katahdinsoftware.com> References: <1DBABA8A-80B8-11D7-B9A5-000393A48A3C@katahdinsoftware.com> Message-ID: <3EB97E30.8010001@stroeder.com> Michael Engelhart wrote: > how do I tell if it's using the "right" libraries? Under Linux there's ldd. Not sure about Mac OS X though. On my Linux system it looks like this: $ 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 (0x40059000) libsasl2.so.2 => /usr/local/cyrus-sasl/lib/libsasl2.so.2 (0x40067000) libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4008b000) libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x400bc000) libc.so.6 => /lib/libc.so.6 (0x40192000) libresolv.so.2 => /lib/libresolv.so.2 (0x402b0000) libdl.so.2 => /lib/libdl.so.2 (0x402c2000) libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0x402c5000) libasn1.so.5 => /usr/lib/libasn1.so.5 (0x402fc000) libroken.so.9 => /usr/lib/libroken.so.9 (0x4031e000) libcom_err.so.1 => /usr/lib/libcom_err.so.1 (0x40330000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40334000) libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40365000) > I'm using pre06 Please always try with latest and greatest (python-ldap 2.0.0pre11 at the moment). But I'm pretty sure that's not your problem. > and > built it against the only libraries that are on my Mac OS X box which > comes with openldap 2.0.x libs installed. Exact version of OpenLDAP? Note that OpenLDAP 2.0.x is not actively maintained anymore. > Maybe I did build it incorrectly??? Please post setup.cfg. Ciao, Michael. From michael at stroeder.com Thu May 8 09:07:06 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 08 May 2003 09:07:06 +0200 Subject: authentication - no errors In-Reply-To: References: Message-ID: <3EBA021A.303@stroeder.com> Steven Graham wrote: > > Looking at the ld(1) man page, it shows -L is used instead of -R. The > configure script might be a little confused about the system (OS X can do > that). We had this discussion before with Steven being one of the participants. :-) Please, check the python-ldap list archive for thread "still probs to compile python-ldap on macosx". Ciao, Michael. From mengelhart at katahdinsoftware.com Thu May 8 03:46:33 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Wed, 7 May 2003 21:46:33 -0400 Subject: authentication - no errors In-Reply-To: <3EB97E30.8010001@stroeder.com> Message-ID: WEll I successfully built BerkeleyDB 4.1.25, OpenLDAP 2.1.18 and now I'm trying to get pre11 compiled and am getting errors. No doubt due to the OS X oddities. I'm not sure if it's distutil that causes this but this is the error: Modules/options.c: In function `LDAP_get_option': Modules/options.c:151: warning: unused variable `doubleval' gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress build/temp.darwin-6.5-Power Macintosh-2.2/LDAPObject.o build/temp.darwin-6.5-Power Macintosh-2.2/common.o build/temp.darwin-6.5-Power Macintosh-2.2/constants.o build/temp.darwin-6.5-Power Macintosh-2.2/errors.o build/temp.darwin-6.5-Power Macintosh-2.2/functions.o build/temp.darwin-6.5-Power Macintosh-2.2/schema.o build/temp.darwin-6.5-Power Macintosh-2.2/ldapmodule.o build/temp.darwin-6.5-Power Macintosh-2.2/linkedlist.o build/temp.darwin-6.5-Power Macintosh-2.2/message.o build/temp.darwin-6.5-Power Macintosh-2.2/version.o build/temp.darwin-6.5-Power Macintosh-2.2/options.o -L/usr/local/lib -Wl,-R/usr/local/lib -lldap -llber -o build/lib.darwin-6.5-Power Macintosh-2.2/_ldap.so ld: for architecture i386 ld: unknown flag: -R/usr/local/lib error: command 'gcc' failed with exit status 1 I don't know why both -arch i1386 & -arch ppc show up Also not sure why the -R/usr/local/lib is causing trouble Any ideas? Thanks Mike On Wednesday, May 7, 2003, at 05:44 PM, Michael Str?der wrote: > Michael Engelhart wrote: >> how do I tell if it's using the "right" libraries? > > Under Linux there's ldd. Not sure about Mac OS X though. On my Linux > system it looks like this: > > $ 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 (0x40059000) > libsasl2.so.2 => /usr/local/cyrus-sasl/lib/libsasl2.so.2 > (0x40067000) > libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4008b000) > libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x400bc000) > libc.so.6 => /lib/libc.so.6 (0x40192000) > libresolv.so.2 => /lib/libresolv.so.2 (0x402b0000) > libdl.so.2 => /lib/libdl.so.2 (0x402c2000) > libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0x402c5000) > libasn1.so.5 => /usr/lib/libasn1.so.5 (0x402fc000) > libroken.so.9 => /usr/lib/libroken.so.9 (0x4031e000) > libcom_err.so.1 => /usr/lib/libcom_err.so.1 (0x40330000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0x40334000) > libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40365000) > >> I'm using pre06 > > Please always try with latest and greatest (python-ldap 2.0.0pre11 at > the moment). But I'm pretty sure that's not your problem. > >> and built it against the only libraries that are on my Mac OS X box >> which comes with openldap 2.0.x libs installed. > > Exact version of OpenLDAP? Note that OpenLDAP 2.0.x is not actively > maintained anymore. > >> Maybe I did build it incorrectly??? > > Please post setup.cfg. > > Ciao, Michael. > > > > From sgraham at wugaa.com Thu May 8 06:44:21 2003 From: sgraham at wugaa.com (Steven Graham) Date: Wed, 07 May 2003 21:44:21 -0700 Subject: authentication - no errors In-Reply-To: Message-ID: Apple has modifed gcc (and ld) to allow what they call "fat" binaries, essentially binaries/libraries that have the ability to run in both architectures. So the '-arch i386' isn't necessarily wrong, but it shouldn't hurt to take it out. Looking at the ld(1) man page, it shows -L is used instead of -R. The configure script might be a little confused about the system (OS X can do that). -Steve On 5/7/03 6:46 PM, "Michael Engelhart" wrote: > WEll I successfully built BerkeleyDB 4.1.25, OpenLDAP 2.1.18 and now > I'm trying to get pre11 compiled and am getting errors. No doubt due > to the OS X oddities. I'm not sure if it's distutil that causes this > but this is the error: > > Modules/options.c: In function `LDAP_get_option': > Modules/options.c:151: warning: unused variable `doubleval' > gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress > build/temp.darwin-6.5-Power Macintosh-2.2/LDAPObject.o > build/temp.darwin-6.5-Power Macintosh-2.2/common.o > build/temp.darwin-6.5-Power Macintosh-2.2/constants.o > build/temp.darwin-6.5-Power Macintosh-2.2/errors.o > build/temp.darwin-6.5-Power Macintosh-2.2/functions.o > build/temp.darwin-6.5-Power Macintosh-2.2/schema.o > build/temp.darwin-6.5-Power Macintosh-2.2/ldapmodule.o > build/temp.darwin-6.5-Power Macintosh-2.2/linkedlist.o > build/temp.darwin-6.5-Power Macintosh-2.2/message.o > build/temp.darwin-6.5-Power Macintosh-2.2/version.o > build/temp.darwin-6.5-Power Macintosh-2.2/options.o -L/usr/local/lib > -Wl,-R/usr/local/lib -lldap -llber -o build/lib.darwin-6.5-Power > Macintosh-2.2/_ldap.so > ld: for architecture i386 > ld: unknown flag: -R/usr/local/lib > error: command 'gcc' failed with exit status 1 > > > I don't know why both -arch i1386 & -arch ppc show up > Also not sure why the -R/usr/local/lib is causing trouble > > Any ideas? > > Thanks > Mike > On Wednesday, May 7, 2003, at 05:44 PM, Michael Str?der wrote: > >> Michael Engelhart wrote: >>> how do I tell if it's using the "right" libraries? >> >> Under Linux there's ldd. Not sure about Mac OS X though. On my Linux >> system it looks like this: >> >> $ 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 (0x40059000) >> libsasl2.so.2 => /usr/local/cyrus-sasl/lib/libsasl2.so.2 >> (0x40067000) >> libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4008b000) >> libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x400bc000) >> libc.so.6 => /lib/libc.so.6 (0x40192000) >> libresolv.so.2 => /lib/libresolv.so.2 (0x402b0000) >> libdl.so.2 => /lib/libdl.so.2 (0x402c2000) >> libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0x402c5000) >> libasn1.so.5 => /usr/lib/libasn1.so.5 (0x402fc000) >> libroken.so.9 => /usr/lib/libroken.so.9 (0x4031e000) >> libcom_err.so.1 => /usr/lib/libcom_err.so.1 (0x40330000) >> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) >> libcrypt.so.1 => /lib/libcrypt.so.1 (0x40334000) >> libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40365000) >> >>> I'm using pre06 >> >> Please always try with latest and greatest (python-ldap 2.0.0pre11 at >> the moment). But I'm pretty sure that's not your problem. >> >>> and built it against the only libraries that are on my Mac OS X box >>> which comes with openldap 2.0.x libs installed. >> >> Exact version of OpenLDAP? Note that OpenLDAP 2.0.x is not actively >> maintained anymore. >> >>> Maybe I did build it incorrectly??? >> >> Please post setup.cfg. >> >> Ciao, Michael. >> >> >> >> From mengelhart at katahdinsoftware.com Thu May 8 11:07:22 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Thu, 8 May 2003 05:07:22 -0400 Subject: Compile Mac OS X 10.2 In-Reply-To: Message-ID: <7AA5C736-8134-11D7-9521-000393A48A3C@katahdinsoftware.com> Thanks Steve for pointing me in the right direction! This -arch flag has been driving me crazy on various software compiles. Why on earth the "default" is to build fat binaries is beyond me since the amount of people running darwin on i386 is probably in the tens of people :-) Anyway, I did the patch to /usr/lib/python2.2/distutils/util.pyt mentioned in the "still probs to compile python-ldap on macosx" which didn't fix the problem at all. Same errors. I think the poster was incorrect in his belief that the linker didn't like the "space" in the build directory names but I'm not sure. Anyway I removed the patch to util.py that was suggested because it didn't do anything towards fixing the problem and I think was based on an incorrect assumption about the linker. What did help was getting rid of the -R flag for ld. since ld -R gives an unknown flag error I figured it couldn't hurt to edit my /usr/lib/python2.2/distutils/unixccompiler.py file and change the def runtime_library_dir_option (self, dir): function to read if compiler == "gcc" or compiler == "g++": return "-Wl,-L" + dir else: return "-L" + dir instead of the default Apple install which is if compiler == "gcc" or compiler == "g++": return "-Wl,-R" + dir else: return "-R" + dir I also filed a bug report with Apple. This still gave me warnings about the -arch i1386 not being found but it built _ldap.so successfully as I believe all the -arch messages were just warnings. Mike On Thursday, May 8, 2003, at 12:44 AM, Steven Graham wrote: > Apple has modifed gcc (and ld) to allow what they call "fat" binaries, > essentially binaries/libraries that have the ability to run in both > architectures. So the '-arch i386' isn't necessarily wrong, but it > shouldn't > hurt to take it out. > > Looking at the ld(1) man page, it shows -L is used instead of -R. The > configure script might be a little confused about the system (OS X can > do > that). > > -Steve > From michael at stroeder.com Thu May 8 12:43:55 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 08 May 2003 12:43:55 +0200 Subject: authentication - no errors In-Reply-To: <34CF66F4-813D-11D7-A9A6-000393A48A3C@katahdinsoftware.com> References: <34CF66F4-813D-11D7-A9A6-000393A48A3C@katahdinsoftware.com> Message-ID: <3EBA34EB.20608@stroeder.com> Michael Engelhart wrote: > OK - got my shiny new OpenLDAP 2.1.18 built and pre11 built and when I > run the following test script with an invalid password like this > [..] > l.simple_bind(dn, password) Well, the problem was so simple that I didn't notice it before. l.simple_bind_s(dn, password) ^^^ Use the synchronous method! Ciao, Michael. From mengelhart at katahdinsoftware.com Thu May 8 12:09:50 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Thu, 8 May 2003 06:09:50 -0400 Subject: authentication - no errors In-Reply-To: <3EB97E30.8010001@stroeder.com> Message-ID: <34CF66F4-813D-11D7-A9A6-000393A48A3C@katahdinsoftware.com> OK - got my shiny new OpenLDAP 2.1.18 built and pre11 built and when I run the following test script with an invalid password like this import ldap try: l = ldap.open("127.0.0.1") dn = "cn=Directory Manager, o=mydomain.com" password = "test" l.simple_bind(dn, password) print "got here" except ldap.LDAPError, e: print e it prints out "got here" I tried changing the dn and password to invalid entries in a bunch of different combinations but it always allows me to bind. Here's my slapd.conf which is basically the default config ## default ACl access to * by self write by users read by anonymous auth database bdb suffix "o=mydomain.com" rootdn "cn=Directory Manager,o=mydomain.com" rootpw secret directory /usr/local/var/openldap-data/mydomain.com/ index uid,cn,sn,givenName pres,eq,sub So is this a configuration issue with openldap? I admit I don't fully understand ACL's but this appears to say that the default access is Allow self write access Allow authenticated users read access Allow anonymous users to authenticate which if I'm correct would cause python-ldap to throw an Exception if I passed in an invalid dn/password. Thanks for any help. Michael On Wednesday, May 7, 2003, at 05:44 PM, Michael Str?der wrote: > Michael Engelhart wrote: >> how do I tell if it's using the "right" libraries? > > Under Linux there's ldd. Not sure about Mac OS X though. On my Linux > system it looks like this: > > $ 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 (0x40059000) > libsasl2.so.2 => /usr/local/cyrus-sasl/lib/libsasl2.so.2 > (0x40067000) > libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4008b000) > libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x400bc000) > libc.so.6 => /lib/libc.so.6 (0x40192000) > libresolv.so.2 => /lib/libresolv.so.2 (0x402b0000) > libdl.so.2 => /lib/libdl.so.2 (0x402c2000) > libkrb5.so.17 => /usr/lib/libkrb5.so.17 (0x402c5000) > libasn1.so.5 => /usr/lib/libasn1.so.5 (0x402fc000) > libroken.so.9 => /usr/lib/libroken.so.9 (0x4031e000) > libcom_err.so.1 => /usr/lib/libcom_err.so.1 (0x40330000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0x40334000) > libdb-4.0.so => /usr/lib/libdb-4.0.so (0x40365000) > >> I'm using pre06 > > Please always try with latest and greatest (python-ldap 2.0.0pre11 at > the moment). But I'm pretty sure that's not your problem. > >> and built it against the only libraries that are on my Mac OS X box >> which comes with openldap 2.0.x libs installed. > > Exact version of OpenLDAP? Note that OpenLDAP 2.0.x is not actively > maintained anymore. > >> Maybe I did build it incorrectly??? > > Please post setup.cfg. > > Ciao, Michael. > > > > From michael at stroeder.com Thu May 8 14:11:53 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 08 May 2003 14:11:53 +0200 Subject: authentication - no errors In-Reply-To: <97AA630E-814D-11D7-ACB3-000393A48A3C@katahdinsoftware.com> References: <97AA630E-814D-11D7-ACB3-000393A48A3C@katahdinsoftware.com> Message-ID: <3EBA4989.4060204@stroeder.com> Michael Engelhart wrote: > ldap.PROTOCOL_ERROR: {'info': 'requested protocol version not allowed', 'desc': 'Protocol error'} Set l.protocol_version to match your server configuration. Most times set it to 3 (ldap.VERSION3) since LDAPv2 servers get rare... Ciao, Michael. From mengelhart at katahdinsoftware.com Thu May 8 14:07:08 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Thu, 8 May 2003 08:07:08 -0400 Subject: authentication - no errors In-Reply-To: <3EBA34EB.20608@stroeder.com> Message-ID: <97AA630E-814D-11D7-ACB3-000393A48A3C@katahdinsoftware.com> Thanks. I actually had tried that yesterday thinking that was the problem but then, as now, I get this error when I try to do any simple_bind_s() no matter what I pass as paramenters. >>> l.simple_bind_s("cn=Directory Manager,o=mydomain.com","secret") Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/ldap/ldapobject.py", line 435, in simple_bind_s self.bind_s(who,passwd,_ldap.AUTH_SIMPLE) File "/usr/lib/python2.2/site-packages/ldap/ldapobject.py", line 154, in bind_s self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.2/site-packages/ldap/ldapobject.py", line 334, in result return self._ldap_call(self._l.result,msgid,all,timeout) File "/usr/lib/python2.2/site-packages/ldap/ldapobject.py", line 90, in _ldap_call result = func(*args,**kwargs) ldap.PROTOCOL_ERROR: {'info': 'requested protocol version not allowed', 'desc': 'Protocol error'} On Thursday, May 8, 2003, at 06:43 AM, Michael Str?der wrote: > Michael Engelhart wrote: > > OK - got my shiny new OpenLDAP 2.1.18 built and pre11 built and when > I > > run the following test script with an invalid password like this > > [..] > > l.simple_bind(dn, password) > > Well, the problem was so simple that I didn't notice it before. > > l.simple_bind_s(dn, password) > ^^^ > Use the synchronous method! > > Ciao, Michael. > > > > From michael at stroeder.com Thu May 8 14:11:53 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 08 May 2003 14:11:53 +0200 Subject: authentication - no errors In-Reply-To: <97AA630E-814D-11D7-ACB3-000393A48A3C@katahdinsoftware.com> References: <97AA630E-814D-11D7-ACB3-000393A48A3C@katahdinsoftware.com> Message-ID: <3EBA4989.4060204@stroeder.com> Michael Engelhart wrote: > ldap.PROTOCOL_ERROR: {'info': 'requested protocol version not allowed', 'desc': 'Protocol error'} Set l.protocol_version to match your server configuration. Most times set it to 3 (ldap.VERSION3) since LDAPv2 servers get rare... Ciao, Michael. From michael at stroeder.com Tue May 13 21:12:25 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 13 May 2003 21:12:25 +0200 Subject: python-ldap freezing In-Reply-To: <20030513164220.B20845@wormhole> References: <20030513164220.B20845@wormhole> Message-ID: <3EC14399.9010702@stroeder.com> Alexander Meisel wrote: > > I have to freeze the software I wrote in order to get it running on a > system which is not allowed to have a python (in fact any scripting language) > installation. I use the python ldap module with the freeze.py utility in the > Python tools distribution, but don't quite know what to do (in the building > process) to the module to make it 'freezable'. The following note in Python-2.2.2/Tools/freeze/README does not sound too good. --------------------------------- snip --------------------------------- A warning about shared library modules -------------------------------------- When your Python installation uses shared library modules such as _tkinter.pyd, these will not be incorporated in the frozen program. Again, the frozen program will work when you test it, but it won't work when you ship it to a site without a Python installation. --------------------------------- snip --------------------------------- I tried to freeze Demo/initialize.py but did not succeed. Ciao, Michael. From alex at kernelhq.cc Tue May 13 17:42:20 2003 From: alex at kernelhq.cc (Alexander Meisel) Date: Tue, 13 May 2003 16:42:20 +0100 Subject: python-ldap freezing Message-ID: <20030513164220.B20845@wormhole> Hi, I have to freeze the software I wrote in order to get it running on a system which is not allowed to have a python (in fact any scripting language) installation. I use the python ldap module with the freeze.py utility in the Python tools distribution, but don't quite know what to do (in the building process) to the module to make it 'freezable'. Can anyboy please give me some advice on how to prepare the module correctly so it won't come up as a dependency in the freezing process, which in the end requires a full python installation on the target system? Thx in advance! Best regards Alex From alex at kernelhq.cc Tue May 13 21:22:30 2003 From: alex at kernelhq.cc (alex at kernelhq.cc) Date: Tue, 13 May 2003 20:22:30 +0100 Subject: python-ldap freezing In-Reply-To: <3EC14399.9010702@stroeder.com>; from michael@stroeder.com on Tue, May 13, 2003 at 09:12:25PM +0200 References: <20030513164220.B20845@wormhole> <3EC14399.9010702@stroeder.com> Message-ID: <20030513202230.A26259@wormhole> Hi Michael, I read that too ... I tried to copy the .so file to /usr/lib/python2.2/lib-dynload where are .so files for the built in modules are kept without success. I was wondering if there is a additional file which tells python (and freeze) that the .so file is actually there and can be used to freeze a script. The 2nd idea I'm going to try is to link the .so file to the binary (editing the Makefile produced by freeze). There must be a 'officall' way to freeze custom build libraries correctly. Best regards Alex On Tue, May 13, 2003 at 09:12:25PM +0200, Michael Str?der wrote: > Alexander Meisel wrote: > > > > I have to freeze the software I wrote in order to get it running on a > > system which is not allowed to have a python (in fact any scripting language) > > installation. I use the python ldap module with the freeze.py utility in the > > Python tools distribution, but don't quite know what to do (in the building > > process) to the module to make it 'freezable'. > > The following note in Python-2.2.2/Tools/freeze/README does not sound too good. > > --------------------------------- snip --------------------------------- > A warning about shared library modules > -------------------------------------- > > When your Python installation uses shared library modules such as > _tkinter.pyd, these will not be incorporated in the frozen program. > Again, the frozen program will work when you test it, but it won't > work when you ship it to a site without a Python installation. > --------------------------------- snip --------------------------------- > > I tried to freeze Demo/initialize.py but did not succeed. > > Ciao, Michael. > From mengelhart at katahdinsoftware.com Wed May 14 19:55:55 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Wed, 14 May 2003 13:55:55 -0400 Subject: adding organizationalUnit Message-ID: <4FAFD8CA-8635-11D7-A1E2-000393A48A3C@katahdinsoftware.com> Hi Is it possible to add an ou to a directory using python-ldap I'm trying to add something like this to my directory (this LDIF works with ldapadd fine) dn: ou=Sales,o=somecompany.com objectclass: top objectclass: organizationalunit ou: Sales When i tried doing this using the add(dn, modlist) function, it failed with an error saying the "dn: attribute type undefined" Any tips would be appreciated. THanks Michael From michael at stroeder.com Wed May 14 20:06:25 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 14 May 2003 20:06:25 +0200 Subject: adding organizationalUnit In-Reply-To: <4FAFD8CA-8635-11D7-A1E2-000393A48A3C@katahdinsoftware.com> References: <4FAFD8CA-8635-11D7-A1E2-000393A48A3C@katahdinsoftware.com> Message-ID: <3EC285A1.90104@stroeder.com> Michael Engelhart wrote: > > When i tried doing this using the add(dn, modlist) function, it failed > with an error saying the "dn: attribute type undefined" Are you sure that your entry data in the modlist contains the attribute used for RDN? Please post the code. Ciao, Michael. From michael at stroeder.com Thu May 15 08:44:40 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 15 May 2003 08:44:40 +0200 Subject: python-ldap and SSL? In-Reply-To: References: Message-ID: <3EC33758.3080300@stroeder.com> David Casti wrote: > > import ldap > l = ldap.initialize( 'ldaps://target:636' ) > [..] > ldap.SERVER_DOWN: {'info': 'error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', 'desc': > "Can't contact LDAP server"} The message is pretty clear. The server's certificate cannot be verified. > ldap.set_option( ldap.OPT_X_TLS_CACERTFILE, '/path/ca.crt' ) This is the right thing to do. Can you please try something like openssl s_client -connect target:636 -CAfile /path/ca.crt and carefully examime its output? Ciao, Michael. From mengelhart at katahdinsoftware.com Wed May 14 20:55:09 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Wed, 14 May 2003 14:55:09 -0400 Subject: adding organizationalUnit In-Reply-To: Message-ID: <958E692C-863D-11D7-804D-000393A48A3C@katahdinsoftware.com> BTW, the LDAPWrapper is just simple wrapper class that I wrote. The add method looks like this: def add(self, dn, modlist): # synchronous add try: self.server.add_s(dn, modlist) except ldap.LDAPError, e: raise On Wednesday, May 14, 2003, at 02:20 PM, Michael Engelhart wrote: > No, I'm not sure. :-) > I guess my misunderstanding is that add() requests a dn. What dn do > you enter for a top-level or mid-level organizationalUnit? > > If have the following single entry setup in my OpenLDAP directory: > > dn: o=mycompany.com > objectclass: top > objectclass: organization > o: mycompany.com > > > and then want to add from python-ldap this organizationUnit: > > dn: ou=People,o=mycompany.com > objectclass: top > objectclass: organizationalunit > ou: People > > > try: > bind_dn="cn=Directory Manager,o=mycompany.com" > password = "xxxxxxxxx" > l = LDAPWrapper(bind_dn,password) > dnToAddTo = "o=mycompany.com" > modlist = [] > modlist.append(('dn','ou=People,o=mycompany.com')) > modlist.append(('objectclass',['top','organizationalunit'])) > modlist.append(('ou','People')) > l.add(dnToAddTo, modlist) > l.close() > except ldap.LDAPError, e: > print e > > I get this error: > {'info': 'dn: attribute type undefined', 'desc': 'Undefined attribute > type'} > > Thanks > Michael > > On Wednesday, May 14, 2003, at 02:06 PM, Michael Str?der wrote: > >> Are you sure that your entry data in the modlist contains the >> attribute used for RDN? >> >> Please post the code. >> >> Ciao, Michael. > From mengelhart at katahdinsoftware.com Wed May 14 20:20:16 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Wed, 14 May 2003 14:20:16 -0400 Subject: adding organizationalUnit In-Reply-To: <3EC285A1.90104@stroeder.com> Message-ID: No, I'm not sure. :-) I guess my misunderstanding is that add() requests a dn. What dn do you enter for a top-level or mid-level organizationalUnit? If have the following single entry setup in my OpenLDAP directory: dn: o=mycompany.com objectclass: top objectclass: organization o: mycompany.com and then want to add from python-ldap this organizationUnit: dn: ou=People,o=mycompany.com objectclass: top objectclass: organizationalunit ou: People try: bind_dn="cn=Directory Manager,o=mycompany.com" password = "xxxxxxxxx" l = LDAPWrapper(bind_dn,password) dnToAddTo = "o=mycompany.com" modlist = [] modlist.append(('dn','ou=People,o=mycompany.com')) modlist.append(('objectclass',['top','organizationalunit'])) modlist.append(('ou','People')) l.add(dnToAddTo, modlist) l.close() except ldap.LDAPError, e: print e I get this error: {'info': 'dn: attribute type undefined', 'desc': 'Undefined attribute type'} Thanks Michael On Wednesday, May 14, 2003, at 02:06 PM, Michael Str?der wrote: > Are you sure that your entry data in the modlist contains the > attribute used for RDN? > > Please post the code. > > Ciao, Michael. From david at casti.com Thu May 15 01:21:08 2003 From: david at casti.com (David Casti) Date: Wed, 14 May 2003 19:21:08 -0400 Subject: python-ldap and SSL? Message-ID: Hello, I have Python 2.2.2, the current version of python-ldap, openldap, and openssl installed. I am trying to connect over SSL to an LDAP server listening on port 636, so I try -- import ldap l = ldap.initialize( 'ldaps://target:636' ) l.bind_s( '', '', ldap.AUTH_SIMPLE ) -- but no matter what I do, I get the following traceback -- Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line 429, in simple_bind return self.bind(who,passwd,_ldap.AUTH_SIMPLE) File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line 147, in bind return self._ldap_call(self._l.bind,who,cred,method) File "/usr/local/lib/python2.2/site-packages/ldap/ldapobject.py", line 90, in _ldap_call result = func(*args,**kwargs) ldap.SERVER_DOWN: {'info': 'error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', 'desc': "Can't contact LDAP server"} -- I have tried adding -- ldap.set_option( ldap.OPT_X_TLS_CACERTFILE, '/path/ca.crt' ) -- right after 'import ldap', but it had no effect. I read the thread on this list from April 2002 which suggested that this should all work... any ideas? SSL support appears to be very lightly documented... Thanks, David. From michael at stroeder.com Thu May 15 08:49:48 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 15 May 2003 08:49:48 +0200 Subject: adding organizationalUnit In-Reply-To: References: Message-ID: <3EC3388C.2040906@stroeder.com> Michael Engelhart wrote: > I guess my misunderstanding is that add() requests a dn. The dn is the complete DN of the new entry => you have to form a new RDN and concatenate this with a base DN of an existing entry. > modlist.append(('dn','ou=People,o=mycompany.com')) Not needed and probably not allowed. > l.add(dnToAddTo, modlist) l.add('ou=People,o=mycompany.com', modlist) > I get this error: > {'info': 'dn: attribute type undefined', 'desc': 'Undefined attribute > type'} Now it's clearer: The attribute type 'dn' is not existent in schema (and not needed as already stated above). Ciao, Michael. From michael at stroeder.com Thu May 15 08:51:07 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 15 May 2003 08:51:07 +0200 Subject: adding organizationalUnit In-Reply-To: <958E692C-863D-11D7-804D-000393A48A3C@katahdinsoftware.com> References: <958E692C-863D-11D7-804D-000393A48A3C@katahdinsoftware.com> Message-ID: <3EC338DB.8080401@stroeder.com> Michael Engelhart wrote: > BTW, the LDAPWrapper is just simple wrapper class that I wrote. > > The add method looks like this: > def add(self, dn, modlist): > # synchronous add > try: > self.server.add_s(dn, modlist) > except ldap.LDAPError, e: > raise And what's the rationale for that? Well, it's up to you... Ciao, Michael. From mengelhart at katahdinsoftware.com Thu May 15 15:44:12 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Thu, 15 May 2003 09:44:12 -0400 Subject: adding organizationalUnit In-Reply-To: <3EC3388C.2040906@stroeder.com> Message-ID: <4FD650B0-86DB-11D7-A95A-000393A48A3C@katahdinsoftware.com> Thanks. So there's no way to dynamically create organzitaionalUnits into an existing schema using python-ldap. I have to manually add a dn before I can add entries to it. Is that correct? Thanks MIke On Thursday, May 15, 2003, at 02:49 AM, Michael Str?der wrote: > Michael Engelhart wrote: > > I guess my misunderstanding is that add() requests a dn. > > The dn is the complete DN of the new entry > => you have to form a new RDN and concatenate this with a base DN of > an existing entry. > > > modlist.append(('dn','ou=People,o=mycompany.com')) > > Not needed and probably not allowed. > > > l.add(dnToAddTo, modlist) > > l.add('ou=People,o=mycompany.com', modlist) > > > I get this error: > > {'info': 'dn: attribute type undefined', 'desc': 'Undefined attribute > > type'} > > Now it's clearer: The attribute type 'dn' is not existent in schema > (and not needed as already stated above). > > Ciao, Michael. > > > > From mengelhart at katahdinsoftware.com Thu May 15 15:48:17 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Thu, 15 May 2003 09:48:17 -0400 Subject: adding organizationalUnit In-Reply-To: <3EC338DB.8080401@stroeder.com> Message-ID: To encapsulate the application specific ldap functionality into a single class as well as wrapping the basic add, modify, search, and delete functionality. Obviously the add, modify and delete methods don't do anything really more than what calling ldap directly does. Just makes my code tidier and easier to manage. On Thursday, May 15, 2003, at 02:51 AM, Michael Str?der wrote: > Michael Engelhart wrote: > > BTW, the LDAPWrapper is just simple wrapper class that I wrote. > > > > The add method looks like this: > > def add(self, dn, modlist): > > # synchronous add > > try: > > self.server.add_s(dn, modlist) > > except ldap.LDAPError, e: > > raise > > And what's the rationale for that? Well, it's up to you... > > Ciao, Michael. > > > > From michael at stroeder.com Thu May 15 16:19:22 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 15 May 2003 16:19:22 +0200 Subject: adding organizationalUnit In-Reply-To: <4FD650B0-86DB-11D7-A95A-000393A48A3C@katahdinsoftware.com> References: <4FD650B0-86DB-11D7-A95A-000393A48A3C@katahdinsoftware.com> Message-ID: <3EC3A1EA.7070404@stroeder.com> Michael Engelhart wrote: > So there's no way to dynamically create organzitaionalUnits > into an existing schema using python-ldap. Off course you can dynamically create entries of object class organizationalUnit. > I have to manually add a dn before I can add entries to it. Is that > correct? Please make sure to fully understand the LDAP data model before start coding: entries, attributes, naming, schema, etc. A good book might be of great help. Ciao, Michael. From vikramdham at hotmail.com Fri May 16 17:32:17 2003 From: vikramdham at hotmail.com (Vikram Dham) Date: Fri, 16 May 2003 11:32:17 -0400 Subject: 'desc': 'Invalid credentials', 'info': :( Message-ID: Hi, I am trying to connect to our schools ldap server using simple.py but I am getting the error "{'desc': 'Invalid credentials', 'info': ''}" Can anyone suggest me what is goig nwrong ? Further what all is required to be done if I need to use TLS or SSL with LDAP on Solaris 9 ? Thanks in advance for your help, Vikram From michael at stroeder.com Fri May 16 17:43:48 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 16 May 2003 17:43:48 +0200 Subject: 'desc': 'Invalid credentials', 'info': :( In-Reply-To: References: Message-ID: <3EC50734.9030500@stroeder.com> Vikram Dham wrote: > > I am trying to connect to our schools ldap server using simple.py but I > am getting the error "{'desc': 'Invalid credentials', 'info': ''}" You are providing the wrong password during simple bind. > Further what all is required > to be done if I need to use TLS or SSL with LDAP on Solaris 9 ? 1. You have to build the OpenLDAP libs --with-tls against OpenSSL. 2. python-ldap has to be build with SSL support by adding 'ssl crypto' to line libs of setup.cfg. 3. See Demo/initialize.py for examples. Ciao, Michael. From t.kloppenburg at billiton.de Wed May 21 09:22:26 2003 From: t.kloppenburg at billiton.de (Tjabo Kloppenburg) Date: Wed, 21 May 2003 09:22:26 +0200 Subject: adding organizationalUnit In-Reply-To: <4FD650B0-86DB-11D7-A95A-000393A48A3C@katahdinsoftware.com> References: <4FD650B0-86DB-11D7-A95A-000393A48A3C@katahdinsoftware.com> Message-ID: <200305210922.26715.t.kloppenburg@billiton.de> Am Donnerstag, 15. Mai 2003 15:44 schrieb Michael Engelhart: > Thanks. So there's no way to dynamically create organzitaionalUnits > into an existing schema using python-ldap. what? I don't believe this. Have been on vacancy for some days. gonna have a look at it... From python-ldap-dev at meisel.cc Tue May 20 11:04:48 2003 From: python-ldap-dev at meisel.cc (Alexander Meisel) Date: Tue, 20 May 2003 10:04:48 +0100 Subject: python-ldap freezing In-Reply-To: <3EC14399.9010702@stroeder.com>; from michael@stroeder.com on Tue, May 13, 2003 at 09:12:25PM +0200 References: <20030513164220.B20845@wormhole> <3EC14399.9010702@stroeder.com> Message-ID: <20030520100448.A5549@wormhole> Hi, just an update how to do it. It is possible to freeze the python ldap library with your code. All you have to do is to archive the .o files into a file called _ldap.a and link them against the frozen binary. If you build py-ldap you find the .o files in /build/tmp..../*.o You need to build an archive (which basically combines them to one file) Linux: ar c _ldap.a /path/to/o/files/*.o Solaris: ar -q _ldap.a /path/to/o/files/*.o Then you use freeze.py as you normally would. After the make, you see the last giant gcc line which links everything to the binary. Copy and paste the line but add the _ldap.a file before the libpython2.2.a. You basically link the file again, but this time with the ldap library. Happy code freezing! Alexander Meisel On Tue, May 13, 2003 at 09:12:25PM +0200, Michael Str?der wrote: > Alexander Meisel wrote: > > > > I have to freeze the software I wrote in order to get it running on a > > system which is not allowed to have a python (in fact any scripting language) > > installation. I use the python ldap module with the freeze.py utility in the > > Python tools distribution, but don't quite know what to do (in the building > > process) to the module to make it 'freezable'. > > The following note in Python-2.2.2/Tools/freeze/README does not sound too good. > > --------------------------------- snip --------------------------------- > A warning about shared library modules > -------------------------------------- > > When your Python installation uses shared library modules such as > _tkinter.pyd, these will not be incorporated in the frozen program. > Again, the frozen program will work when you test it, but it won't > work when you ship it to a site without a Python installation. > --------------------------------- snip --------------------------------- > > I tried to freeze Demo/initialize.py but did not succeed. > > Ciao, Michael. > From ajthomson at optushome.com.au Mon May 26 03:09:15 2003 From: ajthomson at optushome.com.au (Andrew Thomson) Date: Mon, 26 May 2003 11:09:15 +1000 Subject: async.LDIFWriter Message-ID: <20030526010915.GD55461@athomson.prv.au.itouchnet.net> It's great to be able to crank out the ldiff data from a running tree using async.LDIFWriter When we do this, s = ldap.async.LDIFWriter( ldap.initialize('ldap://localhost:389'), is it possible to incorporate bind details?? ie, so I can log in as the directory manager and not be restricted by the SIZELIMIT_EXCEEDED cheers, ajt. From michael at stroeder.com Mon May 26 07:50:55 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 26 May 2003 07:50:55 +0200 Subject: async.LDIFWriter In-Reply-To: <20030526010915.GD55461@athomson.prv.au.itouchnet.net> References: <20030526010915.GD55461@athomson.prv.au.itouchnet.net> Message-ID: <3ED1AB3F.1080100@stroeder.com> Andrew Thomson wrote: > It's great to be able to crank out the ldiff data from a running tree > using async.LDIFWriter > > When we do this, > > s = ldap.async.LDIFWriter( > ldap.initialize('ldap://localhost:389'), > > is it possible to incorporate bind details?? import ldap,ldap.async f = open('results.ldif','w') l = ldap.initialize('ldap://localhost:389') l.protocol_version = ldap.VERSION3 l.simple_bind_s('cn=Directory Manager','top secret') s = ldap.async.LDIFWriter(l,f) s.startSearch('dc=example,dc=com',ldap.SCOPE_SUBTREE,'(objectClass=*)') s.processResults() Note that this will write the entries in the order they are returned from the server. This is not necessarily the right tree order. > ie, so I can log in as the > directory manager and not be restricted by the SIZELIMIT_EXCEEDED This is a matter of the LDAP server implementation. If the server does not impose any search limits for 'cn=Directory Manager' in the example above you will be able to retrieve all results. Ciao, Michael. From ajthomson at optushome.com.au Mon May 26 09:39:51 2003 From: ajthomson at optushome.com.au (Andrew Thomson) Date: Mon, 26 May 2003 17:39:51 +1000 Subject: async.LDIFWriter In-Reply-To: <3ED1AB3F.1080100@stroeder.com> References: <20030526010915.GD55461@athomson.prv.au.itouchnet.net> <3ED1AB3F.1080100@stroeder.com> Message-ID: <20030526073951.GB99641@athomson.prv.au.itouchnet.net> Thanks, that's perfect.. one other question if I may.. how can I modify the following, __init__(self, output_file, base64_attrs=None, cols=76, line_sep='\n') output_file file object for output base64_attrs list of attribute types to be base64-encoded in any case cols Specifies how many columns a line may have before it's folded into many lines. line_sep String used as line separator to increase the column length.. some of my entries are wrapping. Regards, ajt. On Mon, May 26, 2003 at 07:50:55AM +0200, Michael Str?der wrote: > Andrew Thomson wrote: > > It's great to be able to crank out the ldiff data from a running tree > > using async.LDIFWriter > > > > When we do this, > > > > s = ldap.async.LDIFWriter( > > ldap.initialize('ldap://localhost:389'), > > > > is it possible to incorporate bind details?? > > import ldap,ldap.async > > f = open('results.ldif','w') > l = ldap.initialize('ldap://localhost:389') > l.protocol_version = ldap.VERSION3 > l.simple_bind_s('cn=Directory Manager','top secret') > s = ldap.async.LDIFWriter(l,f) > s.startSearch('dc=example,dc=com',ldap.SCOPE_SUBTREE,'(objectClass=*)') > s.processResults() > > Note that this will write the entries in the order they are returned from > the server. This is not necessarily the right tree order. > > > ie, so I can log in as the > > directory manager and not be restricted by the SIZELIMIT_EXCEEDED > > This is a matter of the LDAP server implementation. If the server does not > impose any search limits for 'cn=Directory Manager' in the example above > you will be able to retrieve all results. > > Ciao, Michael. > > From ajthomson at optushome.com.au Mon May 26 09:46:58 2003 From: ajthomson at optushome.com.au (Andrew Thomson) Date: Mon, 26 May 2003 17:46:58 +1000 Subject: async.LDIFWriter In-Reply-To: <3ED1AB3F.1080100@stroeder.com> References: <20030526010915.GD55461@athomson.prv.au.itouchnet.net> <3ED1AB3F.1080100@stroeder.com> Message-ID: <20030526074658.GA1807@athomson.prv.au.itouchnet.net> Michael, You'll hate me, but any updates on this? ;) "The following example demonstrates how to parse an LDIF file with ldif module. To do... " (http://python-ldap.sourceforge.net/doc/python-ldap/ldif-example.html) regards, ajt. On Mon, May 26, 2003 at 07:50:55AM +0200, Michael Str?der wrote: > Andrew Thomson wrote: > > It's great to be able to crank out the ldiff data from a running tree > > using async.LDIFWriter > > > > When we do this, > > > > s = ldap.async.LDIFWriter( > > ldap.initialize('ldap://localhost:389'), > > > > is it possible to incorporate bind details?? > > import ldap,ldap.async > > f = open('results.ldif','w') > l = ldap.initialize('ldap://localhost:389') > l.protocol_version = ldap.VERSION3 > l.simple_bind_s('cn=Directory Manager','top secret') > s = ldap.async.LDIFWriter(l,f) > s.startSearch('dc=example,dc=com',ldap.SCOPE_SUBTREE,'(objectClass=*)') > s.processResults() > > Note that this will write the entries in the order they are returned from > the server. This is not necessarily the right tree order. > > > ie, so I can log in as the > > directory manager and not be restricted by the SIZELIMIT_EXCEEDED > > This is a matter of the LDAP server implementation. If the server does not > impose any search limits for 'cn=Directory Manager' in the example above > you will be able to retrieve all results. > > Ciao, Michael. > > From michael at stroeder.com Mon May 26 09:58:30 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 26 May 2003 09:58:30 +0200 Subject: async.LDIFWriter In-Reply-To: <20030526073951.GB99641@athomson.prv.au.itouchnet.net> References: <20030526010915.GD55461@athomson.prv.au.itouchnet.net> <3ED1AB3F.1080100@stroeder.com> <20030526073951.GB99641@athomson.prv.au.itouchnet.net> Message-ID: <3ED1C926.7050005@stroeder.com> Andrew Thomson wrote: > Thanks, that's perfect.. > > one other question if I may.. how can I modify the following, > > __init__(self, output_file, base64_attrs=None, cols=76, line_sep='\n') Funny you ask for that. In this minute I've checked in a new version which lets you pass in either a ldif.LDIFWriter instance instead or a file-like object. Give it a try: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Lib/ldap/async.py > cols > Specifies how many columns a line may have before it's > folded into many lines. > > to increase the column length.. some of my entries are wrapping. You really should use a LDIF consumer which correctly processes folded lines (see RFC 2849). Ciao, Michael. From michael at stroeder.com Mon May 26 10:03:07 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 26 May 2003 10:03:07 +0200 Subject: async.LDIFWriter In-Reply-To: <20030526074658.GA1807@athomson.prv.au.itouchnet.net> References: <20030526010915.GD55461@athomson.prv.au.itouchnet.net> <3ED1AB3F.1080100@stroeder.com> <20030526074658.GA1807@athomson.prv.au.itouchnet.net> Message-ID: <3ED1CA3B.5040400@stroeder.com> Andrew Thomson wrote: > > You'll hate me, but any updates on this? ;) > > "The following example demonstrates how to parse an LDIF file with ldif > module. > > To do... Unfortunately no. Feel free to submit a patch for the docs... Actually it's quite simple though. Ciao, Michael. From ajthomson at optushome.com.au Tue May 27 05:04:21 2003 From: ajthomson at optushome.com.au (Andrew Thomson) Date: Tue, 27 May 2003 13:04:21 +1000 Subject: async.LDIFWriter In-Reply-To: <3ED1CA3B.5040400@stroeder.com> References: <20030526010915.GD55461@athomson.prv.au.itouchnet.net> <3ED1AB3F.1080100@stroeder.com> <20030526074658.GA1807@athomson.prv.au.itouchnet.net> <3ED1CA3B.5040400@stroeder.com> Message-ID: <20030527030421.GH15113@athomson.prv.au.itouchnet.net> any tips today? ;) --- import ldif f = open('data.ldiff','r') records = ldif.LDIFRecordList(f) data = records.parse() --- thanks, ajt. From michael at stroeder.com Tue May 27 10:33:51 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 27 May 2003 10:33:51 +0200 Subject: async.LDIFWriter In-Reply-To: <20030527030421.GH15113@athomson.prv.au.itouchnet.net> References: <20030526010915.GD55461@athomson.prv.au.itouchnet.net> <3ED1AB3F.1080100@stroeder.com> <20030526074658.GA1807@athomson.prv.au.itouchnet.net> <3ED1CA3B.5040400@stroeder.com> <20030527030421.GH15113@athomson.prv.au.itouchnet.net> Message-ID: <3ED322EF.7030103@stroeder.com> Andrew Thomson wrote: > any tips today? ;) Let's see... ;-) > --- > import ldif > > f = open('data.ldiff','r') > > records = ldif.LDIFRecordList(f) > data = records.parse() > --- This parses the whole input file and stores the data into a list in memory which might not be suitable for very large LDIF files. For stream-processing large LDIF files you simply have to sub-class ldif.LDIFParser and implement the method handle(self,dn,entry). Ciao, Michael. From epo001 at hotmail.com Tue Jun 3 16:06:37 2003 From: epo001 at hotmail.com (Ed .) Date: Tue, 03 Jun 2003 14:06:37 +0000 Subject: Search sizelimit not working? Message-ID: I want to run a query which will return more results than the server permits. If I specify sizelimit to get a fixed and (smaller than server limit) amount I get an exception. Here is a sample program: import ldap l = ldap.initialize("ldap://foo.com:389") l.simple_bind_s(",") res = "No results" try: res = l.search_ext_s("o=foo.com", ldap.SCOPE_SUBTREE, "sn=jones*", sizelimit=5) # This prints all results the server permits #res = l.search_s("o=foo.com", ldap.SCOPE_SUBTREE, "sn=jones*") except ldap.LDAPError, e: print e print res Running this what I'd expect is to get back 5 results, what I get is a size limit exceeded exception. If I run the other form of search then I get back some 150 results. What am I doing wrong? Ed From michael at stroeder.com Tue Jun 3 17:06:44 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 03 Jun 2003 17:06:44 +0200 Subject: Search sizelimit not working? In-Reply-To: References: Message-ID: <3EDCB984.5090204@stroeder.com> Ed . wrote: > I want to run a query which will return more results than the server > permits. If I specify sizelimit to get a fixed and (smaller than server > limit) amount I get an exception. > [..] > l.simple_bind_s(",") ^^^ BTW: This is wrong. > res = l.search_ext_s("o=foo.com", ldap.SCOPE_SUBTREE, "sn=jones*", > sizelimit=5) I couldn't figure out in OpenLDAP's man pages and draft-ietf-ldapext-ldap-c-api-05 whether the python-ldap wrapping in Modules/LDAPObject.c is wrong or whether raising the exception based on non-zero error code is right. (I suspect there is a wrong understanding of the OpenLDAP's error handling in python-ldap's C part.) The synchronous methods are at the moment not suitable for retrieving partial results. You could use module ldap.async for that purpose. Wow! There's even an example in the docs. :-) http://python-ldap.sourceforge.net/doc/python-ldap/ldap.async-example.List.html Ciao, Michael. From malcruzg at univalle.edu.co Thu Jun 5 18:37:24 2003 From: malcruzg at univalle.edu.co (Mario Alberto Cruz Gartner) Date: Thu, 5 Jun 2003 11:37:24 -0500 (GTM) Subject: Bind request problem Message-ID: Hi! I'd installed python-ldap-2.0.0pre13 with my Python 2.1.3 and OpenLDAP 2.1.18 on a FreeBSD 4.4-RELEASE libs = ldap_r lber ssl crypto Even with: libs = ldap lber The build and install process goes well, even i try the python -c "import ldap,ldap.schema;print ldap.__version__" that i've see on the archives of this list and the output was good. BUT, if i try to do a bind (with the example scripts), i got a error referring to a "sasl.c" error. Maybe i think that cyrus-sasl have the fault, so i re-installed it and the problem keep on. The output of the script: $python Demo/simplebrowse.py Connecting to ldap://ldap.openldap.org/ assertion "LBER_VALID( ber )" failed: file "sasl.c", line 99 Abort (core dumped) $ A lot of thanks to anyone, and sorry if my English sucks = ) From michael at stroeder.com Thu Jun 5 18:46:34 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 05 Jun 2003 18:46:34 +0200 Subject: Bind request problem In-Reply-To: References: Message-ID: <3EDF73EA.9040700@stroeder.com> Mario Alberto Cruz Gartner wrote: > > $python Demo/simplebrowse.py > Connecting to ldap://ldap.openldap.org/ > assertion "LBER_VALID( ber )" failed: file "sasl.c", line 99 > Abort (core dumped) > $ Looks very much like a library mix related to OpenLDAP itself. The assertion is in the OpenLDAP libs. Are you sure that you compiled the OpenLDAP libs with the right SASL libs? What's the output of ldd _ldap.so? Are there any unexpected libs listed there? Ciao, Michael. From epo001 at hotmail.com Mon Jun 16 21:41:11 2003 From: epo001 at hotmail.com (Ed .) Date: Mon, 16 Jun 2003 19:41:11 +0000 Subject: Performance penalty for using python-ldap Message-ID: Hi, I was tuning an LDAP directory for a client last week and had cause to run some before and after benchmarks. Basically for a 3000 entry directory I wrote a python script which did the following: listed each entry using the filter (cn=*) using python-ldap and also invoking the shell to use the ldapsearch command. These were done twice: running all attributes an just returning the cn attribute did 3000 random lookups using (cn=exact-match), and then (cn=exact-match*) again using python-ldap and the ldapsearch command. The searches were run twice on unloaded machines, the first time to populate caches, the second time as a rough best-performance figure The findings were somewhat surprising. In the list whole directory search. ldap-search was generally and consistently at least 30% faster than python-ldap. I.e. these figures apply before and after tuning the directory. Remember the python searches are pre-bound while ldapsearch binds each time it is called. In the random lookup test, the performance figures were comparable but this compares calling python-ldap to do a search against spawning a shell, running ldpasearch, binding then doing the search, i.e. the command line search has a LOT more overhead. I'm happy to run some tests to identify the cause to see if we can fix it, any suggestions where to start? General conclusions from my tests: python-ldap has a suprising performance penalty searching is helped by having ample cache (doh!) returning 1 attribute is much faster than returning all of them (doh!) searching on indexed attributes helps a lot (doh!) Ed From michael at stroeder.com Fri Jun 20 11:37:08 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 20 Jun 2003 11:37:08 +0200 Subject: Performance penalty for using python-ldap In-Reply-To: References: Message-ID: <3EF2D5C4.8040008@stroeder.com> Ed . wrote: > > > I'm happy to run some tests to identify the cause to see if we can fix > it, any suggestions where to start? > > General conclusions from my tests: > > python-ldap has a suprising performance penalty Please tell us which versions of python-ldap and OpenLDAP you're using. And please post your Python code and OpenLDAP's indexing configuration. Ciao, Michael. From mengelhart at katahdinsoftware.com Mon Jun 16 14:42:56 2003 From: mengelhart at katahdinsoftware.com (Michael Engelhart) Date: Mon, 16 Jun 2003 08:42:56 -0400 Subject: date format code Message-ID: <0DB9E594-9FF8-11D7-901A-000393A48A3C@katahdinsoftware.com> Hey all, Does anyone have the correct python format pattern for creating datetime strings from either mx.DateTime objects or date strings ('10/10/2003') for OpenLDAP. i know it's in zulu format but I'm wondering if there is any format strings out there that are already tested so I don't have to figure it out. I need to be able to test dates by <= comparison so I need them in the correct format.\ I did a cursory search through the python-ldap code and didn't find anything. Thanks Mike From michael at stroeder.com Fri Jun 20 17:10:32 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 20 Jun 2003 17:10:32 +0200 Subject: date format code In-Reply-To: <0DB9E594-9FF8-11D7-901A-000393A48A3C@katahdinsoftware.com> References: <0DB9E594-9FF8-11D7-901A-000393A48A3C@katahdinsoftware.com> Message-ID: <3EF323E8.6000907@stroeder.com> Michael Engelhart wrote: > > Does anyone have the correct python format pattern for creating datetime > strings from either mx.DateTime objects or date strings ('10/10/2003') > for OpenLDAP. I'd rather use time.strftime() since I don't know about mx.DateTime objects. Current time converted to GeneralizedTime string in Zulu time: import time time.strftime('%Y%m%d%H%M%SZ',time.gmtime(time.time())) Ciao, Michael. From toxicpulse at sbcglobal.net Thu Jun 12 10:58:41 2003 From: toxicpulse at sbcglobal.net (ryan) Date: Thu, 12 Jun 2003 01:58:41 -0700 Subject: python-ldap article Message-ID: <000b01c330c0$d2df27c0$53fefea9@k9u6n0> Hello, I wrote an article on using python-ldap and i'm hoping an expert can look it over and validate the information/code and offer any feedback before i submit it for publication. It can be read at: http://www.seekrut.com/rk/LDAP-Programming-in-Python.html thanks, -Ryan From michael at stroeder.com Fri Jun 20 20:44:57 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 20 Jun 2003 20:44:57 +0200 Subject: python-ldap article In-Reply-To: <000b01c330c0$d2df27c0$53fefea9@k9u6n0> References: <000b01c330c0$d2df27c0$53fefea9@k9u6n0> Message-ID: <3EF35629.1070506@stroeder.com> Ryan, thanks for contributing docs. Sorry, for reviewing it so late. ryan wrote: > > I wrote an article on using python-ldap and i'm hoping an expert can look it > [..] > http://www.seekrut.com/rk/LDAP-Programming-in-Python.html 1. I'd like to note that there's no such thing like a user in LDAP. A bind-DN is normally used with a simple BindRequest which can be the DN of any entry in the directory. I'd prefer to see the terms 'who' and 'cred' being used instead of 'username' and 'password'. 2. Any reason why you start with showing use of async search() instead of the simpler approach for beginners with search_s()? 3. It might be worth to note that an attribute has to be present to retrieve e.g. name = entry[1]['cn'][0]. It will throw a KeyError if attribute 'cn' is not present in entry. Maybe you can add some simple error handling? 4. I'd like to see a more clearer note about exception being exception instances. Something like: except ldap.LDAPError, ldap_error: print str(ldap_error) Please go ahead writing more text. Would be very nice to see a python-ldap tutorial. Ciao, Michael. From michael at stroeder.com Fri Jun 20 20:44:57 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 20 Jun 2003 20:44:57 +0200 Subject: python-ldap article In-Reply-To: <000b01c330c0$d2df27c0$53fefea9@k9u6n0> References: <000b01c330c0$d2df27c0$53fefea9@k9u6n0> Message-ID: <3EF35629.1070506@stroeder.com> Ryan, thanks for contributing docs. Sorry, for reviewing it so late. ryan wrote: > > I wrote an article on using python-ldap and i'm hoping an expert can look it > [..] > http://www.seekrut.com/rk/LDAP-Programming-in-Python.html 1. I'd like to note that there's no such thing like a user in LDAP. A bind-DN is normally used with a simple BindRequest which can be the DN of any entry in the directory. I'd prefer to see the terms 'who' and 'cred' being used instead of 'username' and 'password'. 2. Any reason why you start with showing use of async search() instead of the simpler approach for beginners with search_s()? 3. It might be worth to note that an attribute has to be present to retrieve e.g. name = entry[1]['cn'][0]. It will throw a KeyError if attribute 'cn' is not present in entry. Maybe you can add some simple error handling? 4. I'd like to see a more clearer note about exception being exception instances. Something like: except ldap.LDAPError, ldap_error: print str(ldap_error) Please go ahead writing more text. Would be very nice to see a python-ldap tutorial. Ciao, Michael. From epo001 at hotmail.com Mon Jun 23 14:13:51 2003 From: epo001 at hotmail.com (Ed .) Date: Mon, 23 Jun 2003 12:13:51 +0000 Subject: Python benchmark script Message-ID: Attached is the script I used to compare python-ldap with ldapsearch. Script ran on same machine as the ldap server. The two envirnments teste used fairly recent openldaps and in one case had python-ldap 2.0.0(pre6), the other was more recent. Ratio of python-ldap:ldapsearch seemed constant regardless of version. Ed #!/home/zope/bin/python from os import system, remove from posix import getpid, close from random import random import time import ldap, string search='(cn=*)' host='localhost' port=389 uname="" pw="" # set your directory base here base = "dc=da,dc=mod,dc=uk" iter = 1000 raw = [] def timeit(fn): start = time.time() fn() return time.time() - start # Search whole directory, returning all attributes, python and command line versions def dump_all_py(): global base, search, raw raw = l.search_s(base, ldap.SCOPE_SUBTREE, search) def dump_all_sh(): cmd = 'ldapsearch -h %s -p %i -b "%s" -s sub -x -D "%s" -w "%s" \'%s\' >/dev/null' % \ (host, port, base, uname, pw, search) system(cmd) #print cmd # Search whole directory, returning cn, python and command line versions def dump_cn_py(): global base, search, raw raw = l.search_s(base, ldap.SCOPE_SUBTREE, search, ['cn']) def dump_cn_sh(): cmd = 'ldapsearch -h %s -p %i -b "%s" -s sub -x -D "%s" -w "%s" \'%s\' %s >/dev/null' % \ (host, port, base, uname, pw, search, 'cn') system(cmd) #print cmd # Python cn lookup, exact and initial substring versions def lk_exact_py(): global ents, base for cn in ents: search = '(cn=%s)' % (cn) entry = l.search_s(base, ldap.SCOPE_SUBTREE, search) def lk_sub_py(): global ents, base for cn in ents: search = '(cn=%s*)' % (cn) entry = l.search_s(base, ldap.SCOPE_SUBTREE, search) # Command line cn lookup, exact and initial substring versions # Prepare datafiles for use with command line lookups def prep_sh_data(): global ents, base, tmpf1, tmpf2 tmpf1 = '/tmp/ldap%d-1' % (getpid()) tmpf2 = '/tmp/ldap%d-2' % (getpid()) t1 = open(tmpf1, 'w') t2 = open(tmpf2, 'w') for cn in ents: print >>t1, cn print >>t2, cn+'*' t1.close() t2.close() cmdstring = 'ldapsearch -f %s -h %s -p %i -b "%s" -s sub -x -D "%s" -w "%s" %s>/dev/null' def lk_exact_sh(): global base, tmpf1 cmd = cmdstring % (tmpf1, host, port, base, uname, pw, "'(cn=%s)'") system(cmd) #print cmd def lk_sub_sh(): global base, tmpf2 cmd = cmdstring % (tmpf2, host, port, base, uname, pw, "'(cn=%s*)'") system(cmd) #print cmd l = ldap.initialize('ldap://%s:%s' % (host, port)) l.simple_bind_s(uname, pw) print 'Reading complete directory all attributes' elapsed = timeit(dump_all_py) ct = len(raw) print 'PY: %i entries in %5.2f secs, %5.2f entries/sec' % (ct, elapsed, ct/elapsed) elapsed = timeit(dump_all_sh) l = ldap.initialize('ldap://%s:%s' % (host, port)) l.simple_bind_s(uname, pw) print 'Reading complete directory all attributes' elapsed = timeit(dump_all_py) ct = len(raw) print 'PY: %i entries in %5.2f secs, %5.2f entries/sec' % (ct, elapsed, ct/elapsed) elapsed = timeit(dump_all_sh) print ' C: %i entries in %5.2f secs, %5.2f entries/sec' % (ct, elapsed, ct/elapsed) print '\nReading complete directory, single attribute' raw=[] elapsed = timeit(dump_cn_py) ct = len(raw) print 'PY: %i entries in %5.2f secs, %5.2f entries/sec' % (ct, elapsed, ct/elapsed) elapsed = timeit(dump_cn_sh) print ' C: %i entries in %5.2f secs, %5.2f entries/sec' % (ct, elapsed, ct/elapsed) # First build up a list of entries to lookup ents = [] i = 0 while i < iter: e = int(random()*ct) # N.B. sort this out! ents.append(raw[e][1]['cn'][0]) i += 1 print '\n%i lookups (exact match)' % (iter) elapsed = timeit(lk_exact_py) print 'PY: %5.2f secs, %5.2f entries/sec' % (elapsed, iter/elapsed) prep_sh_data() elapsed = timeit(lk_exact_sh) print ' C: %5.2f secs, %5.2f entries/sec' % (elapsed, iter/elapsed) print '\n%i lookups (substring)' % (iter) elapsed = timeit(lk_sub_py) print 'PY: %5.2f secs, %5.2f entries/sec' % (elapsed, iter/elapsed) elapsed = timeit(lk_sub_sh) print ' C: %5.2f secs, %5.2f entries/sec' % (elapsed, iter/elapsed) remove(tmpf1) remove(tmpf2) l.unbind_s() From michael at stroeder.com Mon Jun 23 14:52:19 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 23 Jun 2003 14:52:19 +0200 Subject: Python benchmark script In-Reply-To: References: Message-ID: <3EF6F803.60003@stroeder.com> Ed . wrote: > Attached is the script I used to compare python-ldap with ldapsearch. Not sure whether everything's ok with your script. On my LDAP server the following appears in the log: Jun 23 14:47:03 nb2 slapd[10223]: conn=67 op=9999 SEARCH RESULT tag=101 err=0 nentries=0 text= Jun 23 14:47:03 nb2 slapd[10218]: conn=67 op=10000 SRCH base="dc=stroeder,dc=de" scope=2 filter="(?=undefined)" The temporary file only contains the name, no attribute type for the search filter. Anyway, if you run it with python -O you will see a big performance gain since all the trace logging stuff in LDAPObject._ldap_call() is completely deactivated (enclose in if __debug__). Ciao, Michael. From michael at stroeder.com Mon Jun 23 19:56:35 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 23 Jun 2003 19:56:35 +0200 Subject: python-ldap problem In-Reply-To: <3EF73D66.3080909@in2p3.fr> References: <3EF73D66.3080909@in2p3.fr> Message-ID: <3EF73F53.6010108@stroeder.com> Andrei Tsaregorodtsev wrote: > > ImportError: /usr/lib/python2.2/site-packages/_ldap.so: undefined > symbol: ldap_first_reference Most times this happens if there's a OpenLDAP library mix on your system. How does your setup.cfg look like? Is /usr/lib/libldap_r.so.2 really the OpenLDAP lib you compiled with? Ciao, Michael. From atsareg at in2p3.fr Mon Jun 23 19:48:22 2003 From: atsareg at in2p3.fr (Andrei Tsaregorodtsev) Date: Mon, 23 Jun 2003 19:48:22 +0200 Subject: python-ldap problem Message-ID: <3EF73D66.3080909@in2p3.fr> Hello, I have a problem using ldap-python package. When I just do import of the ldap module, I get: >>>import ldap Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/ldap/__init__.py", line 21, in ? from _ldap import * ImportError: /usr/lib/python2.2/site-packages/_ldap.so: undefined symbol: ldap_first_reference I use python 2.2.2 and openldap libraries 2.0.27. _ldap.so has all the dependancies resolved: > ldd _ldap.s0 libldap_r.so.2 => /usr/lib/libldap_r.so.2 (0x40021000) liblber.so.2 => /usr/lib/liblber.so.2 (0x4004f000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x4005a000) libssl.so.4 => /lib/libssl.so.4 (0x4006d000) libcrypto.so.4 => /lib/libcrypto.so.4 (0x400a3000) libc.so.6 => /lib/tls/libc.so.6 (0x42000000) libsasl.so.7 => /usr/lib/libsasl.so.7 (0x40194000) libdl.so.2 => /lib/libdl.so.2 (0x4019f000) libresolv.so.2 => /lib/libresolv.so.2 (0x401a2000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x401b4000) libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0x401e1000) libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x401f5000) libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x40253000) libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x40263000) libz.so.1 => /usr/lib/libz.so.1 (0x40265000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40273000) libpam.so.0 => /lib/libpam.so.0 (0x4027a000) Can you please give me a hint what's going wrong ? Thank you, Andrei Tsaregorodtsev -- Centre de Physique des Particules de Marseille 163 avenue de Luminy, case 907 13288 Marseille cedex 09 tel.: +33 491827623 fax: +33 491827299 From michael at stroeder.com Tue Jun 24 09:52:45 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 24 Jun 2003 09:52:45 +0200 Subject: __debug__ and trace_level (was: Python benchmark script) In-Reply-To: References: Message-ID: <3EF8034D.7070504@stroeder.com> Ed, Cc:-ed list since this might be of general interest. Ed . wrote: > > I'm pleased to hear that there are optimisations which can be made, not > sure I understand the reference to __debug__. http://www.python.org/doc/current/ref/assert.html#l2h-310 > Perhaps it's a > documentation problem and that logging should be off by default and > enabled for those doing debugging? Logging is off by default (trace_level=0). But the if-statements checking trace_level are executed if the Python interpreter was invoked without -O. If running with -O it is my understanding that code behind if __debug__ is completely optimized away and never executed. Therefore tracing is only available when running without -O. Ciao, Michael. From estartu at augusta.de Tue Jun 24 12:58:56 2003 From: estartu at augusta.de (Gerhard Schmidt) Date: Tue, 24 Jun 2003 12:58:56 +0200 Subject: ldap controls Message-ID: <20030624105856.GA13418@augusta.de> hi There, im working on an Python script to bulksetup some users in an e-Directory server. The Problem is that i have to set an ldap control to enable simple passwords. Without this control e-Dirctory/nds stores the password in some unreachable attributes. Ist there a way to set ldap controls from python. Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | PGP Public Key Fischbachweg 3 | Privat: estartu at augusta.de | auf Anfrage/ 86856 Hiltenfingen | Dienst: schmidt at ze.tu-muenchen.de | on request -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 366 bytes Desc: not available URL: From michael at stroeder.com Tue Jun 24 13:17:14 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 24 Jun 2003 13:17:14 +0200 Subject: ldap controls In-Reply-To: <20030624105856.GA13418@augusta.de> References: <20030624105856.GA13418@augusta.de> Message-ID: <3EF8333A.7020106@stroeder.com> Gerhard Schmidt wrote: > > Ist there a way to set ldap controls from python. Unfortunately no (see TODO). Contributions welcome. Ciao, Michael. From michael at stroeder.com Tue Jun 24 16:41:08 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 24 Jun 2003 16:41:08 +0200 Subject: Double checked Python benchmark script In-Reply-To: References: Message-ID: <3EF86304.7080203@stroeder.com> Ed, I wrote my own test script (attached). It's less complex to read but more flexible (through LDAP URL as parameter). Please review. Usage: pref_test.py Grab whole sub-tree 100 times (no server-side limit or logging, ~500 entries): $ python perf_test.py "ldap://localhost:1390/dc=stroeder,dc=de?*?sub" 100 Opening connection each time: 20.4206629992 Reusing connection: 16.9708769321 Using ldapsearch: 6.0001270771 I'd appreciate if anyone with C knowledge could review what is done in ldap_result() (LDAPObject.c) and LDAPmessage_to_python() (message.c). Ciao, Michael. --------------------------------- snip --------------------------------- #!/usr/bin/python import sys,os,time,ldap from ldap.ldapobject import LDAPObject from ldapurl import LDAPUrl try: ldap_url = LDAPUrl(sys.argv[1]) num_tests = int(sys.argv[2]) except IndexError: print 'Usage: pref_test.py ' sys.exit(1) iter = num_tests start_time = time.time() while iter: l = LDAPObject(ldap_url.initializeUrl(),trace_level=0) l.protocol_version = 3 l.simple_bind_s(ldap_url.who or '',ldap_url.cred or '') l.search_s( ldap_url.dn, ldap_url.scope or ldap.SCOPE_BASE, ldap_url.filterstr or '(objectClass=*)', ldap_url.attrs or ['*'] ) l.unbind_s() del l iter -= 1 end_time = time.time() print 'Opening connection each time:',end_time-start_time iter = num_tests start_time = time.time() l = LDAPObject(ldap_url.initializeUrl(),trace_level=0) l.protocol_version = 3 l.simple_bind_s(ldap_url.who or '',ldap_url.cred or '') while iter: l.search_s( ldap_url.dn, ldap_url.scope or ldap.SCOPE_BASE, ldap_url.filterstr or '(objectClass=*)', ldap_url.attrs or ['*'] ) iter -= 1 end_time = time.time() l.unbind_s() del l print 'Reusing connection:',end_time-start_time iter = num_tests start_time = time.time() while iter: os.system('ldapsearch -x -H "%s" -b "%s" -s %s "%s" %s > /dev/null' % ( ldap_url.initializeUrl(), ldap_url.dn, {0:'base',1:'one',2:'sub'}[ldap_url.scope or ldap.SCOPE_BASE], ldap_url.filterstr or '(objectClass=*)', ' '.join(ldap_url.attrs or []) )) iter -= 1 end_time = time.time() print 'Using ldapsearch:',end_time-start_time From michael at stroeder.com Wed Jun 25 12:40:38 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 25 Jun 2003 12:40:38 +0200 Subject: Double checked Python benchmark script In-Reply-To: References: Message-ID: <3EF97C26.3050106@stroeder.com> Ed . wrote: > I used to be a C wizard, will check it out later on in my test > environment. I'd very much appreciate that since I'm the opposite of a C wizard. > This is much simpler but in mine I wanted to test the > effect of requesting all all versus single attributes and to do random > lookups. This is good however for initial high level investigations. Note that with my test script you can specify any search by LDAP URL which includes specifying certain attributes to read (see RFC2255). python perf_test.py "ldap://localhost:1390/dc=stroeder,dc=de?cn?sub" only retrieves attribute 'cn' of all search results. It also supports the bindname and X-BINDPW LDAP URL extensions: python perf_test.py "ldap://localhost:1390/dc=stroeder,dc=de?cn?sub?(objectClass=person)?bindname=cn=manager,X-BINDPW=secret" binds with cn=manager and password 'secret'. Ciao, Michael. From epo001 at hotmail.com Wed Jun 25 11:30:52 2003 From: epo001 at hotmail.com (Ed .) Date: Wed, 25 Jun 2003 09:30:52 +0000 Subject: Double checked Python benchmark script Message-ID: I used to be a C wizard, will check it out later on in my test environment. This is much simpler but in mine I wanted to test the effect of requesting all all versus single attributes and to do random lookups. This is good however for initial high level investigations. Ed > >Ed, > >I wrote my own test script (attached). It's less complex to read but more >flexible (through LDAP URL as parameter). Please review. > >Usage: pref_test.py > >Grab whole sub-tree 100 times (no server-side limit or logging, ~500 >entries): > >$ python perf_test.py "ldap://localhost:1390/dc=stroeder,dc=de?*?sub" 100 >Opening connection each time: 20.4206629992 >Reusing connection: 16.9708769321 >Using ldapsearch: 6.0001270771 > >I'd appreciate if anyone with C knowledge could review what is done in >ldap_result() (LDAPObject.c) and LDAPmessage_to_python() (message.c). > >Ciao, Michael. > From michael at stroeder.com Wed Jun 25 12:40:38 2003 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 25 Jun 2003 12:40:38 +0200 Subject: Double checked Python benchmark script In-Reply-To: References: Message-ID: <3EF97C26.3050106@stroeder.com> Ed . wrote: > I used to be a C wizard, will check it out later on in my test > environment. I'd very much appreciate that since I'm the opposite of a C wizard. > This is much simpler but in mine I wanted to test the > effect of requesting all all versus single attributes and to do random > lookups. This is good however for initial high level investigations. Note that with my test script you can specify any search by LDAP URL which includes specifying certain attributes to read (see RFC2255). python perf_test.py "ldap://localhost:1390/dc=stroeder,dc=de?cn?sub" only retrieves attribute 'cn' of all search results. It also supports the bindname and X-BINDPW LDAP URL extensions: python perf_test.py "ldap://localhost:1390/dc=stroeder,dc=de?cn?sub?(objectClass=person)?bindname=cn=manager,X-BINDPW=secret" binds with cn=manager and password 'secret'. Ciao, Michael.