WP Toolkit cloning fails

[moswak]

TITLE:

WP Toolkit cloning fails​

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:

Onyx 17.8.11 Update #42
WP Toolkit 3.6.2-1609
CentOS 7.6

or

Onyx 17.8.11 Update #42
WP Toolkit 3.6.2-1609
CentOS 6.9​

PROBLEM DESCRIPTION:

On all installations with WP Toolkit release 3.6.2-1609 the WP Toolkit cloning function fails

Unable to check database. Error message: mysqlcheck: Got error: 1045: Access denied for user 'xxxx'@'127.0.0.1' (using password: YES) when trying to connect

panel.log

[2019-02-28 16:55:25.023] ERR [util_exec] proc_close() failed ['/usr/local/psa/admin/bin/filemng' '<webspace user account>' 'exec' '/var/www/vhosts/<subscription>/<domain>' '/opt/plesk/php/7.2/bin/php' '-d' 'safe_mode=off' '-d' 'display_errors=off' '-d' 'opcache.enable_cli=off' '-d' 'open_basedir=' '-d' 'error_reporting=341' '-c' '/var/www/vhosts/system/<subscription>/etc/php.ini' '/usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/php/boot-fs.php' '--path=/var/www/vhosts/<subscription>/<domain>' 'db' 'check' '--quick' '--silent'] with exit code [2]

[2019-02-28 16:55:25.024] ERR [1] '/usr/local/psa/admin/bin/filemng' '<webspace user account>' 'exec' '/var/www/vhosts/<subscription>/' '/opt/plesk/php/7.2/bin/php' '-d' 'safe_mode=off' '-d' 'display_errors=off' '-d' 'opcache.enable_cli=off' '-d' 'open_basedir=' '-d' 'error_reporting=341' '-c' '/var/www/vhosts/system/<subscription>/etc/php.ini' '/usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/php/boot-fs.php' '--path=/var/www/vhosts/<subscription>/<domain>' 'db' 'check' '--quick' '--silent' failed with code 2.

stdout:

stderr:
mysqlcheck: Got error: 1045: Access denied for user 'xxxxx'@'127.0.0.1' (using password: YES) when trying to connect​

STEPS TO REPRODUCE:

Create a Wordpress instance or use an existing instance.
Click the "Clone instance" button.​

ACTUAL RESULT:

Unable to check database. Error message: mysqlcheck: Got error: 1045: Access denied for user 'xxxxx'@'xxxx' (using password: YES) when trying to connect​

EXPECTED RESULT:

starting cloning task​

ANY ADDITIONAL INFORMATION:

reset or change dbuser password does not help​

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:

Confirm bug​

 

[zanuda]

Hello, thank you for your report,
Actually the problem is in the following: before the clone operation, we are using mysqlcheck to check that database is Ok. If not, clone operation become blocked. We are going to change this behavior in the nearest update of WordPress Toolkit. Please refer to the bug ID EXTWPTOOLK-2541.
But it is a strange thing that mysqlcheck reports an error for your database against that WordPress is up and running.
I suggest that you do the following:
1. Please wait for the next release of the WordPress Toookit
2. Check, that clone operation is not blocked
3. Try to clone and check panel.log file for erros during the clone operation
Most likely the error will remains in the log. In this case I suggest that you create a support ticket and provide us ticket number so we may get an access to your server and check what is wrong with your database.

 

[moswak]

Hello,

>> we are using mysqlcheck to check that database is Ok. If not, clone operation become blocked.
>> that mysqlcheck reports an error for your database

it's about hundreds of servers. the databases have no errors

example
root:~$ mysqlcheck -c database_gjw -uadmin -p`cat /etc/psa/.psa.shadow`
database_gjw.xSXZ8k84_commentmeta OK
database_gjw.xSXZ8k84_comments OK
database_gjw.xSXZ8k84_layerslider OK
database_gjw.xSXZ8k84_layerslider_revisions OK
...
...

The cloning process with exactly this database then aborts as described above.
mysqlcheck: Got error: 1045: Access denied for user 'xxxxx'@'xxxx' (using password: YES) when trying to connect

I hope the update for the toolkit comes soon

 

[moswak]

I have found out the solution or the cause of the problem and ask you to take this as a bug and eliminate it as soon as possible.

If external access is allowed for a databaseuser then the cloning process starts normally. If only local access is allowed for the database user, the above error occurs.

Since this was not the case in earlier toolkit version this must be a bug in the current version.

Please check this and fix the bug.

 

[zanuda]

Thanks a lot for your investigation.
Are you using local DB server (placed on the same server as the WP Toolkit) or a network connected external DB server?

 

[moswak]

We use on all servers a local DB Server.
On centos 6.9 Servers Mysql 5.6.x
On centos 7 Servers MariadDB 10.1.x

 

[joshuastarr74]

Confirm same scenario with the last update wp toolkit
On centos 7 Mariadb 10.1.x and local database

 

[LeoniG]

Thank you for the information. However, I was not able to reproduce the issue following the below steps:

1. Install WordPress on example.com.
2. Under Subscriptions > example.com > Databases > User Management > wp_user, set Allow local connections only in Access control.
3. Clone WordPress instance to staging.example.com.

The environment was as follows: Plesk Onyx 17.8 #43, WP Toolkit 3.6.2-1609, CentOS 7.6.1810, local MariaDB 10.1.38.

Please let me know if I'm missing anything.

 

[moswak]

on our servers, all databases are only locally accessible by default.

what can be wrong with our configuration if the servers work well for years with the wordpress toolkit and only since the last update anymore?

it does not matter if it's centos 6.9 server with mysql 5.6.43 or centos 7 with mariadb 10.1.38

 

[moswak]

please test this:

dbuser only access locally

if in the wp-config.php is registered:
define ('DB_HOST', 'localhost');

Cloning works

if in the wp-config.php is registered:
define ('DB_HOST', 'localhost: 3306');

Cloning does not work.

Access denied for user 'wordpress_ad'@'::1' (using password: YES) when trying to connect

 

[LeoniG]

Thank you for the update. Just tested it, and it works with the port defined in the configuration, as well as without it. Seems this is not the cause as well.

Therefore, additional symptoms are required to investigate this behavior. Thank you for bringing it to our attention.

Please submit a ticket to our technical support team so they could take a closer look at it.

 

[moswak]

the bug was fixed in the new version 3.6.3-1626.

The cloning process works again.