From cornelius.koelbel at lsexperts.de Mon Jul 1 21:42:16 2013 From: cornelius.koelbel at lsexperts.de (=?ISO-8859-15?Q?Cornelius_K=F6lbel?=) Date: Mon, 01 Jul 2013 21:42:16 +0200 Subject: [python-ldap] Bind with non-ascii DN Message-ID: <51D1DB98.8060004@lsexperts.de> Hi, I have DNs with unsafe characters and other non-ascii characters. Is it possible to do the bin with the base64 encoded DN? Thanks a lot and kind regards Cornelius -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: From michael at stroeder.com Mon Jul 1 23:08:41 2013 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 01 Jul 2013 23:08:41 +0200 Subject: [python-ldap] Bind with non-ascii DN In-Reply-To: <51D1DB98.8060004@lsexperts.de> References: <51D1DB98.8060004@lsexperts.de> Message-ID: <51D1EFD9.30707@stroeder.com> Cornelius K?lbel wrote: > I have DNs with unsafe characters and other non-ascii characters. > Is it possible to do the bin with the base64 encoded DN? LDAPv3 defines UTF-8 based string encoding for DNs in RFC 4514 and python-ldap happily sends that to the server. Note that you have to do the s.decode('utf-8') in your code which calls python-ldap functions/methods. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From cornelius.koelbel at lsexperts.de Thu Jul 4 23:01:16 2013 From: cornelius.koelbel at lsexperts.de (=?ISO-8859-1?Q?Cornelius_K=F6lbel?=) Date: Thu, 04 Jul 2013 23:01:16 +0200 Subject: [python-ldap] Bind with non-ascii DN In-Reply-To: <51D1EFD9.30707@stroeder.com> References: <51D1DB98.8060004@lsexperts.de> <51D1EFD9.30707@stroeder.com> Message-ID: <51D5E29C.8000205@lsexperts.de> Hi Michael, some encoding of the BindDN and BindPW did the trick. Thanks a lot and kind regards Cornelius Am 01.07.2013 23:08, schrieb Michael Str?der: > Cornelius K?lbel wrote: >> I have DNs with unsafe characters and other non-ascii characters. >> Is it possible to do the bin with the base64 encoded DN? > LDAPv3 defines UTF-8 based string encoding for DNs in RFC 4514 and python-ldap > happily sends that to the server. > Note that you have to do the s.decode('utf-8') in your code which calls > python-ldap functions/methods. > > Ciao, Michael. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: From djay at pretaweb.com Mon Jul 8 07:27:26 2013 From: djay at pretaweb.com (Dylan Jay) Date: Mon, 8 Jul 2013 15:27:26 +1000 Subject: [python-ldap] Patch for ReconnectLDAPObject Message-ID: <76FA2A1C-BC29-4A98-8F84-C7C6E00A08BC@pretaweb.com> Hi, We've discovered either an issue with this patch or another issue with timeouts. The details of how reproduce this are in the post by Maurits van Rees https://bugs.launchpad.net/ldapuserfolder/+bug/650371 --- Dylan Jay Technical Solutions Manager PretaWeb: Multisite Performance Support P: +612 80819071 | M: +61421477460 | twitter.com/pretaweb | linkedin.com/in/djay75 From michael at stroeder.com Mon Jul 8 09:33:36 2013 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 08 Jul 2013 09:33:36 +0200 Subject: [python-ldap] Patch for ReconnectLDAPObject In-Reply-To: <76FA2A1C-BC29-4A98-8F84-C7C6E00A08BC@pretaweb.com> References: <76FA2A1C-BC29-4A98-8F84-C7C6E00A08BC@pretaweb.com> Message-ID: <51DA6B50.2000405@stroeder.com> Dylan Jay wrote: > We've discovered either an issue with this patch or another issue with timeouts. Which patch? Please be more precise. > The details of how reproduce this are in the post by Maurits van Rees > > https://bugs.launchpad.net/ldapuserfolder/+bug/650371 Hmm, I don't know anything about Zope. Nor do I have any knowledge about how LDAPUserFolder uses python-ldap. Maybe Jens can comment here. I presume that if updating to 2.4.13 partially solves the issue it's related to recent changes for ReconnectLDAPObject. I think that Jonathan Giannuzzi's contribution helped since I could reproduce the problem before and his patch solved it. What I see finally in the bug report is a SERVER_DOWN: {'desc': "Can't contact LDAP server"} This can happen even with ReconnectLDAPObject. See parameters retry_max and retry_delay of ReconnectLDAPObject.__init__(): http://www.python-ldap.org/doc/html/ldap.html#ldap.ReconnectLDAPObject Also note that only synchronous method calls are retried automagically. If LDAPUserFolder uses asynchronous calls, e.g. to make use of LDAPv3 extended response controls only returned by result3() and result4(), it has to handle ldap.SERVER_DOWN itself by invoking ReconnectLDAPObject.reconnect(ls.uri) and retry the code block. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From djay at pretaweb.com Mon Jul 8 17:03:03 2013 From: djay at pretaweb.com (Dylan Jay) Date: Tue, 9 Jul 2013 01:03:03 +1000 Subject: [python-ldap] Patch for ReconnectLDAPObject In-Reply-To: <51DA6B50.2000405@stroeder.com> References: <76FA2A1C-BC29-4A98-8F84-C7C6E00A08BC@pretaweb.com> <51DA6B50.2000405@stroeder.com> Message-ID: <27ABC044-0E75-4668-8CE6-BA54FC227C13@pretaweb.com> On 08/07/2013, at 5:33 PM, Michael Str?der wrote: > Dylan Jay wrote: >> We've discovered either an issue with this patch or another issue with timeouts. > > Which patch? Please be more precise. http://mail.python.org/pipermail/python-ldap/2013q2/003253.html > >> The details of how reproduce this are in the post by Maurits van Rees >> >> https://bugs.launchpad.net/ldapuserfolder/+bug/650371 > > Hmm, I don't know anything about Zope. Nor do I have any knowledge about how LDAPUserFolder uses python-ldap. Maybe Jens can comment here. > > I presume that if updating to 2.4.13 partially solves the issue it's related to recent changes for ReconnectLDAPObject. I think that Jonathan Giannuzzi's contribution helped since I could reproduce the problem before and his patch solved it. > > What I see finally in the bug report is a > SERVER_DOWN: {'desc': "Can't contact LDAP server"} > > This can happen even with ReconnectLDAPObject. See parameters retry_max and retry_delay of ReconnectLDAPObject.__init__(): > > http://www.python-ldap.org/doc/html/ldap.html#ldap.ReconnectLDAPObject > > Also note that only synchronous method calls are retried automagically. If LDAPUserFolder uses asynchronous calls, e.g. to make use of LDAPv3 extended response controls only returned by result3() and result4(), it has to handle ldap.SERVER_DOWN itself by invoking ReconnectLDAPObject.reconnect(ls.uri) and retry the code block. The relevant code in LDAPUserFolder is try: newconn = self._connect( conn_string , user_dn , user_pwd , conn_timeout=server['conn_timeout'] , op_timeout=server['op_timeout'] ) return newconn except ( ldap.SERVER_DOWN , ldap.TIMEOUT , ldap.INVALID_CREDENTIALS ), e: continue where _connect has # Set the connection timeout if conn_timeout > 0: connection.set_option(ldap.OPT_NETWORK_TIMEOUT, conn_timeout) # Set the operations timeout if op_timeout > 0: connection.timeout = op_timeout # Now bind with the credentials given. Let exceptions propagate out. connection.simple_bind_s(user_dn, user_pwd) return connection (see http://svn.dataflake.org/svn/Products.LDAPUserFolder/tags/2.20/Products/LDAPUserFolder/LDAPDelegate.py) > > Ciao, Michael. > > From michael at stroeder.com Mon Jul 8 19:20:50 2013 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 08 Jul 2013 19:20:50 +0200 Subject: [python-ldap] Patch for ReconnectLDAPObject In-Reply-To: <27ABC044-0E75-4668-8CE6-BA54FC227C13@pretaweb.com> References: <76FA2A1C-BC29-4A98-8F84-C7C6E00A08BC@pretaweb.com> <51DA6B50.2000405@stroeder.com> <27ABC044-0E75-4668-8CE6-BA54FC227C13@pretaweb.com> Message-ID: <51DAF4F2.9060406@stroeder.com> Dylan Jay wrote: >> What I see finally in the bug report is a >> SERVER_DOWN: {'desc': "Can't contact LDAP server"} >> >> This can happen even with ReconnectLDAPObject. See parameters retry_max >> and retry_delay of ReconnectLDAPObject.__init__(): >> >> http://www.python-ldap.org/doc/html/ldap.html#ldap.ReconnectLDAPObject > > The relevant code in LDAPUserFolder is > > try: > newconn = self._connect( conn_string > , user_dn > , user_pwd > , conn_timeout=server['conn_timeout'] > , op_timeout=server['op_timeout'] > ) > return newconn > except ( ldap.SERVER_DOWN > , ldap.TIMEOUT > , ldap.INVALID_CREDENTIALS > ), e: > continue > > where _connect has > > # Set the connection timeout > if conn_timeout > 0: > connection.set_option(ldap.OPT_NETWORK_TIMEOUT, conn_timeout) > > # Set the operations timeout > if op_timeout > 0: > connection.timeout = op_timeout > > # Now bind with the credentials given. Let exceptions propagate out. > connection.simple_bind_s(user_dn, user_pwd) > > return connection > > > > (see http://svn.dataflake.org/svn/Products.LDAPUserFolder/tags/2.20/Products/LDAPUserFolder/LDAPDelegate.py) I assume for now the hanging during reconnect has been fixed by updating to python-ldap 2.4.13. The really relevant code is: try: c_factory = ldap.ldapobject.ReconnectLDAPObject except AttributeError: c_factory = ldap.ldapobject.SimpleLDAPObject [..] if not connection._type is c_factory: connection = c_factory(connection_string) So you can see that because of the fall-back to SimpleLDAPObject (likely for backward compability to ancient python-ldap releases pre-dating 09/2002) retry_max and retry_delay are not set. So with current release it will try to reconnect only once. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From gary21490 at gmail.com Sat Jul 13 00:18:03 2013 From: gary21490 at gmail.com (Gary Olivera) Date: Fri, 12 Jul 2013 15:18:03 -0700 Subject: [python-ldap] Retrieving Members in a large security group Message-ID: Hi guys, I have recently been using the search feature to query for users in OUs and members in security groups. My member search query for security groups works on smaller groups, but when I run the query on big groups it just returns an error. attrs = ['member'] filter = (&(objectCategory=group)(distinguishedName=cn=MyGroup,dc=foo,dc=bar)) search_dn = 'cn=MyGroup,dc=foo,dc=com' I have implemented paged querying for OUs and that works correctly. I haven't been able to get that to work with security groups. Am I going down the right path? How does one deal with security groups with many members. Any guidance would be greatly appreciated. Best, Gary -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan at giannuzzi.be Sat Jul 13 02:26:34 2013 From: jonathan at giannuzzi.be (Jonathan Giannuzzi) Date: Sat, 13 Jul 2013 02:26:34 +0200 Subject: [python-ldap] Patch for ReconnectLDAPObject In-Reply-To: <76FA2A1C-BC29-4A98-8F84-C7C6E00A08BC@pretaweb.com> References: <76FA2A1C-BC29-4A98-8F84-C7C6E00A08BC@pretaweb.com> Message-ID: <3A9F249B-ED82-4EBB-9315-3D300EAF3E0E@giannuzzi.be> Dylan Jay wrote: > The details of how reproduce this are in the post by Maurits van Rees > > https://bugs.launchpad.net/ldapuserfolder/+bug/650371 The last comment (#6) shows that after a failed reconnect, the next call to reconnect() will get stuck in an infinite loop. That is because the _pending_reconnect flag is not reset when the reconnection eventually fails. The fix for that is pretty easy: --- a/ldap/ldapobject.py 2013-07-13 00:31:13.000000000 +0200 +++ b/ldap/ldapobject.py 2013-07-13 00:54:10.000000000 +0200 @@ -792,6 +792,7 @@ )) reconnect_counter = reconnect_counter-1 if not reconnect_counter: + self._pending_reconnect = 0 raise if __debug__ and self._trace_level>=1: self._trace_file.write('=> delay %s...\n' % (self._retry_delay)) But that made me question why that flag was needed at all. I assumed it was in order to prevent multiple threads from calling reconnect at the same time. Unfortunately a quick test (two threads calling search_s in a loop, then kill the connection while they are running) shows that the reconnection is far from being thread-safe. The main problem is that if a call is being made while the reconnect is being done, the internal structures might be invalid (because of "del self._l" and "SimpleLDAPObject.unbind_s(self)"). So I made a patch with the following assumptions in mind: If multiple synchronous calls fail at the same time, only one reconnect should happen. This would avoid having a successful reconnect followed by another useless reconnect. When a reconnection is needed, new synchronous calls should be blocked until the reconnection is done. Pending synchronous calls need to finish before a reconnection can happen. Asynchronous calls can happen while a reconnection takes place, but we want to avoid getting AttributeError exceptions because self._l is not present anymore. Moreover, if asynchronous calls were blocked during a reconnection, we might wait indefinitely for a result with an unknown msgid. Asynchronous calls should thus be prepared to handle "LDAP connection invalid" LDAPError exceptions. One big lock for all synchronous calls (i.e. in _apply_method_s) would have a big performance impact (around 60% slower in one of my test cases). This makes the patch unfortunately quite complex. Here is what is changed: It mostly uses thread conditions to achieve those goals: one condition to control whether a reconnection is pending and another to control the amount of pending synchronous calls. This part of the patch is well commented. The call to start_tls_s done inside reconnect is done directly via SimpleLDAPObject to avoid recursively calling itself. self._l is not deleted explicitly anymore to avoid AttributeError exceptions. It is replaced by another object anyway, so it will get deleted eventually. I tested the patch a lot, but only under Python 2.7. AFAIK it should also work in previous releases, but it should be tested. Let me know if you have any comments on this. Best regards, Jonathan Giannuzzi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ldapobject_threadsafe.diff Type: application/octet-stream Size: 6743 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4145 bytes Desc: not available URL: From michael at stroeder.com Sun Jul 14 02:12:26 2013 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 14 Jul 2013 02:12:26 +0200 Subject: [python-ldap] Retrieving Members in a large security group In-Reply-To: References: Message-ID: <51E1ECEA.8000805@stroeder.com> Gary Olivera wrote: > I have recently been using the search feature to query for users in OUs and > members in security groups. My member search query for security groups > works on smaller groups, but when I run the query on big groups it just > returns an error. > > attrs = ['member'] > filter = > (&(objectCategory=group)(distinguishedName=cn=MyGroup,dc=foo,dc=bar)) > search_dn = 'cn=MyGroup,dc=foo,dc=com' > > I have implemented paged querying for OUs and that works correctly. I > haven't been able to get that to work with security groups. Am I going down > the right path? How does one deal with security groups with many members. > > Any guidance would be greatly appreciated. You're talking about MS AD. Right? Seems I already answered that a month ago: http://mail.python.org/pipermail/python-ldap/2013q2/003251.html Personally I'd rather search member entries with filter (memberOf=). I don't know your requirements though. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From python3ldap at gmail.com Wed Jul 17 22:45:41 2013 From: python3ldap at gmail.com (python3ldap) Date: Wed, 17 Jul 2013 22:45:41 +0200 Subject: [python-ldap] Python3 Ldap Client Library In-Reply-To: References: Message-ID: Hello everybody, thanks for all suggestions you sent me, I've posted an alpha version of python3-ldap on PyPi. It covers all the basic operations defined in rfc4511 and should work on Linux and Windows OS with Python3 (I'm working on backward compatability with Python2 too). If you're interested you can send me feedback at python3ldap at gmail.com. I'd like to thanks Michael and I ask him for forgiveness for the intrusion in this mailing-list. I won't send any more message here. Have fun, gc 2013/6/5 GG CC > Hi, > I'm developing a pure python ldap client library to be used in version 3 > of Python. > > My mandatory requirement are: > 1. strictly follow the latest RFC for LDAP 3 ( from rfc4510 to rfc4519) > 2. platform independent (at least for linux and Windows) architecture > 3. do not have any external dependence (no openldap client library) > 4. to be compatible with python3 and (possibly) python2 > 5. have a list of connection strategies (no thread, single thread, > multithread, event...) to choose from, either synchronous or asynchronous > 6. have a semplified query construction language > 7. have a compatibility mode for application using python-ldap > > The project will be open source. I have a basic client working (at a > pre-alpha stage) and I'm about to create a site for hosting it. I've made a > package submission on pypi for python3-ldap (I'm not sure if this will be > the name), but there is no code available yet. > > A bit more info about the previous requirements: > > 1. Latest RFC for ldap v3 (dated 2006) obsoletes the previous RFC > specified in rfc3377 (2251-2256, 2829, 2830, 3371) for ldap v3 and amend > and clarify the ldap protocol. I've already rewritten all the asn1 > definitions from the rfc4511 because those in the pyasn1_modules package > are not current with the RFC. > > 2. The library should run on Windows and Linux with no differences. > > 3. I usually work on Linux and Windows boxes and each time have to install > the current python-ldap library from different sources. My library should > be directly installed from pypi using pip or a similar package manager on > both platforms. With python-ldap on Windows I can't use pip to update the > library from the CheeseShop so I do not want to have any dependencies, > installation should be the same on both platforms. Socket and thread > programming should be appropriate for the platform used, with no changes > needed in the configuration. My library should depend on the standard > library and (for now) on the pyasn1 package only. > > 4. I'm writing and testing the library in Python 3, but it should > (hopefully) be compatible with Python 2. Unicode strings are appropriately > converted. > > 5. I'm not sure about which connection strategy is the best to use on ldap > messages communication, so I'm writing a connection object with a > "pluggable" socket connection strategy. For now I have "sync-nothread" and > "async-blocking-threaded" strategies, maybe I'll add a > "async-multiprocess-blocking" strategy and an "event-nonblocking-strategy". > > 6. I've already developed (for another project) an "abstraction layer" for > ldap query. For example I can define "application fields" that maps to ldap > attributes with a validate, prequery-transformation, > postquery-transformation and a simplified query language. I think it could > be helpful to extend the abstration to add/modify/delete and include this > abstraction layer in the library to (optionally) simplify ldap usage. The > following is an excerpt from my other project: > > > # This is the definition of an abstract "Role" class mapped to an ldap > object of class "CustomRole". > # Fields maps to attributes (roleName to LocalizedName, roleLevel to > RoleLevel, roleOwner to owner') > # attr is the name of the attribute in ldap > # multivalue fields are returned as a list of values > # validation is a function to be executed with the value of the field. It > it's non True the field is not added to the query > # preQuery is a function to be executed to transform the value of the > field before the query is executed > # postQuery is a function to be executed to transform the response values > of the query > # default is a value to be returned if the query for that attribute is > empty > > class Role(_ldapBase): > LDAPClass = 'CustomRole' > baseLDAP = 'ou=roles,o=company') > attrDefs = { > 'roleName': { > 'attr': 'CustomRoleName', > 'multivalue': False, > 'validation': None, > 'preQuery': lambda attrName, attrValue: > Role._filterName('nrfLocalizedNames', AttrName, AttrValue), > 'postQuery': lambda a: Role._getCustomName(a), > 'default': 'no-role' > }, > 'roleLevel': { > 'attr': 'RoleLevel', > 'multivalue': False, > 'validation': lambda value: True if value in ['1', > '2', '3'] else False, > 'preQuery': None, > 'postQuery': None, > 'default': '' > }, > 'roleOwner': { > 'attr': 'owner', > 'multivalue': True, > 'validation': None, > 'preQuery': None, > 'postQuery': None, > 'default': [] > }, > } > > when I execute a query on this class I can use something like: > roleName:admin,user roleLevel:3 > and get the result for the following search filter: > (&(|(CustomRoleName=admin_role)(CustomRoleName=admin_role))(RoleLevel > = 3)). > > > 7. I have developed different projects that use the python-ldap library. > I'd like to convert them to python3 without changing what I've already done > for the ldap part. So it should be (ideally) enough just to change the > import from python-ldap to python3-ldap (or whatever the name of the > library will be). > > I'm writing in this list to know if anybody is interested in this kind of > project and have suggestions or hints on how to go on. > > Thanks, > gc > > ps. I admit the reading RFCs is not one of the most interesting things to > do in your spare time... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcasale at activenetwerx.com Tue Jul 23 04:01:57 2013 From: jcasale at activenetwerx.com (Joseph L. Casale) Date: Tue, 23 Jul 2013 02:01:57 +0000 Subject: [python-ldap] modrdn changeTypes Message-ID: I need to modify the cn and ou components of several AD users through ldif files and cannot perform the operation over ldap. Does the ldif module support writing such types? Thanks, jlc From michael at stroeder.com Tue Jul 23 09:13:42 2013 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 23 Jul 2013 09:13:42 +0200 Subject: [python-ldap] modrdn changeTypes In-Reply-To: References: Message-ID: <51EE2D26.6020500@stroeder.com> Joseph L. Casale wrote: > I need to modify the cn and ou components of several AD users through > ldif files and cannot perform the operation over ldap. Does the ldif module > support writing such types? Writing LDIF change records is not well supported by module ldif. This really needs work. You could try to sub-class LDIFWriter and extend/modify methods unparse() and _unparseChangeRecord(). BTW: In former times my idea was to implement a drop-in replacement for LDAPObject which simply writes LDIF instead of performing the LDAP operations. But I currently don't have the time for that. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From pythonml at ledeuns.net Mon Aug 12 11:34:51 2013 From: pythonml at ledeuns.net (Denis Fondras) Date: Mon, 12 Aug 2013 11:34:51 +0200 Subject: [python-ldap] Patching python-ldap to compile with OpenBSD 5.3 Message-ID: <5208AC3B.5050704@ledeuns.net> Hello all, When installing openldap-client library on OpenBSD 5.3, include files are copied to /usr/local/include. Include directory of python-ldap only specifies /usr/include and thus can't find the include files when building. Here is a small patch to correct that behaviour : ---8<-------------------- --- setup.cfg.orig 2013-08-12 11:28:46.547336143 +0200 +++ setup.cfg 2013-08-12 11:29:08.118817124 +0200 @@ -1,6 +1,6 @@ [_ldap] library_dirs = /opt/openldap-RE24/lib /usr/lib -include_dirs = /opt/openldap-RE24/include /usr/include/sasl /usr/include +include_dirs = /opt/openldap-RE24/include /usr/include/sasl /usr/include /usr/local/include /usr/local/include/sasl defines = HAVE_SASL HAVE_TLS HAVE_LIBLDAP_R extra_compile_args = extra_objects = ---8<-------------------- Regards, Denis From michael at stroeder.com Mon Aug 12 11:55:14 2013 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 12 Aug 2013 11:55:14 +0200 Subject: [python-ldap] Patching python-ldap to compile with OpenBSD 5.3 In-Reply-To: <5208AC3B.5050704@ledeuns.net> References: <5208AC3B.5050704@ledeuns.net> Message-ID: <5208B102.9070504@stroeder.com> Denis Fondras wrote: > When installing openldap-client library on OpenBSD 5.3, include files > are copied to /usr/local/include. Include directory of python-ldap only > specifies /usr/include and thus can't find the include files when > building. Here is a small patch to correct that behaviour : Hmm, there's a common misunderstanding regarding setup.cfg: The aim is not to provide a setup.cfg which is usable out-of-the-box on each and every platform. I personally don't know whether that would be possible at all. It's rather meant to be tweaked to match the local system configuration. The files beneath Build/ of the source distribution are meant to be rough examples for various platforms. I'd appreciate text for http://www.python-ldap.org/doc/html/installing.html#setup-cfg to make that even more clear. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From mailinglist0 at skurfer.com Mon Aug 12 15:51:11 2013 From: mailinglist0 at skurfer.com (Rob McBroom) Date: Mon, 12 Aug 2013 09:51:11 -0400 Subject: [python-ldap] Patching python-ldap to compile with OpenBSD 5.3 In-Reply-To: <5208B102.9070504@stroeder.com> References: <5208AC3B.5050704@ledeuns.net> <5208B102.9070504@stroeder.com> Message-ID: <39B71149-58E4-488F-BA34-107BE7F3E066@skurfer.com> On Mon Aug 12 2013 at 05:55:14, Michael Str?der wrote: > Hmm, there's a common misunderstanding regarding setup.cfg: > > The aim is not to provide a setup.cfg which is usable out-of-the-box on each > and every platform. I personally don't know whether that would be possible at > all. It's rather meant to be tweaked to match the local system configuration. Isn?t that a round-about way of saying ?You should never expect `pip` or `easy_install` to actually work.?? Because I don?t think that matches most people?s expectations. Maybe they?re all wrong, but it?s something to consider. > The files beneath Build/ of the source distribution are meant to be rough > examples for various platforms. I agree that you shouldn?t try to list everything under the sun, but `/usr/local` doesn?t strike me as a bizarre one-off. `/opt/openldap-RE24`, on the other hand? ;-) -- Rob McBroom From zhbmaillistonly at gmail.com Tue Aug 27 17:53:16 2013 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Tue, 27 Aug 2013 23:53:16 +0800 Subject: [python-ldap] import _ldap: ImportError: Cannot load specified object Message-ID: <71C87DC0C71F4E15BDEAFF5DE25FEA35@gmail.com> Dear developers, I tried to run my python web application on OpenBSD 5.3 with python-ldap-2.4.13, but it raises below error message: import _ldap ImportError: Cannot load specified object I'm not sure whether it's a bug of my application or python-ldap, so i wrote a simple cgi script to test it again, got the same error. The CGI script is really simple: #!/usr/local/bin/python2.7 import ldap print "Content-Type: text/html" print '' The full error log in Apache (unchrooted) log file: Traceback (most recent call last): File "/var/www/cgi-bin/test.py", line 2, in import ldap File "/usr/local/lib/python2.7/site-packages/python_ldap-2.4.13-py2.7-openbsd-5.3-amd64.egg/ldap/__init__.py", line 22, in import _ldap ImportError: Cannot load specified object [Tue Aug 27 23:51:28 2013] [error] [client 172.16.244.1] Premature end of script headers: /var/www/cgi-bin/test.py I installed python-ldap-2.4.13 manually, and it works within Python interpreter: $ python >>> import ldap >>> import _ldap >>> from _ldap import * I can see file _ldap.* below: # ls /usr/local/lib/python2.7/site-packages/python_ldap-2.4.13-py2.7-openbsd-5.3-amd64.egg/_ldap* /usr/local/lib/python2.7/site-packages/python_ldap-2.4.13-py2.7-openbsd-5.3-amd64.egg/_ldap.py /usr/local/lib/python2.7/site-packages/python_ldap-2.4.13-py2.7-openbsd-5.3-amd64.egg/_ldap.pyc /usr/local/lib/python2.7/site-packages/python_ldap-2.4.13-py2.7-openbsd-5.3-amd64.egg/_ldap.pyo /usr/local/lib/python2.7/site-packages/python_ldap-2.4.13-py2.7-openbsd-5.3-amd64.egg/_ldap.so Is it a python-ldap issue? Any solution? From michael at stroeder.com Tue Aug 27 21:05:25 2013 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 27 Aug 2013 21:05:25 +0200 Subject: [python-ldap] import _ldap: ImportError: Cannot load specified object In-Reply-To: <71C87DC0C71F4E15BDEAFF5DE25FEA35@gmail.com> References: <71C87DC0C71F4E15BDEAFF5DE25FEA35@gmail.com> Message-ID: <521CF875.6050001@stroeder.com> Zhang Huangbin wrote: > I tried to run my python web application on OpenBSD 5.3 with python-ldap-2.4.13, but it raises below error message: > > import _ldap > ImportError: Cannot load specified object > I installed python-ldap-2.4.13 manually, and it works within Python interpreter: > [..] > $ python >>>> import ldap >>>> import _ldap >>>> from _ldap import * > > I can see file _ldap.* below: > > # ls /usr/local/lib/python2.7/site-packages/python_ldap-2.4.13-py2.7-openbsd-5.3-amd64.egg/_ldap* > /usr/local/lib/python2.7/site-packages/python_ldap-2.4.13-py2.7-openbsd-5.3-amd64.egg/_ldap.py > /usr/local/lib/python2.7/site-packages/python_ldap-2.4.13-py2.7-openbsd-5.3-amd64.egg/_ldap.pyc > /usr/local/lib/python2.7/site-packages/python_ldap-2.4.13-py2.7-openbsd-5.3-amd64.egg/_ldap.pyo > /usr/local/lib/python2.7/site-packages/python_ldap-2.4.13-py2.7-openbsd-5.3-amd64.egg/_ldap.so Is there any permissions problem? Does python -c "import ldap" also work when invoked as the web application's user? Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From zhbmaillistonly at gmail.com Wed Aug 28 01:40:17 2013 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Wed, 28 Aug 2013 07:40:17 +0800 Subject: [python-ldap] import _ldap: ImportError: Cannot load specified object In-Reply-To: <521CF875.6050001@stroeder.com> References: <71C87DC0C71F4E15BDEAFF5DE25FEA35@gmail.com> <521CF875.6050001@stroeder.com> Message-ID: <211C7EF878F64C4197F07BFF23419C1D@gmail.com> On Wednesday, August 28, 2013 at 3:05 AM, Michael Str?der wrote: > Is there any permissions problem? > Does > python -c "import ldap" > also work when invoked as the web application's user? You're right. I cannot import module as the Apache daemon user "www". # chsh -s /bin/sh www # su - www $ python -c "import ldap" Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.7/site-packages/python_ldap-2.4.13-py2.7-openbsd-5.3-amd64.egg/ldap/__init__.py", line 22, in import _ldap ImportError: Cannot load specified object I try to trace it to see if there's any permission related issue, and i got it solved. Here's what i did: 1) Create a python file with only one line: "import ldap". 2) Trace it with command "ktrace" (it's an alternative for "strace" on Linux): # su - www $ ktrace -t + python 1.py # <- Got error like before: "ImportError: Cannot load specified object" $ kdump -f ktrace.out | grep -2 -i 'permission denied' 30863 python2.7 CALL open(0x16a25bfbf771,0) 30863 python2.7 NAMI "/usr/local/lib/libsasl2.so.3.0" 30863 python2.7 RET open -1 errno 13 Permission denied As you can see, it cannot load file "/usr/local/lib/libsasl2.so.3.0". I checked its permission: -rwx------ 1 root bin 123670 Feb 26 2013 /usr/local/lib/libsasl2.so.3.0 Fix it: # chmod +rx /usr/local/lib/libsasl2.so.3.0 And now my web application works. Thanks very much for your help. :) From zhbmaillistonly at gmail.com Wed Aug 28 02:16:41 2013 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Wed, 28 Aug 2013 08:16:41 +0800 Subject: [python-ldap] import _ldap: ImportError: Cannot load specified object In-Reply-To: <211C7EF878F64C4197F07BFF23419C1D@gmail.com> References: <71C87DC0C71F4E15BDEAFF5DE25FEA35@gmail.com> <521CF875.6050001@stroeder.com> <211C7EF878F64C4197F07BFF23419C1D@gmail.com> Message-ID: <6CDDD0139C3E4304A3BCFB48C90D423A@gmail.com> On Wednesday, August 28, 2013 at 7:40 AM, Zhang Huangbin wrote: > Fix it: > > # chmod +rx /usr/local/lib/libsasl2.so.3.0 > > And now my web application works. Sorry guys, "chmod +x" is enough. The final permission is: rw-r--r--. From djay at pretaweb.com Wed Aug 28 04:21:43 2013 From: djay at pretaweb.com (Dylan Jay) Date: Wed, 28 Aug 2013 12:21:43 +1000 Subject: [python-ldap] Patch for ReconnectLDAPObject In-Reply-To: <3A9F249B-ED82-4EBB-9315-3D300EAF3E0E@giannuzzi.be> References: <76FA2A1C-BC29-4A98-8F84-C7C6E00A08BC@pretaweb.com> <3A9F249B-ED82-4EBB-9315-3D300EAF3E0E@giannuzzi.be> Message-ID: Hi, This patch seems to work really well. Any chance of getting it included in a release? --- Dylan Jay Technical Solutions Manager PretaWeb: Multisite Performance Support P: +612 80819071 | M: +61421477460 | twitter.com/pretaweb | linkedin.com/in/djay75 On 13/07/2013, at 10:26 AM, Jonathan Giannuzzi wrote: > Dylan Jay wrote: >> The details of how reproduce this are in the post by Maurits van Rees >> >> https://bugs.launchpad.net/ldapuserfolder/+bug/650371 > > The last comment (#6) shows that after a failed reconnect, the next call to reconnect() will get stuck in an infinite loop. > That is because the _pending_reconnect flag is not reset when the reconnection eventually fails. > The fix for that is pretty easy: > > --- a/ldap/ldapobject.py 2013-07-13 00:31:13.000000000 +0200 > +++ b/ldap/ldapobject.py 2013-07-13 00:54:10.000000000 +0200 > @@ -792,6 +792,7 @@ > )) > reconnect_counter = reconnect_counter-1 > if not reconnect_counter: > + self._pending_reconnect = 0 > raise > if __debug__ and self._trace_level>=1: > self._trace_file.write('=> delay %s...\n' % (self._retry_delay)) > > But that made me question why that flag was needed at all. I assumed it was in order to prevent multiple threads from calling reconnect at the same time. > Unfortunately a quick test (two threads calling search_s in a loop, then kill the connection while they are running) shows that the reconnection is far from being thread-safe. > The main problem is that if a call is being made while the reconnect is being done, the internal structures might be invalid (because of "del self._l" and "SimpleLDAPObject.unbind_s(self)"). > > So I made a patch with the following assumptions in mind: > ? If multiple synchronous calls fail at the same time, only one reconnect should happen. This would avoid having a successful reconnect followed by another useless reconnect. > ? When a reconnection is needed, new synchronous calls should be blocked until the reconnection is done. > ? Pending synchronous calls need to finish before a reconnection can happen. > ? Asynchronous calls can happen while a reconnection takes place, but we want to avoid getting AttributeError exceptions because self._l is not present anymore. > ? Moreover, if asynchronous calls were blocked during a reconnection, we might wait indefinitely for a result with an unknown msgid. Asynchronous calls should thus be prepared to handle "LDAP connection invalid" LDAPError exceptions. > ? One big lock for all synchronous calls (i.e. in _apply_method_s) would have a big performance impact (around 60% slower in one of my test cases). > > This makes the patch unfortunately quite complex. Here is what is changed: > ? It mostly uses thread conditions to achieve those goals: one condition to control whether a reconnection is pending and another to control the amount of pending synchronous calls. This part of the patch is well commented. > ? The call to start_tls_s done inside reconnect is done directly via SimpleLDAPObject to avoid recursively calling itself. > ? self._l is not deleted explicitly anymore to avoid AttributeError exceptions. It is replaced by another object anyway, so it will get deleted eventually. > ? > I tested the patch a lot, but only under Python 2.7. AFAIK it should also work in previous releases, but it should be tested. > > Let me know if you have any comments on this. > > Best regards, > Jonathan Giannuzzi > From lists at steffen-moser.de Thu Aug 29 19:36:10 2013 From: lists at steffen-moser.de (Steffen Moser) Date: Thu, 29 Aug 2013 19:36:10 +0200 Subject: [python-ldap] Solaris, Python-LDAP, Apache: SEGFAULT due to shared library mismatch? Message-ID: <521F868A.4050904@steffen-moser.de> Hi all, I've got a problem with Python-LDAP on our Solaris 11 based work- group and storage server which is mainly used to host a bunch of web applications (based on PHP and Python). Let me recap the basic data: - Solaris 11.1 (x86_64) - Apache/2.2.24 (Unix) DAV/2 mod_wsgi/3.3 Python/2.6.8 mod_ssl/2.2.24 OpenSSL/1.0.0k - Python-LDAP 2.4.13 (self-compiled and linked against OpenLDAP 2.4.30) Compilation and installation of Python-LDAP worked well, but as soon as a Python script actually uses the LDAP connection, the web server worker process dies with a "Segmentation Fault". When I deactivate the Apache module "mod_ldap.so", the problem is gone and Python-LDAP seems to run quite fine, but the thing is: The Apache web server also hosts applications which actually need "mod_ldap.so" and PHP, so I can't go for that solution. I suppose that I've found the cause for the problem. While everything which is related to Apache (the Apache modules, PHP, and so on), comes with Oracle Solaris and needs LDAP is linked to Oracle's own LDAP library "/usr/lib/libldap.so.5". This is, for example, the case for Apache's "mod_ldap.so": | smoser at regulus:~# ldd /usr/apache2/2.2/libexec/mod_ldap.so | libldap.so.5 => /usr/lib/libldap.so.5 | libc.so.1 => /lib/libc.so.1 | libsasl.so.1 => /usr/lib/libsasl.so.1 | libsocket.so.1 => /lib/libsocket.so.1 | libnsl.so.1 => /lib/libnsl.so.1 | libmd.so.1 => /lib/libmd.so.1 | libnspr4.so => /usr/lib/mps/libnspr4.so | libplc4.so => /usr/lib/mps/libplc4.so | libnss3.so => /usr/lib/mps/libnss3.so | libssl3.so => /usr/lib/mps/libssl3.so | libmp.so.2 => /lib/libmp.so.2 | libsoftcrypto.so.1 => /lib/libsoftcrypto.so.1 | libelf.so.1 => /lib/libelf.so.1 | libpthread.so.1 => /lib/libpthread.so.1 | librt.so.1 => /lib/librt.so.1 | libdl.so.1 => /lib/libdl.so.1 | libnssutil3.so => /usr/lib/mps/libnssutil3.so | libplds4.so => /usr/lib/mps/libplds4.so | libthread.so.1 => /lib/libthread.so.1 | libcryptoutil.so.1 => /lib/libcryptoutil.so.1 | libm.so.2 => /lib/libm.so.2 Python-LDAP is depending on OpenLDAP, so I can't link it against Sun's LDAP libraries (as stated in the FAQs of Python-LDAP): | smoser at regulus:~# ldd /usr/lib/python2.6/site-packages/python_ldap-2.4.13-py2.6-solaris-2.11-i86pc.egg/_ldap.so | libldap-2.4.so.2 => /usr/lib/libldap-2.4.so.2 | liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 | libsasl.so.1 => /usr/lib/libsasl.so.1 | libssl.so.1.0.0 => /lib/libssl.so.1.0.0 | libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0 | libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 | libresolv.so.2 => /lib/libresolv.so.2 | libnsl.so.1 => /lib/libnsl.so.1 | libsocket.so.1 => /lib/libsocket.so.1 | libc.so.1 => /lib/libc.so.1 | libmd.so.1 => /lib/libmd.so.1 | libdl.so.1 => /lib/libdl.so.1 | libm.so.2 => /lib/libm.so.2 | libmp.so.2 => /lib/libmp.so.2 | libsoftcrypto.so.1 => /lib/libsoftcrypto.so.1 | libelf.so.1 => /lib/libelf.so.1 | libcryptoutil.so.1 => /lib/libcryptoutil.so.1 So my questions are: - Can anybody confirm that this is really the probable cause for the problem that we've encountered? - Is there any way to get both LDAP libraries to work in one instance of apache? - Can I link the OpenLDAP libs statically or won't that help? - I am not an expert in linking programs in Solaris, but is it possible to have the OpenLDAP libraries linked to a separate namespace so that they don't interfere in Apache? As far as I know, my options will be: - Re-compile Apache and everything that depends on it by linking all the LDAP related things to OpenLDAP libs. - Run two instances of Apache on two different ports: One for the PHP applications and one for the Python applications. The one for Python applications must not load any module that is linked against Oracle's LDAP lib while the one for the other applications must not load any module that is linked against OpenLDAP lib. - Modify Python-LDAP that it can be linked against Oracle's LDAP library (I assume that this is really a _lot_ of work). - Are there any other options that I might have missed? I would be very glad if someone could help me. Thank you very much in advance! Kind regards, Steffen From michael at stroeder.com Thu Aug 29 19:46:52 2013 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 29 Aug 2013 19:46:52 +0200 Subject: [python-ldap] Solaris, Python-LDAP, Apache: SEGFAULT due to shared library mismatch? In-Reply-To: <521F868A.4050904@steffen-moser.de> References: <521F868A.4050904@steffen-moser.de> Message-ID: <521F890C.2080806@stroeder.com> Steffen Moser wrote: > - Python-LDAP 2.4.13 (self-compiled and linked against OpenLDAP > 2.4.30) > > Compilation and installation of Python-LDAP worked well, but as soon > as a Python script actually uses the LDAP connection, the web server > worker process dies with a "Segmentation Fault". > > When I deactivate the Apache module "mod_ldap.so", the problem is > gone and Python-LDAP seems to run quite fine, I suspect mod_ldap is using a different flavour/version of libldap. Make sure python-ldap and Apache's mod_ldap are linked against the very same libldap. Check with ldd or whatever tool like this is available on Solaris. Ciao, Michael. P.S.: Only mailing list subscribers can directly post to the list. Please subscribe to the (low-traffic) list so I don't have to manually approve your posting and others can answer/learn as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From chris.dukes.aix at gmail.com Thu Aug 29 20:08:30 2013 From: chris.dukes.aix at gmail.com (Chris Dukes) Date: Thu, 29 Aug 2013 14:08:30 -0400 Subject: [python-ldap] Solaris, Python-LDAP, Apache: SEGFAULT due to shared library mismatch? In-Reply-To: <521F868A.4050904@steffen-moser.de> References: <521F868A.4050904@steffen-moser.de> Message-ID: <521F8E1E.1030307@gmail.com> Steffen, I had similar headaches with Apache and python-ldap and Django and AIX. In the end I tossed mod_wsgi for apache and went with one of the fastcgi modules and the python pieces as a separate daemon. Our load was fairly low, so the fastcgi daemon capability that ships with Django was enough. If load had been higher I'd have gone with greenunicorn and moved the python bits to Linux. On 08/29/2013 01:36 PM, Steffen Moser wrote: > Hi all, > > I've got a problem with Python-LDAP on our Solaris 11 based work- > group and storage server which is mainly used to host a bunch of > web applications (based on PHP and Python). > > Let me recap the basic data: > > - Solaris 11.1 (x86_64) > > - Apache/2.2.24 (Unix) DAV/2 mod_wsgi/3.3 Python/2.6.8 > mod_ssl/2.2.24 OpenSSL/1.0.0k > > - Python-LDAP 2.4.13 (self-compiled and linked against OpenLDAP > 2.4.30) > > Compilation and installation of Python-LDAP worked well, but as soon > as a Python script actually uses the LDAP connection, the web server > worker process dies with a "Segmentation Fault". > > When I deactivate the Apache module "mod_ldap.so", the problem is > gone and Python-LDAP seems to run quite fine, but the thing is: The > Apache web server also hosts applications which actually need > "mod_ldap.so" and PHP, so I can't go for that solution. > > I suppose that I've found the cause for the problem. While everything > which is related to Apache (the Apache modules, PHP, and so on), comes > with Oracle Solaris and needs LDAP is linked to Oracle's own LDAP > library "/usr/lib/libldap.so.5". > > This is, for example, the case for Apache's "mod_ldap.so": > > | smoser at regulus:~# ldd /usr/apache2/2.2/libexec/mod_ldap.so > | libldap.so.5 => /usr/lib/libldap.so.5 > | libc.so.1 => /lib/libc.so.1 > | libsasl.so.1 => /usr/lib/libsasl.so.1 > | libsocket.so.1 => /lib/libsocket.so.1 > | libnsl.so.1 => /lib/libnsl.so.1 > | libmd.so.1 => /lib/libmd.so.1 > | libnspr4.so => /usr/lib/mps/libnspr4.so > | libplc4.so => /usr/lib/mps/libplc4.so > | libnss3.so => /usr/lib/mps/libnss3.so > | libssl3.so => /usr/lib/mps/libssl3.so > | libmp.so.2 => /lib/libmp.so.2 > | libsoftcrypto.so.1 => /lib/libsoftcrypto.so.1 > | libelf.so.1 => /lib/libelf.so.1 > | libpthread.so.1 => /lib/libpthread.so.1 > | librt.so.1 => /lib/librt.so.1 > | libdl.so.1 => /lib/libdl.so.1 > | libnssutil3.so => /usr/lib/mps/libnssutil3.so > | libplds4.so => /usr/lib/mps/libplds4.so > | libthread.so.1 => /lib/libthread.so.1 > | libcryptoutil.so.1 => /lib/libcryptoutil.so.1 > | libm.so.2 => /lib/libm.so.2 > > > Python-LDAP is depending on OpenLDAP, so I can't link it against > Sun's LDAP libraries (as stated in the FAQs of Python-LDAP): > > | smoser at regulus:~# ldd /usr/lib/python2.6/site-packages/python_ldap-2.4.13-py2.6-solaris-2.11-i86pc.egg/_ldap.so > | libldap-2.4.so.2 => /usr/lib/libldap-2.4.so.2 > | liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 > | libsasl.so.1 => /usr/lib/libsasl.so.1 > | libssl.so.1.0.0 => /lib/libssl.so.1.0.0 > | libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0 > | libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 > | libresolv.so.2 => /lib/libresolv.so.2 > | libnsl.so.1 => /lib/libnsl.so.1 > | libsocket.so.1 => /lib/libsocket.so.1 > | libc.so.1 => /lib/libc.so.1 > | libmd.so.1 => /lib/libmd.so.1 > | libdl.so.1 => /lib/libdl.so.1 > | libm.so.2 => /lib/libm.so.2 > | libmp.so.2 => /lib/libmp.so.2 > | libsoftcrypto.so.1 => /lib/libsoftcrypto.so.1 > | libelf.so.1 => /lib/libelf.so.1 > | libcryptoutil.so.1 => /lib/libcryptoutil.so.1 > > > So my questions are: > > - Can anybody confirm that this is really the probable cause for the > problem that we've encountered? > > - Is there any way to get both LDAP libraries to work in one > instance of apache? > > - Can I link the OpenLDAP libs statically or won't that help? > > - I am not an expert in linking programs in Solaris, but is it > possible to have the OpenLDAP libraries linked to a separate > namespace so that they don't interfere in Apache? > > > As far as I know, my options will be: > > - Re-compile Apache and everything that depends on it by linking > all the LDAP related things to OpenLDAP libs. > > - Run two instances of Apache on two different ports: One for the > PHP applications and one for the Python applications. The one for > Python applications must not load any module that is linked against > Oracle's LDAP lib while the one for the other applications must not > load any module that is linked against OpenLDAP lib. > > - Modify Python-LDAP that it can be linked against Oracle's LDAP > library (I assume that this is really a _lot_ of work). > > - Are there any other options that I might have missed? > > > I would be very glad if someone could help me. Thank you very much > in advance! > > Kind regards, > Steffen > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap From lists at steffen-moser.de Thu Aug 29 22:48:08 2013 From: lists at steffen-moser.de (Steffen Moser) Date: Thu, 29 Aug 2013 22:48:08 +0200 Subject: [python-ldap] Solaris, Python-LDAP, Apache: SEGFAULT due to shared library mismatch? In-Reply-To: <521F890C.2080806@stroeder.com> References: <521F868A.4050904@steffen-moser.de> <521F890C.2080806@stroeder.com> Message-ID: <521FB388.4080902@steffen-moser.de> Hi Michael, On 8/29/13 7:46 PM, Michael Str?der wrote: > Steffen Moser wrote: >> - Python-LDAP 2.4.13 (self-compiled and linked against OpenLDAP >> 2.4.30) >> >> Compilation and installation of Python-LDAP worked well, but as soon >> as a Python script actually uses the LDAP connection, the web server >> worker process dies with a "Segmentation Fault". >> >> When I deactivate the Apache module "mod_ldap.so", the problem is >> gone and Python-LDAP seems to run quite fine, > > I suspect mod_ldap is using a different flavour/version of libldap. Make sure > python-ldap and Apache's mod_ldap are linked against the very same libldap. OK, then this is -as suspected- definitively the cause of my problem... > Check with ldd or whatever tool like this is available on Solaris. Yes, "ldd" is available and this tool showed it. > P.S.: Only mailing list subscribers can directly post to the list. Please > subscribe to the (low-traffic) list so I don't have to manually approve your > posting and others can answer/learn as well. Thank you for this information, but as far as I know, I had success- fully subscribed (using the Mailman web interface) to the list before posting. I had, of course, also confirmed the subscription and had gotten the "Welcome message". The mail I got after sending my message to the list, was: | Your mail to 'python-ldap' with the subject | | Solaris, Python-LDAP, Apache: SEGFAULT due to shared library | mismatch? | | Is being held until the list moderator can review it for approval. | | The reason it is being held: | | Post to moderated list Regards, Steffen From lists at steffen-moser.de Thu Aug 29 23:19:42 2013 From: lists at steffen-moser.de (Steffen Moser) Date: Thu, 29 Aug 2013 23:19:42 +0200 Subject: [python-ldap] Solaris, Python-LDAP, Apache: SEGFAULT due to shared library mismatch? In-Reply-To: <521F8E1E.1030307@gmail.com> References: <521F868A.4050904@steffen-moser.de> <521F8E1E.1030307@gmail.com> Message-ID: <521FBAEE.9080702@steffen-moser.de> Hi Chris, On 8/29/13 8:08 PM, Chris Dukes wrote: > Steffen, > > I had similar headaches with Apache and python-ldap and Django and AIX. So presumably the same problem: AIX also comes with its own, proprietary LDAP libraries... > In the end I tossed mod_wsgi for apache and went with one of the fastcgi > modules and the python pieces as a separate daemon. OK, that would be an option. > Our load was fairly low, so the fastcgi daemon capability that ships > with Django was enough. I'll propose that to our Python developer tomorrow. As far as I can estimate the load that the application will cause, this should suffice for us. Thank you very much for your hint! > If load had been higher I'd have gone with greenunicorn and moved the > python bits to Linux. I also thought about this. We have some Linux VMs running on our big Solaris box, so that would also be an option. But, I think, FastCGI should most probably be the solution for us. Regards, Steffen From michael at stroeder.com Thu Aug 29 23:36:59 2013 From: michael at stroeder.com (=?windows-1252?Q?Michael_Str=F6der?=) Date: Thu, 29 Aug 2013 23:36:59 +0200 Subject: [python-ldap] Patch for ReconnectLDAPObject In-Reply-To: <44A4A60B-A03F-4B1B-83AE-A441797C99BC@giannuzzi.be> References: <76FA2A1C-BC29-4A98-8F84-C7C6E00A08BC@pretaweb.com> <3A9F249B-ED82-4EBB-9315-3D300EAF3E0E@giannuzzi.be> <44A4A60B-A03F-4B1B-83AE-A441797C99BC@giannuzzi.be> Message-ID: <521FBEFB.1030505@stroeder.com> Jonathan Giannuzzi wrote: > Dylan Jay wrote: >> This patch seems to work really well. Any chance of getting it included in a release? > > What is your view on this patch? It's on my to-do list to carefully look at it. Maybe during the next days... > Are there any specific issues preventing it from getting merged? Hmm, in former times there were Python installations built without threading support. So I'm a bit cautious regarding backward compability. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Thu Aug 29 23:40:17 2013 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 29 Aug 2013 23:40:17 +0200 Subject: [python-ldap] Solaris, Python-LDAP, Apache: SEGFAULT due to shared library mismatch? In-Reply-To: <521FBAEE.9080702@steffen-moser.de> References: <521F868A.4050904@steffen-moser.de> <521F8E1E.1030307@gmail.com> <521FBAEE.9080702@steffen-moser.de> Message-ID: <521FBFC1.8000300@stroeder.com> Steffen Moser wrote: > On 8/29/13 8:08 PM, Chris Dukes wrote: >> In the end I tossed mod_wsgi for apache and went with one of the fastcgi >> modules and the python pieces as a separate daemon. > > OK, that would be an option. Your options very much depend on your architecture which only you know. Another option would be to simply put a reverse proxy with mod_proxy and mod_ldap in front of your Apache server running the PHP and Python applications. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From jonathan at giannuzzi.be Fri Aug 30 20:10:28 2013 From: jonathan at giannuzzi.be (Jonathan Giannuzzi) Date: Fri, 30 Aug 2013 20:10:28 +0200 Subject: [python-ldap] Patch for ReconnectLDAPObject In-Reply-To: <521FBEFB.1030505@stroeder.com> References: <76FA2A1C-BC29-4A98-8F84-C7C6E00A08BC@pretaweb.com> <3A9F249B-ED82-4EBB-9315-3D300EAF3E0E@giannuzzi.be> <44A4A60B-A03F-4B1B-83AE-A441797C99BC@giannuzzi.be> <521FBEFB.1030505@stroeder.com> Message-ID: <05BF9838-2D85-4671-A548-3C6865C77603@giannuzzi.be> Michael Str?der wrote: > Jonathan Giannuzzi wrote: >> Dylan Jay wrote: >>> This patch seems to work really well. Any chance of getting it included in a release? >> >> What is your view on this patch? > > It's on my to-do list to carefully look at it. Maybe during the next days... > >> Are there any specific issues preventing it from getting merged? > > Hmm, in former times there were Python installations built without threading > support. So I'm a bit cautious regarding backward compability. I was using dummy_threading as a fallback for Python installations built without threading, which was introduced in Python 2.3. On top of that, I was using the PEP8-compliant API (thus no camelCase) which was introduced in Python 2.6. In order to be more compatible, I changed the patch to use a dummy condition instead of dummy_threading (similar to DummyLock in ldap/__init__.py) I also changed it to use the camelCase threading API. AFAIK, it should work against Python >= 1.5.1, with or without threads. I tested it against Python 2.5 (threads), 2.6 (threads and no threads) and 2.7 (threads and no threads). Unfortunately I don't have easy access to older installations of Python. Best regards, Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: ldapobject_threadsafe_compatible.diff Type: application/octet-stream Size: 7145 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4145 bytes Desc: not available URL: From python3ldap at gmail.com Wed Sep 4 17:10:03 2013 From: python3ldap at gmail.com (python3ldap) Date: Wed, 4 Sep 2013 17:10:03 +0200 Subject: [python-ldap] Python3-ldap 0.5.3-alpha released! Message-ID: Hello everybody, I've a bunch of new features for the python3-ldap library: - Added Info from DSE (in server.info) - Added connection usage (in connection.usage if collectUsage=True in connection definition) - Added getOperationalAttributes boolean to Search operation to fetch the operational attributes during searches - Added increment operation to modify operation as per rfc 4525 - Added dictionary of OID description (for DSE and schema decoding) - Added Info from DSE (in server.info) - Added connection usage (in connection.usage if collectUsage=True in connection definition) - Modified exceptions for sending controls in LDAP request - Fixed StartTls in asynchronous client strategy I've created a dictionary of OID to decode supported features/controls/extensions gathering information from rfc and major vendors documentation. I'm still missing specific OID for Microsoft Active Directory but hope to add them soon. With this dictionary you can populate the server.info property with a lot of (decoded if possible) information about the ldap server. To have the info gathered you have to create the Server object with the parameter getInfo=GET_DSA_INFO. I also added a connection usage summary in the form of a property in the Connection class. If you create the connection with the parameter collectUsage=True you can have something like this in the connection.usage property: >>> c.usage Connection Usage: Start Time: Wed Sep 4 17:02:58 2013 Elapsed time: 0:00:41.386205 Bytes: 11075 Transmitted: 186 Received: 10889 Messages:31 Trasmitted: 5 Received: 26 Operations: 5 Abandon: 0 Bind: 1 Compare: 0 Delete: 0 Extended: 0 Modify: 0 ModifyDn: 0 Search: 3 Unbind: 1 Let me know if you need more information recorded. I've refined the interface protocol a little, removing the StopTLS method because rfc4511 and rfc 4513 define the removal of TLS as a MAY feature of the ldap server, so I can't have a generic function for it. I'm working on the schema browser now. I hope to have it for the next week, then we could finally move to beta! Once I have the first beta release I'll set up a public repository with ticketing and bug tracking. Have fun, gc -------------- next part -------------- An HTML attachment was scrubbed... URL: From python3ldap at gmail.com Wed Sep 4 17:11:27 2013 From: python3ldap at gmail.com (python3ldap) Date: Wed, 4 Sep 2013 17:11:27 +0200 Subject: [python-ldap] wrong message - Python3-ldap 0.5.3-alpha released! Message-ID: Sorry, I've sent the message to the wrong mailing list. I apologize for that. gc -------------- next part -------------- An HTML attachment was scrubbed... URL: From dc.loco at gmail.com Sat Sep 7 04:13:00 2013 From: dc.loco at gmail.com (Kevin Cole) Date: Fri, 6 Sep 2013 22:13:00 -0400 Subject: [python-ldap] Seemingly random success and failures Message-ID: I'm working under the "easier to beg forgiveness than ask permission" model (having already tried the alternative and gotten a run-around). Hence, I'm lacking some of the specifics about the server I'm talking to. However, I hope I'm providing enough info to get a reasonable answer. Our IT department has some sort of LDAP server. ? (Active Directory, I think.)? I have successfully gotten Python's LDAP module to talk to it, and fetch all the info I need (after authenticating to it). This was in part to determine if a user is "legit" enough to use services I'm providing, and to offer auto-completion of employee names. It seemed to be working fine with the small handful of users that I tested with. Well, now I've been asked to make the login capability of my little web app more publicly available to other folks on campus (who have LDAP records as well). Since advertising the new capability, it behaves randomly: Sometimes a user will succeed in authenticating, and then a few minutes later, it fails for the same user. The failures don't seem to be the same thing twice, and I haven't had the opportunity to copy the various error messages being given back. ? I have two different IP addresses, one of which uses ldaps:// and the other ldap://.? I have had "luck" both good and bad with both of them. This isn't a service that people are going to be hammering at. So, I don't think the source of trouble is that my server is too busy with people trying to authenticate simultaneously. ? It's also depending (a little) on security through obscurity, having an unlikely URL.? Here are the relevant portions of the code: import ldap, ldap.sasl ... server = "ldaps://.../" base_dn = "OU=people,dc=ad,dc=gallaudet,dc=edu" screen = "(sn=*)" scope = ldap.SCOPE_SUBTREE fields = ["sn","givenName",] con = ldap.initialize(server) con.set_option(ldap.OPT_REFERRALS, 0) ? # Recommended somewhere? ... user = request.POST["username"].strip() cut = user.find("@gallaudet.edu") if cut > 0: user = user[:cut] # username, not e-mail passwd = request.POST["password"] token = ldap.sasl.digest_md5(user,passwd) try: con.sasl_interactive_bind_s("",token) except ldap.INVALID_CREDENTIALS, e: return HttpResponseRedirect("/.../login/") ... temp = map(lambda x: x[1], con.search_s(base_dn, scope, screen, fields)) found = [entry for entry in temp if "givenName" in entry] Is it just a matter of bad timing? Should I be "MUNGing" it, retrying repeatedly if it's not an INVALID_CREDENTIALS exception ?, and hoping for a lucky roll of the dice?? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Sat Sep 7 12:16:47 2013 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Sat, 07 Sep 2013 12:16:47 +0200 Subject: [python-ldap] Seemingly random success and failures In-Reply-To: References: Message-ID: <522AFD0F.5060402@stroeder.com> Kevin Cole wrote: > Our IT department has some sort of LDAP server. > ? (Active Directory, I think.)? > I have successfully gotten Python's LDAP module to talk to it, and fetch > all the info I need (after authenticating to it). This was in part to > determine if a user is "legit" enough to use services I'm providing, and to > offer auto-completion of employee names. > > It seemed to be working fine with the small handful of users that I tested > with. Well, now I've been asked to make the login capability of my little > web app more publicly available to other folks on campus (who have LDAP > records as well). Since advertising the new capability, it behaves > randomly: Sometimes a user will succeed in authenticating, and then a few > minutes later, it fails for the same user. The failures don't seem to be > the same thing twice, and I haven't had the opportunity to copy the various > error messages being given back. > ? I have two different IP addresses, one of which uses ldaps:// and the > other ldap://.? I have had "luck" both good and bad with both of them. > > This isn't a service that people are going to be hammering at. So, I don't > think the source of trouble is that my server is too busy with people > trying to authenticate simultaneously. > ? It's also depending (a little) on security through obscurity, having an > unlikely URL.? Well, there are many aspects in your infrastructure where to look for the cause of temporary failure. Especially without having exact error messages / exceptions or similar it's unpossible to help. > Here are the relevant portions of the code: Again I'm not sure whether I fully understand what you're trying to achieve. > ... > user = request.POST["username"].strip() > cut = user.find("@gallaudet.edu") > if cut > 0: user = user[:cut] # username, not e-mail There's no else clause here. > passwd = request.POST["password"] > token = ldap.sasl.digest_md5(user,passwd) > try: > con.sasl_interactive_bind_s("",token) > except ldap.INVALID_CREDENTIALS, e: > return HttpResponseRedirect("/.../login/") Note that there are some issues with SASL DIGEST-MD5 and MS AD regarding the use of non-ASCII chars in usernames. Not sure about passwords. I'd recommend to set trace_level/trace_file and look at what python-ldap really sends and receives: http://www.python-ldap.org/doc/html/ldap.html#ldapobject-classes In most strange cases like this using trace_level=2 helped a lot. ;-) Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From jakobsg at gmail.com Tue Sep 10 12:14:08 2013 From: jakobsg at gmail.com (Jakob Simon-Gaarde) Date: Tue, 10 Sep 2013 12:14:08 +0200 Subject: [python-ldap] Paging in LDAP Message-ID: Hi. I have tried to use python-ldap to implement a paged search for returning limited amounts of data using SimplePagedResultsControl. This works fine as long as I need to iterate through data from start to end. In my case I have a situation where a web client should be able to ask for the next page or jump 10 pages ahead or back. I can't seem to find a way to make the server control "jump" to a certain page. It seems like the problem is solved in java's ldap implementation with the VirtualListViewRequestControl. Is there enything I can do? I was thinking fast-forward with "result" ig you can ask the ldapserver not to send data but just the next cookie? Please help. -- Med venlig hilsen / Best regards Jakob Simon-Gaarde From michael at stroeder.com Tue Sep 10 20:15:28 2013 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 10 Sep 2013 20:15:28 +0200 Subject: [python-ldap] Paging in LDAP In-Reply-To: References: Message-ID: <522F61C0.9010702@stroeder.com> Jakob Simon-Gaarde wrote: > I have tried to use python-ldap to implement a paged search for > returning limited amounts of data using SimplePagedResultsControl. > This works fine as long as I need to iterate through data from start > to end. In my case I have a situation where a web client should be > able to ask for the next page or jump 10 pages ahead or back. I can't > seem to find a way to make the server control "jump" to a certain > page. Yes, see http://tools.ietf.org/html/rfc2696 > It seems like the problem is solved in java's ldap > implementation with the VirtualListViewRequestControl. > Is there enything I can do? You have to implement classes for the LDAPv3 extended controls described herein: https://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09 Contributions to python-ldap welcome. Note that the LDAP server has to also support this. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From pviktori at redhat.com Fri Sep 13 12:51:26 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Sep 2013 12:51:26 +0200 Subject: [python-ldap] Inconsistent capitalization breaks schema parsing Message-ID: <5232EE2E.3040303@redhat.com> Hello, Is this the proper place to bring bugs to the attention of python-ldap developers? I've noticed that inconsistent capitalization of attributes in a schema LDIF file can result in a SubSchema with some entries missing. Use the attached files to reproduce the issue. The problem is that the LDIF parsing yields to something like `{'attributeTypes': [...], 'attributetypes': [...]}`, but when that is converted to a case-insensitive dict, one of the keys overwrites the other. I'm not sure where to do a proper fix. Clean up the dictionary before converting? Modify the LDIF parser to normalize attribute names to the first value seen? Modify cidict to optionally handle conflicts like these? I'd be grateful if someone familiar with the code base could give me an opinion. -- Petr Viktorin -------------- next part -------------- A non-text attachment was scrubbed... Name: parse-schema.py Type: text/x-python Size: 134 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: schema.ldif Type: text/x-ldif Size: 425 bytes Desc: not available URL: From michael at stroeder.com Fri Sep 13 20:04:56 2013 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 13 Sep 2013 20:04:56 +0200 Subject: [python-ldap] Inconsistent capitalization breaks schema parsing In-Reply-To: <5232EE2E.3040303@redhat.com> References: <5232EE2E.3040303@redhat.com> Message-ID: <523353C8.9030606@stroeder.com> Petr Viktorin wrote: > Is this the proper place to bring bugs to the attention of python-ldap > developers? Yes. Thanks for reporting issues here. > I've noticed that inconsistent capitalization of attributes in a schema LDIF > file can result in a SubSchema with some entries missing. > Use the attached files to reproduce the issue. > > The problem is that the LDIF parsing yields to something like > `{'attributeTypes': [...], 'attributetypes': [...]}`, but when that is > converted to a case-insensitive dict, one of the keys overwrites the other. > > I'm not sure where to do a proper fix. Clean up the dictionary before > converting? Modify the LDIF parser to normalize attribute names to the first > value seen? Modify cidict to optionally handle conflicts like these? For now I've added a work-around in function ldap.schema.subentry.urlfetch(): http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ldap/schema/subentry.py?r1=1.33&r2=1.34 The down-side is that it might not perform very well since list.extend() is used and usually lots of attribute values are in the schema per multi-valued attribute. Please test and provide feedback. Ciao, Michael. Index: Lib/ldap/schema/subentry.py =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Lib/ldap/schema/subentry.py,v retrieving revision 1.33 diff -u -r1.33 subentry.py --- Lib/ldap/schema/subentry.py 19 Feb 2012 13:49:30 -0000 1.33 +++ Lib/ldap/schema/subentry.py 13 Sep 2013 18:01:55 -0000 @@ -464,13 +464,13 @@ l.simple_bind_s(ldap_url.who or '', ldap_url.cred or '') subschemasubentry_dn = l.search_subschemasubentry_s(ldap_url.dn) if subschemasubentry_dn is None: - subschemasubentry_entry = None + s_temp = None else: if ldap_url.attrs is None: schema_attrs = SCHEMA_ATTRS else: schema_attrs = ldap_url.attrs - subschemasubentry_entry = l.read_subschemasubentry_s( + s_temp = l.read_subschemasubentry_s( subschemasubentry_dn,attrs=schema_attrs ) l.unbind_s() @@ -480,7 +480,16 @@ ldif_file = urllib.urlopen(uri) ldif_parser = ldif.LDIFRecordList(ldif_file,max_entries=1) ldif_parser.parse() - subschemasubentry_dn,subschemasubentry_entry = ldif_parser.all_records[0] + subschemasubentry_dn,s_temp = ldif_parser.all_records[0] + # Work-around for mixed-cased attribute names + subschemasubentry_entry = ldap.cidict.cidict() + for at,av in s_temp.items(): + if at in SCHEMA_CLASS_MAPPING: + try: + subschemasubentry_entry[at].extend(av) + except KeyError: + subschemasubentry_entry[at] = av + # Finally parse the schema if subschemasubentry_dn!=None: parsed_sub_schema = ldap.schema.SubSchema(subschemasubentry_entry) else: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2398 bytes Desc: S/MIME Cryptographic Signature URL: From pviktori at redhat.com Wed Sep 18 13:46:38 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 18 Sep 2013 13:46:38 +0200 Subject: [python-ldap] Inconsistent capitalization breaks schema parsing In-Reply-To: <523353C8.9030606@stroeder.com> References: <5232EE2E.3040303@redhat.com> <523353C8.9030606@stroeder.com> Message-ID: <5239929E.9010600@redhat.com> On 09/13/2013 08:04 PM, Michael Str?der wrote: > Petr Viktorin wrote: >> Is this the proper place to bring bugs to the attention of python-ldap >> developers? > > Yes. > > Thanks for reporting issues here. > >> I've noticed that inconsistent capitalization of attributes in a schema LDIF >> file can result in a SubSchema with some entries missing. >> Use the attached files to reproduce the issue. >> >> The problem is that the LDIF parsing yields to something like >> `{'attributeTypes': [...], 'attributetypes': [...]}`, but when that is >> converted to a case-insensitive dict, one of the keys overwrites the other. >> >> I'm not sure where to do a proper fix. Clean up the dictionary before >> converting? Modify the LDIF parser to normalize attribute names to the first >> value seen? Modify cidict to optionally handle conflicts like these? > > For now I've added a work-around in function ldap.schema.subentry.urlfetch(): > > http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ldap/schema/subentry.py?r1=1.33&r2=1.34 > > The down-side is that it might not perform very well since list.extend() is > used and usually lots of attribute values are in the schema per multi-valued > attribute. > > Please test and provide feedback. > > Ciao, Michael. It works well in my testing so far, thank you! I don't think performance is too bad, either -- list.extend() isn't called too many times. -- Petr?