Bug 1322095 - /etc/sysconfig/clustercheck should use clustercheck-specific account, not "root"
Summary: /etc/sysconfig/clustercheck should use clustercheck-specific account, not "root"
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: 8.0 (Liberty)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 10.0 (Newton)
Assignee: Michele Baldessari
QA Contact: Arik Chernetsky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-29 19:23 UTC by Michael Bayer
Modified: 2016-10-11 13:27 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-11 13:07:59 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Launchpad 1581677 None None None 2016-05-13 21:36:38 UTC
OpenStack gerrit 316297 None MERGED Tighten the access rules for galera 2020-01-27 15:43:14 UTC

Description Michael Bayer 2016-03-29 19:23:27 UTC
It seems the installer is placing the "root" username with a blank password into /etc/sysconfig/clustercheck.  This is a poor security practice as the root user has unlimited permissions and is also misleading to users who often change their root account password such that clustercheck no longer functions.

Best practice for /etc/sysconfig/clustercheck is that a user named "clustercheck" is created with any strong password; then, the account should be created in the Galera cluster as:

    GRANT USAGE ON *.* TO 'clustercheck'@'localhost' IDENTIFIED BY PASSWORD '<password>';

The above grant most likely needs to be established on each MariaDB node running individually, since the Galera cluster can't be started by pacemaker until /etc/sysconfig/clustercheck has a working login.   OTOH, if the Galera cluster is up and running through some other means, the above grant can be invoked on just one node and Galera will replicate it to the other nodes.

Comment 2 Mike Burns 2016-04-07 21:36:02 UTC
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.


Note You need to log in before you can comment on or make changes to this bug.