+++ This bug was initially created as a clone of Bug #1153131 +++ Description of problem: Keystone juno-rc2 needs python-ldap 2.3 for ldap identity. Centos7 comes with python-ldap 2.4 Version-Release number of selected component (if applicable): - openstack-keystone.noarch 2014.2-0.6rc2.el7.centos @openstack-juno - python-ldap.x86_64 2.4.6-6.el7 @base - CentOS 7 Steps to Reproduce: 1. Configure keystone to use ldap 2. keystone user-list Actual results: 2014-10-15 18:01:42.877 7294 ERROR keystone.common.wsgi [-] 'module' object has no attribute 'LDAP_CONTROL_PAGE_OID' 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi Traceback (most recent call last): 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 223, in __call__ 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi result = method(context, **params) 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/token/controllers.py", line 100, in authenticate 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi context, auth) 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/token/controllers.py", line 287, in _authenticate_local 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi username, CONF.identity.default_domain_id) 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 202, in wrapper 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi return f(self, *args, **kwargs) 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 213, in wrapper 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi return f(self, *args, **kwargs) 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/core.py", line 600, in get_user_by_name 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi ref = driver.get_user_by_name(user_name, domain_id) 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/identity/backends/ldap.py", line 87, in get_user_by_name 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi return self.user.filter_attributes(self.user.get_by_name(user_name)) 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/ldap/core.py", line 1475, in get_by_name 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi res = self.get_all(query) 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/ldap/core.py", line 1746, in get_all 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi return super(EnabledEmuMixIn, self).get_all(ldap_filter) 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/ldap/core.py", line 1483, in get_all 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi for x in self._ldap_get_all(ldap_filter)] 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/ldap/core.py", line 1445, in _ldap_get_all 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi attrs) 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/ldap/core.py", line 929, in search_s 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi filterstr, attrlist) 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/ldap/core.py", line 964, in _paged_search_s 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi controlType=ldap.LDAP_CONTROL_PAGE_OID, 2014-10-15 18:01:42.877 7294 TRACE keystone.common.wsgi AttributeError: 'module' object has no attribute 'LDAP_CONTROL_PAGE_OID' Expected results: List of users. Additional info: I tried with python-ldap 2.3 and works. --- Additional comment from Nathan Kinder on 2014-10-15 17:13:57 EDT --- What does your Keystone LDAP configuration look like? Also, what version of the 'openldap' package do you have installed? This is working for me on a fresh install using a domain specific LDAP backend for identity (assignment in SQL): [rhosuser@rhos ~]$ rpm -q openstack-keystone python-ldap openldap openstack-keystone-2014.2-0.6rc2.el7.centos.noarch python-ldap-2.4.6-6.el7.x86_64 openldap-2.4.39-3.el7.x86_64 [rhosuser@rhos ~(keystone_cloud_admin)]$ openstack user list --domain ipa +------------------------------------------------------------------+----------+ | ID | Name | +------------------------------------------------------------------+----------+ | 08c8bb1b1b8efa7abea9a8eb73784c59e6fbd7283e864d341aaea7d45b42814e | admin | | 1f94e7038ecd141dfe1656aa56d89779a27dd8b7a6aca4863860a1d58ac168ab | keystone | +------------------------------------------------------------------+----------+ --- Additional comment from Nathan Kinder on 2014-10-15 17:30:32 EDT --- Ok, so this is indeed a problem. Keystone needs some changes to allow it to work with the new way that paging works in python-ldap 2.4. --- Additional comment from Nathan Kinder on 2014-10-15 17:31:42 EDT --- An upstream bug was filed on this issue here: https://bugs.launchpad.net/keystone/+bug/1381768 --- Additional comment from Nathan Kinder on 2014-10-15 18:51:01 EDT --- A fix has been proposed for this upstream (in master): https://review.openstack.org/128782 There should not be a problem with backporting this to Juno once it's accepted for master. --- Additional comment from Bruno Bompastor on 2014-10-16 04:10:53 EDT --- Great! Thanks.
To reproduce this issue: - Set up Keystone using LDAP as an identity backend on a system with python-ldap-2.4. - Set 'page_size' to a non-zero value in the '[ldap]' section of keystone.conf and restart Keystone. - Perform a user list using the 'keystone' or 'openstack' CLIs. The error mentioned in the beginning of this bug will be reported if the bug is present. With the fix, the user list should succeed without error.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1753.html