From J.Balaji at gmail.com Sat May 16 20:39:10 2020 From: J.Balaji at gmail.com (Balaji Jeevan) Date: Sat, 16 May 2020 17:39:10 -0700 Subject: [python-ldap] search_s call hangs (macos, python-ldap3.2). ldapsearch call is successful Message-ID: I am having an issue with search_s call hanging indefinitely. Direct ldapsearch call is working fine. I have included the working ldapsearch and the failing python-ldap call. I appreciate any pointers. Thanks, Balaji $ python --version Python 3.7.7 $ pip list | grep python-ldap python-ldap 3.2.0 $ sw_vers ProductName: Mac OS X ProductVersion: 10.14.6 BuildVersion: 18G4032 (Mojave) LDAP version: $ /usr/libexec/slapd -d3 5ec08515 @(#) $OpenLDAP: slapd 2.4.28 (Dec 3 2019 04:47:49) $ root at osx332.sd.apple.com: /BuildRoot/Library/Caches/com.apple.xbs/Binaries/OpenLDAP/install/TempContent/Objects/servers/slapd 5ec08515 daemon: SLAP_SOCK_INIT: dtblsize=256 5ec08515 daemon_init: listen on ldap:/// 5ec08515 daemon_init: 1 listeners to open... Direct ldapsearch call works as expected: $ ldapsearch -x -h ad-ldap.xxxxx.com -D "bjeevan at xxxxx.com" -w 'xxxxxx!' -b "dc=xxxxx,dc=com" -s sub '(&(objectCategory=person)(objectClass=user)(sAMAccountName=bjeevan)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' cn # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectCategory=person)(objectClass=user)(sAMAccountName=bjeevan)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) # requesting: cn # # Balaji Jeevan, Users, Sunnyvale, xxxxx.com dn: CN=Balaji Jeevan,OU=Users,OU=Sunnyvale,DC=xxxxx,DC=com cn: Balaji Jeevan Here is the hanging python-ldap call: $ python Python 3.7.7 (default, Mar 10 2020, 15:43:03) [Clang 11.0.0 (clang-1100.0.33.17)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import ldap >>> con = ldap.initialize('ldap://ad-ldap.xxxxx.com:389') >>> con.simple_bind_s( 'bjeevan at xxxxx.com', "yyyyy!" ) (97, [], 1, []) >>> rt = con.search_s("dc=xxxxx,dc=com", ldap.SCOPE_SUBTREE, '(sAMAccountName=bjeevan)', []) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at krondo.com Mon May 18 11:53:19 2020 From: dave at krondo.com (Dave Peticolas) Date: Mon, 18 May 2020 08:53:19 -0700 Subject: [python-ldap] search_s call hangs (macos, python-ldap3.2). ldapsearch call is successful In-Reply-To: References: Message-ID: I recommend you use the feature to turn off referrals in the Python code. I suspect the python code version is trying to follow a domain referral that doesn't actually exist. That seems to be a typical issue when you are using active directory. On Mon, May 18, 2020, 2:21 AM Balaji Jeevan wrote: > I am having an issue with search_s call hanging indefinitely. Direct > ldapsearch call is working fine. > I have included the working ldapsearch and the failing python-ldap call. > > I appreciate any pointers. > Thanks, > Balaji > > $ python --version > Python 3.7.7 > > $ pip list | grep python-ldap > python-ldap 3.2.0 > > $ sw_vers > ProductName: Mac OS X > ProductVersion: 10.14.6 > BuildVersion: 18G4032 > > (Mojave) > > > LDAP version: > $ /usr/libexec/slapd -d3 > 5ec08515 @(#) $OpenLDAP: slapd 2.4.28 (Dec 3 2019 04:47:49) $ > root at osx332.sd.apple.com: > /BuildRoot/Library/Caches/com.apple.xbs/Binaries/OpenLDAP/install/TempContent/Objects/servers/slapd > 5ec08515 daemon: SLAP_SOCK_INIT: dtblsize=256 > 5ec08515 daemon_init: listen on ldap:/// > 5ec08515 daemon_init: 1 listeners to open... > > > Direct ldapsearch call works as expected: > > $ ldapsearch -x -h ad-ldap.xxxxx.com -D "bjeevan at xxxxx.com" -w 'xxxxxx!' > -b "dc=xxxxx,dc=com" -s sub > '(&(objectCategory=person)(objectClass=user)(sAMAccountName=bjeevan)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' > cn > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: > (&(objectCategory=person)(objectClass=user)(sAMAccountName=bjeevan)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) > # requesting: cn > # > > # Balaji Jeevan, Users, Sunnyvale, xxxxx.com > dn: CN=Balaji Jeevan,OU=Users,OU=Sunnyvale,DC=xxxxx,DC=com > cn: Balaji Jeevan > > Here is the hanging python-ldap call: > $ python > Python 3.7.7 (default, Mar 10 2020, 15:43:03) > [Clang 11.0.0 (clang-1100.0.33.17)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import ldap > >>> con = ldap.initialize('ldap://ad-ldap.xxxxx.com:389') > >>> con.simple_bind_s( 'bjeevan at xxxxx.com', "yyyyy!" ) > (97, [], 1, []) > >>> rt = con.search_s("dc=xxxxx,dc=com", ldap.SCOPE_SUBTREE, > '(sAMAccountName=bjeevan)', []) > > > > > > > > > _______________________________________________ > 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 J.Balaji at gmail.com Mon May 18 14:29:56 2020 From: J.Balaji at gmail.com (Balaji Jeevan) Date: Mon, 18 May 2020 11:29:56 -0700 Subject: [python-ldap] search_s call hangs (macos, python-ldap3.2). ldapsearch call is successful In-Reply-To: References: Message-ID: Dave, That was it!. After turning off referrals, it worked as expected. Thanks so much, Balaji On Mon, May 18, 2020 at 8:53 AM Dave Peticolas wrote: > I recommend you use the feature to turn off referrals in the Python code. > I suspect the python code version is trying to follow a domain referral > that doesn't actually exist. That seems to be a typical issue when you are > using active directory. > > On Mon, May 18, 2020, 2:21 AM Balaji Jeevan wrote: > >> I am having an issue with search_s call hanging indefinitely. Direct >> ldapsearch call is working fine. >> I have included the working ldapsearch and the failing python-ldap call. >> >> I appreciate any pointers. >> Thanks, >> Balaji >> >> $ python --version >> Python 3.7.7 >> >> $ pip list | grep python-ldap >> python-ldap 3.2.0 >> >> $ sw_vers >> ProductName: Mac OS X >> ProductVersion: 10.14.6 >> BuildVersion: 18G4032 >> >> (Mojave) >> >> >> LDAP version: >> $ /usr/libexec/slapd -d3 >> 5ec08515 @(#) $OpenLDAP: slapd 2.4.28 (Dec 3 2019 04:47:49) $ >> root at osx332.sd.apple.com: >> /BuildRoot/Library/Caches/com.apple.xbs/Binaries/OpenLDAP/install/TempContent/Objects/servers/slapd >> 5ec08515 daemon: SLAP_SOCK_INIT: dtblsize=256 >> 5ec08515 daemon_init: listen on ldap:/// >> 5ec08515 daemon_init: 1 listeners to open... >> >> >> Direct ldapsearch call works as expected: >> >> $ ldapsearch -x -h ad-ldap.xxxxx.com -D "bjeevan at xxxxx.com" -w 'xxxxxx!' >> -b "dc=xxxxx,dc=com" -s sub >> '(&(objectCategory=person)(objectClass=user)(sAMAccountName=bjeevan)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' >> cn >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: >> (&(objectCategory=person)(objectClass=user)(sAMAccountName=bjeevan)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) >> # requesting: cn >> # >> >> # Balaji Jeevan, Users, Sunnyvale, xxxxx.com >> dn: CN=Balaji Jeevan,OU=Users,OU=Sunnyvale,DC=xxxxx,DC=com >> cn: Balaji Jeevan >> >> Here is the hanging python-ldap call: >> $ python >> Python 3.7.7 (default, Mar 10 2020, 15:43:03) >> [Clang 11.0.0 (clang-1100.0.33.17)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import ldap >> >>> con = ldap.initialize('ldap://ad-ldap.xxxxx.com:389') >> >>> con.simple_bind_s( 'bjeevan at xxxxx.com', "yyyyy!" ) >> (97, [], 1, []) >> >>> rt = con.search_s("dc=xxxxx,dc=com", ldap.SCOPE_SUBTREE, >> '(sAMAccountName=bjeevan)', []) >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 pviktori at redhat.com Thu Jun 18 10:19:17 2020 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 18 Jun 2020 16:19:17 +0200 Subject: [python-ldap] ANN: python-ldap 3.3.0 Message-ID: <3a40bcdd-8be0-26ec-f966-35a4419db8aa@redhat.com> After a long delay, you can find a new release of python-ldap here: https://pypi.python.org/pypi/python-ldap/3.3.0 Notable changes since 3.2.0 are: * LDAPError now contains additional fields, such as ctrls, result, msgid * passwd_s can now extract the newly generated password * LDAP connections can now be made from a file descriptor This is the last 3.x release of python-ldap to support CPython 2.7, 3.4 and 3.5, which are past or near end-of-life. For information on supported CPython versions, see: https://devguide.python.org/#status-of-python-branches https://devguide.python.org/devcycle/#end-of-life-branches If you find any issues, please report them either on this mailing list or on the GitHub tracker: https://github.com/python-ldap/python-ldap/issues Git tag hash for the release: python-ldap-3.3.0 e885b621562a3c987934be3fba3873d21026bf5c The tag is signed by my GPG key with fingerprint: AD4D FBDB 5D40 4CA8 0600 A5F4 0BA8 70E7 9E17 2F37 -------- About the project: 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/ -------- Released 3.3.0 2020-06-18 Highlights: * ``LDAPError`` now contains additional fields, such as ctrls, result, msgid * ``passwd_s`` can now extract the newly generated password * LDAP connections can now be made from a file descriptor This release is tested on Python 3.8, and the beta of Python 3.9. The following undocumented functions are deprecated and scheduled for removal: - ``ldap.cidict.strlist_intersection`` - ``ldap.cidict.strlist_minus`` - ``ldap.cidict.strlist_union`` Modules/ * Ensure ReconnectLDAPObject is not left in an inconsistent state after a reconnection timeout * Syncrepl now correctly parses SyncInfoMessage when the message is a syncIdSet * Release GIL around global get/set option call * Do not leak serverctrls in result functions * Don't overallocate memory in attrs_from_List() * Fix thread support check for Python 3 * With OpenLDAP 2.4.48, use the new header openldap.h Lib/ * Fix some edge cases regarding quoting in the schema tokenizer * Fix escaping a single space in ldap.escape_dn_chars * Fix string formatting in ldap.compare_ext_s * Prefer iterating dict instead of calling dict.keys() Doc/ * Clarify the relationship between initialize() and LDAPObject() * Improve documentation of TLS options * Update FAQ to include Samba AD-DC error message "Operation unavailable without authentication" * Fix several incorrect examples and demos (but note that these are not yet tested) * Update Debian installation instructions for Debian Buster * Typo fixes in docs and docstrings Test/ * Test and document error cases in ldap.compare_s * Test if reconnection is done after connection loss * Make test certificates valid for the far future * Use slapd -Tt instead of slaptest Infrastructure: * Mark the LICENCE file as a license for setuptools * Use "unittest discover" rather than "setup.py test" to run tests From hahn at univention.de Mon Jun 29 04:04:33 2020 From: hahn at univention.de (Philipp Hahn) Date: Mon, 29 Jun 2020 10:04:33 +0200 Subject: [python-ldap] PEP 484 -- Type Hints for python-ldap? Message-ID: Hello, Am 18.06.20 um 16:19 schrieb Petr Viktorin: > This is the last 3.x release of python-ldap to support CPython 2.7, 3.4 > and 3.5, which are past or near end-of-life. For information on > supported CPython versions, see: > > https://devguide.python.org/#status-of-python-branches > https://devguide.python.org/devcycle/#end-of-life-branches Python supports type hints to improve static analysis: This helps to identify cases, were wrong types are passed into functions et al by using type checkers like or . Sadly "python-ldap" does not yet seem to contain those annotations nor am I aware of any project doing that. Those annotation can either we added directly in the library like > def func(arg: str, val: int = 0) -> Tuple[int, str] since Python 3.5 or in a Python-2 backward compatible way as > def func(arg, val=0): # type: (str, int) -> Tuple[int, str] As an alternative the annotations can be put into so-called "stub files" names "*.pyi", which are collected by , but inline annotations are preferred as they are easier to keep in sync. Is someone working on that? Would such an effort be appreciated? I started working on that, but other projects have preempted that effort. My current work is at , but it not much more then generating the stubs using `stubgen`. If someone wants to join that effort that is much appreciated. Philipp -- Philipp Hahn Open Source Software Engineer Univention GmbH be open. Mary-Somerville-Str. 1 D-28359 Bremen Tel.: +49-421-22232-57 Fax : +49-421-22232-99 hahn at univention.de https://www.univention.de/ Gesch?ftsf?hrer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876 From christian at python.org Mon Jun 29 05:26:31 2020 From: christian at python.org (Christian Heimes) Date: Mon, 29 Jun 2020 11:26:31 +0200 Subject: [python-ldap] PEP 484 -- Type Hints for python-ldap? In-Reply-To: References: Message-ID: On 29/06/2020 10.04, Philipp Hahn wrote: > Hello, > > Am 18.06.20 um 16:19 schrieb Petr Viktorin: >> This is the last 3.x release of python-ldap to support CPython 2.7, 3.4 >> and 3.5, which are past or near end-of-life. For information on >> supported CPython versions, see: >> >> https://devguide.python.org/#status-of-python-branches >> https://devguide.python.org/devcycle/#end-of-life-branches > > Python supports type hints to improve static analysis: > > This helps to identify cases, were wrong types are passed into functions > et al by using type checkers like or > . > > Sadly "python-ldap" does not yet seem to contain those annotations nor > am I aware of any project doing that. > Those annotation can either we added directly in the library like > >> def func(arg: str, val: int = 0) -> Tuple[int, str] > > since Python 3.5 or in a Python-2 backward compatible way as > >> def func(arg, val=0): # type: (str, int) -> Tuple[int, str] > > As an alternative the annotations can be put into so-called "stub files" > names "*.pyi", which are collected by > , but inline annotations are > preferred as they are easier to keep in sync. > > Is someone working on that? > Would such an effort be appreciated? > > I started working on that, but other projects have preempted that > effort. My current work is at > , > but it not much more then generating the stubs using `stubgen`. > If someone wants to join that effort that is much appreciated. Hi, we are planning to drop support for Python 3.5 and earlier in the next version of python-ldap. This would make it simpler to add signatures for type hints directly to the code base. Patches are welcome, but please wait until we have finalized Python 2 cleanup in master. Could you please open a bug on https://github.com/python-ldap/python-ldap ? One personal note: I don't like how you phrased 'Sadly "python-ldap" does not yet seem to contain those annotations'. It feels like you are putting emotional pressure on us and shaming us for not providing more free labor. It was probably not your intention, but I still like to point out that the prase is problematic. Christian From jens at dataflake.org Mon Jun 29 06:04:37 2020 From: jens at dataflake.org (Jens Vagelpohl) Date: Mon, 29 Jun 2020 12:04:37 +0200 Subject: [python-ldap] PEP 484 -- Type Hints for python-ldap? In-Reply-To: References: Message-ID: <27699750-3141-4407-B34E-2AC8C9D06CC6@dataflake.org> > On 29. Jun 2020, at 11:26 , Christian Heimes wrote: > > On 29/06/2020 10.04, Philipp Hahn wrote: >> Sadly "python-ldap" does not yet seem to contain those annotations nor >> am I aware of any project doing that. > > One personal note: > I don't like how you phrased 'Sadly "python-ldap" does not yet seem to > contain those annotations'. It feels like you are putting emotional > pressure on us and shaming us for not providing more free labor. It was > probably not your intention, but I still like to point out that the > prase is problematic. I am sure there wasn?t any specific negative intent here, but I am 1000% behind your sentiment that many people have a serious lack of appreciation for the work others do in their spare time. This issue comes up again and again in the projects I help maintain. jens -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From pviktori at redhat.com Mon Jun 29 10:52:38 2020 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 29 Jun 2020 16:52:38 +0200 Subject: [python-ldap] ANN: python-ldap 3.3.1 Message-ID: You can find a new release of python-ldap here: https://pypi.python.org/pypi/python-ldap/3.3.1 This release fixes builds on MacOS with the system libldap, which is missing the function `ldap_init_fd`. If you have built 3.3.0 successfully, you don't need to update. If you find any issues, please report them either on this mailing list or on the GitHub tracker: https://github.com/python-ldap/python-ldap/issues Git tag hash for the release: python-ldap-3.3.1 dae0c5193d02709df6f6918d0e495180a1bff0c8 The tag is signed by my GPG key with fingerprint: AD4D FBDB 5D40 4CA8 0600 A5F4 0BA8 70E7 9E17 2F37 -------- About the project: 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/ -------- Released 3.3.1 2020-06-29 Changes: * On MacOS, remove option to make LDAP connections from a file descriptor when built wit the system libldap (which lacks the underlying function, ``ldap_init_fd``)