MySQL uses connection and config parameters from a number of possible sources. The easiest way to find out where it is looking for config files is to run
As can be seen, my version of the MySQL client checks in this order
The cnf file is a file in dot-ini syntax, so you have
[groups] and each group contains lines with
key = value pairs. Which groups are read?
So in my case, I would create a
/Users/kkoehntopp/.my.cnf looking like this:
That is, I put general connection parameters such as the host, user and password into the
client group, and program specific parameters such as database, prompt and others into program specific groups such as
mysql. That way, the
mysql programs will connect automatically, but the
mysql options will not interfere with
Some time in 2012, the
.mylogin.cnf mechanism and the
mysql_config_editor program were added. They provide little value in security as we will see, but allow storage of more than one set of credentials: It is now possible to store a number of login pathes (credential sets) in a mylogin file, and call the client program with
--login-path=.... The client program will then read the mylogin file and use the connection parameters from there.
mylogin files are being made with the
mysql_config_editor program, for example
will create a new mylogin, or amend an existing one, and define a login path named
test. It will take the host and the username on the command line, but you cannot specify the password easily - it has to be typed in.
This makes provisioning hard - templating this in Ansible is not easy and dancing around with
expect and friends is just silly.
Working around this
It can decode and encode mylogin files, opening them up to Ansible templating. Just provision a valid mylogin file in plain text, encode it and delete the plain text original file.
The sample session looks like this:
The program depends on
pycrypto, but really any implementation of
aes-128-ebc should be easily usable.