• Halloween is coming! To celebrate the occasion, we dusted off a couple of old skins, and even created a brand new one (Pixel).
    To get into the festive spirit, install the Skins extension.
  • The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • The Plesk Mobile apps for iOS and Android and the Plesk Mobile Center extension have been deprecated, and are no longer available for new installations. In Plesk Obsidian 18.0.84, the Plesk Mobile Center extension will be removed from servers during the upgrade, and the Plesk Mobile apps will lose their server management features.
  • The Social Login extension has been deprecated and will be removed in Plesk Obsidian 18.0.84. After that, it will no longer be possible to log in to Plesk with a Google, Facebook, GitHub account, or with a passkey. Plesk usernames and passwords, as well as logging in with a WebPros Account, are not affected.

Problems with Plesk Migration Manager

G

greyboy

Guest
Hello,

We are trying to move many sites from a cPanel server to a Plesk v7.5.4_build75051209.14 os_RedHat el4 machine and are experiencing many problems.

The process goes like this.

1) I package up the sites using cPanel9.pl --no-compress --accounts=acctname
2) SCP the files over to the new server
3) copy and chown the files to /usr/local/psa/PMM/archives
4) copy the cPanel.xml file to /usr/local/psa/PMM/var/dump.xml
5) Proceed to use the PMM took from within Plesk.

However, we are seeing quite a few errors. Most seem to be OK anyway, but the database errors are not. This is common for almost every domain:

1. Failed deployment of database user username of database username_dbname
Execution of '/usr/local/psa/bin/database.sh' '--update' 'username_dbname' '-add_user' 'username' '-type' 'mysql' '-passwd' '' failed with the return code 1.
STDOUT:

STDERR:
Unable add user to database: Unable to create the database user: User username already exists.

[Plus many more...]

I believe the problem is that username is already assigned to another database, which is common. A single username can span multiple databases, so this script fails.

I see how to manually manipulate the psa database to account for this, but it's a tedious process.

Does anyone here have any experience they can share regarding this?

Thanks,
-N
 
Back
Top