Changing root user password causes MariaDB root password to fail

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.

SYSTEM INFORMATION
OS type and version AWS Lightsail Debian
Virtualmin version 7.2

When you changed the password, Virtualmin lost the ability to manage the database server.

You could rerun the post install wizard to let Virtualmin know about the new password. Virtualmin will thereafter be able to manage the database server, as before.

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.

1 Like

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!

I’ll check out the install wizard approoach.

I looked and I don’t see anything matching your description. Could you please clarify further or provide a screenshot? Thanks!

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.

For regular Virtualmin domain owners, we do keep the MySQL password in sync with the Unix password, unless a separate password has been set. But I don’t think this happens for root by default.

2 Likes

I misunderstood your comment, please disregard my response to it.

Doesn’t that change if you select to have encrypted passwords in the Initial Wizard?

I don’t understand the logic of generating random passwords, as you need to know the database password to use it.

Yes, if you select to use hashed passwords in the wizard, the MySQL password is always separate from the Unix password.

Why? As it’s a random password, I have to manually change it before the new VM database can be used. I don’t see the point of creating a database and then making it unusable.

We hash user passwords, although we have to store database password in plain-text in domain config, for install scripts to work correctly.

Yes, but why is it random?

It has to be known to be useful.

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.

No that from a existing database, just change the password as per screenshot, not random. If you do generate random use the eye icon to view.

Thanks for trying to help, but if you have encrypted passwords selected, there is no eye available.

The question still remains, what use is a random password?

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.

Richard

Thanks, but if you don’t use encrypted passwords, it uses the admin password for the domain, so it is known. On a brand new virtual server.

Why not still do that with encryption?

Really this is a minor issue and I am sure that the team have more important issues to deal with.