Tuesday March 25
 
17:03
 
Moving Hosting Companies - Solving Technical Issues

Introduction

Last night I moved The Korean Blog List to Cirtex.

Moving webhosting companies (or servers within the same company) is a right royal pain in the butt, made harder when you have a database driven dynamic site that is running 24/7.

Not only do you have the obvious problems of DNS transfer - during the 24 hour period when the DNS is changing to point to the new servers, you don’t know whether visitor sare viewing the “old” site or the “new” site - but you have the unobvious also: different versions of MySql and php, having to reconfigure email.

For my future reference, and for anyone who is moving host and may come across similar problems, here are some of the issues I had and how I solved them. Some of them took a lot of hunting in Google.

1. The Database.

If you have a site which is database driven - how do you copy the database to the new server when people could still be using the old server? It takes a day for DNS to transfer - during which time people could be accessing “old” or “new” site. You have no control.

One way to handle this would be for the new server to have a different URL - eg http://www.thekoreanbloglist.com/ for the new server, and http://www.koreanbloglist.com/ for the old. You can then:

1. Setup the new server - scripts, email, and everything except the database.
2. Take the old site offline - eg, move www to www2, and create www/index.php with “Back in 5 mins.”
3. Quickly transfer the databases.
4. Test the new site.
5. Change “Back in 5 mins.” to redirect to the new site.
6. Switch the DNS of the old domain name to the new server
7. Now you have two URLs pointing to the same site.

Unfortunately I use Wordpress for TKBL RSS feeds and blog, and Wordpress is a pain for switching URL - so this was not an option.

The way I had to handle this was as follow - and I actually think this is better:

1. Create the database and DB user on the new server.

2. Try to access the NEW database from a test PHP or CGI script on the old server.

How to write a script to access the new database from the old server? Personally, I recommend using MySQLMan from Gossamer Threads. While phpMyAdmin is great, MySQLMan gives you the ability to connect to a remote database - hence you can run it on the old server to connect to the database on the new server. Note: I still use phpMyAdmin for exporting and importing databases.

There are two potential connection problems you might have.

Firstly, remote connection might not be enabled. With hosting firm like Cirtex who use the industry standard cPanel, you just need to add the old server IP address or hostname to the “Remote MySQL” section. With other hosting companies you might need to email them to get this done.

Secondly, you might get the error “Client does not support authentication protocol requested by server; consider upgrading MySQL client” or even just a connection failed error. This happens when your old server is using a pre-4.1 version of MySQL, but your new server is using a later version. To solve this, you need to contact your hosting firm and ask them to do this:

UPDATE mysql.user SET Password = OLD_PASSWORD(’newpwd’)
WHERE Host = ’some_host’ AND User = ’some_user’;
FLUSH PRIVILEGES;

If it still doesn’t work - check your code. I had a script coded to use $SERVE instead of $SERVER. Doh. 

3. You should now be able to access the new database from the old server.

4. Take the old site offline - eg, move www to www2, and create www/index.php with “Back in 5 mins.”

5. Quickly transfer over the databases using phpMyAdmin.

Note about importing databases: The first time I did this, I hit a problem with character sets. Newer versions of MySQL have character set and collation options. I transferred my database leaving these as the default, and when I tried retrieving back posts with Korean or Japanese text - they were scrambled. If you don’t need international character sets, this is probably not an issue. For me it was.

Therefore, before importing the database, I have to do the following in phpMyAdmin. Firstly, ensure the default character set is utf8_unicode_ci. Secondly, for each database, click on the database name, then go to Operations and change the collation of utf8_unicode_ci. 

I could then export databases from my old server (phpMyAdmin, using gzip’d files) and upload them to the new server without character set issues.

Update: I subsequently found I have to do another step before importing: opening the exported file in Editpad Lite and converting to UTF8. See this post.

If you need to edit the database files in any way, eg. to remove a database name if your version of phpMyAdmin adds them, or to switch newline characters, then I recommend Editpad Lite, which handles both Linux and Windows newline characters, and international characters.

7. Restore the old www directory.

You now have the old webserver pointing to the new database. Since both the old server and new server can point to this database, you’ll never have issues with the databases being out of sync - and you can take your time moving the actual scripts across and setup the new server.

2. The DNS

After transferring scripts to the new server, there’s a problem. DNS takes up to a day to transfer over. After you switch the domain name to point to the new server, how can you be sure it works? For this, OpenDNS has been a lifesaver.

Firstly, update your domain name (with your registration company, such as Go Daddy) to point to your new server.

Then configure your PC to use the OpenDNS servers - instructions here.

Once that’s done, use CacheCheck to check the DNS for your domain name, and “RefreshCache” to ensure OpenDNS updates it’s cache with the new settings. Be sure to use “www.” at the beginning when entering your domain name.

Then flush the DNS on your PC. In WinXP this is done by: Start -> Run… ; cmd [OK] ; ipconfig /flushdns [Enter]

You should now be able to ping your domain name (On XP from the cmd window: ping www.domainname.com) and see that it points to your new server.

You can now immediately start accessing the new site from your browser to check that everything is working as expected. At this time most users will still be pointing to the old version of the site, so you have an early opportunity to correct things.

3. Teething Issues

I had two main teething issues: email and PHP.

Email was simple - I forgot to configure email on the new server :) My bad. So when my scripts sent email to me, they didn’t reach me.

PHP, I had a few issues with. Firstly, some of my scripts used $PHP_SELF, which wasn’t set on the new server - so none of my FORMS worked. The solution (after much hunting): add php_flag register_globals on to .htaccess.

Secondly, some of my scripts had the extension .inc, which were served as text files instead of processed as PHP. I couldn’t work out how to get them processed as PHP, so I used Fileman (another excellent tool from Gossamer Threads) to replace all .inc with .php in my scripts, and then renamed all the .inc files to .php.

I later found that by adding the following to .htaccess, the .inc files will also be parsed as php.

AddHandler custom-php .php .pcgi .phtml .inc .phtml~ .php~ .inc~ .html~
Action custom-php /cgi-sys/php5

But at the time I just needed a quick solution to get the scripts working again and secure.

Thirdly - and this issue probably existed on my old server but I didn’t notice - the anti-spam comment prevention images didn’t appear properly in Wordpress.

It took me hours to work out the reason, and finally I found it. My main Korean Blog List scripts and the Wordpress scripts both created database connections as the same user, but accessed different databases. Those were interfering with each other. The solution - without mass rewrites of code - was to create a new database user so that each set of scripts has its own distinct database connection.

Conclusion

None of these issues are due to Cirtex - I’d experience similar issues even if I just switched servers within the same webhost. In fact, being with Cirtex actually helped, because cPanel is flexible, and Cirtex responded quickly to helpdesk requests.

The main reason I’ve written this up is so that I can remember next time the checks I need to make when I switch domains between servers. I also hope this page helps anyone faced with similar issues or errors, who is frantically searching on Google to find a solution.

If you’re looking for a webhost, Cirtex are offering The Korean Blog List users half price hosting for two years - just click here and then use the The Korean Blog List special coupon code GALLERY to get 2 years hosting for $59.88 instead of $119.76, with a 30-day money back guarantee. Note: This is a limited offer that could be removed at any time. It’s hard to find a good web hosting company.

I find Cirtex’s service to be responsive, the servers to be fast, and I know several other people who use Cirtex who also have had good experiences. With the 30-day money back guarantee, it’s difficult to go wrong by trying them out. They even say they will transfer cPanel hosted sites for free - unfortunately my old host didn’t use cPanel!