mysql-install-privileges fails on the first run about percona

[patcon]

Haven't run into this myself, but what's your platform?

[aub]

It's Ubuntu precise.

[patcon]

Cool, thanks. I might have time to reproduce. Can you tell me about anything else relevant in your run_list and attributes? Like what's your basic run_list and do you have any percona attributes set?

[patcon]

I'm unable to reproduce this with the test suite that we're about to merge in:
https://github.com/patcon/chef-percona/blob/65-test-kitchen/.kitchen.yml#L26-L30

Basically, with a run_list of simply percona::client,percona::server on precise64, with no attributes, this runs through fine. If you can provide more info, I might be able to reproduce.

EDIT

These are the changes since the last stable release on the community site:
0.14.5...master

You might want to consider whether your missing these changes might be causing your issue. Feel free to drop info on which version or commit of this cookbook you're using

[aub]

ok, i think i should be able to narrow it down some today. in the meantime
i created a branch that just explicitly passes the password on the command
line for those steps. if you're interested in adding that, I can send a
pull request, but I suspect the reason for not doing it relates to security
of passing the password on the command line.

On Tue, Jun 18, 2013 at 1:22 AM, Patrick Connolly
[email protected]:

I'm unable to reproduce this with the test suite that we're about to merge
in:

https://github.com/patcon/chef-percona/blob/65-test-kitchen/.kitchen.yml#L26-L30

Basically, with a run_list of simply percona::client,percona::server on
precise64, with no attributes, this run through fine. If you can provide
more info, I might be able to reproduce.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/67#issuecomment-19591477
.

[castro1688]

I'm getting the same issue. My /root/.my.cnf is set but the user running chef-client is ubuntu.

[2013-06-26T14:09:15+00:00] INFO: Processing execute[mysql-install-privileges] action run (percona::access_grants line 18)

================================================================================
Error executing action `run` on resource 'execute[mysql-install-privileges]'
================================================================================


Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of /usr/bin/mysql < /etc/mysql/grants.sql ----
STDOUT:
STDERR: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
---- End output of /usr/bin/mysql < /etc/mysql/grants.sql ----
Ran /usr/bin/mysql < /etc/mysql/grants.sql returned 1


Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/percona/recipes/access_grants.rb

 18: execute "mysql-install-privileges" do
 19:   command "/usr/bin/mysql < /etc/mysql/grants.sql"
 20:   action :nothing
 21:   subscribes :run, resources("template[/etc/mysql/grants.sql]"), :immediately
 22: end

[patcon]

I'd like to suggest that this might be a wont' fix issue, as we're in the process of a major rewrite of the cookbook, and if @phlipper agrees, I would suggest that the root my.cnf file should go away, as it seems to reflect a personal preference to have easy access to admin tools for one system user. I'd think this could exist outside the cookbook

[phlipper]

@patcon 8e1da72 is when the /root/my.cnf was introduced to prevent leaking the password in shell commands. It seems that this should probably stay in place. I'm not sure if this needs to be user-dependent (do some systems need a /home/ubuntu/my.cnf?) but I think we'll need to find a work-around for this. Thoughts?

[patcon]

Hm. OK, so if we're noting this as a valid concern, then there is more stuff in in the the mysql cookbook that will need dealing with

But now that I'm looking at it, the percona cookbook is setting root password through the CLI as well (rather than preseed). Isn't this inconsistent?
https://github.com/phlipper/chef-percona/blob/master/recipes/configure_server.rb#L69-L73

Is the goal to keep it out of the chef logs? Is that as far as we are concerned with leaking? Or are we trying to keep it totally off the command line?

[castro1688]

As a temporary fix, my work around was sudo -i

recipes/access_grants.rb
command "sudo -i /usr/bin/mysql < /etc/mysql/grants.sql"

[phlipper]

@patcon:

But now that I'm looking at it, the percona cookbook is setting root password through the CLI as well (rather than preseed). Isn't this inconsistent?
https://github.com/phlipper/chef-percona/blob/master/recipes/configure_server.rb#L69-L73

Yep it is, we'll have to look at that case. The goal is to keep the passwords out of all logs and off the console so it can't be captured.

Also, no matter which method we use there's going to be a "dance" around changing passwords which is something we'll need to figure out.

[patcon]

So since some systems are architected in such a way that they don't care about leakage through the logs, might this be something that fits best in a separate cookbook? It seems to add complexity that isn't strictly necessary. I would feel the same way about root password setting as well (with mysqladmin), since a full solution for password leaking (if we deem it a problem that the base cookbook should solve) would involve figuring out a yum equivalent for preseed, which is yet more complexity. Setting root password via mysqladmin is the most consistent way to do it across platforms.

Especially given the existence of chef-rewind, anything in the resource collection can be turned off using an action :nothing override (or otherwise altered as needed). So simplifying this cookbook (ie. ignoring password leakage as a concern) doesn't prevent someone with stricter goals from leveraging it.

EDIT: This is what I have in the queues for the mysql cookbook that has me trying to sort this out, btw:

• sous-chefs/mysql#96
• https://github.com/opscode-cookbooks/mysql/pull/97/files#L5R141

With this setting the password only on the first run:

execute "assign-root-password" do
  command "#{node['mysql']['mysqladmin_bin']} -u root password '#{node['mysql']['server_root_password']}'"
  action :run
  # ping will fail after first run, since root requires password, so "alive" isn't found
  only_if "#{node['mysql']['mysqladmin_bin']} -u root ping | grep alive"
end

[freerobby]

This is fixed in https://github.com/phlipper/chef-percona/pull/93/commits if anybody wants to cherry-pick the commit into their repo.

[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.