Is there a
authentication_string column in mysql.user?
The short answer is that Mysql has dropped the Password field and now uses authentication_string. Mariadb has both Password and authentication_string, but still stores passwords in Password, and does not actually use the authentication_string field. This may change in future releases, but as of 10.1.20, this is how Mariadb does it. That is probably why Heidi does not show a password, it is looking in authentication_string, sees that it is empty, does not check the Password field (why should it, after all, Mysql no longer uses it) and says there is no password.
So much for Mariadb being a drop in replacement for Mysql....when I switched over, I had to wipe the DB and rebuild it from scratch because Mariadb would not work with the mysql DB. Grrrr.....
Here is the long version of the above :)
So to satisfy my own curiosity, I
- Installed the current version of Mysql (5.7.17) and I notice that you no longer use mysql_install_db to initialize the DB. Huh, that is news to me, I switched to MariaDB before they started doing that. So anyhow, I use bin/mysqld --initialize to init the DB, and look at the user table. It does not even have a Password field, it looks like they have dropped that completely. I see auth info is in authentication_string.
Then I wiped the DB and tried the mysql_install_db script. No difference.
- Took an install of MariaDB 10.1.20. I notice that with Mariadb, the mysql_install_db is still a script, where with mysql it is an executable. I also note that with Mariadb you can't mysqld --initialize, it is not supported. OK, fine, so I use the mysql_install_db script (you know, like we've been doing for that past thousand years? Mysql devs don't seem to have a problem changing things that break our stuff, but that is another story).
This creates a user table with both Password and authentication_string.
If I set a password, the encrypted password goes into Password, not authentication_string.