Apologies if you found Losing it unavailable earlier. I was upgrading its backend. Well, the operating system of the virtual server that runs Losing it, Tiggercam and some other sites. Which is just the sort of thing I like to do on a quiet Boxing Day afternoon.
I was reminded that I should upgrade Debian to the latest version when I did the usual
apt-get update && apt-get-upgrade
which updates all the various bits and bobs to the latest releases. Well, the latest releases for the distribution you’re using, that is. So it wouldn’t upgrade you to Debian 8 if you’re running Debian 7, but it would make sure you’ve got the latest bits for Debian 7. Rather like Windows Update won’t upgrade you to Windows 10 if you’re running Windows 8. Err, well, rather not like that, given Microsoft’s enthusiasm for that particular change.
Anyway, I ran all that, and amongst the many messages shown was a warning that the version of PHP in use wasn’t getting any more updates, was deprecated, likely to kick the cat, and so on and so forth.
So, I decided to check up on the process for upgrading my Linode virtual server. Not being as versed in the wiles of Linux as I am in those of OS X and Windows, I always read the instructions before doing anything that might cause breakage. Several releases ago, the upgrade broke the MySQL database server, which wasn’t fun. Anyway, Linode, in addition to providing nicely specified virtual servers, provide loads of documentation, including a useful piece on upgrading from Debian 7 (known as Wheezy) to Debian 8 (known as Jessie):
And it’s a good job that I read it – the upgrade takes the Apache web server, which is ever so slightly essential, from v2.2 to v2.4. And v2.4 requires some changes to the little files that tell it which sites it’s supposed to be running, and where the files for those sites live. The easy bit is that instead of being called
the configuration file for this site would have to be called
Well, that wouldn’t be a problem, as v2.2 wouldn’t have objected to the change, which would have allowed me to do a quick tweak and have everything working after upgrading. But there was another problem. Apache 2.4 needs a different setting included in those configuration files, which isn’t needed in 2.2. And if you do include that setting in the configuration file while you’re running 2.2, your sites will, apparently, fall over with the dreaded 500 error. All this is helpfully documented, of course:
So, I decided to prepare for the upgrade in a way that wouldn’t break anything. I copied each configuration file using this command:
cp losingit.me.uk losingit.me.uk.conf
(Repeated for each site)
I then edited the new files, adding something similar to this in each one:
<VirtualHost *:80> ... <Directory /path/to/public/website/> Require all granted </Directory> ... </VirtualHost>
Making sure to put the new Directory block inside the existing VirtualHost bit, and getting the path correct – easy to do as it’s already on another line in the file.
Then came the most important bit – taking a backup of the server. I pay for Linode’s optional backup service, which apart from taking daily backups of the whole server, lets me take a snapshot at any time. As it’s only saving changes, this typically takes about five minutes on my Linode, so there’s no excuse for not doing it.
Once the backup was done, I followed the steps in the instructions. I’d already run
to allow me to run all this stuff with root privileges without typing sudo every time. So I then:
Stopped a few services:
service apache2 stop service mysql stop
Set up emergency console access in case it broke:
apt-get install screen screen
Then I edited /etc/apt/sources.list to replace all the references from “wheezy” to “jessie” and did another:
and followed the instructions to update some packages. In the usual Linux way, this also updated a load of other bits:
apt-get install apt dpkg aptitude
This produced several squillion lines of messages, some text files that had to be paged through, and a warning or two. Yours may differ, if in doubt look up the messages in your choice of search engine.
Then came the major upgrade bit:
This led to much of the same, mainly confirming that I wanted to keep my settings files rather than having them replaced by new default ones. The process restarted Apache and MySQL, so it was just a matter of getting Apache to look at those .conf files I’d prepared earlier.
I thought I might have to disable the old settings first, but as the files lacked the essential .conf extension, they were already disabled. So all I had to was enable each site:
(Repeated for each site)
In order for Apache to actually do its business with the sites, it needs to be restarted:
service apache2 reload
A quick check confirmed that Losing it was up and running. The only remaining thing to do was to reboot the server to make sure that nothing would break on startup – better to find out now rather than at some arbitrary point in the future (reboots are rare). And that all worked as well.
So there you go. Longest post for a while, packed with details that most
unicorns regular readers will either find ludicrously trivial or moderately incomprehensible, which come to think of it, is probably about normal around here….
And now it’s an even longer post.
My quick look omitted one bit of testing. This is something so basic, that’s been there in WordPress for over a decade, that I sort of forgot to make sure a major web server upgrade and reconfiguration hadn’t broken it. This is the thing that lets me give each article a human-friendly url, such as:
(That’s not a real link, because if I put one in, WordPress will do helpful things with it.)
Anyway, I just happened to click on title of a post, which should have taken me to that post’s own page, but instead it led me to an unfriendly “page not found” page. Not the usual WordPress one, but the default Apache one. This could only mean that Permalinks (the feature in question) were borked. I did the usual think of changing the settings to another option and back again, but that made no difference. Having reached the limit of my Apache knowledge, I did a quick search, and soon found a useful thread on the WordPress support forums:
This involved a similar situation after an upgrade from Apache 2.2 to 2.4, and an answer was provided. It suggested that a setting was missing from the configuration of the server, which is the kind of thing that might happen with upgrades. What was needed was something like this:
<Directory> AllowOverride All </Directory>
A bit of thought led me to the solution for my server – having added that Directory setting to each site’s configuration, I suspect this was replacing, or indeed overriding any Directory settings in the default settings. So, I thought, if I added that new line into the Directory section of each site’s configuration file, normal service might be resumed. I gave it a try with my test site, and sure enough changing the section to read:
<VirtualHost *:80> ... <Directory /path/to/public/website/> Require all granted AllowOverride All </Directory> ... </VirtualHost>
followed by another restart of Apache, of course, made things work as they should. I did the same for all the other sites (not that all of them need it, but it’s easier to be prepared), and things came back to normal.
 Oooerr, missus, etc
 The language used by WordPress amongst other things. Allegedly stands for PHP Hypertext Processor, making it one of those ever-popular recursive acronyms
 Even if you don’t have one
 That’s the business of serving web pages, you understand.
 Could be wrong, of course