• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Resolved Migration Failed to execute SQL query

Brahim

New Pleskian
Hi,

We have two plesk onyx servers running , one of the server is the production server and the other one is the acceptance server. But if we want to use the plesk migration from the Plesk Onyx production environment to get the data from the acceptance environment we get error message back about;.

Failed to fetch basic information about resellers, clients and domains data from source servers
Cause: Failed to execute SQL query on Plesk database: failed to parse JSON returned by SQL script.
Query:
SELECT Subscriptions.id as subscription_id, clients.id, login, pname
FROM clients
LEFT JOIN Subscriptions ON
Subscriptions.object_id = clients.id
AND Subscriptions.object_type = 'client'
WHERE clients.type = 'reseller'

Command's exit code: 255
Command's stdout:
Command's stderr: Died at AgentConfig.pm line 23.

That is a critical error, migration was stopped.
=======
The user have root rights and connecting from the production server to the acceptance server on port 22 works fine.
 

Attachments

  • Screenshot.jpg
    Screenshot.jpg
    75.5 KB · Views: 14
Most probably that something wrong with database on source server. Try to check this failed SQL query with

# plesk db
mysql> SELECT Subscriptions.id as subscription_id, clients.id, login, pname FROM clients LEFT JOIN Subscriptions ON Subscriptions.object_id = clients.id AND Subscriptions.object_type = 'client' WHERE clients.type = 'reseller';

What is output there?
 
Hello Brahim,

Check that migration has been started using 'root' account and not any over.
 
Hello IgorG & Mr.D,

Thanks for the reply, I will check this tomorrow at the office.
We have a managed services servers and limited rights on the root user.
Is there an option to use the migration tool with "sudo su - user"?

Thanks,
Greets Brahim
 
System Overview
OS ‪Red Hat Enterprise Linux Server 6
Product Plesk Onyx
Version 17.0.17 Update #8,

:).
 
Same issue here as described by Brahim.

@Mr.D
Do I understand this right that the user for migration must be named "root"? It's not about the privileges, it's about the user name? Then this behavior ought to be changed. We believe that it is best practice to NOT name the user that has root access privileges "root", e.g. disallow SSH access for "root". Or will it also be sufficient to have a user with full root privileges but a different name?
 
Hi @IgorG,

i ran you select query but the output of the query is empty...

@UFHH01 & @Mr.D.
This won’t work because the root user and the GID/UID 0 that is used for the root user cannot connect to SSH to the servers.
This is disabled by default on all our enterprise linux servers as it is considered a serious security risk.

And yes i agree with @Peter Debik..

Why should this be root user? if normal user has also the right as root or to become a root user by "su -" or "sudo su -" / "sudo -i" " or sudo "username" then the normal user should also perform the migration tool.
 
Last edited:
Hi Brahim,

This won’t work because the root user and the GID/UID 0 that is used for the root user cannot connect to SSH to the servers.
This is disabled by default on all our enterprise linux servers as it is considered a serious security risk.

And yes i agree with @Peter Debik..
In such a case, you should consider to "temporary" change this sort of configuration, during the migration process, in order to avoid issues/errors/problems with the Plesk Migrator. The Plesk Migrator is limited to "GID/UID = 0" not only for compatility reasons to several operating systems, but as well because of security reasons. I doubt that the Plesk - Team / Developers will answer this in detail, but you might still hope for an explizit answer here from them, which could answer your curiosity more accurately. ;) If you would like to benefit from using the Plesk Migrator, then you can only achieve this, when you use the user "root" with GID/UID = 0.
 
We've tested it and confirm that GID/UID must be 0. The issue does not occur when the root user is used. A temporary change of "PermitRootLogin no" to "PermitRootLogin yes" in the SSH configuration of the source host system is acceptable to us. Thank you for your assistance.
 
Hello,

The "root" user or user with another name and "GUI/UID = 0" is required for avoiding issues with access, security restrictions and another possible issues on many supported Linux distributions, Plesk versions and other panels. SSH connections is actively used by Plesk Migrator for executing CLI commands on the source server and schemes with rising privileges could be unstable and call a new issues.
Also it is not needed that "root" user could login from anywhere of Internet. You can permit root login from specific IP addresses or networks for time when migration will be performed. Also you can use key based authentication with specified IP in key. After migration the access settings could be returned back.

@Brahim,
This query can return empty output when no resellers on the server and it is normal.
I have tried to start migration from RHEL 7 using not 'root' account and your case was reproduced. Please use 'root' account this is Plesk migrator requirement.
 
Back
Top