When upgrading this site, I replaced the underlying hardware as well. The old server was just a dead end in too many regards to be worth upgrading in place, and besides, being able to run new and old side by side for a time is helpful.
This type of maneuver is routine work for a professional sysadmin. But it’s been at least two years since I’ve done a similar maneuver at all, and at least five years since I did it with Linux.
When I built the new machine, I gave it a unique IP address. Turnkey Linux makes getting an operational LAMP stack trivial, and depending on what you want to run on that stack, you may even be able to get that installed for you too.
Unfortunately for me, the Geeklog migration tool doesn’t seem to work with WordPress 3.0.1. So I had to get WordPress running on my old hardware in order to migrate. I chose WordPress 2.0.11 because the 2.0 branch appeared to be the current branch when Justdave wrote his migration tool, and 2.0.11 ran without complaint on the dated versions of PHP and MySQL that were on my old server.
After importing the content, I used mysqldump to export my databases. Specifically:
mysqldump --opt -u [mysql username] -p [database name, probably wordpress] > wordpress.sql
I should have gzipped the file, but I didn’t.
gzip wordpress.sql
I then connected to the old server via FTP and transferred the file. Use your favorite file transfer method; I happened to have FTP set up for my internal network.
Uncompress the file if you compressed it:
gunzip wordpress.sql.gz
Then restore the file:
mysql -u [mysql username] -p [database name] < wordpress.sql
Or, if the database already exists, like in my case:
mysqlimport -u [uname] -p [database name] wordpress.sql
Then I connected to the webserver via my web browser. WordPress 3.0.1 saw the WordPress 2.0.11 database and informed me that it needed to be upgraded. So I let it do its thing, and a few minutes later, I had a functioning WordPress site with 10 years’ worth of legacy entries.
I messed around with it for a while. Finally, I decided to go live. And at this point, I should have physically moved the new server into its permanent home. I didn’t do that, so now when I decide to move the server, I’m going to have some downtime.
To flip the IP addresses, you need to know where your Linux box stores its IP address. Debian and Ubuntu both store it in /etc/network/interfaces. As far as I can tell, Red Hat and derivatives like CentOS store it in /etc/sysconfig/network-scripts/ifcfg-eth0, but I haven’t used Red Hat or a derivative in a long time, perhaps 2003.
If worse comes to worse, try something like this to determine where it’s stored:
grep -r [ip address] /etc/
I edited the appropriate file on both boxes, changing the IP address while leaving all of the other parameters unchanged.
I then issued the command ifdown eth0 on both machines.
On my new production server, I then issued the command ifup eth0. Depending on the Linux distribution, it might also be necessary to re-issue a default route command. I didn’t have to do that.
Depending on how much Linux/Unix cred you have at stake, you could just do it the Windows way and reboot the box. Or both of them.
Once I was satisfied everything was working, I powered down the old server and celebrated.
David Farquhar is a computer security professional, entrepreneur, and author. He started his career as a part-time computer technician in 1994, worked his way up to system administrator by 1997, and has specialized in vulnerability management since 2013. He invests in real estate on the side and his hobbies include O gauge trains, baseball cards, and retro computers and video games. A University of Missouri graduate, he holds CISSP and Security+ certifications. He lives in St. Louis with his family.
