Cookbook tries to set root password on every run instead of first install only

[kierandelaney]

Looks like changes a few days ago no longer check whether this is a fresh install for RH7 - the post install script just repeatedly tries to set the root password regardless.

This was introduced in 1.5.2 (which has affected us as we use pessimistic locking and this is quite a large change for minor patch release).

Edit:
Can confirm rolling back to a hard lock on 1.5.1 fixes this in the short term, so it is a regression introduced in 1.5.2 #173

[shoekstra]

Hi!

Thanks for reporting this. This behaviour doesn't sound very familiar though, my experience with this cookbook has been setting/managing the root password via the cookbook.

That said I'm happy to help restore previous behaviour but I can't see how that worked before.
Looking through v1.5.1. I found the same execute['change first install root password'] resource here - could you please show the code that did this check?

Cheers,
Stephen

[kierandelaney]

Hi Stephen,

Sorry I appreciate I was a bit rushed when filing the report!

We too are setting/managing the root password with the cookbook using the following attributes:

default['mariadb']['server_root_password'] = 'NEWPASSWORD';
default['mariadb']['forbid_remote_root'] = false;
default['mariadb']['allow_root_pass_change'] = true;

You are correct - that piece of code hasn't changed - but the trigger for it did.

Previously it was called from the lines immediate above you link: https://github.com/sinfomicien/mariadb/blob/v1.5.1/recipes/_redhat_server.rb#L34-L43

You can see that execute['change first install root password'] has a default action of :nothing but is called from the action MariaDB first start - which itself does nothing unless the MariaDB-server is installed.

This would ultimately mean the password is only set on first install, as it should be.

However, now, these lines trigger the post install recipe regardless, and the post install recipe now triggers the password reset regardless, unless it is empty.

Ultimately you could add a check to the post install script like:
only_if "/usr/bin/mysql -u root -e 'show databases;'"

EG, if you can show databases without a password, the password is blank and needs to be set - obviously this would need to be combined with the existing empty password check.

Sorry I would submit a patch but I have no way of testing on our boxes at the moment.

[shoekstra]

Thanks for the additional info! I see what you mean - no problem re patch, I think I have enough to work something out. Unfortunately I am short on time for the next two days, but should have the fix released on Thursday.

I've created #175 as a reminder to write some documentation in the README on using Test Kitchen to do some troubleshooting/testing patches.

[kierandelaney]

@damacus this is definitely a bug and not a documentation issue :)

[shoekstra]

Agreed - updated labels and should have some time this afternoon to sort this out.

[damacus]

Fail... Sorry about that..

I shouldn't be changing labels that late at night :D

[mjuszczak]

In looking at these lines:

case node['mariadb']['install']['type']
when 'package'
  include_recipe platform_post_install_recipe
end

include_recipe "#{cookbook_name}::_mariadb_postinstall"

... I had a little trouble understanding why _redhat_server_postinstall existed at all if /etc/mariadb_grants contained execute[install-grants] to change the root password, and was executed from _maraidb_postinstall. Then I realized that _redhat_server_postinstall takes care of the initial password change, and then the execute[install-grants] inside _mariadb_postinstall takes care of any future password changes. Might it be possible to refactor this and get creative with only_if and not_if guards (and/or template variables with /etc/mariadb_grants) so the password is only ever changed in one place by one method? Just curious. Might help prevent future issues.

In any event, I was able to reproduce this bug with a .kitchen.local.yml file of:

---
suites:
  #
  # default
  #
  - name: default
    run_list:
      - recipe[mariadb::default]
    attributes:
      mariadb:
        use_default_repository: true
        server_root_password: 'NEWPASSWORD'
        forbid_remote_root: false
        allow_root_pass_change: true

Executing kitchen converge default-centos-73 succeeded on the first run, and failed on the second.

After #176, I was able to execute kitchen converge default-centos-73 two times in a row without issue. On the third time, I changed the password, and on the fourth time I changed it back. All worked well.

[shoekstra]

PR has been merged, I need some time to update the metadata to reflect this cookbook's now with Sous Chefs. I'll update when it's in the supermarket.

Thanks @mjuszczak !

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.