• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue After changing root password and Plesk admin passwords, migration fails

Tim_Wakeling

Basic Pleskian
Server operating system version
Centos 7.9.2009
Plesk version and microupdate number
18.0.43 Update #1
I've read and tried solutions from various other threads but still getting the problem. Desperate now, I'm asking for help! :)

I had a migration script running every 4 hours to copy-content from one Plesk server to another. I know there is a debate about whether this is the right way to do things but that's a separate issue. For now that's how it's working.

Yesterday I updated the Plesk admin passwords on both source and destination servers, and the root password on the source server. I updated the root password in /usr/local/psa/var/modules/panel-migrator/conf/config.ini accordingly.

But now when the copy-content command runs, every time it tries to migrate one of the databases, it gives this error (with key details redacted for public posting here):

Failed to perform an action on subscription 'xxxxx': Failed to copy content of database 'xxxxx' Exception message: Migration tools tried to perform operation in 3 attempts: Command execution failed on the source server 'pfu' (xxx.xx.xxx.xxx) with non-zero exit code.
command: MYSQL_PWD="$(cat)" mysqldump --no-defaults -h localhost -P 3306 -uadmin --quick --quote-names --add-drop-table --default-character-set=utf8 --set-charset --routines --events xxxxxx > /root/plesk_migrator/plesk_migrator-ylaja2280wl5cyh98eacjsvbqg3wfi2q/db-dumps/xxxxxxx.sql
exit code: 2
stdout:
stderr: mysqldump: Got error: 1045: "Access denied for user 'admin'@'localhost' (using password: YES)" when trying to connect

The last line suggests my changing of Plesk's admin passwords on either the source or the destination was to blame. But I was unwise enough not to note what they were before, so I cannot change them back.

Any idea how I can persuade the migrator to copy my databases again? I know the MariaDB admin@localhost password isn't supposed to be the same as the Plesk ones, but the Plesk ones were the only ones that changed, and that's definitely when the problem occurred.

Thanks in advance!

Tim
 
Since it is a dump failing, it should be the source server.
On the source server, check if the login works manually:
Bash:
MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin psa
 
Thanks for your reply! Yes, that command you gave me works when I enter it manually on the source server. I get logged in and given a
MariaDB [psa]> prompt.
 
The last line suggests my changing of Plesk's admin passwords ...
What exactly do you mean by "Plesk's admin passwords"? If you are talking about the GUI login password: That will be totally different than the one that is stored in /etc/psa/.psa.shadow.

I always thought that PMM takes the database access from where Plesk normally takes it: /etc/psa/.psa.shadow. If "MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin psa" logs you in to your database, there should not be any reason that migrator cannot do the same. Have you double-checked that you are addressing the correct server?

/usr/local/psa/var/modules/panel-migrator/conf/config.ini
I must admit I never knew that such a file exists. Even on servers where I have the /usr/local/psa/var/modules/panel-migrator/ directory I don't have a /conf that descends from there. Interesting.
 
I must admit I never knew that such a file exists. Even on servers where I have the /usr/local/psa/var/modules/panel-migrator/ directory I don't have a /conf that descends from there. Interesting.
AFAIR it only exists when there is a pending migration.
 
What exactly do you mean by "Plesk's admin passwords"?
Yeah, just the GUI ones on both source and destination. But I also updated the root password on the destination via the command line - passwd root.

After posting this I found I did have a record of all the old passwords in each of these cases, and changed them back, but the problem remains.

I concur that it definitely looks as if I must be accessing the wrong server but I assure you I have triple-checked! I will look again to make extra sure...

It's a strange one; it had been working fine for weeks before this, and I wasn't expecting it to suddenly stop. I tried creating a fresh migration with the transfer-accounts command as well; that also failed with the same error.
 
Back
Top