Trying to remote transfer sites from one AWS EC2 instance to another. Getting this frustrating error message that tells me nothing, with no errors in the logs. How can I avoid this?
Make sure you have api enabled for the username “admin” from where you wish to fetch the files from.
Make sure you haven’t changed the default 8090 port of cyberpanel.
Update both the cyberpanel setup to the latest version (just dont overlook the version number because many fixes are done without changing the version number). Just run the cyberpanel upgrade command via SSH for both the servers and try again.
Right now I tested and it all works perfect for me.
1 Like
Thanks @die2mrw007. This was a fun one, I had a few things going on, I’m going to document here to help future me and maybe others.
First, I thought I was smarter than cyberpanel (I’m not), and manually changed the SSL certs in /usr/local/lsws/admin/conf to the same cert/key as my main domain name. This duplicate appears to have triggered something which then corrupted the /usr/local/lsws/conf/httpd_config.conf file. So I manually fixed that by removing a bunch of ‘@’ characters that were randomly inserted, fixed the error.
THEN, I created an entirely new WEBSITE with a subdomain, issued it a LetsEncrypt SSL cert as part of the creation.
THEN, I applied that website as the hostname in SSL → hostname SSL
This cleared up an issue causing the webserver to frequently restart- I think it was trying to read the SSL I put in, but was duplicated on the website itself. So using a SEPARATE WEBSITE (subdomain is ok) for the host name is key, it would seem.
Verified that SSL was working at subdomain.mydomain.com:8090 AND at mydomain.com, separately.
Spun up new server, made sure that NEW SERVER gets the dedicated IP address (would be a real bitch to have to do this with a new IP address). Yes, downtime commences.
Now, create a new website on the new server, and create an A record of the subdomain created above, pointing the the new IP address of the OLD server. This will allow you to use a host name for SSL connectivity. In other words, the new server needs to be the DNS server, and point to the old server.
Do the hostname process (separate website necessary) on the NEW server.
Now with SSL working for the whatever.domain.com:8090 on BOTH SERVERS, we can back up. Do not use IP addresses with the remote backup processes, as SSL won’t be allowed.
Ultimately, I think the issue had been that by screwing with the SSL certs myself, the web API was using a self-signed or unverifiable certificate, which in turn would not allow the remote backup process to continue from the origin server’s end.
Worked for me, AWS t3.small Ubuntu 20.04 → same, Ubuntu 18.
1 Like
You always go the longer route when everything is already out of box 
And there is no real requirement of hostname SSL or SSL in my tests. I had a spare server in oracle free cloud with cyberpanel installed. There is no hostname issued in that server. I was able to fetch all the websites hosted in that server to my aws server just by mentioning the ip address and admin password at aws server installed cyberpanel remote transfer option. It was successfully fetched.
Interesting. Must have been just a broken API then, and correctly setting the host’s SSL had the side effect of fixing it. Nice healthy server tonight though! hah!
1 Like
Glad its all fine now.