Initial mysql root user setup

[Nigel Metheringham]

When you install a myql server package you typically end up with a root
user without a password.

As a way of dealing with this in a indempotent way I was thinking of
extending the mysql_user module to add a boolean option, say
fix_unpassworded_root_user, which if set:-
- throws an error if login_user is not root or login_password
is not set
- throws an error if user or password parameters are set - this only
does one thing
- attempts to authenticate with the given login_user/login_password
returns ok (unchanged) if works
- attempts to authenticate with root/empty password and returns
failed if that does not work
- sets the root password to the supplied login_password, returns
ok (changed) if works

I think it may be possible to do this with a hacked around pair of
mysql_user calls (the first ignoring failure, the second being there to
check the root password is correctly set), but I think extending the
module for this special case may make things clearer at the cost of
additional internal complexity...

Or do others disagree?

Nigel.

--
[ Nigel Metheringham ------------------------------ ni...@dotdot.it ]
[ Ellipsis Intangible Technologies ]

[Michael DeHaan]

On Sun, Feb 24, 2013 at 3:03 PM, Nigel Metheringham <ni...@dotdot.it> wrote:
> When you install a myql server package you typically end up with a root user
> without a password.
>
> As a way of dealing with this in a indempotent way I was thinking of
> extending the mysql_user module to add a boolean option, say
> fix_unpassworded_root_user, which if set:-
> - throws an error if login_user is not root or login_password
> is not set
> - throws an error if user or password parameters are set - this only
> does one thing
> - attempts to authenticate with the given login_user/login_password
> returns ok (unchanged) if works
> - attempts to authenticate with root/empty password and returns
> failed if that does not work
> - sets the root password to the supplied login_password, returns

> ok (changed) if works'

This seems to be a confusing option to me.

>
> I think it may be possible to do this with a hacked around pair of
> mysql_user calls (the first ignoring failure, the second being there to
> check the root password is correctly set), but I think extending the module
> for this special case may make things clearer at the cost of additional
> internal complexity...
>
> Or do others disagree?
>
> Nigel.
>
> --
> [ Nigel Metheringham ------------------------------ ni...@dotdot.it ]
> [ Ellipsis Intangible Technologies ]
>

> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ansible-proje...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Mark Theunissen]

Hi Nigel,

To deal with MySQL root user in an idempotent way, I use the following:

- name: MySQL | Set the root password.

  action: mysql_user user=root password=$mysql_root_password host=localhost

- name: MySQL | Drop the credentials file so that this playbook can run again.

  action: template src=templates/root-my-cnf.j2 dest=/root/.my.cnf

The first time this playbook is run, the login_user and login_password are root/(empty), so task #1 succeeds. The second task drops the credentials in the root user's home directory. 

On subsequent runs of the playbook, Ansible will discover the credentials file containing the login_user and login_password in task #1, and authenticate successfully as root, and the run through will be idempotent. 

I have added a pull request to put this in the documentation, as it is perhaps a little non-obvious. 

https://github.com/ansible/ansible/pull/2235/files

- Mark

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.

[Mark Theunissen]

It may be a good idea for future development to provide a 'credentials_file' argument to the mysql_* modules, containing the path to the credentials file, but since the MySQL client itself uses ~/.my.cnf natively, that's what we went for in creating the module.