plone site wedged when ldap server not reachable

Bug #1218938 reported by blackbronze
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Products.LDAPUserFolder
Won't Fix
Undecided
Unassigned

Bug Description

     We have Plone 4.3.1 with PloneHotfix20130618 applied. With version Products.LDAPUserFolder-2.26-py2.7 when only one LDAP server is configured and isn't reachable plone upon startup (via ./bin/plonectl start) will results in a initially non-responsive site.

     When that LDAP server is unreachable anytime the site has been successfully running the site becomes completely unresponsive and requires a plonectl restart. IMHO a timeout shouldn't lock the site up.

     Let me know what additional information I need to provide.

2013-08-15T13:49:54 CRITICAL event.LDAPDelegate Failure connecting, last attempted server: ldaps://ldap.mydomain.com:636 ({'desc': "Can't contact LDAP server"})
Traceback (most recent call last):
  File "/usr/local/Plone/buildout-cache/eggs/Products.LDAPUserFolder-2.26-py2.7.egg/Products/LDAPUserFolder/LDAPDelegate.py", line 240, in connect
    , op_timeout=server['op_timeout']
  File "/usr/local/Plone/buildout-cache/eggs/Products.LDAPUserFolder-2.26-py2.7.egg/Products/LDAPUserFolder/LDAPDelegate.py", line 342, in _connect
    connection.simple_bind_s(user_dn, user_pwd)
  File "/usr/local/Plone/buildout-cache/eggs/python_ldap-2.4.13-py2.7-linux-x86_64.egg/ldap/ldapobject.py", line 834, in simple_bind_s
    res = self._apply_method_s(SimpleLDAPObject.simple_bind_s,*args,**kwargs)
  File "/usr/local/Plone/buildout-cache/eggs/python_ldap-2.4.13-py2.7-linux-x86_64.egg/ldap/ldapobject.py", line 820, in _apply_method_s
    self.reconnect(self._uri)
  File "/usr/local/Plone/buildout-cache/eggs/python_ldap-2.4.13-py2.7-linux-x86_64.egg/ldap/ldapobject.py", line 787, in reconnect
    self._apply_last_bind()
  File "/usr/local/Plone/buildout-cache/eggs/python_ldap-2.4.13-py2.7-linux-x86_64.egg/ldap/ldapobject.py", line 759, in _apply_last_bind
    SimpleLDAPObject.simple_bind_s(self,'','')
  File "/usr/local/Plone/buildout-cache/eggs/python_ldap-2.4.13-py2.7-linux-x86_64.egg/ldap/ldapobject.py", line 207, in simple_bind_s
    msgid = self.simple_bind(who,cred,serverctrls,clientctrls)
  File "/usr/local/Plone/buildout-cache/eggs/python_ldap-2.4.13-py2.7-linux-x86_64.egg/ldap/ldapobject.py", line 201, in simple_bind
    return self._ldap_call(self._l.simple_bind,who,cred,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
  File "/usr/local/Plone/buildout-cache/eggs/python_ldap-2.4.13-py2.7-linux-x86_64.egg/ldap/ldapobject.py", line 99, in _ldap_call
    result = func(*args,**kwargs)
SERVER_DOWN: {'desc': "Can't contact LDAP server"}

Revision history for this message
Dylan Jay (t-launchpad-dylanjay-com) wrote :

This is related to a bug in python-ldap that is still being fixed.

Revision history for this message
blackbronze (blackbronze979) wrote :

Thanks Dylan! I looked for the bug report and couldn't find it. Would you mind posting where you found it at?

Revision history for this message
gwarah (lhmp1967) wrote :

I've got a similar problem. Our ldap server has changed IP, so the webserver downs after plone-ldap try to connect ldap server. Nothing works even ZMI. Is there another way than ZMI to reconfigure the new ldap server? Thanks for any tip.

Revision history for this message
Jens Vagelpohl (dataflake-deactivatedaccount-deactivatedaccount) wrote :

Please see the previous comments. Also, have you reduced the timeout values set for the respective LDAP connection in the LDAPUserFolder server settings?

Changed in ldapuserfolder:
status: New → Incomplete
assignee: nobody → Jens Vagelpohl (dataflake)
Revision history for this message
gwarah (lhmp1967) wrote :

I solve the bug related on my last post just deleting ldap plugin directly on instance and activating again on site.

more details, see stack overflow question #37681319

Changed in ldapuserfolder:
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.