bavatuesdays

This post will be as much about thinking through account migrations for Reclaim Hosting, as trying to capture some of the technical aspects of moving sites to Reclaim Cloud. In fact, it promises to be all over the place, but that is the prerogative of this blog and that’s why I love it so.

Migrations: the act of moving people’s shit from one server to another.

The vernacular for what I am talking about here when saying migrations, not pretty but true.

Domains migrations: This can be a very straightforward process, for example when we have someone on one of our school cPanel accounts that wants to move to our shared hosting. CPanel has a transfer tool baked in and we can move accounts between servers within seconds (assuming they are under 10 GBs or so), and after that just make sure all the details in our client management software WHMCS are aligned and we are good to go. What’s more, migrations like this are easy enough that there is no charge for anyone migrating from a Domain of One’s Own school to our shared hosting.

Third-party free site migrations: There are too many of these to list, but a few popular ones are WordPress.com, Wix, Weebly, and Squarespace. Interestingly enough the only one of these listed with anything resembling a migration option is WordPress.com. You can export and import the posts, pages, media, and author data, but you have to re-build the site design with appropriate themes and plugins. All the other services would be a straight-up copy and paste of page content which should tell you everything you need to know. No HTML files to download, no easily accessible media, no database … nothing. Say what you will about WordPress, but at least it’s an ethos.  WordPress.com migrations are fairly straightforward, you just need to prepare folks that some plugins and themes on wordpress.com may not be readily available for free outside that space (I still hate the plugin and theme marketplace and always will). These migrations usually cost $25.

Everything else: Pretty much everything after those two categories is a crap shoot. We have done a fair amount of migrations from just about every host imaginable: Bluehost, Host Gator, Godaddy, Dreamhost, Webfaction, 1and1, etc. And while a few of these use cPanel (Bluehost, Host Gator and sometimes Godaddy) they’re by no means similar. It’s next to impossible to get a full backup from Bluehost without an upsell, Godaddy’s interface is as confusing as they come, and good luck making it through the advertisements in Host Gator. What’s more, if you live and die by the command line (which I don’t but should) getting SSH access is often another level of hell. Services like Webfaction (soon to be gone) and Dreamhost are better in that regard, but given they run their own hosting software there is no straightforward migration path, so the migrations are often manual, and if you have an account with 5-10 sites, that is 5-10x the work as one cPanel migration, which wraps everything up into one neat package.

So, long story short, these migrations are by definition more time intensive and as a result expensive. As a rule of thumb we charge $25 per site migrated in these cases, but as we have learned some of these services allow folks to run beefy sites on their shared hosting services, which is not something we can afford to do. For example, we limit our accounts to no more than 100GB of storage for a shared hosting account, and no more than 1 GB or total server resources. For some sites that want to come over to our shared hosting these limitations will be a hard stop given the amount of storage and CPU resources needed, so that raises two crucial questions before a migration like these even starts: 1) how much data?, 2) how many resources? A few others is what PHP versions they are running and whether or not they are running the latest version of the application (issues with folks needing to run older apps on older versions of PHP is always a red flag).

I’m sure there are other variations, but for sake of memory and dragging this post out I’ll leave it to these three categories, and taking the last as an example of how a site previously run on webfaction‘s shared hosting needing to be migrated to Reclaim Cloud. The site in question had 170 GB of data, a 2 GB database, and was running Drupal 7 on PHP 5.6. The storage was an immediate flag for our shared hosting, and while previously we would point folks to managed hosting (which can run as much as $400 per month), Reclaim Cloud offers a much more affordable, albeit unmanaged, option. Storage is quite cheap at .08¢ per GB per month, or less than $1 per 10GB per month. Also, for large sites with regular traffic and a long history Reclaim Cloud provides dedicated resources wherein you can reserve up to 2 GB of CPU but allow your instance to expand to 4 GB or more if need be, while only paying for those resources if and when needed.

On the Cloud we are able to install a container-based full-stack LiteSpeed server, also known as LLSMP, that is optimized for a PHP app running LiteSpeed (a drop-in replacement for Apache) that also gives the user root access to only that container. So, the client gets more storage, more resources, root access, and an overall more secure experience for roughly $50 per month (this is based on using 10 cloudlets, 150GB of storage, a dedicated IP address, and the LiteSpeed license). What’s more, you have the option to scale instantly should that be of concern.*

