Careful when migrating from 6 to 8 (Serious complications)

Steini Petur

Well-Known Member
Apr 24, 2016
99
25
68
Iceland
cPanel Access Level
Root Administrator
Hey guys,

I just wanted to write this friendly reminder because of the errors that we went through, we were migrating from Cloudlinux 6 to Cloudlinux 8.5, the previous version of SQL was MariaDB and by default, and here is the thing, the default MySQL is 8! on the new cPanel you can avoid this with this

mkdir /root/cpanel_profile
nano /root/cpanel_profile/cpanel.config


and set this line

mysql-version=10.3

Whatever version you had on your server before because if you do not, you will be in so much trouble!, we had to do endless tinkering with the my.cnf of MySQL 8 to allow this, allow that, to name a few

sql-mode="NO_ENGINE_SUBSTITUTION"
default-authentication-plugin=mysql_native_password
validate_password = OFF
plugin-load-add=validate_password.so
validate_password_policy=LOW
log_bin_trust_function_creators = 1
default-character-set=utf8


This is just so far, to at least alleviate some of the symptoms.


We had to help a few clients where restoring them didn't pan out because MySQL doesn't allow TEXT to be DEFAULT etc.. Endless pain, we're not sure if this was related but restorations of Addon domains did not go as planned out, we ended with all Main domains, all subdomains but Addon records in

/var/cpanel/userdata/*/main of everyuser was empty pretty much

The physical files were still there, so we knew it was still a chance to resolve this, not 1 by 1, went back to our old server took a copy of /var/cpanel/userdata, and moved it over, and followed this: How to Rebuild userdata Files | cPanel & WHM Documentation

This link allowed me to understand to set it to .orig (or whatever .bak) and then replace it with the old one, then run the userdata update and updatecache, that fixed the addon domains back to place, How I was confirming it was WHM > Convert Addon to Main, going in there I would see like 7 so I knew it was just recent 7 someone put, I had to be quick, did this and boom over 300 records, so I knew we were in the clear, I checked the domains and voila they were good. Now just rebuild the HTTPD conf and restart the Apache/LiteSpeed

One more issue was, we ran AutoSSL on them now that they had /path, so they could be validated and SSL installed.

I can't stress the importance to set the MariaDB default before starting (or match the version and software you have on your previous server).

This was such pain, and such a nightmare that I can't believe and I strongly believe during the sh ./latest when setting up the cPanel, cPanel should ask you, this simple question

!!! NOTE: MySQL 8 has these and these changes, if you are migrating from an existing system and would like to set another MySQL version please type y?
Which version would you like to set up [ x, x2, x3]? x2


Proceeding to install x2, <normal installation resumes>

I am probably not the only one that has had this issue, and to realize this so late when you have restored the whole server almost, I saw a few yellow warnings here and there but didn't think much of it, usually, it always panned out, been a broken subdomain or a non-pingable domain remnant, in this case, it was all legitimate couldn't do this couldn't restore this.

-- Why my backup was a bit slow (Optional, just my thoughts) --

I ended up seeing why my backing up was so slow, it was because of how cPanel focuses on CPU core use and sleeps when it's busy and is a bit conservative and balanced, and in normal situations that is great! but for me that was waste of time migrating over so i came to the conclusion that me doing for loops through /pkgacct catting the /var/cpanel/userdata was much better, than just another for x loop through /scripts/restorepkg --unrestricted --allow_reseller --force $x.

I was trying to move it quickly between servers at a good speed, using Rsync

for x in ` ls -arth /path/to/all/the/backups | grep tar`; do rsync -avh --progress -e 'ssh -p <port> -T -o Compression=no -x' $x [email protected]:/home/; done

Anyway, all is well that ends well, but just remember MySQL 8.0 has some SERIOUS differences to previous versions, it is so different that it will hit your clients hard if you have 100-1000 on the server, they are bound to hit a brick wall with scripts that are no longer compatible, it's a big leap forward MySQL 8.0, I urge cPanel to consider adding a step in the latest, let the admin choose if he wants to go a different way without having to look up your documents and hope there is a way.

All the best
 
Last edited:
  • Like
Reactions: kernow

Steini Petur

Well-Known Member
Apr 24, 2016
99
25
68
Iceland
cPanel Access Level
Root Administrator
@cPRex I currently have an open ticket with cPanel support, because even after doing the updateuserdata, and everything looks okay on it's face, for some odd reason even after checking vhost records in the httpd.conf etc, all the addon domain records exist now, all connection looks great, but for some odd reason they ALL redirect to the primary domain only, not sure why, not sure how, but hoping cPanel can help me and if they do help me and figure it out, I will submit that in here as well so not to leave anyone else in the future that googles and comes onto this forum is left hanging.
 

Steini Petur

Well-Known Member
Apr 24, 2016
99
25
68
Iceland
cPanel Access Level
Root Administrator
@cPRex we rolled back to 6.0 server, the complications that arose from this migration were to horrendous, back to the drawing board with a clear picture, best not export any configs from whmapi1 just write down the details that need changing the exim IPs etc everything just do it by hand, to avoid this, and make sure the MySQL is MariaDB 10.03, the MySQL 8.0 part was the biggest trainwreck I have ever run into.
 

Steini Petur

Well-Known Member
Apr 24, 2016
99
25
68
Iceland
cPanel Access Level
Root Administrator
They did not but It's okay I told them to drop it because the issue is mostly in the MySQL 8.0 and just anything else that followed, I would have done this without pkgacct and restorepkg if i didn't run into a boring issue with the Transfer Tool which I explained here : First 8 characters conflict with one or more other usernames - This is why i went to PKGACCT and RESTOREPKG because the transfer tool is buggy about some username issues, that have nothing to do with MySQL versions, just annoying..

But the way we're doing this is different, we've mapped out me and a colleague how we're approaching this situation now, we're going to spin up the new machine on a secondary IP, this will LATER become the final IP, just live transfer slow and steady with a little heads-up post pointing to Network Issue page to follow the updates
 

kernow

Well-Known Member
Jul 23, 2004
1,020
62
178
cPanel Access Level
Root Administrator
mkdir /root/cpanel_profile
nano /root/cpanel_profile/cpanel.config


and set this line

mysql-version=10.3
If CloudLinux 8.5 has already been installed, what will adding the above achieve? will it help with account transfers or is the above only to be done on a new server during a cpanel install?
 

ffeingol

Well-Known Member
PartnerNOC
Nov 9, 2001
765
310
363
cPanel Access Level
DataCenter Provider
@kernow It has to be done before cPanel is installed. The installer will ready that and install the version of MySQL/MariaDB that you request instead of the default. The only caveat is that that version has to exist on the new distro. If not, the installer will simply error out.