Install and configure in Installation Guide: Populate the Identity service database step fails on CentOS7

Bug #1698455 reported by Marcin Dulak on 2017-06-16

This bug report will be marked for expiration in 3 days if no further activity occurs. (find out why)

8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Medium
Unassigned

Bug Description

- [X] This doc is inaccurate in this way:

Failure in step "3. Populate the Identity service database:" of https://docs.openstack.org/ocata/install-guide-rdo/keystone-install.html
su -s /bin/sh -c "keystone-manage db_sync" keystone

A similar problem has been reported at https://ask.openstack.org/en/question/52838/error-when-creating-administrative-tenant-cento7-juno/
How to reproduce:

[root@controller ~]# whoami
root
[root@controller ~]# hostname
controller
[root@controller ~]# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
[root@controller ~]# rpm -q centos-release-openstack-ocata
centos-release-openstack-ocata-1-1.el7.noarch
[root@controller ~]# rpm -q mariadb-server
mariadb-server-10.1.20-1.el7.x86_64
[root@controller ~]# echo 'SHOW GRANTS FOR keystone' | mysql -uroot -pDBpass
Grants for keystone@%
GRANT USAGE ON *.* TO 'keystone'@'%' IDENTIFIED BY PASSWORD '*61D672B503D8DD7C9992AA31B0AC5B7DC43887AB'
GRANT ALL PRIVILEGES ON `keystone`.* TO 'keystone'@'%'
[root@controller ~]# echo 'SELECT HOST, USER from user\G' | mysql -uroot -pDBpass mysql
*************************** 1. row ***************************
HOST: %
USER: keystone
*************************** 2. row ***************************
HOST: 127.0.0.1
USER: root
*************************** 3. row ***************************
HOST: ::1
USER: root
*************************** 4. row ***************************
HOST: localhost
USER: keystone
*************************** 5. row ***************************
HOST: localhost
USER: root
[root@controller ~]# echo > /var/log/keystone/keystone.log
[root@controller ~]# su -s /bin/sh -c "keystone-manage db_sync" keystone; echo $?
1
[root@controller ~]# tail /var/log/keystone/keystone.log
2017-06-16 20:04:40.519 17512 ERROR keystone File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 1124, in _request_authentication
2017-06-16 20:04:40.519 17512 ERROR keystone auth_packet = self._read_packet()
2017-06-16 20:04:40.519 17512 ERROR keystone File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 991, in _read_packet
2017-06-16 20:04:40.519 17512 ERROR keystone packet.check_error()
2017-06-16 20:04:40.519 17512 ERROR keystone File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 393, in check_error
2017-06-16 20:04:40.519 17512 ERROR keystone err.raise_mysql_exception(self._data)
2017-06-16 20:04:40.519 17512 ERROR keystone File "/usr/lib/python2.7/site-packages/pymysql/err.py", line 107, in raise_mysql_exception
2017-06-16 20:04:40.519 17512 ERROR keystone raise errorclass(errno, errval)
2017-06-16 20:04:40.519 17512 ERROR keystone OperationalError: (pymysql.err.OperationalError) (1045, u"Access denied for user 'keystone'@'controller' (using \
password: YES)")
2017-06-16 20:04:40.519 17512 ERROR keystone

- [X] I have a fix to the document that I can paste below including example: input and output.

A possible solution is to add a grant for 'keystone'@'controller' in the "Grant proper access to the keystone database" section:

[root@controller ~]# echo "GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'controller' IDENTIFIED BY 'KEYSTONE_DBPASS';" | mysql -uroot -pDBpass
[root@controller ~]# echo > /var/log/keystone/keystone.log
[root@controller ~]# su -s /bin/sh -c "keystone-manage db_sync" keystone; echo $?
0

-----------------------------------
Release: 15.0.0 on 2017-06-12 16:28
SHA: 839afb2adab31b0a283c212fc73bc82d4775e7f4
Source: https://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/install-guide/source/keystone-install.rst
URL: https://docs.openstack.org/ocata/install-guide-rdo/keystone-install.html

Anne Gentle (annegentle) wrote :

Seems like a reasonable scoped user.

Changed in openstack-manuals:
status: New → Won't Fix
status: Won't Fix → Confirmed
importance: Undecided → Medium
Anne Gentle (annegentle) wrote :

To fix, in the keystone-install.rst file, add a grant for 'keystone'@'controller' in the "Grant proper access to the keystone database" section:

[root@controller ~]# echo "GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'controller' IDENTIFIED BY 'KEYSTONE_DBPASS';" | mysql -uroot -pDBpass
[root@controller ~]# echo > /var/log/keystone/keystone.log
[root@controller ~]# su -s /bin/sh -c "keystone-manage db_sync" keystone;

Ritesh (sarya0113) on 2017-06-29
Changed in openstack-manuals:
assignee: nobody → Ritesh (sarya0113)
Sahil (warlord77) wrote :

Any one working on this bug ?
If not I would like to assign and help out in fixing this bug

Ritesh (sarya0113) on 2017-09-06
Changed in openstack-manuals:
assignee: Ritesh (sarya0113) → nobody
affects: openstack-manuals → keystone
Changed in keystone:
status: Confirmed → New
Lance Bragstad (lbragstad) wrote :

Sahil,

Feel free to propose a patch if you'd like to pick up the work. Bug fixes are usually driven by whoever proposes a patch to review. We have infrastructure that keeps Launchpad in sync with the state of patches in review.

tags: added: docu
tags: added: documentation
removed: docu
tags: added: low-hanging-fruit
Rajat Sharma (tajar29) on 2017-10-26
Changed in keystone:
assignee: nobody → Rajat Sharma (tajar29)

Fix proposed to branch: master
Review: https://review.openstack.org/515662

Changed in keystone:
status: New → In Progress
Colleen Murphy (krinkle) wrote :

Why is this only a problem for keystone? I see for example nova uses the same permissions for rdo: https://docs.openstack.org/nova/pike/install/controller-install-rdo.html

Marcin Dulak (marcin-dulak) wrote :

This is not only for keystone. All database configurations I've used during the tutorial are affected: keystone, glance, nova, neutron, cinder

Lance Bragstad (lbragstad) wrote :

Sounds like this bug either needs to be opened for other services or closed. I'd rather keep the guides consistent across projects.

Rajat Sharma (tajar29) on 2018-01-15
Changed in keystone:
assignee: Rajat Sharma (tajar29) → nobody
Lance Bragstad (lbragstad) wrote :

Is there any update on this from a cross-project perspective?

Colleen Murphy (krinkle) wrote :

We need more info on why this is keystone specific. As far as I'm aware the documentation is correct here.

Changed in keystone:
status: In Progress → Incomplete
Marcin Dulak (marcin-dulak) wrote :

It has been mentioned above that this is not keystone specific. Granting database privileges looks the same https://docs.openstack.org/keystone/rocky/install/keystone-install-obs.html as in ocata, so the problem is probably still present. Has anybody actually tried to reproduce it after my initial report?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers