Failure to set mysql root password

[tobixen]

I'm currently installing percona on centos7 using this puppet module

Notice: /Stage[main]/Mysql::Password/Exec[mysql_backup_root_my_cnf]/returns: executed successfully
Notice: /Stage[main]/Mysql::Password/File[/root/.my.cnf]/ensure: created
Info: /Stage[main]/Mysql::Password/File[/root/.my.cnf]: Scheduling refresh of Exec[mysql_root_password]
Notice: /Stage[main]/Mysql::Password/Exec[mysql_root_password]/returns: mysqladmin: connect to server at 'localhost' failed
Notice: /Stage[main]/Mysql::Password/Exec[mysql_root_password]/returns: error: 'Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)'
Notice: /Stage[main]/Mysql::Password/Exec[mysql_root_password]/returns: Check that mysqld is running and that the socket: '/var/lib/mysql/mysql.sock' exists!
Error: /Stage[main]/Mysql::Password/Exec[mysql_root_password]: Failed to call refresh: mysqladmin --defaults-file=/root/.my.cnf.backup -uroot password 'hunter2' returned 1 instead of one of [0]
Error: /Stage[main]/Mysql::Password/Exec[mysql_root_password]: mysqladmin --defaults-file=/root/.my.cnf.backup -uroot password 'hunter2' returned 1 instead of one of [0]
Notice: Finished catalog run in 38.91 seconds

[root@test-centos7 ~]# mysqladmin ping
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: YES)'

[root@test-centos7 ~]# mysqladmin -p ping 
Enter password: 
mysqld is alive

I think I may have found the culprit. Will do some research and eventually come back with a pull request.

[tobixen]

This turned out to be quite different than expected. Things works as designed above. The problem is more or less in our manifests. We've managed to override the mysql socket path. Without arguments, mysqladmin is able to find the socket path in the default configuration file. With "mysqladmin --defaults-file=/some/file/here" mysqladmin won't read it and fails to find the socket. Hm. I think I need to do some research internally to see if I can figure out ... why would we want to change the socket path?

Alternatively, /root/.my.cnf and /root/.my.cnf.backup could explicitly include the socket location or could include the main config file.

[tobixen]

FWIW, the puppetlabs mysql module does include socket location in the ~root/.my.cnf file. It's probably a good idea.

[alvagante]

Thanks for the info, if you want to provide a PR with a fixed .my.cnf you're welcomed

[tobixen]

I'd love to - but it seems to be rather non-trivial; the default value both for the mysql config file template and for the options is empty, so it's completely up to the user how to configure those things. We use a template that lets us define all the mysql configuration through hiera, I was a bit surprised to see that it's our own work and not part of the puppet-mysql module.

Here are some alternative approaches:

• If template is defined, let the .my.cnf and .my.cnf.backup include the resulting config file (using the !include directive), and then it's up to the puppet module user to ensure that things like non-standard socket or port numbers are mirrored in a client-section in the default config file.
• Add even more parameters to the class; a custom string or template to be included in .my.cnf and .my.cnf.backup
• Make some assumptions on mysql::options; if the assumptions are met and the socket path is specified there, include it in .my.cnf and .my.cnf.backup
• Move our template into the puppet-mysql module. If mysql::options is set but template is not set, use our template as the default. This way we will have a default structure on the mysql::options and can get out the socket path from there.

Personally I think the last one looks best and the first one looks second best, though I haven't really thought hard about what potential draw backs or side effects there can be.

Anyway, I'd like to hear your opinions before spending efforts on a non-acceptable PR.

(Post-edit: tried to clarify my ideas a bit better)

[alvagante]

Thanks for the round up of options. If a password is set, there's actually a default template for root's my.cnf:

https://github.com/example42/puppet-mysql/blob/master/manifests/params.pp#L19

so maybe it's just a matter of placing the socket path there (it should be a parameter, though, so that users can customize it, and it should have by default the correct value for the underlying OS).

[tobixen]

Ok - so I'll just add another parameter mysql::socket and reference it in the templates for .my.cnf and .my.cnf.backup. That's a simple-easy solution and should work.

I wonder if I explained myself clearly enough when putting out the options above. What I found to be "missing" in the module is a default for mysql::template and mysql::options. We specify all our mysql configuration (including the socket path) in an mysql::options hiera hash - and we provide a very generic template in mysql::template (basically, "print out everything from mysql::options"). My feeling is that the socket dir should be read from mysql::options rather than mysql::socket - but that would require that those two variables comes with defaults.

[alvagante]

Right, we need to be sure that socket path is correctly set both on my.cnf and local .my.cnf, but since the module doesn't enforce a default my.cnf we should care of having a correct socket path in the local .my.cnf . What happens if the socket path is set wrong on the local .my.cnf we manage ? If we risk to break existing setups, we should reconsider.

[tobixen]

I'll probably have a pull request ready within an hour or two. If the socket path is explicitly set, it will be included in the .my.cnf, if it's not explicitly set it will not be included, hence it won't break any existing setups. The inline documentation states that the socket path also needs to be included in the server section in the mysql config file.

Wrong socket path causes the same problem as missing socket path in our setup. In addition to the problem highlighted at top here (root password not set) the databases and database users aren't rolled out.

[alvagante]

+1, thank you