So that’s the argument for the Cloud in this case, and it really is a good solution when it comes to speed and experience, and the reason I even took on this migration was it would force me to get more familiar with Reclaim Cloud, in particular creating a LLSMP environment and importing a large Drupal instance. As I predicted, these migrations are never simple, and one of the trickiest pieces beyond understanding what environment you are coming from and where it is going to, is making sure the DNS points from one server to the other cleanly, more tears have been shed over DNS in the previous 8 years than I care to acknowledge in this post.

That said, here comes the notes part of this post because I’ve learned a few things here that I will be referencing in the future, cue blog as outboard brain.

LLSMP was dead simple to setup on Reclaim Cloud, I installed 6.0.2 and ran PHP 7.3.27 and once that was done I was able to login via the web-based SSH and start migrating the files to /var/www/webroot/ROOT

I ultimately had to enable root access on the container and thankfully Webfaction provides SSH access to their server, so most of this migration was done using command thanks to the rsync command, which is amazing. Logged into the Reclaim Cloud I ran the following command to sync files from webfaction:

rsync  -avzh [email protected]:/home/user/webapps/app /var/www/webroot/ROOT

Thanks worked cleanly, then I needed to grab a dump of the database on Webfaction, which this worked for:

mysqldump -u db_username -p db_name > database.sql

After that I rsynced it to the Reclaim Cloud instance

rsync  -avzh [email protected]:/home/user/database.sql /var/www/webroot/

After that I had to create the database user, datamase, and create privileges via command line, cause I am kind of a big deal. Well, I thought I was until I hit my first snag:

ERROR 1045 (28000): Access denied for user 'user_db'@'127.0.0.1' (using password: YES)

This is where I reached out to help from my Reclaim Hosting colleagues, and the always awesome Chris Blankenship bailed me out with some detailed instructions on how to fix this in Reclaim Cloud:

MySQL actually sees db_user@localhost and [email protected] as two separate accounts, which can cause problems. cPanel handles this automatically by creating both for all db users, but you’ll have to manually create both in Jelastic containers; so like this:

CREATE USER 'db_user'@'localhost' IDENTIFIED BY 'securepassword';
GRANT ALL PRIVILEGES ON db_name .* TO 'db_user'@'localhost';
CREATE USER 'db_user'@'127.0.0.1' IDENTIFIED BY 'securepassword';
GRANT ALL PRIVILEGES ON db_name .* TO 'db_user'@'127.0.0.1';

To make it simple usually add skip-grant-tables under the mysqld section of /etc/my.cnf, restart mysql (systemctl restart mysql), log in as root without the password. From there I run this:
FLUSH PRIVILEGES;

Followed by those commands above. Then I comment out, skip-grant-tables under  the mysqld section of /etc/my.cnf, restart mysql (systemctl restart mysql) again.

Once I figured out the permissions i was able to import the database.sql file using the following command from the /var/www/webroot/ directory:

mysql -u db_user -p db_name < database.sql

Once that imported I did a final rsync of files using the following command, with the -u flag to skip files that are newer on the destination.

rsync -avzhu [email protected]:/home/user/webapps/app /var/www/webroot/ROOT

There was also the bit where Chris updated ‘localhost’ to ‘127.0.0.1’ in the settings.php file for the Drupal instance given Reclaim Cloud is particular.

So those are very specific notes for this migration of a larger PHP application to a Reclaim Cloud instance, what’s more I had to do it again a week later given this was just to test the instance before moving the production site (this is where rsync is very useful, although the SQL dump had to be re-done though). As you can tell by now, this is not a $25 migration, this requires spinning up a server, syncing files between servers, and providing a testing environment. Luckily Reclaim Cloud environments automatically have a test unique URL that the mapped domain overwrites (namely something like site.uk.reclaim.cloud as opposed to site.com) that makes testing the environment easy before pointing DNS, which was quite convenient—even better than pointing localhost files.

Anyway, this is a long post about migrations and Reclaim Cloud, as much a series of notes as a way of narrating what I hope will be a deeper dive into the possibilities of Reclaim Cloud over the next 12 months or so given i have been freed up from other responsibilities, but more on that in my next post.
__________________________________________

*The hard part of the Cloud to wrap your head around is the variable pricing, I know it does remain fairly consistent from personal experience, but need for predictability is what Digital Ocean understood and has seemed to figure out, which I admire.