Bug 1323305
Summary: | Password not required to login as root to MariaDB | |||
---|---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Chris Lincoln <clincoln> | |
Component: | openstack-tripleo-heat-templates | Assignee: | Michele Baldessari <michele> | |
Status: | CLOSED ERRATA | QA Contact: | Arik Chernetsky <achernet> | |
Severity: | medium | Docs Contact: | ||
Priority: | high | |||
Version: | 7.0 (Kilo) | CC: | dbecker, dchia, dciabrin, dmatthew, dyasny, fdinitto, jguiditt, jjoyce, jstransk, mbayer, mburns, mcornea, michele, morazi, pkomarov, rhel-osp-director-maint, scorcora, tvignaud, ushkalim | |
Target Milestone: | ga | Keywords: | Security | |
Target Release: | 9.0 (Mitaka) | |||
Hardware: | x86_64 | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | openstack-tripleo-heat-templates-2.0.0-9.el7ost | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1340208 1340210 (view as bug list) | Environment: | ||
Last Closed: | 2016-08-11 11:30:21 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1340208, 1340210 |
Description
Chris Lincoln
2016-04-01 20:02:28 UTC
OK so there is a canonical way to solve this Galera chicken/egg problem of root user not set up, but then once Galera is running it's not that simple to set up a root user because the user replication gets in the way. The step that would have to be added is that mysqld is run temporarily in non-wsrep mode (easiest way is pass --wsrep-provider=none), then the password setup for root occurs, then you stop mysqld so that it can be started in wsrep mode. Looking at the puppet setup here, which keep in mind my experience reading puppet code started about a week ago, I would imagine the approach would be a new exec {} operation that essentially would have to take place within root_password. We'd probably like the actual code to be local to overcloud_controller_pacemaker.pp so I suppose in puppet terms this means we'd create a new "class mysql::server::root_password" to override the one that's in tripleo-heat-templates. I'm not sure how easy it is to "wrap" an existing operation in puppet vs. lift-and-copy. With lift-and-copy we'd have to keep an eye on changes to this function in subsequent versions as there seem to be a bunch to the root_password method in the rhos-8.0 version. we've done a plain tripleO install and noted the accounts are as follows: MariaDB [(none)]> select user,password,host from mysql.user; +----------+-------------------------------------------+------------------------+ | user | password | host | +----------+-------------------------------------------+------------------------+ | root | | localhost | | root | | overcloud-controller-1 | | keystone | *D2247B46A5AA8FAEE048E647F127D89B2C48AC2A | 192.0.2.6 | | keystone | *D2247B46A5AA8FAEE048E647F127D89B2C48AC2A | % | | | | overcloud-controller-1 | | heat | *AF151D3ED848C66AC4C1B67D4587855CBFA17C90 | % | | heat | *AF151D3ED848C66AC4C1B67D4587855CBFA17C90 | 192.0.2.6 | | gnocchi | *B1221C453AB2D8BA2647CDB1338D3E42DE7CC2D2 | % | | gnocchi | *B1221C453AB2D8BA2647CDB1338D3E42DE7CC2D2 | 192.0.2.6 | | cinder | *0FEB5458B6A3EA4AB7E4FA4C4B288DE57AF0CF15 | 192.0.2.6 | | cinder | *0FEB5458B6A3EA4AB7E4FA4C4B288DE57AF0CF15 | 192.0.2.10 | | cinder | *0FEB5458B6A3EA4AB7E4FA4C4B288DE57AF0CF15 | % | | neutron | *4C1878ED41D83ED1199798FC138B8794C7AF165F | 192.0.2.10 | | sahara | *8B57208506727DF21DF4367E3EEA7F2023525076 | 192.0.2.10 | | sahara | *8B57208506727DF21DF4367E3EEA7F2023525076 | 192.0.2.6 | | sahara | *8B57208506727DF21DF4367E3EEA7F2023525076 | % | | nova | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | % | | gnocchi | *B1221C453AB2D8BA2647CDB1338D3E42DE7CC2D2 | 192.0.2.10 | | neutron | *4C1878ED41D83ED1199798FC138B8794C7AF165F | % | | nova | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | 192.0.2.10 | | nova | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | 192.0.2.6 | | neutron | *4C1878ED41D83ED1199798FC138B8794C7AF165F | 192.0.2.6 | | heat | *AF151D3ED848C66AC4C1B67D4587855CBFA17C90 | 192.0.2.10 | | nova_api | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | 192.0.2.6 | | nova_api | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | % | | nova_api | *0CC7260C7DBBB06BCD3F0B548900794234EB0FC3 | 192.0.2.10 | | glance | *688E4B37E428F6A398D7A6AC9C258D6FA849D619 | % | | glance | *688E4B37E428F6A398D7A6AC9C258D6FA849D619 | 192.0.2.10 | | glance | *688E4B37E428F6A398D7A6AC9C258D6FA849D619 | 192.0.2.6 | | keystone | *D2247B46A5AA8FAEE048E647F127D89B2C48AC2A | 192.0.2.10 | +----------+-------------------------------------------+------------------------+ 30 rows in set (0.00 sec) the password should be set for both of the "root" logins. Additionally, the "anonymous" user, i.e. the one without a username, should be either removed, or given a password; this account is the "anonymous user" account and while it has low privileges, it's not necessary. Additionally, as outlined in bz#1322095, "root" is also in /etc/sysconfig/clustercheck. This username should be a low-privilege "clustercheck" user also with a password; the password for that user also needs to be in the clustercheck file and should not be the "root" user. If we can add a step to the pacemaker galera install where we temporarily start the MySQL daemon in non-wsrep mode, we can apply all three of these changes in series to the running daemon. so today, Michele, Damien and I spent a good stretch with our heads together to cobble something up for this, and we will be integrating bz#1322095 into this as well since we don't want our shiny new root password sticking out in a clustercheck config file (which we will also see if we can set to chmod 400). Michele with help from Damien worked up a proof of concept on an undercloud he had lying around as we all watched on tmux and he is still trying to work out some races that are occurring. We're working on the "install" path first, with considerations being made for how "upgrades" should work. https://bugzilla.redhat.com/show_bug.cgi?id=1364576 opened for the undercloud DB 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/RHEA-2016-1599.html |