I’ve hosted this site and a few other WordPress sites that I manage on a Linode virtual private server (VPS) that has gradually become more outdated, so this week I’ve worked at freshening it up.
They’re mostly low-traffic sites and have never needed anything special in terms of configuration, but it was past time that I did some important and straightforward improvements, including HTTPS (thanks to Let’s Encrypt) for all traffic and enabling HTTP/2.
Upgrading the Server
The server was still running on Ubuntu 14.04, which I kept updated but still had the default older versions of software packages, so I wanted to switch to the latest Long-Term Support (LTS) version, 16.04, which would also bring with it PHP 7.0 and other improvements.
When I created the original server I made sure to make the disk image take up less than half of the storage space available on my Linode account. The server didn’t need any more space and it comes in handy for duplicating the image as a backup before doing anything experimental. And for this upgrade, it also meant I could create a new Ubuntu 16.04 server image configured with the same IP address so I didn’t need to mess around with updating DNS records for the sites.
The migration steps were:
- Export database contents for migration, which I did using
mysqldumpto export the whole DBMS.
Download the database backup (using Transmit for SFTP), all of the files from each website (in my case, the entire contents of
/srv/www) and the nginx server configuration files (from
In Linode Manager, shut down the server, then deploy a new 16.04 image and boot it. Here’s the main drawback to my approach, because from this point until I got everything configured on the new server the sites were unavailable, but an hour or two of downtime wasn’t a critical issue for me.
Set up the new server, which pretty much involved working through the steps in a few of Linode’s guides: Getting Started, Securing Your Server, Configuring UFW (including a rule to allow https as well as www), and then Installing a LEMP Stack (although I used MariaDB instead of MySQL).
Upload all of the files I had downloaded at step 1, move the website files and nginx configuration files into place, and Restore the DBMS from backup.
Extra Steps and Gotchas
That process just about had everything in place, but there were a few things that needed extra work along the way:
- The new database configuration defaulted to expecting all of the database user accounts imported from the backup (I create a separate one for each WordPress installation) to have user logins on the server itself. I connected as root (
sudo mysql -u root -p) and then set native database authentication using commands similar to option 1 in this StackOverflow answer, but inserting the username for each of the websites’ database user accounts.
Figuring out which PHP extensions the WordPress installation would need took some reading and experimentation. Note that you can use
php -mto get a list of installed modules, which might be worth running on the original server as a guide. Everything seems to be working with what I’ve installed at the moment, although when I first got the sites running I found that Jetpack wouldn’t work properly because I hadn’t installed
Restarting the Websites
Once everything appeared to be in place, I enabled the server blocks (and also removed the default site –
sudo rm /etc/nginx/sites-enabled/default) and restarted nginx.
This got the websites back to functioning as they had before, but on an upgraded server that would support changing the sites to have better security through HTTPS and performance by enabling HTTP/2. I’ll write up how I got all of the WordPress sites switched across to those protocols – and why it’s worth doing – in a separate post.
UPDATE 29 December 2017
I missed one thing that the server needed – setting up a mail server so that the WordPress sites can send email notifications. I used Linode’s guide to configure Postfix to send mail via Gmail/Google Apps using my G Suite account.