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 root@xxx:/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
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 root@xxx:/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:
