Linode Tutorial: How To Move Your WordPress Blog to Linode

Want to easily transition your existing Wordpress blog to Linode? Check out this Linode tutorial. By Ray Wenderlich.

Leave a rating/review
Save for later
Share

We're now on a Linode!

We're now on a Linode!

Yesterday, I moved this WordPress blog from a shared hosting site to a virtual private server at Linode.com. Did anybody notice? :]

The process was much easier than I expected, largely due to the excellent instructions available at the Linode Library.

However, in practice I found myself navigating between several guides and blog posts, so I wanted to gather all the material it takes to do this in a single Linode tutorial.

Why Linode?

Personally, the main reason I switched to Linode was so that I could have a web server that I could customize the way I wanted it. This way, I can easily play around with various technologies such as APNS or running my own TCP services on arbitrary ports.

I also like the improved performance it offers over shared hosting and the simple fact that it gives me some good practice at Linux administration! :]

As for why I chose Linode specifically, there are several other options out there (including Slicehost) that are pretty similar. I’ve heard good things about Linode from a lot of people and was impressed with their site and documentation, so decided to give them a shot.

And based on my experience with them so far, I’ve been very happy!

Signing Up and Booting Up

If you’ve decided to sign up for a Linode account and like this blog, please consider using my referral link – it helps reduce my web hosting cost, at no cost to you.

Either way, all you have to do is go to the main site, click “Sign up” and fill in the one page form – that’s all there is to it!

As for the plan to select, it depends on your space and traffic needs. I just have this blog and my wife’s blog on the box, so all I needed was the smallest plan (the Linode 360), which is $19.95/month for 16GB storage and 200GB data transfer.

Looking at the site, it appears to be quite easy to upgrade resources on the Linode if you need to later so it looks like it doesn’t hurt to start small (although I haven’t tried this myself).

Screenshot of Linode Upgrade Screen

Once you’ve signed up, the next step is to choose a datacenter for your Linode.

Check out used the speed test page on the web site to download the various binaries simultaneously to get an eyeball of which loaded more quickly.

Once you’ve chosen you can install an OS on your Linode. Personally, I picked Ubuntu 9.10 because that is the distribution I’m most famliar with at the moment – and it’s also recommended for people who are new to administering Linux.

I chose the 32-bit distribution rather than the 64-bit distribution because it saves memory, chose the entire disk space available for the Linode, and left the Swap Disk size at the default option.

The OS is usually deployed to the Linode extremely quickly – probably 30 seconds or so. Once it’s done just click the Boot button to load it up, and pow – your own VPS ready to roll!

Connecting And Upgrading

Once it’s booted up, click on the Network tab in the Linode manager, and jot down the IP address of your Linode. You can SSH to it from your remote machine with the following command:

ssh root@x.x.x.x

Enter the password you chose when you set up the Linode, and you’re in! The first thing to do is to update the system so the latest security patches applied.

You can either do this with apt-get or with aptitude. I chose to do so with aptitude after reading a couple of threads like this one that explain some of the benefits of aptitude over apt-get, including better removal of unused packages and simpler command-line interface.

To use aptitude, first enable the “universe” reposititories in the aptitude configuration file, which is disabled by default. This allows aptitude to search the community-maintained open source software for Ubuntu as well as the official Ubuntu-supported software.

Just edit /etc/apt/sources.list with your favorite editor and uncomment the six lines under the “universe repositories” section.

Then to update the system, run the following commands:

aptitude update
aptitude safe-upgrade
aptitude full-upgrade

That’s it – system updated!

Initial Configuration Tidbits

Also, early in the process you should probably set up a hostname for your machine. Even if you haven’t modified the DNS record for your domain yet, it’s not a problem to configure the machine so it treats itself like that early.

You can set the hostname with the following commands (naming your machine www):

echo "www" > /etc/hostname
hostname -F /etc/hostname

Then fix up /etc/hosts so that it has an entry for your IP:

127.0.0.1 localhost
x.x.x.x www.yourdomain.com www

Also, you may notice that if you let your terminal idle for a while, when you return to the terminal the SSH session may be hung. Obviously, this can be quite annoying, but there is an easy fix. Simply edit /etc/ssh_config and add the following line to the bottom of the file:

ServerAliveInterval 5

This will cause your SSH client to send a keepalive packet to the server every 5 seconds.

Keep in mind that this is basically disabling a security feature (I guess so that if you leave your computer unattended someone can’t hijack your session), but this wasn’t a concern for me so I’d rather have the convenience :]

Securing SSH and Setting Up a Firewall

As is, the system has a big security weakness: SSH is enabled, on the default port, and for root logins! That means that someone could run a password guessing attack against your system and potentially gain root access.

The other problem is we’re still using a root login rather than a user login using sudo, another security no-no! Luckily, it’s easy to patch these up – use the following guide from Slicehost. Just page 1, page 2 is optional.

Don’t worry that it’s about an older version of Ubuntu and for Slicehost, it works just the same with the latest version of Ubuntu on Linode!

Also, you may find it useful to have a way to test that the firewall is indeed working. Before you setup your new firewall rules (blocking everything), you can verify that the existing rules (allowing everything) allow you to connect to an arbitrary port by using netcat to listen on a port:

nc -l -p 1234

Then you can use telnet on your local machine to see if you can connect to that port:

telnet x.x.x.x 1234

You should be able to connect with the default rules, but not with your modified rules.