Description of problem: We looked at the changes to MySQL (with OSP 7.2 binaries and templates) and saw that a random 10 character password is being passed into hiera for the MySQL root user. The problem we are seeing is that a password is still not required to login as root to the database: MariaDB [(none)]> select user,password from mysql.user; +----------+-------------------------------------------+ | user | password | +----------+-------------------------------------------+ | root | | | root | | | | | Looking into it, it seems that the reason the password is not set is due to the order in which Galera is configured and then later started by Pacemaker. Here is the mysql::server::root_password puppet class: class mysql::server::root_password { $options = $mysql::server::options # manage root password if it is set if $mysql::server::create_root_user == true and $mysql::server::root_password != 'UNSET' { mysql_user { 'root@localhost': ensure => present, password_hash => mysql_password($mysql::server::root_password), } } if $mysql::server::create_root_my_cnf == true and $mysql::server::root_password != 'UNSET' { file { "${::root_home}/.my.cnf": content => template('mysql/my.cnf.pass.erb'), owner => 'root', mode => '0600', } if $mysql::server::create_root_user == true { Mysql_user['root@localhost'] -> File["${::root_home}/.my.cnf"] } } } First off, the variable create_root_user is set to false in the overcloud_controller_pacemaker.pp manifest that is run in an HA overcloud, along with create_root_my_cnf. Even if these are set to true, in this step of the manifest (step 1), the database is not yet started, and will not be started until later in the next step (step 2). In our testing, you also can't just call the mysql::server::root_password class in step 2 as that is a duplicate declaration. Expected results: Password prompted to login to MariaDB as root Additional info: Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1261303 https://bugzilla.redhat.com/show_bug.cgi?id=1289310
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