I’m moving from one machine to another, and things have mostly gone cleanly. The source was CentOS, but since the Virtualmin installation had issues on CentOS8, I went with Ubuntu 18.04 LTS.
Restores of domains exported from the old site went cleanly (once I disabled quotas as one domain was slightly over after migration.) All looks good, except one domain that can’t connect to the database.
This domain is essentially just a wordpress site. Connections to the web site itself fail with a notice saying it can’t connect to the database, and logging in from the command line with “mysql -u user-in-question -p” fail as well. “[Note] Access denied for user ‘user-in-question’@‘localhost’ (using password: YES)” shows up in the logs with both kinds of failures.
The only thing I can think of that might be part of the problem is that the database password includes an &. Deleting it doesn’t seem to change this behavior, but maybe changing the password on the source server, exporting, and importing would fix it?
I’m just loathe to dig too far into this as everything else came across cleanly.
Any suggestion on first steps to try before I go behind Virtualmin’s back and try to resolve this directly?
Did you restored the database and the user too?
If not, do that. Otherwise try to change the password for the user and then update it on the wordpress installation.
I used the virtualmin restore-domain tool to bring the user to the new machine.
Changing the password in Virtualmin and updating the wp-config file don’t really address the issue; it seems the user isn’t allowed to log into the MySQL database from localhost.
Is it safe to just edit the user outside of virtualmin, or is this likely to cause a problem?
If thats the case, then you can check in virtualmin (webmin -> server -> database server -> user rights) if the user got access to it. Its possible that something is wrong there. Keep in mind that the direction is just a rough guess since I use another language for it.
Rather than manually correct the issues I opted to try again. This time I made sure that all pending updates were applied on the source server before exporting, and it looks like that was the issue. MySQL was upgraded (MariaDB? Don’t remember) as one of those, so something about the export/re-import was failing as a result of the packages not being identical.