From michael at stroeder.com Wed Apr 5 05:24:43 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 5 Apr 2017 11:24:43 +0200 Subject: [python-ldap] CfP LDAPcon 2017 Message-ID: <9a3e3947-54d3-d8ac-d7b0-de41fce8e264@stroeder.com> HI! (This is sent to several mailing lists. Sorry in advance if you receive multiple copies.) This year's LDAPcon 2017 will be in Bruxelles 19th-20th October, 2017. Kudos to Paola PENATI and Benoit MORTIER at OpenSides for organizing the event. If you'd like to submit a conference talk then please have a look at the CfP: https://ldapcon.org/2017/call-for-papers/ Looking forward to your submission. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From hahn at univention.de Mon Apr 24 03:00:54 2017 From: hahn at univention.de (Philipp Hahn) Date: Mon, 24 Apr 2017 09:00:54 +0200 Subject: [python-ldap] [BUG, PATCH] Not all synchronous methods are wrapped in ReconnectLDAPObject Message-ID: <95908862-742f-dd91-c466-17c1d7df006f@univention.de> Hi, I noticed that not all synchronous methods are wrapped by ReconnectLDAPObject(), such not doing the re-connect for the not-overwritten methods of SimpleLDAPObject: > $ diff -y -t -W 60 <(sed -rne '/^class SimpleLDAPObject/,/^\S/s/\s+def ([a-z][a-z_]+_st?)\(.*\):/\1/p' Lib/ldap/ldapobject.py|sort) <(sed -rne '/^class ReconnectLDAPObject/,/^\S/s/\s+def ([a-z][a-z_]+_st?)\(.*\):/\1/p' Lib/ldap/ldapobject.py|sort) > add_ext_s add_ext_s > add_s < > bind_s bind_s > cancel_s cancel_s > compare_ext_s < > compare_s compare_s > delete_ext_s delete_ext_s > delete_s < *** uses delete_ext_s() *** > extop_s extop_s > modify_ext_s modify_ext_s > modify_s < > modrdn_s < *** uses rename_s() *** > passwd_s < > read_s < *** uses search_ext_s() *** > read_subschemasubentry_s < *** uses read_s() ? search_ext_s() *** > rename_s rename_s > sasl_interactive_bind_s sasl_interactive_bind_s > search_ext_s search_ext_s > search_s < *** uses search_ext_s() *** > search_st < *** uses search_ext_s() *** > search_subschemasubentry_s < *** uses search_s ? search_ext_s() *** > simple_bind_s simple_bind_s > start_tls_s start_tls_s > unbind_ext_s < *** must not be wrapped *** > unbind_s < *** must not be wrapped *** > whoami_s whoami_s Find attached my patch to add the 4 missing wrappers. An alternative would be to implement add_s(...) := add_ext_s(..., None, None) modify_s(...) := modify_ext_s(..., None, None) but "compare_ext_s" "and passwd_s" are definitely missing - those are the modern _ext variants. Philipp -- Philipp Hahn Open Source Software Engineer Univention GmbH be open. Mary-Somerville-Str. 1 D-28359 Bremen Tel.: +49 421 22232-0 Fax : +49 421 22232-99 hahn at univention.de http://www.univention.de/ Gesch?ftsf?hrer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-missing-wrappers-for-synchronous-calls-for-recon.patch Type: text/x-diff Size: 2153 bytes Desc: not available URL: From michael at stroeder.com Mon Apr 24 04:27:23 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 24 Apr 2017 10:27:23 +0200 Subject: [python-ldap] [BUG, PATCH] Not all synchronous methods are wrapped in ReconnectLDAPObject In-Reply-To: <95908862-742f-dd91-c466-17c1d7df006f@univention.de> References: <95908862-742f-dd91-c466-17c1d7df006f@univention.de> Message-ID: Philipp, Philipp Hahn wrote: > I noticed that not all synchronous methods are wrapped by > ReconnectLDAPObject(), such not doing the re-connect for the > not-overwritten methods of SimpleLDAPObject: thanks for spotting these historical misfits. I've committed a slightly different fix to HEAD. Please review and test. If you need this I'd be willing to make a quick-fix release. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Tue Apr 25 03:47:01 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Tue, 25 Apr 2017 09:47:01 +0200 Subject: [python-ldap] ANN: python-ldap 2.4.33 Message-ID: Find a new release of python-ldap: https://pypi.python.org/pypi/python-ldap/2.4.33 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, LDAP URLs and LDAPv3 schema). Project's web site: https://www.python-ldap.org/ Ciao, Michael. ---------------------------------------------------------------- Released 2.4.33 2017-04-25 Lib/ * faster implementation of ldap.schema.tokenizer.split_tokens() (thanks to Christian Heimes) * removed unused 2nd argument of ldap.schema.tokenizer.split_tokens() * fixed method calls in ReconnectLDAPObject (thanks to Philipp Hahn) Modules/ * an empty info message is replaced with str(errno) if errno is non-zero which gives more information e.g. in case of ldap.SERVER_DOWN (thanks to Markus Klein) * removed superfluous ldap_memfree(error) from LDAPerror() (thanks to Markus Klein) Tests/ * re-factored t_ldap_schema_tokenizer.py -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From sebastian at utzerath.eu Wed Apr 26 10:22:49 2017 From: sebastian at utzerath.eu (Sebastian Utzerath) Date: Wed, 26 Apr 2017 16:22:49 +0200 Subject: [python-ldap] python-ldap doesn't raise invalid_credentials exception, instead results in KeyError Message-ID: Hi all, we want to provide LDAP authentication for a Django app (Weblate). We use django-auth-ldap (v1.2.11) which requires python-ldap (v2.4.35). In our app, the login works correctly when I enter valid user credentials. But as soon as I enter invalid credentials, we receive a KeyError Exception. I know that python-ldap is meant to make errors appear as exceptions, but please have a look at this: --- File "/var/www/weblate/env/local/lib/python2.7/site-packages/ldap/ldapobject.py" in _ldap_call 116. e.args[0]['info'] = strerror(e.args[0]['errno']) Exception Type: KeyError at /accounts/login/ Exception Value: 'errno' --- The local vars inside of _ldap_call are: --- args: (1, 1, -1, 0, 0, 0) diagnostic_message_success: None e: INVALID_CREDENTIALS({'desc': 'Invalid credentials'},) func: kwargs: {} self: --- I've pasted the full stack trace here: https://github.com/WeblateOrg/weblate/issues/1460 Could it be that we don't receive an INVALID_CREDENTIALS exception as expected, but python-ldap may have issues extracting the error message? Can you help me to understand why python-ldap is extracting e.args[0]['errno'] or which options we may need to set to skip this? Thank you very much in advance for any help! Kind regards, Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Apr 26 13:12:53 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 26 Apr 2017 19:12:53 +0200 Subject: [python-ldap] ANN: python-ldap 2.4.36 Message-ID: <9515ef14-8dba-1715-7adb-7a1b1e94a74c@stroeder.com> Find a new release of python-ldap: https://pypi.python.org/pypi/python-ldap/2.4.36 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, LDAP URLs and LDAPv3 schema). Project's web site: https://www.python-ldap.org/ Ciao, Michael. ---------------------------------------------------------------- Released 2.4.36 2017-04-26 Changes since 2.4.35: Lib/ * gracefully handle KeyError in LDAPObject._ldap_call() when using errno * added new stand-alone module slapdtest (formerly Tests/slapd.py) for general use (still experimental) Tests/ * re-factored t_cext.py and t_search.py * set env var LDAPNOINIT=1 in t_cext.py and t_search.py to avoid interference with locally installed .ldaprc or ldap.conf * by default back-mdb is now used for slapd-based tests which requires fairly recent OpenLDAP builds but implements full feature set * env vars can be set for slapd.py to tweak path names of executables, temporary and schema data to be used * new class SlapdTestCase ---------------------------------------------------------------- Released 2.4.35 2017-04-25 Changes since 2.4.33: (2.4.34 is missing because of foolish pypi version madness) Modules/ * use errno in a safer way * set errno as LDAPError class item * do not use strerror() which is not thread-safe and platform-specific Lib/ * LDAPObject._ldap_call() sets LDAPError info to value returned by platform-neutral os.stderror() -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Wed Apr 26 13:15:23 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 26 Apr 2017 19:15:23 +0200 Subject: [python-ldap] python-ldap doesn't raise invalid_credentials exception, instead results in KeyError In-Reply-To: References: Message-ID: Sebastian Utzerath wrote: > --- > File "/var/www/weblate/env/local/lib/python2.7/site-packages/ldap/ldapobject.py" in > _ldap_call > 116. e.args[0]['info'] = strerror(e.args[0]['errno']) > > Exception Type: KeyError at /accounts/login/ > Exception Value: 'errno' > --- Sorry, this was a regression in 2.4.35 which got fixed in 2.4.36 (released few minutes ago). Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From glawrence at nice-challenge.com Wed Apr 26 18:21:14 2017 From: glawrence at nice-challenge.com (Garry Lawrence) Date: Wed, 26 Apr 2017 15:21:14 -0700 Subject: [python-ldap] python-ldap doesn't raise invalid_credentials exception, instead results in KeyError Message-ID: In my testing, the fix in 2.4.36 appears incomplete. I have attached a patch. -Garry Lawrence -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: keyerror.patch Type: application/octet-stream Size: 690 bytes Desc: not available URL: From michael at stroeder.com Thu Apr 27 04:53:37 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Thu, 27 Apr 2017 10:53:37 +0200 Subject: [python-ldap] ANN: python-ldap 2.4.37 Message-ID: <3b2a7fd6-752e-dc4d-ba54-a552436a053a@stroeder.com> Find a new release of python-ldap: https://pypi.python.org/pypi/python-ldap/2.4.37 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, LDAP URLs and LDAPv3 schema). Project's web site: https://www.python-ldap.org/ Ciao, Michael. ---------------------------------------------------------------- Released 2.4.37 2017-04-27 Changes since 2.4.36: Lib/ * fixed errno-related regression introduced in 2.4.35 Tests/ * added more checks to t_cext.py * renamed t_search.py to t_ldapobject.py and code-cleaning * added test for errno-related regression to t_ldapobject.py -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Thu Apr 27 04:54:54 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Thu, 27 Apr 2017 10:54:54 +0200 Subject: [python-ldap] python-ldap doesn't raise invalid_credentials exception, instead results in KeyError In-Reply-To: References: Message-ID: Garry Lawrence wrote: > In my testing, the fix in 2.4.36 appears incomplete. I have attached a patch. Yes, you're right. Release 2.4.37 has a slightly different fix and especially it has an automated test for it. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Thu Apr 27 05:00:00 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Thu, 27 Apr 2017 11:00:00 +0200 Subject: [python-ldap] Tests/t_ldapobject.py and module slapdtest Message-ID: <4f03e293-e034-ee91-e1ef-5263bc9a92bd@stroeder.com> HI! Tests, tests, tests... Some of you might have noticed that work was done in Tests/ to make it easier to add new tests against a spawned OpenLDAP server. If anyone has some spare cycles I'd appreciate receiving patches for some more tests still missing in Tests/t_ldapobject.py (simple add/modify/whatever operations). Especially there's a new stand-alone module 'slapdtest' which makes it easier for 3rd-party software to develop own tests (e.g. to be used in my python-aedir). This is still experimental and the API is likely subject to change. But give it a try and report back. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From amedee.potier at gmail.com Fri May 5 08:19:23 2017 From: amedee.potier at gmail.com (Amedee Potier) Date: Fri, 5 May 2017 14:19:23 +0200 Subject: [python-ldap] python-ldap licensing ? Message-ID: Hello, thanks for your work on this python-ldap project. Great stuff. One question : what is the license associated to this product ? Can it be used in commercial applications or not ? What are the obligations a product that would bundle your packages ? Thanks, Amedee From michael at stroeder.com Fri May 5 08:27:14 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Fri, 5 May 2017 14:27:14 +0200 Subject: [python-ldap] python-ldap licensing ? In-Reply-To: References: Message-ID: <37d59967-bc71-ca6c-3836-1ea9110bbcb2@stroeder.com> Amedee Potier wrote: > thanks for your work on this python-ldap project. Great stuff. > > One question : what is the license associated to this product ? Can it be used in > commercial applications or not ? What are the obligations a product that would bundle > your packages ? Unfortunately the term "Python-style license" introduced by myself is pretty blurry. But basically the intention is that you can freely use python-ldap just as Python itself. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From ilya at glas.net Fri May 5 08:50:52 2017 From: ilya at glas.net (Ilya Etingof) Date: Fri, 5 May 2017 14:50:52 +0200 Subject: [python-ldap] python-ldap licensing ? In-Reply-To: <37d59967-bc71-ca6c-3836-1ea9110bbcb2@stroeder.com> References: <37d59967-bc71-ca6c-3836-1ea9110bbcb2@stroeder.com> Message-ID: >From my experience, boldly sticking to one of the standard FOSS licenses tend to benefit software adoption. It might be even more applicable to LDAP, as it's more of an enterprise application as opposed to end-user one. Just my 2c. ;-) On 05/05/2017 02:27 PM, Michael Str?der wrote: > Amedee Potier wrote: >> thanks for your work on this python-ldap project. Great stuff. >> >> One question : what is the license associated to this product ? Can it be used in >> commercial applications or not ? What are the obligations a product that would bundle >> your packages ? > > Unfortunately the term "Python-style license" introduced by myself is pretty blurry. > > But basically the intention is that you can freely use python-ldap just as Python itself. > > Ciao, Michael. > From michael at stroeder.com Fri May 5 09:40:49 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Fri, 5 May 2017 15:40:49 +0200 Subject: [python-ldap] python-ldap licensing ? In-Reply-To: References: <37d59967-bc71-ca6c-3836-1ea9110bbcb2@stroeder.com> Message-ID: <3bb55659-a8c0-686e-673e-be4195a21a4d@stroeder.com> Ilya Etingof wrote: > On 05/05/2017 02:27 PM, Michael Str?der wrote: >> Amedee Potier wrote: >>> thanks for your work on this python-ldap project. Great stuff. >>> >>> One question : what is the license associated to this product ? Can it be used in >>> commercial applications or not ? What are the obligations a product that would bundle >>> your packages ? >> >> Unfortunately the term "Python-style license" introduced by myself is pretty blurry. >> >> But basically the intention is that you can freely use python-ldap just as Python >> itself. > > From my experience, boldly sticking to one of the standard FOSS licenses > tend to benefit software adoption. It might be even more applicable to > LDAP, as it's more of an enterprise application as opposed to end-user one. Basically broad adoption was my intention by saying "Python-style license". Again, I had to learn many years ago that this was a beginner's fault. Today I'd choose APL-2.0. But it's nearly impossible to fix that retroactively. That's also one reason why I always recommended a new clean-room implementation for Python 3. Anyway: Feel free to simply use it. David (original author of C wrapper part) and me will never stand in anyone's way using python-ldap. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From ilya at glas.net Fri May 5 10:38:05 2017 From: ilya at glas.net (Ilya Etingof) Date: Fri, 5 May 2017 16:38:05 +0200 Subject: [python-ldap] python-ldap licensing ? In-Reply-To: <20170505163112.515b4c9a@ithor.polyconseil.fr> References: <37d59967-bc71-ca6c-3836-1ea9110bbcb2@stroeder.com> <3bb55659-a8c0-686e-673e-be4195a21a4d@stroeder.com> <20170505163112.515b4c9a@ithor.polyconseil.fr> Message-ID: <7e5e713a-4e0b-d994-f9d0-cd4684d26c64@glas.net> On 05/05/2017 04:31 PM, Rapha?l Barrois wrote: > > > On Fri, 5 May 2017 15:40:49 +0200 > Michael Str?der wrote: > >> Ilya Etingof wrote: >>> On 05/05/2017 02:27 PM, Michael Str?der wrote: >>>> Amedee Potier wrote: >>>>> thanks for your work on this python-ldap project. Great stuff. >>>>> >>>>> One question : what is the license associated to this product ? Can it be used in >>>>> commercial applications or not ? What are the obligations a product that would bundle >>>>> your packages ? >>>> >>>> Unfortunately the term "Python-style license" introduced by myself is pretty blurry. >>>> >>>> But basically the intention is that you can freely use python-ldap just as Python >>>> itself. >>> >>> From my experience, boldly sticking to one of the standard FOSS licenses >>> tend to benefit software adoption. It might be even more applicable to >>> LDAP, as it's more of an enterprise application as opposed to end-user one. >> >> Basically broad adoption was my intention by saying "Python-style license". Again, I had >> to learn many years ago that this was a beginner's fault. Today I'd choose APL-2.0. But >> it's nearly impossible to fix that retroactively. That's also one reason why I always >> recommended a new clean-room implementation for Python 3. >> >> Anyway: Feel free to simply use it. David (original author of C wrapper part) and me will >> never stand in anyone's way using python-ldap. >> >> Ciao, Michael. >> > > > There has already been a couple of threads on this topic ;) > > If I remember correctly, the conclusion was that the only obstacle to changing the license would be to collect the > opinion of every past contributor: their contributions were made within a "redistribution under a python-style license" > context; if the license were to be changed to, say, APL-2.0, it looked like their agreement could be required before > changing that? Does current license allow re-licensing? If it does, logically, could upstream change its own license leveraging the re-licensing allowance that current license offers? ;-) I'm infinitely far from being a lawyer, just trying to debug the conclusion. ;-) From raphael.barrois at m4x.org Fri May 5 10:31:12 2017 From: raphael.barrois at m4x.org (=?UTF-8?B?UmFwaGHDq2w=?= Barrois) Date: Fri, 5 May 2017 16:31:12 +0200 Subject: [python-ldap] python-ldap licensing ? In-Reply-To: <3bb55659-a8c0-686e-673e-be4195a21a4d@stroeder.com> References: <37d59967-bc71-ca6c-3836-1ea9110bbcb2@stroeder.com> <3bb55659-a8c0-686e-673e-be4195a21a4d@stroeder.com> Message-ID: <20170505163112.515b4c9a@ithor.polyconseil.fr> On Fri, 5 May 2017 15:40:49 +0200 Michael Str?der wrote: > Ilya Etingof wrote: > > On 05/05/2017 02:27 PM, Michael Str?der wrote: > >> Amedee Potier wrote: > >>> thanks for your work on this python-ldap project. Great stuff. > >>> > >>> One question : what is the license associated to this product ? Can it be used in > >>> commercial applications or not ? What are the obligations a product that would bundle > >>> your packages ? > >> > >> Unfortunately the term "Python-style license" introduced by myself is pretty blurry. > >> > >> But basically the intention is that you can freely use python-ldap just as Python > >> itself. > > > > From my experience, boldly sticking to one of the standard FOSS licenses > > tend to benefit software adoption. It might be even more applicable to > > LDAP, as it's more of an enterprise application as opposed to end-user one. > > Basically broad adoption was my intention by saying "Python-style license". Again, I had > to learn many years ago that this was a beginner's fault. Today I'd choose APL-2.0. But > it's nearly impossible to fix that retroactively. That's also one reason why I always > recommended a new clean-room implementation for Python 3. > > Anyway: Feel free to simply use it. David (original author of C wrapper part) and me will > never stand in anyone's way using python-ldap. > > Ciao, Michael. > There has already been a couple of threads on this topic ;) If I remember correctly, the conclusion was that the only obstacle to changing the license would be to collect the opinion of every past contributor: their contributions were made within a "redistribution under a python-style license" context; if the license were to be changed to, say, APL-2.0, it looked like their agreement could be required before changing that? -- Rapha?l From amedee.potier at gmail.com Fri May 5 11:33:35 2017 From: amedee.potier at gmail.com (Amedee Potier) Date: Fri, 5 May 2017 17:33:35 +0200 Subject: [python-ldap] python-ldap licensing ? In-Reply-To: <7e5e713a-4e0b-d994-f9d0-cd4684d26c64@glas.net> References: <37d59967-bc71-ca6c-3836-1ea9110bbcb2@stroeder.com> <3bb55659-a8c0-686e-673e-be4195a21a4d@stroeder.com> <20170505163112.515b4c9a@ithor.polyconseil.fr> <7e5e713a-4e0b-d994-f9d0-cd4684d26c64@glas.net> Message-ID: <0f33309a-93e4-28b2-a25a-9eb938412135@gmail.com> Le 05/05/2017 ? 16:38, Ilya Etingof a ?crit : > > On 05/05/2017 04:31 PM, Rapha?l Barrois wrote: >> >> On Fri, 5 May 2017 15:40:49 +0200 >> Michael Str?der wrote: >> >>> Ilya Etingof wrote: >>>> On 05/05/2017 02:27 PM, Michael Str?der wrote: >>>>> Amedee Potier wrote: >>>>>> thanks for your work on this python-ldap project. Great stuff. >>>>>> >>>>>> One question : what is the license associated to this product ? Can it be used in >>>>>> commercial applications or not ? What are the obligations a product that would bundle >>>>>> your packages ? >>>>> Unfortunately the term "Python-style license" introduced by myself is pretty blurry. >>>>> >>>>> But basically the intention is that you can freely use python-ldap just as Python >>>>> itself. >>>> From my experience, boldly sticking to one of the standard FOSS licenses >>>> tend to benefit software adoption. It might be even more applicable to >>>> LDAP, as it's more of an enterprise application as opposed to end-user one. >>> Basically broad adoption was my intention by saying "Python-style license". Again, I had >>> to learn many years ago that this was a beginner's fault. Today I'd choose APL-2.0. But >>> it's nearly impossible to fix that retroactively. That's also one reason why I always >>> recommended a new clean-room implementation for Python 3. >>> >>> Anyway: Feel free to simply use it. David (original author of C wrapper part) and me will >>> never stand in anyone's way using python-ldap. >>> >>> Ciao, Michael. >>> >> >> There has already been a couple of threads on this topic ;) >> >> If I remember correctly, the conclusion was that the only obstacle to changing the license would be to collect the >> opinion of every past contributor: their contributions were made within a "redistribution under a python-style license" >> context; if the license were to be changed to, say, APL-2.0, it looked like their agreement could be required before >> changing that? > Does current license allow re-licensing? If it does, logically, could > upstream change its own license leveraging the re-licensing allowance > that current license offers? ;-) > > I'm infinitely far from being a lawyer, just trying to debug the > conclusion. ;-) > Thank you all !! Much appreciated your quick (and positive) response. I'll definitely make sure to include all the due credits in the documentations. This is the least you deserve! Have a great week-end, Amedee From riteshn at gmail.com Sat May 13 01:25:40 2017 From: riteshn at gmail.com (Ritesh Nadhani) Date: Fri, 12 May 2017 22:25:40 -0700 Subject: [python-ldap] Auto encoding of binary fields Message-ID: Hello Using ldapsearch, it seems it autoencodes non printable attribute value into something that is more printable on console. Is there any flag with python-ldap package that can do the same? -- Ritesh From michael at stroeder.com Sat May 13 04:23:02 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 13 May 2017 10:23:02 +0200 Subject: [python-ldap] Auto encoding of binary fields In-Reply-To: References: Message-ID: Ritesh Nadhani wrote: > Using ldapsearch, it seems it autoencodes non printable attribute > value into something that is more printable on console. > > Is there any flag with python-ldap package that can do the same? The ldapsearch command-line outputs LDIF (see RFC 2849): https://tools.ietf.org/html/rfc2849 The module ldif can be used to do the same: https://www.python-ldap.org/doc/html/ldif.html Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From riteshn at gmail.com Tue May 16 23:34:20 2017 From: riteshn at gmail.com (Ritesh Nadhani) Date: Tue, 16 May 2017 20:34:20 -0700 Subject: [python-ldap] Auto encoding of binary fields In-Reply-To: References: Message-ID: Hello On Sat, May 13, 2017 at 1:23 AM, Michael Str?der wrote: > Ritesh Nadhani wrote: >> Using ldapsearch, it seems it autoencodes non printable attribute >> value into something that is more printable on console. >> >> Is there any flag with python-ldap package that can do the same? > > The ldapsearch command-line outputs LDIF (see RFC 2849): > https://tools.ietf.org/html/rfc2849 > > The module ldif can be used to do the same: > https://www.python-ldap.org/doc/html/ldif.html Thanks. Learnt something new. One more observation that I cannot seem to find information for, is why the python package returns every attribute value as a list. Even for attribute like sAMAccountName (which seems can only hold on single string value) is returned as: ['someName'] For display purposes in my app, I would like to show those values as single element but attributes which allow multiple values as list. Is there some specification/list of fields that can be multivalue? Sorry, if its something that I overlooked or is just a simple question. > > Ciao, Michael. > -- Ritesh From hahn at univention.de Wed May 17 01:38:12 2017 From: hahn at univention.de (Philipp Hahn) Date: Wed, 17 May 2017 07:38:12 +0200 Subject: [python-ldap] Auto encoding of binary fields In-Reply-To: References: Message-ID: Hello, Am 17.05.2017 um 05:34 schrieb Ritesh Nadhani: > One more observation that I cannot seem to find information for, is > why the python package returns every attribute value as a list. Even > for attribute like sAMAccountName (which seems can only hold on single > string value) is returned as: > > ['someName'] Because that is the data model defined by LDAP, so it's not python-ldap specific. It makes generic LDAP application easier to write if you can just handle every attribute the same, that is as multi-valued. Otherwise you would need attribute specific knowledge into every app, which breaks as soon as you add new attributes, which old application then would not be able to handle. (I've inherited a legacy LDAP library, which adds some wrapper around the low-level LDAP stuff. It distinguished between single-valued attributes and multi-valued attributes and either presents them an "string" or "list of strings" in Python. Any application using that application is riddled with if statements like "if that attribute is single-valued, do this, otherwise do that". Often they are wrong because in Python "stings" are handled as "list of characters", leading to strange errors.) > For display purposes in my app, I would like to show those values as > single element but attributes which allow multiple values as list. Is > there some specification/list of fields that can be multivalue? Look at the schema definition of each attribute; if it is declared as "SINGLE-VALUE", only one value is allowed, otherwise it's multi-valued: > ldapsearch -x -LLL -o ldif-wrap=no -b cn=Subschema -s base attributeTypes | grep SINGLE-VALUE > Sorry, if its something that I overlooked or is just a simple question. I hope I could help you. Philipp From diptiburli21 at gmail.com Tue May 23 01:55:45 2017 From: diptiburli21 at gmail.com (dipti Burli) Date: Tue, 23 May 2017 11:25:45 +0530 Subject: [python-ldap] stop tls without ldap unbind Message-ID: Hi , I do conn = ldap.initialize('ldap://localhost:16611') conn.start_tls_s() print '\nBinding\n' conn.simple_bind_s("cn=sdfrun", "sdfrun1") At this point i want to do something like #conn.stop_tls_s() so that the messages on this connection go as plain ldap messgaes ( search/modify etc) and not encrypted. How can I do that? Thanks, Dipti -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Tue May 23 03:16:59 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Tue, 23 May 2017 09:16:59 +0200 Subject: [python-ldap] stop tls without ldap unbind In-Reply-To: References: Message-ID: <7e9b4207-fff4-937c-111f-9222393d8c07@stroeder.com> dipti Burli wrote: > I do > conn = ldap.initialize('ldap://localhost:16611') > conn.start_tls_s() > print '\nBinding\n' > conn.simple_bind_s("cn=sdfrun", "sdfrun1") > > At this point i want to do something like > > #conn.stop_tls_s() > > so that the messages on this connection go as plain ldap messgaes ( search/modify > etc) and not encrypted. > > How can I do that? You can't without opening a new connection (see RFC 2830). Why do you want that? Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From diptiburli21 at gmail.com Wed May 24 05:25:01 2017 From: diptiburli21 at gmail.com (dipti Burli) Date: Wed, 24 May 2017 14:55:01 +0530 Subject: [python-ldap] stop tls without ldap unbind In-Reply-To: <7e9b4207-fff4-937c-111f-9222393d8c07@stroeder.com> References: <7e9b4207-fff4-937c-111f-9222393d8c07@stroeder.com> Message-ID: According to RFC I thought it was possible. Below is what am referring. by ldap association being intact when TLS is closed down. 4. Closing a TLS Connection 4.1. Graceful Closure *Either the client or server MAY terminate the TLS connection on an LDAP association by sending a TLS closure alert. This will leave the LDAP association intact. * Before closing a TLS connection, the client MUST either wait for any outstanding LDAP operations to complete, or explicitly abandon them [LDAPv3]. After the initiator of a close has sent a closure alert, it MUST discard any TLS messages until it has received an alert from the other party. It will cease to send TLS Record Protocol PDUs, and following the receipt of the alert, MAY send and receive LDAP PDUs. The other party, if it receives a closure alert, MUST immediately transmit a TLS closure alert. It will subsequently cease to send TLS Record Protocol PDUs, and MAY send and receive LDAP PDUs. Thanks, Dipti On Tue, May 23, 2017 at 12:46 PM, Michael Str?der wrote: > dipti Burli wrote: > > I do > > conn = ldap.initialize('ldap://localhost:16611') > > conn.start_tls_s() > > print '\nBinding\n' > > conn.simple_bind_s("cn=sdfrun", "sdfrun1") > > > > At this point i want to do something like > > > > #conn.stop_tls_s() > > > > so that the messages on this connection go as plain ldap messgaes ( > search/modify > > etc) and not encrypted. > > > > How can I do that? > > You can't without opening a new connection (see RFC 2830). > > Why do you want that? > > Ciao, Michael. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed May 24 05:41:15 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 24 May 2017 11:41:15 +0200 Subject: [python-ldap] stop tls without ldap unbind In-Reply-To: References: <7e9b4207-fff4-937c-111f-9222393d8c07@stroeder.com> Message-ID: <697c2c0d-14b9-840c-490d-f3d6dba8df3a@stroeder.com> dipti Burli wrote: > According to RFC I thought it was possible. > > Below is what am referring. by ldap association being intact when TLS is closed down. > > 4. Closing a TLS Connection Yes, but there's no such thing like a StopTLS LDAP PDU. Again: Why do you want that? Note that security is also about integrity and TLS gives you integrity protection for the connection. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From diptiburli21 at gmail.com Wed May 24 07:36:30 2017 From: diptiburli21 at gmail.com (dipti Burli) Date: Wed, 24 May 2017 17:06:30 +0530 Subject: [python-ldap] stop tls without ldap unbind In-Reply-To: <697c2c0d-14b9-840c-490d-f3d6dba8df3a@stroeder.com> References: <7e9b4207-fff4-937c-111f-9222393d8c07@stroeder.com> <697c2c0d-14b9-840c-490d-f3d6dba8df3a@stroeder.com> Message-ID: Hi Michael, I understand that TLS gives security and integrity. Am using python-ldap as test scripts/code to Test the ldap server. Its ldapServer`s requirement that it needs to respond with ldap(add/search/modify) operations on a connection which was binded on TLS and torn down after bind. The Server has performance/delay issues when data gets encrypted on large search and modify operations. Hence the query in python. I have 2 options 1. Create python socket, wrap it with ssl then use it to send encrypted message or plain test message( after tearing down only TLS) on the ssl_socket, but issue here is framing ldap messages explictly. is there anyway to do it? 2. Using python-ldap , wihich readily provides apis to bind ,search, and other operations .but cant tear down TLS after bind and still use the same association. Any help will be much of great assitance. On Wed, May 24, 2017 at 3:11 PM, Michael Str?der wrote: > dipti Burli wrote: > > According to RFC I thought it was possible. > > > > Below is what am referring. by ldap association being intact when TLS is > closed down. > > > > 4. Closing a TLS Connection > > Yes, but there's no such thing like a StopTLS LDAP PDU. > > Again: Why do you want that? > > Note that security is also about integrity and TLS gives you integrity > protection for the > connection. > > Ciao, Michael. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at codetastic.com Wed May 24 19:24:09 2017 From: matt at codetastic.com (Matt Bosworth) Date: Wed, 24 May 2017 16:24:09 -0700 Subject: [python-ldap] [BUG] KeyError on 'errno' Message-ID: Hi all, It looks like this might be a regression that snuck back in over the last couple weeks? I just updated to the latest version of python-ldap (2.4.38), django-auth-ldap (1.2.12), and django (1.11.1) and now successful LDAP authentication raises an Exception (full stack trace below). Rolling back to 2.4.37 fixes the issue. Also, if I jump into python-ldap/ldapobject.py and change line 272 to 'pass' then things work. Original line 272: e.args[0]['info'] = strerror(e.args[0]['errno']) Stack trace: Environment: Request Method: POST Request URL: http://localhost:8000/login/ Django Version: 1.11.1 Python Version: 2.7.13 Installed Applications: ('django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'django_select2', 'session_security', 'bootstrapform', 'rt.utils', 'rt.main', 'rt.menus', 'rt.onset_survey', 'rt.onset_survey_collab', 'rt.tableau', 'rt.patient_filter', 'rt.prog_changes', 'rt.caseconf', 'rt.user_prefs', 'batt_watchlist', 'long_plot', 'custom_reports') Installed Middleware: ('django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'session_security.middleware.SessionSecurityMiddleware', 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'rt.middleware.RequireLoginMiddleware') Traceback: File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/core/handlers/exception.py" in inner 41. response = get_response(request) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/core/handlers/base.py" in _get_response 187. response = self.process_exception_by_middleware(e, request) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/core/handlers/base.py" in _get_response 185. response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/views/generic/base.py" in view 68. return self.dispatch(request, *args, **kwargs) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/utils/decorators.py" in _wrapper 67. return bound_func(*args, **kwargs) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/views/decorators/debug.py" in sensitive_post_parameters_wrapper 76. return view(request, *args, **kwargs) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/utils/decorators.py" in bound_func 63. return func.__get__(self, type(self))(*args2, **kwargs2) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/utils/decorators.py" in _wrapper 67. return bound_func(*args, **kwargs) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/utils/decorators.py" in _wrapped_view 149. response = view_func(request, *args, **kwargs) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/utils/decorators.py" in bound_func 63. return func.__get__(self, type(self))(*args2, **kwargs2) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/utils/decorators.py" in _wrapper 67. return bound_func(*args, **kwargs) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/views/decorators/cache.py" in _wrapped_view_func 57. response = view_func(request, *args, **kwargs) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/utils/decorators.py" in bound_func 63. return func.__get__(self, type(self))(*args2, **kwargs2) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/contrib/auth/views.py" in dispatch 90. return super(LoginView, self).dispatch(request, *args, **kwargs) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/views/generic/base.py" in dispatch 88. return handler(request, *args, **kwargs) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/views/generic/edit.py" in post 182. if form.is_valid(): File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/forms/forms.py" in is_valid 183. return self.is_bound and not self.errors File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/forms/forms.py" in errors 175. self.full_clean() File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/forms/forms.py" in full_clean 385. self._clean_form() File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/forms/forms.py" in _clean_form 412. cleaned_data = self.clean() File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/contrib/auth/forms.py" in clean 187. self.user_cache = authenticate(self.request, username=username, password=password) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django/contrib/auth/__init__.py" in authenticate 101. user = backend.authenticate(*args, **credentials) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django_auth_ldap/backend.py" in authenticate 171. user = ldap_user.authenticate(password) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django_auth_ldap/backend.py" in authenticate 345. self._check_requirements() File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django_auth_ldap/backend.py" in _check_requirements 510. self._check_required_group() File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django_auth_ldap/backend.py" in _check_required_group 523. result = required_group_dn.resolve(self) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django_auth_ldap/config.py" in resolve 693. result = self.aggregator(self._resolve_children(ldap_user, groups)) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django_auth_ldap/config.py" in _resolve_children 721. yield groups.is_member_of(child) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django_auth_ldap/backend.py" in is_member_of 848. is_member = self._group_type.is_member(self._ldap_user, group_dn) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/django_auth_ldap/config.py" in is_member 476. force_str(ldap_user.dn) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/ldap/ldapobject.py" in compare_s 474. return self.compare_ext_s(dn,attr,value,None,None) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/ldap/ldapobject.py" in compare_ext_s 463. resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/ldap/ldapobject.py" in result3 682. resp_ctrl_classes=resp_ctrl_classes File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/ldap/ldapobject.py" in result4 689. ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) File "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/ldap/ldapobject.py" in _ldap_call 273. e.args[0]['info'] = strerror(e.args[0]['errno']) Exception Type: KeyError at /login/ Exception Value: u'errno' Hope this is useful! Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu May 25 05:16:38 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Thu, 25 May 2017 11:16:38 +0200 Subject: [python-ldap] [BUG] KeyError on 'errno' In-Reply-To: References: Message-ID: Matt Bosworth wrote: > It looks like this might be a regression that snuck back in over the last couple > weeks? > > I just updated to the latest version of python-ldap (2.4.38), django-auth-ldap > (1.2.12), and django (1.11.1) and now successful LDAP authentication raises an Exception > (full stack trace below). > > Rolling back to 2.4.37 fixes the issue. Hmm, are you sure with the versions? I'm asking because there wasn't any change in Lib/ldap/ from 2.4.37 to 2.4.38 (check CHANGES): ---------------------------------- snip ------------------------------------ $ diff -ur python-ldap-2.4.37/Lib/ldap python-ldap-2.4.38/Lib/ldap diff -ur python-ldap-2.4.37/Lib/ldap/__init__.py python-ldap-2.4.38/Lib/ldap/__init__.py --- python-ldap-2.4.37/Lib/ldap/__init__.py 2017-04-26 22:48:43.000000000 +0200 +++ python-ldap-2.4.38/Lib/ldap/__init__.py 2017-04-27 13:11:01.000000000 +0200 @@ -3,12 +3,12 @@ See http://www.python-ldap.org/ for details. -$Id: __init__.py,v 1.115 2017/04/26 20:48:43 stroeder Exp $ +$Id: __init__.py,v 1.116 2017/04/27 11:11:01 stroeder Exp $ """ # This is also the overall release version number -__version__ = '2.4.37' +__version__ = '2.4.38' import sys ---------------------------------- snip ------------------------------------ > Traceback: > [..] > "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/python2.7/site-packages/ldap/ldapobject.py" > in _ldap_call > 273. e.args[0]['info'] = strerror(e.args[0]['errno']) > > Exception Type: KeyError at /login/ > Exception Value: u'errno' The error you experienced was fixed in 2.4.37 as noted in CHANGES (see the Lib/ldap/ diff from 2.4.35 to 2.4.38 attached below). Are you sure that you have tested a clean installation of 2.4.38 in your virtualenv? I suspect that your downgrade to 2.4.37 has overwritten some left-overs from 2.4.35 installation. Ciao, Michael. ---------------------------------- snip ------------------------------------ --- python-ldap-2.4.35/Lib/ldap/__init__.py 2017-04-25 15:52:48.000000000 +0200 +++ python-ldap-2.4.38/Lib/ldap/__init__.py 2017-04-27 13:11:01.000000000 +0200 @@ -3,12 +3,12 @@ See http://www.python-ldap.org/ for details. -$Id: __init__.py,v 1.113 2017/04/25 13:52:48 stroeder Exp $ +$Id: __init__.py,v 1.116 2017/04/27 11:11:01 stroeder Exp $ """ # This is also the overall release version number -__version__ = '2.4.35' +__version__ = '2.4.38' import sys diff -ur python-ldap-2.4.35/Lib/ldap/ldapobject.py python-ldap-2.4.38/Lib/ldap/ldapobject.py --- python-ldap-2.4.35/Lib/ldap/ldapobject.py 2017-04-25 15:44:47.000000000 +0200 +++ python-ldap-2.4.38/Lib/ldap/ldapobject.py 2017-04-27 10:40:10.000000000 +0200 @@ -3,7 +3,7 @@ See http://www.python-ldap.org/ for details. -\$Id: ldapobject.py,v 1.160 2017/04/25 13:40:52 stroeder Exp $ +\$Id: ldapobject.py,v 1.162 2017/04/27 08:40:10 stroeder Exp $ Compability: - Tested with Python 2.0+ but should work with Python 1.5.x @@ -111,9 +111,9 @@ diagnostic_message_success = self._l.get_option(ldap.OPT_DIAGNOSTIC_MESSAGE) finally: self._ldap_object_lock.release() - except LDAPError,e: - if 'info' not in e.args[0]: - e.args[0]['info'] = strerror(e.args[0]['errno']) + except LDAPError, e: + if not e.args[0].has_key('info') and e.args[0].has_key('errno'): + e.args[0]['info'] = strerror(e.args[0]['errno']) if __debug__ and self._trace_level>=2: self._trace_file.write('=> LDAPError - %s: %s\n' % (e.__class__.__name__,str(e))) raise -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From matt at codetastic.com Thu May 25 15:59:58 2017 From: matt at codetastic.com (Matt Bosworth) Date: Thu, 25 May 2017 12:59:58 -0700 Subject: [python-ldap] [BUG] KeyError on 'errno' In-Reply-To: References: Message-ID: My bad! The error is actually in pyldap, which merged in python-ldap 2.4.35 a few weeks ago It appears that pyldap and python-ldap are stomping on each other. I'm using django-auth-ldap, which pulls in python-ldap, but I'm also pulling in pyldap from another (internal) library. And since they both sit in site-packages/ldap/ I mistakenly thought python-ldap was the issue. Apologies! I'll go pester the other project :) Cheers, Matt On Thu, May 25, 2017 at 2:16 AM, Michael Str?der wrote: > Matt Bosworth wrote: > > It looks like this might be a regression that snuck back in over the > last couple > > weeks? > > > > I just updated to the latest version of python-ldap (2.4.38), > django-auth-ldap > > (1.2.12), and django (1.11.1) and now successful LDAP authentication > raises an Exception > > (full stack trace below). > > > > Rolling back to 2.4.37 fixes the issue. > > Hmm, are you sure with the versions? > > I'm asking because there wasn't any change in Lib/ldap/ from 2.4.37 to > 2.4.38 (check > CHANGES): > > ---------------------------------- snip ------------------------------ > ------ > $ diff -ur python-ldap-2.4.37/Lib/ldap python-ldap-2.4.38/Lib/ldap > diff -ur python-ldap-2.4.37/Lib/ldap/__init__.py > python-ldap-2.4.38/Lib/ldap/__init__.py > --- python-ldap-2.4.37/Lib/ldap/__init__.py 2017-04-26 > 22:48:43.000000000 +0200 > +++ python-ldap-2.4.38/Lib/ldap/__init__.py 2017-04-27 > 13:11:01.000000000 +0200 > @@ -3,12 +3,12 @@ > > See http://www.python-ldap.org/ for details. > > -$Id: __init__.py,v 1.115 2017/04/26 20:48:43 stroeder Exp $ > +$Id: __init__.py,v 1.116 2017/04/27 11:11:01 stroeder Exp $ > """ > > # This is also the overall release version number > > -__version__ = '2.4.37' > +__version__ = '2.4.38' > > import sys > ---------------------------------- snip ------------------------------ > ------ > > > Traceback: > > [..] > > "/Users/bosworth/Documents/git/RtDjango/venv-py27/lib/ > python2.7/site-packages/ldap/ldapobject.py" > > in _ldap_call > > 273. e.args[0]['info'] = strerror(e.args[0]['errno']) > > > > Exception Type: KeyError at /login/ > > Exception Value: u'errno' > > The error you experienced was fixed in 2.4.37 as noted in CHANGES (see the > Lib/ldap/ diff > from 2.4.35 to 2.4.38 attached below). Are you sure that you have tested a > clean > installation of 2.4.38 in your virtualenv? I suspect that your downgrade > to 2.4.37 has > overwritten some left-overs from 2.4.35 installation. > > Ciao, Michael. > > ---------------------------------- snip ------------------------------ > ------ > --- python-ldap-2.4.35/Lib/ldap/__init__.py 2017-04-25 > 15:52:48.000000000 +0200 > +++ python-ldap-2.4.38/Lib/ldap/__init__.py 2017-04-27 > 13:11:01.000000000 +0200 > @@ -3,12 +3,12 @@ > > See http://www.python-ldap.org/ for details. > > -$Id: __init__.py,v 1.113 2017/04/25 13:52:48 stroeder Exp $ > +$Id: __init__.py,v 1.116 2017/04/27 11:11:01 stroeder Exp $ > """ > > # This is also the overall release version number > > -__version__ = '2.4.35' > +__version__ = '2.4.38' > > import sys > > diff -ur python-ldap-2.4.35/Lib/ldap/ldapobject.py > python-ldap-2.4.38/Lib/ldap/ldapobject.py > --- python-ldap-2.4.35/Lib/ldap/ldapobject.py 2017-04-25 > 15:44:47.000000000 +0200 > +++ python-ldap-2.4.38/Lib/ldap/ldapobject.py 2017-04-27 > 10:40:10.000000000 +0200 > @@ -3,7 +3,7 @@ > > See http://www.python-ldap.org/ for details. > > -\$Id: ldapobject.py,v 1.160 2017/04/25 13:40:52 stroeder Exp $ > +\$Id: ldapobject.py,v 1.162 2017/04/27 08:40:10 stroeder Exp $ > > Compability: > - Tested with Python 2.0+ but should work with Python 1.5.x > @@ -111,9 +111,9 @@ > diagnostic_message_success = self._l.get_option(ldap.OPT_ > DIAGNOSTIC_MESSAGE) > finally: > self._ldap_object_lock.release() > - except LDAPError,e: > - if 'info' not in e.args[0]: > - e.args[0]['info'] = strerror(e.args[0]['errno']) > + except LDAPError, e: > + if not e.args[0].has_key('info') and e.args[0].has_key('errno'): > + e.args[0]['info'] = strerror(e.args[0]['errno']) > if __debug__ and self._trace_level>=2: > self._trace_file.write('=> LDAPError - %s: %s\n' % > (e.__class__.__name__,str(e))) > raise > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Fri May 26 04:25:04 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Fri, 26 May 2017 10:25:04 +0200 Subject: [python-ldap] [BUG] KeyError on 'errno' In-Reply-To: References: Message-ID: <403d5e68-42af-fdd0-f4df-f86cb3699160@stroeder.com> Matt Bosworth wrote: > It appears that pyldap and python-ldap are stomping on each other. I'm using > django-auth-ldap, which pulls in python-ldap, but I'm also pulling in pyldap from > another (internal) library. And since they both sit in site-packages/ldap/ I > mistakenly thought python-ldap was the issue. Yes, IMO it was a wrong decision by pyldap to use the same 'ldap' module name. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From akkornel at stanford.edu Mon May 29 03:43:00 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Mon, 29 May 2017 07:43:00 +0000 Subject: [python-ldap] syncrepl_poll timeout causing extra IndexError exception Message-ID: <799E8EC0-CA04-4906-A03F-7EC71BBAF46A@stanford.edu> Hello! I would like to report a syncrepl-related issue with python-ldap 2.4.38, running in Python 2.7.13, on Mac OS X. The OpenLDAP library is 2.4.44. It seems like the `timeout` parameter in syncrepl_poll() is causing an unexpected exception (that is, not a timeout). Here is the situation: I am doing syncrepl in ?refreshAndPersist? mode. My code is subclassing the SyncreplConsumer and SimpleLDAPObject classes. The code is successfully able to go through the refresh phase, and syncrepl_refreshdone() is called. The exception occurs when I make the first call to syncrepl_poll() in the refresh phase. Here is the exception and traceback: Traceback (most recent call last): File "demo.py", line 62, in loop_result = client.poll() File "/Users/akkornel/git/syncrepl/syncrepl_client/__init__.py", line 400, in poll all=1, timeout=3) File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/ldap/syncrepl.py", line 352, in syncrepl_poll add_intermediates=1, add_ctrls=1, all = 0 File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/ldap/ldapobject.py", line 523, in result4 ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/ldap/ldapobject.py", line 115, in _ldap_call if not e.args[0].has_key('info') and e.args[0].has_key('errno'): IndexError: tuple index out of range I turned up trace_level to 9, deleted all temporary files (to ensure a full sync) and then ran again. Here is the last portion of the output: ===== OUTPUT START ===== => result: (121, [('1.3.6.1.4.1.4203.1.9.1.4', '\xa16\x044rid=000,csn=20170529043510.977702Z#000000#000#000000', [])], 5, []) REFRESH COMPLETE! *** ldap://directory-master.stanford.edu/cn%3Dpeople%2Cdc%3Dstanford%2Cdc%3Dedu??one?%28suPrivilegeGroup%3Dresearch-computing%3A%2A%29?bindname=GSSAPI - Syncrepl.result4 ((5, 0, 3, 1, 1, 0), {}) File "demo.py", line 62, in loop_result = client.poll() File "/Users/akkornel/git/syncrepl/syncrepl_client/__init__.py", line 400, in poll all=1, timeout=3) File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/ldap/syncrepl.py", line 352, in syncrepl_poll add_intermediates=1, add_ctrls=1, all = 0 File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/ldap/ldapobject.py", line 523, in result4 ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/ldap/ldapobject.py", line 104, in _ldap_call traceback.print_stack(limit=self._trace_stack_limit,file=self._trace_file) Traceback (most recent call last): File "demo.py", line 62, in loop_result = client.poll() File "/Users/akkornel/git/syncrepl/syncrepl_client/__init__.py", line 400, in poll all=1, timeout=3) File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/ldap/syncrepl.py", line 352, in syncrepl_poll add_intermediates=1, add_ctrls=1, all = 0 File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/ldap/ldapobject.py", line 523, in result4 ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/ldap/ldapobject.py", line 115, in _ldap_call if not e.args[0].has_key('info') and e.args[0].has_key('errno'): IndexError: tuple index out of range *** ldap://directory-master.stanford.edu/cn%3Dpeople%2Cdc%3Dstanford%2Cdc%3Dedu??one?%28suPrivilegeGroup%3Dresearch-computing%3A%2A%29?bindname=GSSAPI - Syncrepl.unbind_ext ((None, None), {}) File "/Users/akkornel/git/syncrepl/syncrepl_client/__init__.py", line 326, in __del__ return self.unbind() File "/Users/akkornel/git/syncrepl/syncrepl_client/__init__.py", line 320, in unbind return SimpleLDAPObject.unbind(self) File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/ldap/ldapobject.py", line 649, in unbind return self.unbind_ext(None,None) File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/ldap/ldapobject.py", line 628, in unbind_ext res = self._ldap_call(self._l.unbind_ext,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls)) File "/Users/akkornel/Library/Python/2.7/lib/python/site-packages/ldap/ldapobject.py", line 104, in _ldap_call traceback.print_stack(limit=self._trace_stack_limit,file=self._trace_file) => result: None ===== OUTPUT END ===== The ?REFRESH COMPLETE!? message is my code inside of syncrepl_refreshdone(). I am calling syncrepl_poll() with `all=1` and `timeout=3`. If I remove the `timeout` parameter, the crash does not happen. Of course, syncrepl_poll() hangs, but I expect that here. So, next I removed the `all` parameter, and put `timeout` back in. In other words, I am calling syncrepl_poll() with just `timeout=3`. That gives me the same exception as before. Finally, I removed the `timeout` parameter again, so now I am calling syncrepl_poll() without any extra parameters (the only parameter is `msgid`). This time, syncrepl_poll() again works, but it regularly hangs when there are no changes. So, it seems to me that there is a problem when using timeout: The LDAP operations is allowed to time out, but the timeout is not identified as a timeout. If you have any questions for me, please let me know! -- A. Karl Kornel | System Administrator Research Computing | Stanford University +1 (650) 736-9327 From michael at stroeder.com Mon May 29 04:38:56 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 29 May 2017 10:38:56 +0200 Subject: [python-ldap] syncrepl_poll timeout causing extra IndexError exception In-Reply-To: <799E8EC0-CA04-4906-A03F-7EC71BBAF46A@stanford.edu> References: <799E8EC0-CA04-4906-A03F-7EC71BBAF46A@stanford.edu> Message-ID: Karl Kornel wrote: > I would like to report a syncrepl-related issue with python-ldap 2.4.38, running in > Python 2.7.13, on Mac OS X. The OpenLDAP library is 2.4.44. It seems like the > `timeout` parameter in syncrepl_poll() is causing an unexpected exception (that is, > not a timeout). Sigh ? the inconsistent exception raising really sucks. Was the ldap.TIMEOUT caused by a syncrepl provider not reachable in time? Could you come up with a simple test code showing the problem? Ideally as patch to Tests/t_ldapobject.py. Could you please test whether the patch attached below solves this? (It simply masks the IndexError probably raised by e.args[0] not fully populated for the ldap.TIMEOUT exception.) Ciao, Michael. Index: Lib/ldap/ldapobject.py =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Lib/ldap/ldapobject.py,v retrieving revision 1.162 diff -u -r1.162 ldapobject.py --- Lib/ldap/ldapobject.py 27 Apr 2017 08:40:10 -0000 1.162 +++ Lib/ldap/ldapobject.py 29 May 2017 08:34:10 -0000 @@ -112,8 +112,11 @@ finally: self._ldap_object_lock.release() except LDAPError, e: - if not e.args[0].has_key('info') and e.args[0].has_key('errno'): + try: + if not e.args[0].has_key('info') and e.args[0].has_key('errno'): e.args[0]['info'] = strerror(e.args[0]['errno']) + except IndexError: + pass if __debug__ and self._trace_level>=2: self._trace_file.write('=> LDAPError - %s: %s\n' % (e.__class__.__name__,str(e))) raise -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Wed May 31 08:38:25 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 31 May 2017 14:38:25 +0200 Subject: [python-ldap] ANN: python-ldap 2.4.39 Message-ID: <003dfd52-1b74-a9f8-0444-da3d7a923d0c@stroeder.com> Find a new release of python-ldap: https://pypi.python.org/pypi/python-ldap/2.4.39 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, LDAP URLs and LDAPv3 schema). Project's web site: https://www.python-ldap.org/ Ciao, Michael. ---------------------------------------------------------------- Released 2.4.39 2017-05-31 Changes since 2.4.38: Lib/ * fixed errno-related ldap.TIMEOUT regression Lib/slapdtest.py * Removed obsolete assert statements ---------------------------------------------------------------- Released 2.4.38 2017-04-28 Changes since 2.4.37: Lib/slapdtest.py * SlapdObject now evaluates env var SLAPD for optionally pointing to OpenLDAP's slapd executable (e.g. with OpenLDAP LTB builds) * added LDAPI support in slaptest.SlapdObject which is internally used in methods ldapadd() and ldapwhoami() * added method slaptest.SlapdObject.ldapmodify() * fixed enabling logger in slaptest * directory name now contains port to be able to run several SlapdObject instances side-by-side (e.g. with replication) * added authz-regexp mapping to rootdn for user running the test * internally use SASL/EXTERNAL via LDAPI to bind * SlapdObject.server_id used as serverID in slapd.conf for MMR * Removed method SlapdObject.started() because SlapdTestCase.setUpClass() will be used to add initial entries Tests/ * ReconnectLDAPObject is also tested by sub-classing test class -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From akkornel at stanford.edu Sun Jun 4 17:26:03 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Sun, 4 Jun 2017 21:26:03 +0000 Subject: [python-ldap] How to get the python-ldap test suite working in Ubuntu 16.10 Message-ID: Hello! I was just working on getting the python-ldap test suite working on an Ubuntu 16.10 (yakkety) VM, and I wanted to let people know the changes I needed to make, so that the test suite would work. Assuming that you are already able to build and install python-ldap, you need to DO four more things to get the test suite working: DO: Install the `slapd` package. Python-ldap starts an instance of slapd in order to run tests. So, you need slapd support! During installation, you will be asked to choose an LDAP administrator password. This can be anything you want, and it is _not_ needed for python-ldap tests, so you can make it random if you want. DO: After installing slapd, disable it by running `systemctl stop slapd` and `systemctl disable slapd`. Even though you need slapd, it doesn?t need to be running as a service. So, let?s stop and disable it! This is especially important if you are running this on a system that is not restricted. In my case, I?m running it as a Virtual Box VM behind a NAT. In your case, you might be running it on a server that is more open. DO: Make a symlink from /etc/openldap to /etc/ldap The test suite expects to find core schema files in /etc/openldap/schema, but Ubuntu installs to /etc/ldap. So, make a symlink! DO: Put the python-ldap source directory into /var/tmp For example, let?s say you wanted to run a single test suite. You could do so with this command: PYTHONPATH=../Lib LOGLEVEL=4 python2.7 ./t_cext.py When run from inside the ?Tests? directory, that runs the t_cext.py test suite. For some test suites, this will work, but others will fail with this exception: > RuntimeError: configuration test failed The reason for this is, python-ldap is asking slapd to open a local socket file in a non-standard directory (for testing), and AppArmor is preventing this. So, the server dies during startup, and python-ldap interprets this as a configuration issue. One solution would be to modify slapd?s AppArmor profile (it lives in /etc/apparmor.d/usr.sbin.slapd), but the easier thing to do is to run things from inside /var/tmp. That is because there is an existing rule allowing writing to sub-directories of /var/tmp. So, just move your entire python-ldap directory into /var/tmp, and run from there: cd /var/tmp mv ~/python-ldap-2.4.39 . cd python-ldap-2.4.39 LOGLEVEL=4 python2.7 setup.py test With the above 4 commands, all 94 tests run fine! -- A. Karl Kornel | System Administrator Research Computing | Stanford University +1 (650) 736-9327 -------------- next part -------------- An HTML attachment was scrubbed... URL: From akkornel at stanford.edu Sun Jun 4 23:37:15 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Mon, 5 Jun 2017 03:37:15 +0000 Subject: [python-ldap] syncrepl_poll timeout causing extra IndexError exception In-Reply-To: References: <799E8EC0-CA04-4906-A03F-7EC71BBAF46A@stanford.edu> Message-ID: <9C762E52-A06D-4CE0-9495-1AF1C4829D23@stanford.edu> Sorry for the delay! It?s really hard doing intensive work on this during the week. On 5/29/17, 1:38 AM, "Michael Str?der" wrote: > >Karl Kornel wrote: >> I would like to report a syncrepl-related issue with python-ldap 2.4.38, running in >> Python 2.7.13, on Mac OS X. The OpenLDAP library is 2.4.44. It seems like the >> `timeout` parameter in syncrepl_poll() is causing an unexpected exception (that is, >> not a timeout). > >Sigh ? the inconsistent exception raising really sucks. > >Was the ldap.TIMEOUT caused by a syncrepl provider not reachable in time? In this case, the ldap.TIMEOUT was expected to happen. It happens because of the way syncrepl works. One of the modes of syncrepl operation is ?refresh and persist? mode. In this mode, once your client is brought up-to-date, you will have a long-running search operation open. The behavior of the search operation is performed using ldap.syncrepl.SyncreplConsumer.syncrepl_poll, and it depends on the parameter ?timeout?. If the syncrepl_poll ?timeout? parameter is set to a number, and no changes come in before the timeout, then an ldap.TIMEOUT exception will be raised. This is useful for several cases, including: * In single-threaded code, it lets us do extra work when the LDAP server has no changes pending. If we left ?timeout? at ?None?, then our thread would pause forever (or until the connection dies for some reason). * If we want to cancel the syncrepl search (using the cancel method), then we need to wait for the poll to timeout, because I don?t think we can call the cancel method on an LDAP connection that has an operation in progress. So, we need to wait for the operation to return a result (if something on the server updates), or we need to wait for the timeout. > >Could you come up with a simple test code showing the problem? >Ideally as patch to Tests/t_ldapobject.py. Sure! Since ldap.syncrepl is a separate module, I have created a new test script that you can add into the Tests directory. I am attaching two files to this email: * slapdtest.py.patch is a unified diff of changes that need to be made to slapdtest.py, so that the OpenLDAP server (slapd) is able to generate and store the information needed for syncrepl to work. * t_syncrepl.py is a test script that can go directly into the Tests directory. I tried to follow your style, in terms of how to set up the test. Feel free to make changes! I think it is safe to apply these changes, for two reasons: 1. The syncprov module is part of a normal OpenLDAP distribution, so It should be safe to load and configure. 2. Although ldap.syncrepl requires pyasn1, the test suite checks for this: If pyasn1 is not present, all of the syncrepl tests are skipped. NOTE: As I mentioned in the test script, there are still five tests to implement. At least, five more tests that I can think of so far. If the test script looks good, then I can add the rest of the tests. Otherwise, if you want to make changes, then I will wait until you check t_syncrepl.py into CVS, then I will modify that file. >Could you please test whether the patch attached below solves this? >(It simply masks the IndexError probably raised by e.args[0] not fully populated for the >ldap.TIMEOUT exception.) > I ran the attached tests on python-syncrepl 2.4.39, and unfortunately the timeout test still failed. But now, you should be able to run the tests yourself! ~ Karl -------------- next part -------------- A non-text attachment was scrubbed... Name: slapdtest.py.patch Type: application/octet-stream Size: 526 bytes Desc: slapdtest.py.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t_syncrepl.py Type: text/x-python-script Size: 12812 bytes Desc: t_syncrepl.py URL: From akkornel at stanford.edu Mon Jun 5 00:15:41 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Mon, 5 Jun 2017 04:15:41 +0000 Subject: [python-ldap] Patch: ldap.syncrepl UUID constructors use bytes (Python 3 compatbility) Message-ID: <0FE49176-53F3-46EB-AFE6-CB3328923E35@stanford.edu> Hello! I have a patch for python-ldap?s syncrepl.py. This is specially a patch for Python 3 support in syncrepl. Even though python-ldap does not have Python 3 support, I noticed that python-ldap has not made any changes to syncrepl.py. So, I tested this code first in python-ldap 2.4.35.1. I then tested the code using python-ldap 2.4.39. I also used my t_syncrepl.py test script, and the tests pass. The problem is this: In Python 3, the UUID class constructor?s ?bytes? input requires that you provide a bytes object. In Python 3, the current syncrepl code gives an exception like this: ? snip part of the traceback ? File "/Users/akkornel/Library/Python/3.6/lib/python/site-packages/ldap/syncrepl.py", line 135, in decodeControlValue uuid = UUID(bytes=d[0].getComponentByName('entryUUID')) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/uuid.py", line 150, in __init__ assert isinstance(bytes, bytes_), repr(bytes) AssertionError: syncUUID(hexValue='25a19266b609102b8a810bcc11d0e1be') Since Python 3 strings are Unicode by default, passing strings as ?bytes? does not work anymore. There are two places where UUID objects are constructed; in both places, my patch wraps the string value in a ?bytes? call. I was originally thinking of sending this to python-ldap directly, but this change seems like a no-op on Python 2.7, so I decided to send it in here! This patch also works on test code I have in development (https://github.com/akkornel/syncrepl), running on Python 2.7 with python-ldap 2.4.38. But, I understand that you might not want to accept this until the t_syncrepl.py is more complete. I think that?s it. Please let me know your questions and comments! -- A. Karl Kornel | System Administrator Research Computing | Stanford University +1 (650) 736-9327 -------------- next part -------------- A non-text attachment was scrubbed... Name: syncrepl.py.diff Type: application/octet-stream Size: 1110 bytes Desc: syncrepl.py.diff URL: From michael at stroeder.com Mon Jun 5 05:10:35 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 5 Jun 2017 11:10:35 +0200 Subject: [python-ldap] How to get the python-ldap test suite working in Ubuntu 16.10 In-Reply-To: References: Message-ID: <7e867a11-a961-ef05-d135-46b50a63f2d9@stroeder.com> Karl, Karl Kornel wrote: > I was just working on getting the python-ldap test suite working on an Ubuntu 16.10 > (yakkety) VM, and I wanted to let people know the changes I needed to make, so that the > test suite would work. since 2.4.37 you should get it working without path changes and symbolic links by just setting env vars. At least I got it working on one Ubuntu box one time. This is not yet documented. But you can easily find out about the env vars used by looking at how the class attributes of SlapdObject are initially set: TMPDIR = os.environ.get('TMP', os.getcwd()) SBINDIR = os.environ.get('SBIN', '/usr/sbin') BINDIR = os.environ.get('BIN', '/usr/bin') SCHEMADIR = os.environ.get('SCHEMA', '/etc/openldap/schema') INIT_SCHEMA_FILE = os.environ.get('SCHEMA_FILE', 'core.schema') INIT_SCHEMA_PATH = os.environ.get('SCHEMA_PATH', os.path.join(SCHEMADIR, INIT_SCHEMA_FILE)) PATH_LDAPADD = os.path.join(BINDIR, 'ldapadd') PATH_LDAPMODIFY = os.path.join(BINDIR, 'ldapmodify') PATH_LDAPWHOAMI = os.path.join(BINDIR, 'ldapwhoami') PATH_SLAPD = os.environ.get('SLAPD', os.path.join(SBINDIR, 'slapd')) PATH_SLAPTEST = os.path.join(SBINDIR, 'slaptest') Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Mon Jun 5 05:24:55 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 5 Jun 2017 11:24:55 +0200 Subject: [python-ldap] Patch: ldap.syncrepl UUID constructors use bytes (Python 3 compatbility) In-Reply-To: <0FE49176-53F3-46EB-AFE6-CB3328923E35@stanford.edu> References: <0FE49176-53F3-46EB-AFE6-CB3328923E35@stanford.edu> Message-ID: Karl Kornel wrote: > The problem is this: In Python 3, the UUID class constructor?s ?bytes? input requires > that you provide a bytes object. > [..] > This patch also works on test code I have in development > (https://github.com/akkornel/syncrepl), running on Python 2.7 with python-ldap 2.4.38. > But, I understand that you might not want to accept this until the t_syncrepl.py is > more complete. Thanks for your submission. AFAIK the built-in function bytes() was introduced in Python 2.6. So unfortunately this raises a question about back-ward compability to older Python versions. Which versions of Python 2.x still have to be supported by today's python-ldap? Yes, I know. We could do something like: try: bytes except NameError: bytes = str But I'm not sure whether it makes sense to add compability kludges into python-ldap. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From trs80 at ucc.asn.au Mon Jun 5 10:50:27 2017 From: trs80 at ucc.asn.au (James Andrewartha) Date: Mon, 5 Jun 2017 22:50:27 +0800 (AWST) Subject: [python-ldap] Patch: ldap.syncrepl UUID constructors use bytes (Python 3 compatbility) In-Reply-To: References: <0FE49176-53F3-46EB-AFE6-CB3328923E35@stanford.edu> Message-ID: On Mon, 5 Jun 2017, Michael Str?der wrote: > AFAIK the built-in function bytes() was introduced in Python 2.6. So unfortunately this > raises a question about back-ward compability to older Python versions. > > Which versions of Python 2.x still have to be supported by today's python-ldap? RHEL 6 shipped with Python 2.6 in 2010, that is the oldest distro I'd reasonably expect to be supported today. You could argue for 2.7 since that was also released in 2010 and is easily availble for RHEL 6. -- # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ # UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best | [ "There's nobody getting rich writing ]| -- Collect and hide your | [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / From jamesa at daa.com.au Mon Jun 5 11:01:44 2017 From: jamesa at daa.com.au (James Andrewartha) Date: Mon, 5 Jun 2017 23:01:44 +0800 (AWST) Subject: [python-ldap] Patch: ldap.syncrepl UUID constructors use bytes (Python 3 compatbility) In-Reply-To: References: <0FE49176-53F3-46EB-AFE6-CB3328923E35@stanford.edu> Message-ID: On Mon, 5 Jun 2017, Michael Str?der wrote: > AFAIK the built-in function bytes() was introduced in Python 2.6. So unfortunately this > raises a question about back-ward compability to older Python versions. > > Which versions of Python 2.x still have to be supported by today's python-ldap? RHEL 6 shipped with Python 2.6 in 2010, that is the oldest distro I'd reasonably expect to be supported today. You could argue for 2.7 since that was also released in 2010 and is easily availble for RHEL 6. [apologies to Michael and Karl for three copies - I forgot I was subscribed from an email address that is forwarded elsewhere] -- # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ # UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best | [ "There's nobody getting rich writing ]| -- Collect and hide your | [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / From akkornel at stanford.edu Mon Jun 5 21:12:59 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Tue, 6 Jun 2017 01:12:59 +0000 Subject: [python-ldap] Patch: ldap.syncrepl UUID constructors use bytes (Python 3 compatbility) In-Reply-To: References: <0FE49176-53F3-46EB-AFE6-CB3328923E35@stanford.edu> Message-ID: <4A59771C-B10C-471E-A5FC-0E34703E92EC@stanford.edu> On 6/5/17, 8:01 AM, "James Andrewartha" wrote: On Mon, 5 Jun 2017, Michael Str?der wrote: > AFAIK the built-in function bytes() was introduced in Python 2.6. So unfortunately this > raises a question about back-ward compability to older Python versions. > > Which versions of Python 2.x still have to be supported by today's python-ldap? RHEL 6 shipped with Python 2.6 in 2010, that is the oldest distro I'd reasonably expect to be supported today. You could argue for 2.7 since that was also released in 2010 and is easily availble for RHEL 6. [apologies to Michael and Karl for three copies - I forgot I was subscribed from an email address that is forwarded elsewhere] -- # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ # UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best | [ "There's nobody getting rich writing ]| -- Collect and hide your | [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / That?s a good question. I have looked around, and have come up with a summary of major Linux distributions, the current Python 2 version being shipped, and the expected end-of-life date for the oldest supported OS version. By ?major Linux distributions?, I mean: RHEL, Debian, Ubuntu, Slackware, Gentoo, and Arch. Note that I do not list derivative distributions, except for Ubuntu (since Ubuntu makes so many changes from Debian). That means I don?t list (for example) CentOS or Oracle Linux, since they are derivatives of RHEL. Apologies if I missed a distro! The executive summary is, for the major Linux distros, the oldest supported releases come with some version of Python 2.6. If you want to only support Python 2.7, then you have to drop RHEL 6 and Slackware 13.x, but the rest of the releases are OK. Here are the full results: ? RHEL: RHEL 5 has gone ?End of Production?, so the only people getting support (until 30 Nov. 2020) are those who paid for the Extended Life-cycle support [7]. That means the oldest RHEL under general support is RHEL 6. The current python 2 version in RHEL 6 is version 2.6.6-66.el6_8 [15]. RHEL 7 currently has python 2 version 2.7.5-48 [15]. ? Debian: The oldest supported Debian is 7 (wheezy), which is under support until end of May 2018 [6]. The current python 2 version in Debian wheezy is 2.7.3-4+deb7u1 [5]. ? Ubuntu: The oldest support Ubuntu is 14.04 LTS (Trusty), which is under support until April 2019 [4]. The current python 2 version in Ubuntu Trusty is 2.7.6-8ubuntu0.3 [3]. ? Slackware: According to [12], the oldest supported Slackware is 13.0 (released 26 August 2009), simple because no EOL has been announced. I haven?t used Slackware, and it seems that the EOL policy is ?when people stop posting updates? [13]. The Python 2 version in Slackware 13.0 is 2.6.2 [11]. I also checked, and the oldest Slackware to come with Python 2.7 is Slackware 14.0 (released 28 September 2012 [12]) that has Python 2.7.3 [14]. ? Gentoo: I haven?t used Gentoo before, but my understanding (from [2]) is that it is updating weekly, and is meant for people to build their own software from source. The current Python 2 version in Gentoo?s package manager is 2.7.12 [1]. ? Arch: Arch Linux puts out a new release every month [9], doing rolling releases similar to Gentoo [10]. The current Python 2 version in Arch?s package manager is 2.7.13-2 [8]. [1]: https://packages.gentoo.org/packages/dev-lang/python [2]: https://en.wikipedia.org/wiki/Gentoo_Linux [3]: https://packages.ubuntu.com/trusty-updates/python2.7 [4]: https://wiki.ubuntu.com/Releases, see the line for Ubuntu 14.04.5 LTS. [5]: https://packages.debian.org/wheezy/python [6]: https://www.debian.org/releases/wheezy/ [7]: https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates [8]: https://www.archlinux.org/packages/extra/x86_64/python2/ [9]: https://www.archlinux.org/releng/releases/ [10]: https://en.wikipedia.org/wiki/Arch_Linux#Rolling_releases [11]: http://www.slackware.com/announce/13.0.php [12]: https://en.wikipedia.org/wiki/Slackware#Releases [13]: http://www.linuxquestions.org/questions/slackware-14/slackware-release-end-of-life-policy-642390/ [14]: http://www.slackware.com/announce/14.0.php [15]: Info pulled from our internal Yum server. ~ Karl From akkornel at stanford.edu Tue Jun 13 11:28:14 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Tue, 13 Jun 2017 15:28:14 +0000 Subject: [python-ldap] Welcome back, python-ldap! Message-ID: <4A1800DF-A658-47E4-89C2-599FE71FB8B0@stanford.edu> Hello! I was preparing to write an email saying ?I notice that python-ldap.org has been down for a few days. Is everything OK?? But I now see that python-ldap.org is back up! I hope everything recovered OK, and I wish you good server stability. -- A. Karl Kornel | System Administrator Research Computing | Stanford University +1 (650) 736-9327 -------------- next part -------------- An HTML attachment was scrubbed... URL: