From michael at stroeder.com Sat Jul 22 03:01:46 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 22 Jul 2017 09:01:46 +0200 Subject: [python-ldap] ANN: python-ldap 2.4.41 Message-ID: <37ebb51b-719f-bf2f-ba79-e2e39bbd5543@stroeder.com> Find a new release of python-ldap: https://pypi.python.org/pypi/python-ldap/2.4.41 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.41 2017-07-12 Changes since 2.4.40: Lib/ * Added support for increment: lines in LDIF changes records ---------------------------------------------------------------- Released 2.4.40 2017-06-27 Changes since 2.4.39: Modules/ * fixed memory leaks when using extended controls (thanks to Erik Cumps) -------------- 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 Fri Aug 11 08:51:16 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Fri, 11 Aug 2017 14:51:16 +0200 Subject: [python-ldap] LDAPCon 2017 programme now online In-Reply-To: <20170811124341.GC25623@slab.skills-1st.co.uk> References: <20170811124341.GC25623@slab.skills-1st.co.uk> Message-ID: HI! The programme for the 2017 LDAP Conference has just been published: https://ldapcon.org/2017/conference-program/ So get your booking in quickly to get early-bird tickets and start thinking about where you want to stay in Brussels! The conference runs 19th and 20th October 2017. Hope to meet some of you folks there. 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 Aug 15 11:31:14 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Tue, 15 Aug 2017 17:31:14 +0200 Subject: [python-ldap] Anyone using python-ldap's dsml module? Message-ID: HI! Is anyone here using the dsml module shipped with python-ldap? Rather I'd like to drop dsml module from python-ldap for these reasons: - it only supports DSMLv1 - AFAIK no-one uses it anyway - it's stand-alone and could be easily shipped as separate module if needed - I have no spare-time maintaining it So if anyone would like use it any longer speak up now. See below the output of static code analyser bandit (see https://pypi.python.org/pypi/bandit) for the reason why I'm asking. I won't spend time for investigating this in detail. Ciao, Michael. -------------------------------------- snip ------------------------------------------- Run started:2017-08-15 15:22:12.836064 Test results: >> Issue: [B406:blacklist] Using xml.sax to parse untrusted XML data is known to be vulnerable to XML attacks. Replace xml.sax with the equivalent defusedxml package, or make sure defusedxml.defuse_stdlib() is called. Severity: Low Confidence: High Location: Lib/dsml.py:153 152 153 import xml.sax,xml.sax.handler 154 -------------------------------------------------- >> Issue: [B317:blacklist] Using xml.sax.make_parser to parse untrusted XML data is known to be vulnerable to XML attacks. Replace xml.sax.make_parser with its defusedxml equivalent function or make sure defusedxml.defuse_stdlib() is called Severity: Medium Confidence: High Location: Lib/dsml.py:279 278 self.records_read = 0 279 self._parser = xml.sax.make_parser() 280 self._parser.setFeature(xml.sax.handler.feature_namespaces,0) -------------- 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 Wed Aug 16 01:53:29 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Wed, 16 Aug 2017 05:53:29 +0000 Subject: [python-ldap] ldap.initialize() URLs must only contain scheme and hostport components: Commas break inside OpenLDAP Message-ID: Hello! I have a documentation issue that I'd like to report, specific to `ldap.initialize()`[1], and the note regarding the URL parameter. The documentation for pyldap says? > Parameter uri has to be a valid LDAP URL. But then, someone who is using my code (which uses pyldap) found an LDAP URL which was throwing a weird exception: > Traceback (most recent call last): > File "syncrepl-client", line 92, in > else SyncreplMode.REFRESH_ONLY > File "/Users/akkornel/git/syncrepl/syncrepl_client/__init__.py", line 411, in __init__ > SimpleLDAPObject.__init__(self, safe_url.unparse(), **kwargs) > File "/Users/akkornel/Library/Python/3.6/lib/python/site-packages/pyldap-2.4.37-py3.6-macosx-10.12-x86_64.egg/ldap/ldapobject.py", line 87, in __init__ > self._l = ldap.functions._ldap_function_call(ldap._ldap_module_lock,_ldap.initialize,uri) > File "/Users/akkornel/Library/Python/3.6/lib/python/site-packages/pyldap-2.4.37-py3.6-macosx-10.12-x86_64.egg/ldap/functions.py", line 66, in _ldap_function_call > result = func(*args,**kwargs) > ldap.LDAPError: (2, 'No such file or directory') I ended up tracing through pyldap, and then into OpenLDAP's code. Eventually, I found the problem: According to OpenLDAP documentation for the `ldap_initialize` function[2]? > The uri parameter may be a comma- or whitespace-separated list of URIs containing only the schema, the host, and the port fields. So, you can pass `ldap_initialize` a "URL" like this: > ldaps://server1:636,ldaps://server2:636 ? and OpenLDAP will accept it (if one URL doesn't work, try the next one, and so on). This only got discovered because the LDAP URL which threw the exception was requesting multiple attributes[3]. That meant the URL included an un-encoded comma, and the OpenLDAP library thought that was a URL separator. I was wondering, would it be possible to change the pyldap documentation, to note the restriction on LDAP URLs? Here's a diff of my proposed changes, for each application: Index: Doc/ldap.rst =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Doc/ldap.rst,v retrieving revision 1.34 diff -u -r1.34 ldap.rst --- Doc/ldap.rst 24 Jul 2016 16:12:55 -0000 1.34 +++ Doc/ldap.rst 16 Aug 2017 05:49:59 -0000 @@ -35,7 +35,8 @@ Initializes a new connection object for accessing the given LDAP server, and return an LDAP object (see :ref:`ldap-objects`) used to perform operations - on that server. Parameter *uri* has to be a valid LDAP URL. + on that server. Parameter *uri* has to be a valid LDAP URL containing + *only* the scheme and hostport components. Note that the C wrapper function :py:func:_ldap.initialize() is called which calls the OpenLDAP funtion ldap_initialize(). Calling this function just initializes Index: Lib/ldap/functions.py =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Lib/ldap/functions.py,v retrieving revision 1.34 diff -u -r1.34 functions.py --- Lib/ldap/functions.py 15 Aug 2017 16:21:58 -0000 1.34 +++ Lib/ldap/functions.py 16 Aug 2017 05:49:59 -0000 @@ -83,7 +83,7 @@ Parameters: uri - LDAP URL containing at least connection scheme and hostport, + LDAP URL containing only the connection scheme and hostport, e.g. ldap://localhost:389 trace_level If non-zero a trace output of LDAP calls is generated. Another option would be to modify `ldap.initialize()` to accept any URL, and then pull out only the parts we want. But that seems like it wouldn't be worth it. Please let me know if you have any questions about my request. Thanks very much! [1]:?https://www.python-ldap.org/doc/html/ldap.html#ldap.initialize [2]: https://linux.die.net/man/3/ldap_initialize [3]: https://github.com/akkornel/syncrepl/issues/17 --? ~ A. Karl Kornel, (650) 736-9327 Research Computing University IT, Stanford University From akkornel at stanford.edu Wed Aug 16 01:56:56 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Wed, 16 Aug 2017 05:56:56 +0000 Subject: [python-ldap] Anyone using python-ldap's dsml module? In-Reply-To: References: Message-ID: On Tue, 15 Aug 2017, Michael Str?der said: > HI! > > Is anyone here using the dsml module shipped with python-ldap? > > <<>> I'm not aware of anyone here who uses it. The LDAP admins I know only work with LDIFs. But I'll put the word out; if I don't reply this week, that means nobody here spoke up! --? ~ A. Karl Kornel, (650) 736-9327 Research Computing University IT, Stanford University From michael at stroeder.com Wed Aug 16 04:28:31 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 16 Aug 2017 10:28:31 +0200 Subject: [python-ldap] ldap.initialize() URLs must only contain scheme and hostport components: Commas break inside OpenLDAP In-Reply-To: References: Message-ID: <8fc8c386-c845-1b49-0321-d2458f24536e@stroeder.com> Karl Kornel wrote: > I have a documentation issue that I'd like to report, specific to > `ldap.initialize()`[1], and the note regarding the URL parameter. Thanks for spotting this. > According to OpenLDAP documentation for the `ldap_initialize` function[2]? > >> The uri parameter may be a comma- or whitespace-separated list of URIs containing >> only the schema, the host, and the port fields. > > So, you can pass `ldap_initialize` a "URL" like this: > >> ldaps://server1:636,ldaps://server2:636 Yes. > Here's a diff of my proposed changes, for each application: > - on that server. Parameter *uri* has to be a valid LDAP URL. > + on that server. Parameter *uri* has to be a valid LDAP URL containing > + *only* the scheme and hostport components. Hmm, maybe we should just repeat the wording from ldap_initialize(3): "The uri parameter may be a comma- or whitespace-separated list of URIs containing only the schema, the host, and the port fields." > Another option would be to modify `ldap.initialize()` to accept any URL, and then pull > out only the parts we want. But that seems like it wouldn't be worth it. The caller should use ldapurl.LDAPUrl() to parse the full LDAP URL and pass the result of LDAPUrl.initializeUrl() to ldap.initialize(). 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 Wed Aug 16 04:47:25 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Wed, 16 Aug 2017 08:47:25 +0000 Subject: [python-ldap] ldap.initialize() URLs must only contain scheme and hostport components: Commas break inside OpenLDAP In-Reply-To: <8fc8c386-c845-1b49-0321-d2458f24536e@stroeder.com> References: , <8fc8c386-c845-1b49-0321-d2458f24536e@stroeder.com> Message-ID: On Wednesday, August 16, 2017 at 1:28 AM, Michael Str?der said: > <<>> > > Here's a diff of my proposed changes, for each application: > > -?? on that server.? Parameter *uri* has to be a valid LDAP URL. > > +?? on that server.? Parameter *uri* has to be a valid LDAP URL containing > > +?? *only* the scheme and hostport components. > > Hmm, maybe we should just repeat the wording from ldap_initialize(3): > > "The uri parameter may be a comma- or whitespace-separated list of URIs containing only > the schema, the host, and the port fields." I think that would be fine, with one note: For ReconnectLDAPObject, I think it should note what the behavior is when you initialize it with multiple URLs. For example, would it only try to reconnect to the initial URL that is used, or would it re-try all URLs? > > Another option would be to modify `ldap.initialize()` to accept any URL, and then pull > > out only the parts we want.? But that seems like it wouldn't be worth it. > > The caller should use ldapurl.LDAPUrl() to parse the full LDAP URL and pass the result of > LDAPUrl.initializeUrl() to ldap.initialize(). Ah, I was not aware of that method! I don't see it mentioned anywhere in the online ldapurl module documentation, so I didn't know it was there. > Ciao, Michael. Thanks very much! ~ Karl From michael at stroeder.com Wed Aug 16 06:39:56 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 16 Aug 2017 12:39:56 +0200 Subject: [python-ldap] ldap.initialize() URLs must only contain scheme and hostport components: Commas break inside OpenLDAP In-Reply-To: References: <8fc8c386-c845-1b49-0321-d2458f24536e@stroeder.com> Message-ID: <238a5a76-d019-e6ee-bdbf-fa97d7f5378e@stroeder.com> Karl Kornel wrote: > On Wednesday, August 16, 2017 at 1:28 AM, Michael Str?der said: >> Hmm, maybe we should just repeat the wording from ldap_initialize(3): >> >> "The uri parameter may be a comma- or whitespace-separated list of URIs containing >> only the schema, the host, and the port fields." > > I think that would be fine, with one note: For ReconnectLDAPObject, I think it should > note what the behavior is when you initialize it with multiple URLs. For example, > would it only try to reconnect to the initial URL that is used, or would it re-try all > URLs? It simply passes the very same uri value to C wrapper method _ldap.initialize() no matter whether it contains multiple URIs or not. Generally I try to avoid (Reconnect)LDAPObject to be too smart. Therefore I don't recommend passing mutiple comma-/space-separated URIs to ldap.initialize() or ReconnectLDAPObject.__init__() without careful consideration. Because with such an implicit fail-over under the hood you could run into subtle read-after-write issues when accessing multiple writeable replicas (multi-master replication). Recommendations: 1. You can safely use ReconnectLDAPObject with multiple uri values if your application always reads and accepts replication latency (no strictly fresh LDAP data). 2. You should use ReconnectLDAPObject only accessing a single replica for robust write access. Do the fail-over in the calling application if needed/possible so you can reset your process to a well-defined entry point for avoiding read-after-write issues. >> LDAPUrl.initializeUrl() to ldap.initialize(). > > Ah, I was not aware of that method! I don't see it mentioned anywhere in the online > ldapurl module documentation, so I didn't know it was there. Yes, unfortuately the docs are note complete. :-( More doc patches would be highly appreciated. 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 Wed Aug 16 08:03:42 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 16 Aug 2017 14:03:42 +0200 Subject: [python-ldap] ldap.initialize() URLs must only contain scheme and hostport components: Commas break inside OpenLDAP In-Reply-To: References: Message-ID: <6ccd300f-b29d-ae48-2b58-e77e456c9551@stroeder.com> Karl Kornel wrote: > I have a documentation issue that I'd like to report, specific to `ldap.initialize()`[1], and the note regarding the URL parameter. Please review latest changes: https://www.python-ldap.org/doc/html/ldap.html#ldap.initialize 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 Thu Aug 17 03:07:04 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Thu, 17 Aug 2017 07:07:04 +0000 Subject: [python-ldap] ldap.initialize() URLs must only contain scheme and hostport components: Commas break inside OpenLDAP In-Reply-To: <6ccd300f-b29d-ae48-2b58-e77e456c9551@stroeder.com> References: , <6ccd300f-b29d-ae48-2b58-e77e456c9551@stroeder.com> Message-ID: On Wednesday, August 16, 2017 5:03 AM, Michael Str?der said: > Karl Kornel wrote: > > I have a documentation issue that I'd like to report, specific to `ldap.initialize()`[1], and the note regarding the URL parameter. > > Please review latest changes: > > https://www.python-ldap.org/doc/html/ldap.html#ldap.initialize > I've checked it out, and I think it looks good. Thanks very much! ~ Karl From akkornel at stanford.edu Thu Aug 17 03:09:20 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Thu, 17 Aug 2017 07:09:20 +0000 Subject: [python-ldap] ldap.initialize() URLs must only contain scheme and hostport components: Commas break inside OpenLDAP In-Reply-To: <238a5a76-d019-e6ee-bdbf-fa97d7f5378e@stroeder.com> References: <8fc8c386-c845-1b49-0321-d2458f24536e@stroeder.com> , <238a5a76-d019-e6ee-bdbf-fa97d7f5378e@stroeder.com> Message-ID: On Wednesday, August 16, 2017 3:39 AM, Michael Str?der said: > <<>> > > >> LDAPUrl.initializeUrl() to ldap.initialize(). > > > > Ah, I was not aware of that method!? I don't see it mentioned anywhere in the online > > ldapurl module documentation, so I didn't know it was there. > > Yes, unfortuately the docs are note complete. :-( > More doc patches would be highly appreciated. Sure, I will add that to the list of stuff, and come back with docs patches later! ~ Karl From akkornel at stanford.edu Thu Aug 17 03:22:55 2017 From: akkornel at stanford.edu (Karl Kornel) Date: Thu, 17 Aug 2017 07:22:55 +0000 Subject: [python-ldap] pyasn1 recent versions break ldap.syncrepl - What policy should be followed? Message-ID: Hello! In testing my syncrepl code, I have discovered that pyasn1 version 0.3.1 and 0.3.2 have a change in their API, which causes ldap.syncrepl to silently fail. When I say "silently fail", I mean the exceptions pyasn1 generates are mostly ignored, because most of the Syncrepl LDAP controls are not marked critical. I have many more details, including a script to expose the pyasn1 issue, at this URL: https://github.com/akkornel/syncrepl/issues/18 I need to open an issue with pyasn1, which I'll probably do tomorrow. However, before I do that, I have a question: What is the policy regarding supported versions of pyasn1? Here's what I mean: If the author of pyasn1 decides that the new version is not going to be backwards-compatible, then ldap.syncrepl will have to either use the old API, use the new API, or detect the pyasn1 version in real-time. Which policy be preferred? For reference, Debian jessie (the current oldstable) has pyasn1 version 0.1.7. All other active Debian distributions have version 0.1.9. CentOS 6 has version 0.0.12a; CentOS 7 has version 0.1.8. Fedora 22 has version 0.1.7 (with patches). MacPorts has version 0.2.2. So, to maintain support with most packages, the policy would have to be "use the old API" or "detect the version". One other possibility is, the pyasn1 author fixes the issue, so that ldap.syncrepl works again. As for my opinion, I am not sure. I want to wait to hear from the pyasn1 author, to see if this is something which is going to be a breaking change. So, what should be the direction? --? ~ A. Karl Kornel, (650) 736-9327 Research Computing University IT, Stanford University From ilya at glas.net Thu Aug 17 05:31:48 2017 From: ilya at glas.net (Ilya Etingof) Date: Thu, 17 Aug 2017 11:31:48 +0200 Subject: [python-ldap] pyasn1 recent versions break ldap.syncrepl - What policy should be followed? In-Reply-To: References: Message-ID: Hi Karl, I've proposed a (hopefully) easy fix to the syncrepl code to make it compatible with all pyasn1 versions: https://github.com/akkornel/syncrepl/issues/18 On 08/17/2017 09:22 AM, Karl Kornel wrote: > Hello! > > In testing my syncrepl code, I have discovered that pyasn1 version 0.3.1 and 0.3.2 have a change in their API, which causes ldap.syncrepl to silently fail. > > When I say "silently fail", I mean the exceptions pyasn1 generates are mostly ignored, because most of the Syncrepl LDAP controls are not marked critical. > > I have many more details, including a script to expose the pyasn1 issue, at this URL: > > https://github.com/akkornel/syncrepl/issues/18 > > I need to open an issue with pyasn1, which I'll probably do tomorrow. However, before I do that, I have a question: What is the policy regarding supported versions of pyasn1? > > Here's what I mean: If the author of pyasn1 decides that the new version is not going to be backwards-compatible, then ldap.syncrepl will have to either use the old API, use the new API, or detect the pyasn1 version in real-time. > > Which policy be preferred? > > For reference, Debian jessie (the current oldstable) has pyasn1 version 0.1.7. All other active Debian distributions have version 0.1.9. CentOS 6 has version 0.0.12a; CentOS 7 has version 0.1.8. Fedora 22 has version 0.1.7 (with patches). MacPorts has version 0.2.2. > > So, to maintain support with most packages, the policy would have to be "use the old API" or "detect the version". > > One other possibility is, the pyasn1 author fixes the issue, so that ldap.syncrepl works again. > > As for my opinion, I am not sure. I want to wait to hear from the pyasn1 author, to see if this is something which is going to be a breaking change. > > So, what should be the direction? > > -- > ~ A. Karl Kornel, (650) 736-9327 > Research Computing > University IT, Stanford University > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > https://mail.python.org/mailman/listinfo/python-ldap > From michael at stroeder.com Sat Aug 19 16:02:09 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Sat, 19 Aug 2017 22:02:09 +0200 Subject: [python-ldap] pyasn1 recent versions break ldap.syncrepl - What policy should be followed? In-Reply-To: References: Message-ID: Ilya Etingof wrote: > I've proposed a (hopefully) easy fix to the syncrepl code to make it > compatible with all pyasn1 versions: > > https://github.com/akkornel/syncrepl/issues/18 Hmm, I'd strongly prefer follow-ups to go to python-ldap mailing list so it's archived to non-proprietary and freely accessible mbox archive. 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 Helen_He at symantec.com Tue Aug 29 22:18:04 2017 From: Helen_He at symantec.com (Helen He) Date: Wed, 30 Aug 2017 02:18:04 +0000 Subject: [python-ldap] django-ldap Installation Error. Please Help!!! Thank you very much!!! Message-ID: Python 3.5 error modules\errors.h(8): fatal error C1083: Cannot open include file: 'lber.h': No such file or directory c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>pip.exe install "c:\Users\Administrator\Downloads\django_auth_lda p-1.2.15-py3-none-any.whl" Processing c:\users\administrator\downloads\django_auth_ldap-1.2.15-py3-none-any.whl Requirement already satisfied: django in c:\program files (x86)\python\python35-32\lib\site-packages (from django-auth-l dap==1.2.15) Collecting pyldap (from django-auth-ldap==1.2.15) Using cached pyldap-2.4.37.tar.gz Requirement already satisfied: setuptools in c:\program files (x86)\python\python35-32\lib\site-packages (from pyldap->d jango-auth-ldap==1.2.15) Installing collected packages: pyldap, django-auth-ldap Running setup.py install for pyldap ... error Complete output from command "c:\program files (x86)\python\python35-32\python.exe" -u -c "import setuptools, tokeni ze;__file__='C:\\TEMP\\pip-build-maui6ppt\\pyldap\\setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().r eplace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record C:\TEMP\pip-wi6dunu5-record\insta ll-record.txt --single-version-externally-managed --compile: defines: HAVE_SASL HAVE_TLS HAVE_LIBLDAP_R extra_compile_args: extra_objects: include_dirs: /usr/include /usr/include/sasl /usr/local/include /usr/local/include/sasl library_dirs: /usr/lib /usr/lib64 /usr/local/lib /usr/local/lib64 libs: ldap_r running install running build running build_py file Lib\ldap.py (for module ldap) not found file Lib\ldap\controls.py (for module ldap.controls) not found file Lib\ldap\extop.py (for module ldap.extop) not found file Lib\ldap\schema.py (for module ldap.schema) not found creating build\lib.win32-3.5 copying Lib\ldapurl.py -> build\lib.win32-3.5 copying Lib\ldif.py -> build\lib.win32-3.5 copying Lib\dsml.py -> build\lib.win32-3.5 copying Lib\slapdtest.py -> build\lib.win32-3.5 creating build\lib.win32-3.5\ldap copying Lib\ldap\__init__.py -> build\lib.win32-3.5\ldap copying Lib\ldap\async.py -> build\lib.win32-3.5\ldap copying Lib\ldap\compat.py -> build\lib.win32-3.5\ldap creating build\lib.win32-3.5\ldap\controls copying Lib\ldap\controls\__init__.py -> build\lib.win32-3.5\ldap\controls copying Lib\ldap\controls\deref.py -> build\lib.win32-3.5\ldap\controls copying Lib\ldap\controls\libldap.py -> build\lib.win32-3.5\ldap\controls copying Lib\ldap\controls\openldap.py -> build\lib.win32-3.5\ldap\controls copying Lib\ldap\controls\ppolicy.py -> build\lib.win32-3.5\ldap\controls copying Lib\ldap\controls\psearch.py -> build\lib.win32-3.5\ldap\controls copying Lib\ldap\controls\pwdpolicy.py -> build\lib.win32-3.5\ldap\controls copying Lib\ldap\controls\readentry.py -> build\lib.win32-3.5\ldap\controls copying Lib\ldap\controls\sessiontrack.py -> build\lib.win32-3.5\ldap\controls copying Lib\ldap\controls\simple.py -> build\lib.win32-3.5\ldap\controls copying Lib\ldap\controls\sss.py -> build\lib.win32-3.5\ldap\controls copying Lib\ldap\cidict.py -> build\lib.win32-3.5\ldap copying Lib\ldap\dn.py -> build\lib.win32-3.5\ldap creating build\lib.win32-3.5\ldap\extop copying Lib\ldap\extop\__init__.py -> build\lib.win32-3.5\ldap\extop copying Lib\ldap\extop\dds.py -> build\lib.win32-3.5\ldap\extop copying Lib\ldap\filter.py -> build\lib.win32-3.5\ldap copying Lib\ldap\functions.py -> build\lib.win32-3.5\ldap copying Lib\ldap\ldapobject.py -> build\lib.win32-3.5\ldap copying Lib\ldap\logger.py -> build\lib.win32-3.5\ldap copying Lib\ldap\modlist.py -> build\lib.win32-3.5\ldap copying Lib\ldap\resiter.py -> build\lib.win32-3.5\ldap copying Lib\ldap\sasl.py -> build\lib.win32-3.5\ldap creating build\lib.win32-3.5\ldap\schema copying Lib\ldap\schema\__init__.py -> build\lib.win32-3.5\ldap\schema copying Lib\ldap\schema\models.py -> build\lib.win32-3.5\ldap\schema copying Lib\ldap\schema\subentry.py -> build\lib.win32-3.5\ldap\schema copying Lib\ldap\schema\tokenizer.py -> build\lib.win32-3.5\ldap\schema copying Lib\ldap\syncrepl.py -> build\lib.win32-3.5\ldap file Lib\ldap.py (for module ldap) not found file Lib\ldap\controls.py (for module ldap.controls) not found file Lib\ldap\extop.py (for module ldap.extop) not found file Lib\ldap\schema.py (for module ldap.schema) not found running egg_info writing requirements to Lib\pyldap.egg-info\requires.txt writing Lib\pyldap.egg-info\PKG-INFO writing dependency_links to Lib\pyldap.egg-info\dependency_links.txt writing top-level names to Lib\pyldap.egg-info\top_level.txt warning: manifest_maker: standard file '-c' not found file Lib\ldap.py (for module ldap) not found file Lib\ldap\controls.py (for module ldap.controls) not found file Lib\ldap\extop.py (for module ldap.extop) not found file Lib\ldap\schema.py (for module ldap.schema) not found reading manifest file 'Lib\pyldap.egg-info\SOURCES.txt' reading manifest template 'MANIFEST.in' warning: no files found matching 'Makefile' warning: no files found matching 'Modules\LICENSE' writing manifest file 'Lib\pyldap.egg-info\SOURCES.txt' running build_ext building '_ldap' extension creating build\temp.win32-3.5 creating build\temp.win32-3.5\Release creating build\temp.win32-3.5\Release\Modules C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -DHAVE_SASL -D HAVE_TLS -DHAVE_LIBLDAP_R -DHAVE_LIBLDAP_R -DLDAPMODULE_VERSION=2.4.37 -IModules -I/usr/include -I/usr/include/sasl -I/u sr/local/include -I/usr/local/include/sasl "-Ic:\program files (x86)\python\python35-32\include" "-Ic:\program files (x8 6)\python\python35-32\include" "-IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE" "-IC:\Program Files (x 86)\Windows Kits\10\include\10.0.10240.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um" "-IC:\P rogram Files (x86)\Windows Kits\8.1\include\\shared" "-IC:\Program Files (x86)\Windows Kits\8.1\include\\um" "-IC:\Progr am Files (x86)\Windows Kits\8.1\include\\winrt" "-IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE" "-IC: \Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\in clude\um" "-IC:\Program Files (x86)\Windows Kits\8.1\include\\shared" "-IC:\Program Files (x86)\Windows Kits\8.1\include \\um" "-IC:\Program Files (x86)\Windows Kits\8.1\include\\winrt" /TcModules/LDAPObject.c /Fobuild\temp.win32-3.5\Release \Modules/LDAPObject.obj LDAPObject.c c:\temp\pip-build-maui6ppt\pyldap\modules\errors.h(8): fatal error C1083: Cannot open include file: 'lber.h': No suc h file or directory error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\cl.exe' failed with exit status 2 ---------------------------------------- Command ""c:\program files (x86)\python\python35-32\python.exe" -u -c "import setuptools, tokenize;__file__='C:\\TEMP\\p ip-build-maui6ppt\\pyldap\\setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.c lose();exec(compile(code, __file__, 'exec'))" install --record C:\TEMP\pip-wi6dunu5-record\install-record.txt --single-v ersion-externally-managed --compile" failed with error code 1 in C:\TEMP\pip-build-maui6ppt\pyldap\ c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>pip.exe install "c:\Users\Administrator\Downloads\ldap3-2.3-py2.p y3-none-any.whl" Requirement already satisfied: ldap3==2.3 from file:///C:/Users/Administrator/Downloads/ldap3-2.3-py2.py3-none-any.whl i n c:\program files (x86)\python\python35-32\lib\site-packages Requirement already satisfied: pyasn1>=0.1.8 in c:\program files (x86)\python\python35-32\lib\site-packages (from ldap3= =2.3) c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>pip.exe install "c:\Users\Administrator\Downloads\django_auth_lda p-1.2.15-py3-none-any.whl" -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaoseternal at gmail.com Thu Aug 31 12:23:19 2017 From: chaoseternal at gmail.com (Jun Sheng) Date: Thu, 31 Aug 2017 16:23:19 +0000 Subject: [python-ldap] django-ldap Installation Error. Please Help!!! Thank you very much!!! In-Reply-To: References: Message-ID: I Guess you haven't have ldap related headers and libs installed. consult openldap.org On Fri, Sep 1, 2017 at 12:12 AM Helen He wrote: > Python 3.5 error > > modules\errors.h(8): fatal error C1083: > > Cannot open include file: 'lber.h': No such file or directory > > > > > > > > c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>pip.exe install > "c:\Users\Administrator\Downloads\django_auth_lda > > p-1.2.15-py3-none-any.whl" > > Processing > c:\users\administrator\downloads\django_auth_ldap-1.2.15-py3-none-any.whl > > Requirement already satisfied: django in c:\program files > (x86)\python\python35-32\lib\site-packages (from django-auth-l > > dap==1.2.15) > > Collecting pyldap (from django-auth-ldap==1.2.15) > > Using cached pyldap-2.4.37.tar.gz > > Requirement already satisfied: setuptools in c:\program files > (x86)\python\python35-32\lib\site-packages (from pyldap->d > > jango-auth-ldap==1.2.15) > > Installing collected packages: pyldap, django-auth-ldap > > Running setup.py install for pyldap ... error > > Complete output from command "c:\program files > (x86)\python\python35-32\python.exe" -u -c "import setuptools, tokeni > > ze;__file__='C:\\TEMP\\pip-build-maui6ppt\\pyldap\\setup.py';f=getattr(tokenize, > 'open', open)(__file__);code=f.read().r > > eplace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" > install --record C:\TEMP\pip-wi6dunu5-record\insta > > ll-record.txt --single-version-externally-managed --compile: > > defines: HAVE_SASL HAVE_TLS HAVE_LIBLDAP_R > > extra_compile_args: > > extra_objects: > > include_dirs: /usr/include /usr/include/sasl /usr/local/include > /usr/local/include/sasl > > library_dirs: /usr/lib /usr/lib64 /usr/local/lib /usr/local/lib64 > > libs: ldap_r > > running install > > running build > > running build_py > > file Lib\ldap.py (for module ldap) not found > > file Lib\ldap\controls.py (for module ldap.controls) not found > > file Lib\ldap\extop.py (for module ldap.extop) not found > > file Lib\ldap\schema.py (for module ldap.schema) not found > > creating build\lib.win32-3.5 > > copying Lib\ldapurl.py -> build\lib.win32-3.5 > > copying Lib\ldif.py -> build\lib.win32-3.5 > > copying Lib\dsml.py -> build\lib.win32-3.5 > > copying Lib\slapdtest.py -> build\lib.win32-3.5 > > creating build\lib.win32-3.5\ldap > > copying Lib\ldap\__init__.py -> build\lib.win32-3.5\ldap > > copying Lib\ldap\async.py -> build\lib.win32-3.5\ldap > > copying Lib\ldap\compat.py -> build\lib.win32-3.5\ldap > > creating build\lib.win32-3.5\ldap\controls > > copying Lib\ldap\controls\__init__.py -> > build\lib.win32-3.5\ldap\controls > > copying Lib\ldap\controls\deref.py -> build\lib.win32-3.5\ldap\controls > > copying Lib\ldap\controls\libldap.py -> > build\lib.win32-3.5\ldap\controls > > copying Lib\ldap\controls\openldap.py -> > build\lib.win32-3.5\ldap\controls > > copying Lib\ldap\controls\ppolicy.py -> > build\lib.win32-3.5\ldap\controls > > copying Lib\ldap\controls\psearch.py -> > build\lib.win32-3.5\ldap\controls > > copying Lib\ldap\controls\pwdpolicy.py -> > build\lib.win32-3.5\ldap\controls > > copying Lib\ldap\controls\readentry.py -> > build\lib.win32-3.5\ldap\controls > > copying Lib\ldap\controls\sessiontrack.py -> > build\lib.win32-3.5\ldap\controls > > copying Lib\ldap\controls\simple.py -> > build\lib.win32-3.5\ldap\controls > > copying Lib\ldap\controls\sss.py -> build\lib.win32-3.5\ldap\controls > > copying Lib\ldap\cidict.py -> build\lib.win32-3.5\ldap > > copying Lib\ldap\dn.py -> build\lib.win32-3.5\ldap > > creating build\lib.win32-3.5\ldap\extop > > copying Lib\ldap\extop\__init__.py -> build\lib.win32-3.5\ldap\extop > > copying Lib\ldap\extop\dds.py -> build\lib.win32-3.5\ldap\extop > > copying Lib\ldap\filter.py -> build\lib.win32-3.5\ldap > > copying Lib\ldap\functions.py -> build\lib.win32-3.5\ldap > > copying Lib\ldap\ldapobject.py -> build\lib.win32-3.5\ldap > > copying Lib\ldap\logger.py -> build\lib.win32-3.5\ldap > > copying Lib\ldap\modlist.py -> build\lib.win32-3.5\ldap > > copying Lib\ldap\resiter.py -> build\lib.win32-3.5\ldap > > copying Lib\ldap\sasl.py -> build\lib.win32-3.5\ldap > > creating build\lib.win32-3.5\ldap\schema > > copying Lib\ldap\schema\__init__.py -> build\lib.win32-3.5\ldap\schema > > copying Lib\ldap\schema\models.py -> build\lib.win32-3.5\ldap\schema > > copying Lib\ldap\schema\subentry.py -> build\lib.win32-3.5\ldap\schema > > copying Lib\ldap\schema\tokenizer.py -> build\lib.win32-3.5\ldap\schema > > copying Lib\ldap\syncrepl.py -> build\lib.win32-3.5\ldap > > file Lib\ldap.py (for module ldap) not found > > file Lib\ldap\controls.py (for module ldap.controls) not found > > file Lib\ldap\extop.py (for module ldap.extop) not found > > file Lib\ldap\schema.py (for module ldap.schema) not found > > running egg_info > > writing requirements to Lib\pyldap.egg-info\requires.txt > > writing Lib\pyldap.egg-info\PKG-INFO > > writing dependency_links to Lib\pyldap.egg-info\dependency_links.txt > > writing top-level names to Lib\pyldap.egg-info\top_level.txt > > warning: manifest_maker: standard file '-c' not found > > > > file Lib\ldap.py (for module ldap) not found > > file Lib\ldap\controls.py (for module ldap.controls) not found > > file Lib\ldap\extop.py (for module ldap.extop) not found > > file Lib\ldap\schema.py (for module ldap.schema) not found > > reading manifest file 'Lib\pyldap.egg-info\SOURCES.txt' > > reading manifest template 'MANIFEST.in' > > warning: no files found matching 'Makefile' > > warning: no files found matching 'Modules\LICENSE' > > writing manifest file 'Lib\pyldap.egg-info\SOURCES.txt' > > running build_ext > > building '_ldap' extension > > creating build\temp.win32-3.5 > > creating build\temp.win32-3.5\Release > > creating build\temp.win32-3.5\Release\Modules > > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.exe /c > /nologo /Ox /W3 /GL /DNDEBUG /MD -DHAVE_SASL -D > > HAVE_TLS -DHAVE_LIBLDAP_R -DHAVE_LIBLDAP_R -DLDAPMODULE_VERSION=2.4.37 > -IModules -I/usr/include -I/usr/include/sasl -I/u > > sr/local/include -I/usr/local/include/sasl "-Ic:\program files > (x86)\python\python35-32\include" "-Ic:\program files (x8 > > 6)\python\python35-32\include" "-IC:\Program Files (x86)\Microsoft Visual > Studio 14.0\VC\INCLUDE" "-IC:\Program Files (x > > 86)\Windows Kits\10\include\10.0.10240.0\ucrt" "-IC:\Program Files > (x86)\Windows Kits\NETFXSDK\4.6.1\include\um" "-IC:\P > > rogram Files (x86)\Windows Kits\8.1\include\\shared" "-IC:\Program Files > (x86)\Windows Kits\8.1\include\\um" "-IC:\Progr > > am Files (x86)\Windows Kits\8.1\include\\winrt" "-IC:\Program Files > (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE" "-IC: > > \Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt" > "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\in > > clude\um" "-IC:\Program Files (x86)\Windows Kits\8.1\include\\shared" > "-IC:\Program Files (x86)\Windows Kits\8.1\include > > \\um" "-IC:\Program Files (x86)\Windows Kits\8.1\include\\winrt" > /TcModules/LDAPObject.c /Fobuild\temp.win32-3.5\Release > > \Modules/LDAPObject.obj > > LDAPObject.c > > c:\temp\pip-build-maui6ppt\pyldap\modules\errors.h(8): fatal error > C1083: Cannot open include file: 'lber.h': No suc > > h file or directory > > error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio > 14.0\\VC\\BIN\\cl.exe' failed with exit status 2 > > > > ---------------------------------------- > > Command ""c:\program files (x86)\python\python35-32\python.exe" -u -c > "import setuptools, tokenize;__file__='C:\\TEMP\\p > > ip-build-maui6ppt\\pyldap\\setup.py';f=getattr(tokenize, 'open', > open)(__file__);code=f.read().replace('\r\n', '\n');f.c > > lose();exec(compile(code, __file__, 'exec'))" install --record > C:\TEMP\pip-wi6dunu5-record\install-record.txt --single-v > > ersion-externally-managed --compile" failed with error code 1 in > C:\TEMP\pip-build-maui6ppt\pyldap\ > > > > c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>pip.exe install > "c:\Users\Administrator\Downloads\ldap3-2.3-py2.p > > y3-none-any.whl" > > Requirement already satisfied: ldap3==2.3 from > file:///C:/Users/Administrator/Downloads/ldap3-2.3-py2.py3-none-any.whl i > > n c:\program files (x86)\python\python35-32\lib\site-packages > > Requirement already satisfied: pyasn1>=0.1.8 in c:\program files > (x86)\python\python35-32\lib\site-packages (from ldap3= > > =2.3) > > > > c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>pip.exe install > "c:\Users\Administrator\Downloads\django_auth_lda > > p-1.2.15-py3-none-any.whl" > > > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > https://mail.python.org/mailman/listinfo/python-ldap > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Mon Sep 4 05:27:29 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 4 Sep 2017 11:27:29 +0200 Subject: [python-ldap] caching support in LDAPObject.search_ext_s() Message-ID: HI! For various reasons it's sometimes useful to cache search results. As usual one has to use that with care. I've implemented low-level search caching in web2ldap and module aedir [1] but I wonder whether it might be generally useful. Before I back-port this to python-ldap two questions: 1. Do people here consider it to be useful? Note that IMHO higher-level caching of response data in your application might be more useful. 2. Integrate it with SimpleLDAPObject (the base class) or use a derived class or even a mix-in class? Ciao, Michael. [1] https://pypi.python.org/pypi/aedir -------------- 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 Sep 4 06:08:20 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 4 Sep 2017 12:08:20 +0200 Subject: [python-ldap] ANN: python-ldap 2.4.42 Message-ID: Find a new release of python-ldap: https://pypi.python.org/pypi/python-ldap/2.4.42 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.42 2017-09-04 Changes since 2.4.41: Lib/ * added new SlapdObject methods _ln_schema_files() and _create_sub_dirs() * SlapdObject methods setup_rundir() and gen_config() are now "public" methods * removed pseudo test script from module ldap.cidict Tests/ * added sub-module for testing class ldap.cidict.cidict * avoid deprecated method alias unittest.TestCase.assertEquals -------------- 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 Sep 6 04:06:44 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 6 Sep 2017 10:06:44 +0200 Subject: [python-ldap] ANN: python-ldap 2.4.43 Message-ID: Find a new release of python-ldap: https://pypi.python.org/pypi/python-ldap/2.4.43 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.43 2017-09-06 Changes since 2.4.42: Lib/ * fixed passing all arguments from LDAPObject.sasl_non_interactive_bind_s() to LDAPObject.sasl_interactive_bind_s() Tests/ * added test for LDAPObject.sasl_external_bind_s() Doc/ * added docs for SASL bind methods * more references * better sorting of LDAPObject methods -------------- 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 Sep 6 09:47:58 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 6 Sep 2017 15:47:58 +0200 Subject: [python-ldap] more fine-grained GIL releasing in l_ldap_result4() Message-ID: <5218a9f4-5684-5403-0483-22460e50d8a4@stroeder.com> HI! I plan to apply the attached patch to ensure that GIL is only released when calling out to libldap and re-claimed immediately afterwards. Please review. Basically l_ldap_result4() etc. is a real mess and one of the deficiencies in python-ldap's code base. Any comments on that? Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-gil-issue.patch Type: text/x-patch Size: 1562 bytes Desc: not available URL: -------------- 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 miro_g at rocketmail.com Thu Sep 7 00:09:58 2017 From: miro_g at rocketmail.com (Miro) Date: Thu, 7 Sep 2017 04:09:58 +0000 (UTC) Subject: [python-ldap] Set the source IP of LDAP queries References: <2017893596.4457272.1504757398113.ref@mail.yahoo.com> Message-ID: <2017893596.4457272.1504757398113@mail.yahoo.com> Hello,I just started using python-ldap and was wondering if there way to set the source IP address of LDAP connections to an LDAP server ? Thanks,Miro De Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu Sep 7 03:04:09 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Thu, 7 Sep 2017 09:04:09 +0200 Subject: [python-ldap] Set the source IP of LDAP queries In-Reply-To: <2017893596.4457272.1504757398113@mail.yahoo.com> References: <2017893596.4457272.1504757398113.ref@mail.yahoo.com> <2017893596.4457272.1504757398113@mail.yahoo.com> Message-ID: Miro via python-ldap wrote: > Hello,I just started using python-ldap and was wondering if > there way to set the source IP address of LDAP connections to > an LDAP server ? No. OpenLDAP's libldap does not expose an API for that. Adding such a connection option was discussed on OpenLDAP mailing list recently but I'm not sure about the decision. 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 Sep 7 05:17:58 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Thu, 7 Sep 2017 11:17:58 +0200 Subject: [python-ldap] more fine-grained GIL releasing in l_ldap_result4() In-Reply-To: <5218a9f4-5684-5403-0483-22460e50d8a4@stroeder.com> References: <5218a9f4-5684-5403-0483-22460e50d8a4@stroeder.com> Message-ID: Michael Str?der wrote: > I plan to apply the attached patch to ensure that GIL is only > released when calling out to libldap and re-claimed immediately > afterwards. This was committed to CVS HEAD: http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Modules/LDAPObject.c?r1=1.96&r2=1.97&diff_format=l > Please review. Still reviews are appreciated... 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 Thu Sep 7 14:10:57 2017 From: riteshn at gmail.com (Ritesh Nadhani) Date: Thu, 7 Sep 2017 11:10:57 -0700 Subject: [python-ldap] LDIFParser seems to only parse 200 out of 9K odd records Message-ID: Hello I have code like (taken from official docs): [riteshn at niara4 ldap]$ more myldif.py import sys from ldif import LDIFParser,LDIFWriter class MyLDIF(LDIFParser): def __init__(self,input,output): LDIFParser.__init__(self,input) self.writer = LDIFWriter(output) self.count = 0 def handle(self,dn,entry): # self.writer.unparse(dn,entry) self.count = self.count + 1 parser = MyLDIF(open(sys.argv[1], 'rb'), sys.stdout) parser.parse() sys.stdout.write("Parsed: {} records".format(parser.count)) .. I have a file generated by ldapsearch using -LLL format and pagedresult: ldasearch .... -E pr=200/noprompt ... When I parse the above file, it seems it only parses 200 records and stops. Is there something about the paged result comment that breaks the parsing? Since the file contains confidential PII, I cannot attach the file but here are some statistics: [riteshn at niara4 ldap]$ python myldif.py log_win_ad_user.7 Parsed: 200 records[riteshn at niara4 ldap]$ grep "dn: " log_win_ad_user.7 | wc -l 9043 ... To me it seems this line is the culprit: # pagedresults: cookie=AQAAADQCAAD/////hiZDEOF1HmHDzgiafe+UPajr0z0XvrN8Nrs4JYyW TBX86O5bP1QQQ65fZxTI5IAhAAAAAAEAAAAAAAAAbjoAAAUAAAAFAAAAAgAAAAAAAAAAAAAABQAAAE MACgCYBwAAlwcAAJgHAAAAAAAALA3SQhI2IEmzx0Fkiqk54QAAAAACAAAAAQAAAAAAAAAAAAAA//// /8kAAADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD/////oZEJStHOUUMCUHAQiI cFT2u5R8OYP4qRkojEgkWk8+IAAAAAf7AAAAB/gAA6bgAAAAAAAAAAAAD//////////wAAAAAuAQkA DgAAAAUAAAAAAQAASU5ERVhfMDAwOTAxMkV/sAAAAH+wAAAA////////////////////////////// ////////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////wAA ... Any ideas? -- Ritesh From riteshn at gmail.com Thu Sep 7 14:53:37 2017 From: riteshn at gmail.com (Ritesh Nadhani) Date: Thu, 7 Sep 2017 11:53:37 -0700 Subject: [python-ldap] LDIFParser seems to only parse 200 out of 9K odd records In-Reply-To: References: Message-ID: More debugging it seems like its this line: 36030 # refldap://DomainDnsZones.arubanetworks.com/DC=DomainDnsZones,DC=arubanetworks 36031 ,DC=com 36032 36033 # refldap://ForestDnsZones.arubanetworks.com/DC=ForestDnsZones,DC=arubanetworks 36034 ,DC=com 36035 36036 # refldap://arubanetworks.com/CN=Configuration,DC=arubanetworks,DC=com ... any record after that first occurance, is not parsed. On Thu, Sep 7, 2017 at 11:10 AM, Ritesh Nadhani wrote: > Hello > > I have code like (taken from official docs): > > [riteshn at niara4 ldap]$ more myldif.py > import sys > from ldif import LDIFParser,LDIFWriter > > class MyLDIF(LDIFParser): > def __init__(self,input,output): > LDIFParser.__init__(self,input) > self.writer = LDIFWriter(output) > self.count = 0 > > def handle(self,dn,entry): > # self.writer.unparse(dn,entry) > self.count = self.count + 1 > > > parser = MyLDIF(open(sys.argv[1], 'rb'), sys.stdout) > parser.parse() > sys.stdout.write("Parsed: {} records".format(parser.count)) > > .. > > I have a file generated by ldapsearch using -LLL format and pagedresult: > > ldasearch .... -E pr=200/noprompt ... > > When I parse the above file, it seems it only parses 200 records and > stops. Is there something about the paged result comment that breaks > the parsing? > > Since the file contains confidential PII, I cannot attach the file but > here are some statistics: > > [riteshn at niara4 ldap]$ python myldif.py log_win_ad_user.7 > Parsed: 200 records[riteshn at niara4 ldap]$ grep "dn: " log_win_ad_user.7 | wc -l > 9043 > > ... > > To me it seems this line is the culprit: > > # pagedresults: > cookie=AQAAADQCAAD/////hiZDEOF1HmHDzgiafe+UPajr0z0XvrN8Nrs4JYyW > TBX86O5bP1QQQ65fZxTI5IAhAAAAAAEAAAAAAAAAbjoAAAUAAAAFAAAAAgAAAAAAAAAAAAAABQAAAE > MACgCYBwAAlwcAAJgHAAAAAAAALA3SQhI2IEmzx0Fkiqk54QAAAAACAAAAAQAAAAAAAAAAAAAA//// > /8kAAADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD/////oZEJStHOUUMCUHAQiI > cFT2u5R8OYP4qRkojEgkWk8+IAAAAAf7AAAAB/gAA6bgAAAAAAAAAAAAD//////////wAAAAAuAQkA > DgAAAAUAAAAAAQAASU5ERVhfMDAwOTAxMkV/sAAAAH+wAAAA////////////////////////////// > ////////////////////////////////////////////////////////////////////////////// > ////////////////////////////////////////////////////////////////////////////// > ////////////////////////////////////////////////////////////////////////////// > /////////////////////////////////////////////////////////////////////wAA > > ... > > Any ideas? > -- > Ritesh -- Ritesh From riteshn at gmail.com Thu Sep 7 15:06:57 2017 From: riteshn at gmail.com (Ritesh Nadhani) Date: Thu, 7 Sep 2017 12:06:57 -0700 Subject: [python-ldap] LDIFParser seems to only parse 200 out of 9K odd records In-Reply-To: References: Message-ID: I was able to do some text manipulation to add some sample data. This reproduces that we are only parsing 1 record instead of 2. On Thu, Sep 7, 2017 at 11:53 AM, Ritesh Nadhani wrote: > More debugging it seems like its this line: > > 36030 # refldap://DomainDnsZones.arubanetworks.com/DC=DomainDnsZones,DC=arubanetworks > 36031 ,DC=com > 36032 > 36033 # refldap://ForestDnsZones.arubanetworks.com/DC=ForestDnsZones,DC=arubanetworks > 36034 ,DC=com > 36035 > 36036 # refldap://arubanetworks.com/CN=Configuration,DC=arubanetworks,DC=com > > ... > > any record after that first occurance, is not parsed. > > On Thu, Sep 7, 2017 at 11:10 AM, Ritesh Nadhani wrote: >> Hello >> >> I have code like (taken from official docs): >> >> [riteshn at niara4 ldap]$ more myldif.py >> import sys >> from ldif import LDIFParser,LDIFWriter >> >> class MyLDIF(LDIFParser): >> def __init__(self,input,output): >> LDIFParser.__init__(self,input) >> self.writer = LDIFWriter(output) >> self.count = 0 >> >> def handle(self,dn,entry): >> # self.writer.unparse(dn,entry) >> self.count = self.count + 1 >> >> >> parser = MyLDIF(open(sys.argv[1], 'rb'), sys.stdout) >> parser.parse() >> sys.stdout.write("Parsed: {} records".format(parser.count)) >> >> .. >> >> I have a file generated by ldapsearch using -LLL format and pagedresult: >> >> ldasearch .... -E pr=200/noprompt ... >> >> When I parse the above file, it seems it only parses 200 records and >> stops. Is there something about the paged result comment that breaks >> the parsing? >> >> Since the file contains confidential PII, I cannot attach the file but >> here are some statistics: >> >> [riteshn at niara4 ldap]$ python myldif.py log_win_ad_user.7 >> Parsed: 200 records[riteshn at niara4 ldap]$ grep "dn: " log_win_ad_user.7 | wc -l >> 9043 >> >> ... >> >> To me it seems this line is the culprit: >> >> # pagedresults: >> cookie=AQAAADQCAAD/////hiZDEOF1HmHDzgiafe+UPajr0z0XvrN8Nrs4JYyW >> TBX86O5bP1QQQ65fZxTI5IAhAAAAAAEAAAAAAAAAbjoAAAUAAAAFAAAAAgAAAAAAAAAAAAAABQAAAE >> MACgCYBwAAlwcAAJgHAAAAAAAALA3SQhI2IEmzx0Fkiqk54QAAAAACAAAAAQAAAAAAAAAAAAAA//// >> /8kAAADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD/////oZEJStHOUUMCUHAQiI >> cFT2u5R8OYP4qRkojEgkWk8+IAAAAAf7AAAAB/gAA6bgAAAAAAAAAAAAD//////////wAAAAAuAQkA >> DgAAAAUAAAAAAQAASU5ERVhfMDAwOTAxMkV/sAAAAH+wAAAA////////////////////////////// >> ////////////////////////////////////////////////////////////////////////////// >> ////////////////////////////////////////////////////////////////////////////// >> ////////////////////////////////////////////////////////////////////////////// >> /////////////////////////////////////////////////////////////////////wAA >> >> ... >> >> Any ideas? >> -- >> Ritesh > > > > -- > Ritesh -- Ritesh -------------- next part -------------- A non-text attachment was scrubbed... Name: newaccounts.ldif Type: application/octet-stream Size: 4066 bytes Desc: not available URL: From michael at stroeder.com Thu Sep 7 18:32:34 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Fri, 8 Sep 2017 00:32:34 +0200 Subject: [python-ldap] LDIFParser seems to only parse 200 out of 9K odd records In-Reply-To: References: Message-ID: <97d70d4c-ca05-762b-b9bd-e6eb568afb6d@stroeder.com> Ritesh Nadhani wrote: > I have a file generated by ldapsearch using -LLL format and > pagedresult: > > ldasearch .... -E pr=200/noprompt ... > > When I parse the above file, it seems it only parses 200 > records and stops. > [..] > To me it seems this line is the culprit: > > # pagedresults: > cookie=AQAAADQCAAD/////hiZDEOF1HmHDzgiafe+UPajr0z0XvrN8Nrs4JYyW Yes, that does not seem like valid LDIF to me. Why don't you implement the LDAP search with paged results control in a Python script? This would give you more control over it anyway than using CLI tools. See examples scripts: Demo/page_control.py Demo/paged_search_ext_s.py 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 Sep 7 18:35:13 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Fri, 8 Sep 2017 00:35:13 +0200 Subject: [python-ldap] LDIFParser seems to only parse 200 out of 9K odd records In-Reply-To: References: Message-ID: <3195afce-6f8b-44cd-ca3d-786ff2536e0e@stroeder.com> Ritesh Nadhani wrote: > I was able to do some text manipulation to add some sample data. It seems module ldif does not unfold comment lines. Frankly I don't have the time to fix this now. You should look into implement the paged search directly in your Python script (see my other posting). 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 Thu Sep 7 18:36:36 2017 From: riteshn at gmail.com (Ritesh Nadhani) Date: Thu, 7 Sep 2017 15:36:36 -0700 Subject: [python-ldap] LDIFParser seems to only parse 200 out of 9K odd records In-Reply-To: <97d70d4c-ca05-762b-b9bd-e6eb568afb6d@stroeder.com> References: <97d70d4c-ca05-762b-b9bd-e6eb568afb6d@stroeder.com> Message-ID: Well, sometimes we just dont have access to the server and customer give us the ldif file generated from the command line that we have to injest. On Thu, Sep 7, 2017 at 3:32 PM, Michael Str?der wrote: > Ritesh Nadhani wrote: >> >> I have a file generated by ldapsearch using -LLL format and >> pagedresult: >> >> ldasearch .... -E pr=200/noprompt ... >> >> When I parse the above file, it seems it only parses 200 >> records and stops. >> [..] >> To me it seems this line is the culprit: >> >> # pagedresults: >> cookie=AQAAADQCAAD/////hiZDEOF1HmHDzgiafe+UPajr0z0XvrN8Nrs4JYyW > > > Yes, that does not seem like valid LDIF to me. > > Why don't you implement the LDAP search with paged results control in a > Python script? This would give you more control over it anyway than using > CLI tools. > > See examples scripts: > Demo/page_control.py > Demo/paged_search_ext_s.py > > Ciao, Michael. > -- Ritesh From michael at stroeder.com Fri Sep 8 06:26:56 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Fri, 8 Sep 2017 12:26:56 +0200 Subject: [python-ldap] LDIFParser seems to only parse 200 out of 9K odd records In-Reply-To: References: <97d70d4c-ca05-762b-b9bd-e6eb568afb6d@stroeder.com> Message-ID: Ritesh Nadhani wrote: > Well, sometimes we just dont have access to the server and > customer give us the ldif file generated from the command line > that we have to injest. So given my lack of spare time at the moment you currently have two options: 1. fix ldif module yourself (start by adding proper test-case(s) to Tests/t_ldif.py) 2. implement pre-filtering your customer's LDIF files 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 Fri Sep 8 13:13:09 2017 From: riteshn at gmail.com (Ritesh Nadhani) Date: Fri, 8 Sep 2017 10:13:09 -0700 Subject: [python-ldap] LDIFParser seems to only parse 200 out of 9K odd records In-Reply-To: References: <97d70d4c-ca05-762b-b9bd-e6eb568afb6d@stroeder.com> Message-ID: I will look into (1). It definitely does it for other parts like pagedresultcookie. So just need to debug why it did not do for refldap part. On Fri, Sep 8, 2017 at 3:26 AM, Michael Str?der wrote: > Ritesh Nadhani wrote: >> >> Well, sometimes we just dont have access to the server and >> customer give us the ldif file generated from the command line >> that we have to injest. > > > So given my lack of spare time at the moment you currently have two options: > > 1. fix ldif module yourself (start by adding proper test-case(s) to > Tests/t_ldif.py) > > 2. implement pre-filtering your customer's LDIF files > > Ciao, Michael. > -- Ritesh From aigars.grins at sentor.se Mon Sep 18 09:02:44 2017 From: aigars.grins at sentor.se (Aigars Grins) Date: Mon, 18 Sep 2017 15:02:44 +0200 Subject: [python-ldap] Strange network problems? Message-ID: <1775e9e5-25c7-330b-8b8c-dc7710e75d38@sentor.se> Hi! I have a problem and I'm wonder if any of you have stubled across something similar. I have a python daemon that uses gevent + daemonize + python-ldap. That python daemon runs on a Debian 8 machine and connects to an OpenLDAP daemon running on FreeBSD. Now and then the LDAP daemon is restarted. When that happens, the python daemon looses it's capability to create new connections. [SERVER_DOWN] {'info': "Error in the system's randomness device.", 'errno': 11, 'desc': "Can't contact LDAP server"} (I think that the text about "Error in the system's randomness device", while certainly correct in some sense, is a red herring. There's nothing wrong with the randomness device on the host as such. Other python daemons, on the same machine, have no problems. That said, obviously something is broken.) Also, any existing connections are now somehow broken. When the python daemon code tries to use them, they block. Even though I use `search_st(timeout = 120.0)`. Trying to create new connections can sometimes, but not always, also block. Even though I use `cnxn = initialize(url); cnxn.set_option(OPT_NETWORK_TIMEOUT, 10.0); cnxn.set_option(OPT_X_TLS_NEWCTX, 0); cnxn.simple_bind(bind, password)`. Most often though, new connections are simply not possible to create. All of the problems go away if I restart the python daemon after the LDAP daemon is restarted. Previously I've had a related issue which I believe is more to do with gevent. I took it up on their tracker [1]. I'm including a reference here, if the data available there is of any use. [1] Furthermore, the same code base works better in other python daemons on the same machine. So, "obviously" something's wrong in my code. It's just that I really can't see what the difference could be. Do you have any ideas? -- Aigars Grins From michael at stroeder.com Mon Sep 18 12:35:35 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Mon, 18 Sep 2017 18:35:35 +0200 Subject: [python-ldap] Strange network problems? In-Reply-To: <1775e9e5-25c7-330b-8b8c-dc7710e75d38@sentor.se> References: <1775e9e5-25c7-330b-8b8c-dc7710e75d38@sentor.se> Message-ID: <5f019174-ea64-309f-cdbf-a0884a5b2979@stroeder.com> Aigars Grins wrote: > I have a python daemon that uses gevent + daemonize + python-ldap. > That python daemon runs on a Debian 8 machine and connects to an > OpenLDAP daemon running on FreeBSD. Now and then the LDAP daemon is > restarted. When that happens, the python daemon looses it's > capability to create new connections. [SERVER_DOWN] {'info': "Error > in the system's randomness device.", 'errno': 11, 'desc': "Can't > contact LDAP server"} libldap on Debian is linked against GnuTLS. Maybe there's an issue with that? Sure there's enough entropy? Does GnuTLS do OCSP queries, CRL lookups or similar under the hood? Which version of python-ldap is this? > Also, any existing connections are now somehow broken. When the > python daemon code tries to use them, they block. Even though I use > `search_st(timeout = 120.0)`. Trying to create new connections can > sometimes, but not always, also block. Even though I use `cnxn = > initialize(url); cnxn.set_option(OPT_NETWORK_TIMEOUT, 10.0); > cnxn.set_option(OPT_X_TLS_NEWCTX, 0); cnxn.simple_bind(bind, > password)`. Most often though, new connections are simply not > possible to create. I have no idea what's going on in your code but some remarks for the general understanding: When opening new connections via libldap a module-wide lock is used in module-wide ldap to serialize the calls to libldap's function ldap_initialize() but which only initializes the struct in libldap. Or course this affects reconnecting in ReconnectLDAPObject. So if your LDAP server is restarted reconnecting hits the module-wide locking and reconnecting a connection pool will be serialized. If you set ldap._trace_level = 3 then you should see whether global or connection-specific lock is used. BTW: Do you really need a connection pool for parallel long-running LDAP queries? > Previously I've had a related issue which I believe is more to do with > gevent. Sorry, I have never used gevent. 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 aigars.grins at sentor.se Wed Sep 20 04:11:40 2017 From: aigars.grins at sentor.se (Aigars Grins) Date: Wed, 20 Sep 2017 10:11:40 +0200 Subject: [python-ldap] Strange network problems? In-Reply-To: <5f019174-ea64-309f-cdbf-a0884a5b2979@stroeder.com> References: <1775e9e5-25c7-330b-8b8c-dc7710e75d38@sentor.se> <5f019174-ea64-309f-cdbf-a0884a5b2979@stroeder.com> Message-ID: <80f8109d-e5ce-9407-8a02-897b0f18f71e@sentor.se> Hi! On 2017-09-18 18:35, Michael Str?der wrote: > libldap on Debian is linked against GnuTLS. Maybe there's an issue with > that? Sure there's enough entropy? Does GnuTLS do OCSP queries, CRL > lookups or similar under the hood? I really don't know. The connection string does start with "ldaps://" so I guess some TLS-functionality is used at least. I don't see any special settings in e.g. /etc/ldap/ldap.conf, so I guess that the "default behaviour" is used. Whatever that is. With regards to "errors in the randomness device", the internet tells me that some other projects [1] switched over to bind against OpenSSL instead. Would it be possible to do that for python-ldap as well? Some kind of compiler flag I could set? [1] > Which version of python-ldap is this? It's version 2.4.39. > When opening new connections via libldap a module-wide lock is used in > module-wide ldap to serialize the calls to libldap's function > ldap_initialize() but which only initializes the struct in libldap. Or > course this affects reconnecting in ReconnectLDAPObject. So if your LDAP > server is restarted reconnecting hits the module-wide locking and > reconnecting a connection pool will be serialized. > > If you set ldap._trace_level = 3 then you should see whether global or > connection-specific lock is used. Interesting. I'll set up some kind of logging for this, but since I only see this behaviour in PROD and not in DEV, it will take me some time to get results back. > BTW: Do you really need a connection pool for parallel long-running LDAP > queries? During burst activity it's good in general to have readily available connections and to be able to process data in paralell. -- Aigars Grins From michael at stroeder.com Wed Sep 20 04:49:25 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Wed, 20 Sep 2017 10:49:25 +0200 Subject: [python-ldap] Strange network problems? In-Reply-To: <80f8109d-e5ce-9407-8a02-897b0f18f71e@sentor.se> References: <1775e9e5-25c7-330b-8b8c-dc7710e75d38@sentor.se> <5f019174-ea64-309f-cdbf-a0884a5b2979@stroeder.com> <80f8109d-e5ce-9407-8a02-897b0f18f71e@sentor.se> Message-ID: <3af81653-5b46-1077-0389-368a0338b126@stroeder.com> Aigars Grins wrote: > On 2017-09-18 18:35, Michael Str?der wrote: >> libldap on Debian is linked against GnuTLS. Maybe there's an issue >> with that? Sure there's enough entropy? Does GnuTLS do OCSP queries, >> CRL lookups or similar under the hood? > > I really don't know. The connection string does start with "ldaps://" > so I guess some TLS-functionality is used at least. I don't see any > special settings in e.g. /etc/ldap/ldap.conf, so I guess that the > "default behaviour" is used. Whatever that is. The problem is that this default behaviour has nothing to do with configuration of python-ldap or libldap. You could try to find out by observing the network traffic, DNS queries etc. > With regards to "errors in the randomness device", the internet tells > me that some other projects [1] switched over to bind against > OpenSSL instead. Would it be possible to do that for python-ldap as > well? Some kind of compiler flag I could set? > > [1] The Debian developers, with their infinite wisdom and anti-OpenSSL licensing paranoia, decided to link libldap against GnuTLS. This causes nothing than grief but they are pretty much ignorant to change that. If you want to change that you have to compile the whole stack [1] yourself and take care of not mixing dynamic linking with OS-installed libldap: [1] https://www.python-ldap.org/doc/html/installing.html#prerequisites Maybe you could try to build a statically linked python-ldap with all the issues with that solution (updates etc.). >> BTW: Do you really need a connection pool for parallel long-running >> LDAP queries? > > During burst activity it's good in general to have readily available > connections and to be able to process data in paralell. If the burst queries are (partially) the same it might be better to have a single LDAP connection and a cache with short TTL. Hard to tell without knowing the details though. 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 aigars.grins at sentor.se Tue Sep 26 03:00:08 2017 From: aigars.grins at sentor.se (Aigars Grins) Date: Tue, 26 Sep 2017 09:00:08 +0200 Subject: [python-ldap] Reraising wrong exception in _ldap_call() Message-ID: <85834b1c-f2d1-7d03-ed31-c23282c4687c@sentor.se> Hi, In ldap.ldapobject theres a method called SimpleLDAPObject._ldap_call(). In it there's error handling code along the lines of (abbreviated here): try: result = func(*args, **kwargs) except LDAPError, e: 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 raise This means that if the raised LDAPError was e.g. a TIMEOUT w/o any args, then the `e.args[0]` will raise an IndexError. That will be caught, which is fine. But then the reraise will reraise not the LDAPError but the IndexError. So the `raise` should be replaced with `raise e`. The way I found this was by running something along the lines of: msgid = cnxn.search_ext(base, scope, ..., timeout = 0.00001) cnxn.result(msgid, timeout = 0.00001) The short timeouts triggers a TIMEOUT, but it doesn't have any args. -- Aigars Grins From michael at stroeder.com Tue Sep 26 05:44:04 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Tue, 26 Sep 2017 11:44:04 +0200 Subject: [python-ldap] Reraising wrong exception in _ldap_call() In-Reply-To: <85834b1c-f2d1-7d03-ed31-c23282c4687c@sentor.se> References: <85834b1c-f2d1-7d03-ed31-c23282c4687c@sentor.se> Message-ID: <91560ae2-a842-8db7-e4fe-dd3f4f3e9f3e@stroeder.com> Aigars Grins wrote: > In ldap.ldapobject theres a method called > SimpleLDAPObject._ldap_call(). In it there's error handling code > along the lines of (abbreviated here): Many thanks for spotting this. I've committed the fix to CVS HEAD. 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 space at wechall.net Tue Sep 26 05:50:41 2017 From: space at wechall.net (Space One) Date: Tue, 26 Sep 2017 11:50:41 +0200 Subject: [python-ldap] Reraising wrong exception in _ldap_call() In-Reply-To: <91560ae2-a842-8db7-e4fe-dd3f4f3e9f3e@stroeder.com> References: <85834b1c-f2d1-7d03-ed31-c23282c4687c@sentor.se> <91560ae2-a842-8db7-e4fe-dd3f4f3e9f3e@stroeder.com> Message-ID: <10db0457-d105-eda6-d736-ae56e747c85d@wechall.net> "raise e" will changes the stack trace, which might be necessary for further debugging. You can instead also do: etype, exc, etrace = sys.exc_info() try: ?exc.foo= bar? except IndexError: ??? pass raise etype, exc, etrace Am 26.09.2017 um 11:44 schrieb Michael Str?der: > Aigars Grins wrote: >> In ldap.ldapobject theres a method called >> SimpleLDAPObject._ldap_call(). In it there's error handling code >> along the lines of (abbreviated here): > > Many thanks for spotting this. > > I've committed the fix to CVS HEAD. > > Ciao, Michael. > > > > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > https://mail.python.org/mailman/listinfo/python-ldap -------------- next part -------------- An HTML attachment was scrubbed... URL: