I decided to change my root user password on the Webmin/Virtualmin front-end. This worked fine and I was able to log back in with no issues. I then ran into MariaDB warning telling me I needed to verify my root password.
The full MariaDB error message was : DBI connect failed : Access denied for user 'root'@'localhost' (using password: YES)
I entered my password and it failed. I tried the ‘Force Override’ checkbox option and this also produced an error.
### MariaDB safe mode : Password change failed : ERROR 1396 (HY000) at line 1: Operation ALTER USER failed for 'root'@'localhost'
Nothing else was changed on the server besides the root password using the UI. I cloned over an earlier snapshot of my server and verified the password entered was correct.
Webmin does have an option to change the MySQL password when the root password is changed, but its not on by default. You have to enable it at Servers → MySQL Database Server → User Permissions, at the bottom of the page.
Keep in mind… my root login password is not the same as the MariaDB password. So you’re saying that changing the Virtualmin login password somehow causes MariaDB to not function with its existing password? Surely that can’t be true!
Virtualmin does not manage the root user. This isn’t a Virtualmin question, though Virtualmin users can be configured to sync up the database and system user passwords (this is probably even the default, though I don’t like it). Jamie discussed the Webmin option about this (Webmin can manage the root user).
In the past, it was accidentally possible to bring root under control of Virtualmin by assigning ownership of a domain to root, but that was only because we never imagined anyone would ever do that…because it doesn’t make sense, as root owns all virtual servers. But, as far as I know, it is no longer possible to do that without jumping through hoops and hitting config files directly (and one should never do that).
Crap, it’s seeming like maybe this is an option we turn on during Virtualmin installation to sync Virtualmin users with their databases and such. I’m ambivalent about that option, in general, but we’ll fix it to never apply to the root user, because that’s not a reasonable thing to happen.
Edit: I was wrong. We do not do that as part of the install. So…I don’t know what’s happening here. Shouldn’t be happening for root unless it was intentionally configured to act that way, I think.
Ive never had to use a random password for the database in the wizard, they offer a random password but you should be able to see it before saving, hash is different. ie if I wanted to use the very bad password for password
That’s the installation wizard, I am talking about when you Create Virtual Server for a client. Then if the client wants the database password, I have to manually set it for them, as random isn’t any use.
Well… What else is it supposed to generate on a brand-new virtual server?
If a backup is restored or a domain imported into the server, it retains whatever existing database user / password information already exists. But if it’s a brand-new account, there’s nothing to retain; so it has to generate something random.
It’s easy enough to change in any case; and I think there’s an option somewhere in the template to allow the users to change it themselves.