Tag Archives: update

What a week!

What a week it has been! We returned to Kent from visiting family in Derbyshire, unaware of the events in store…

It all started Monday morning with an ominous email reading “The server has disappeared!”. Never something you want to see, never mind on a Monday! The usual ping test confirmed the host was down, though the hosting companies routers confirmed that the host was unreachable, so at least the DNS was not to blame.

Checking the providers news feed revealed they’d had a server outage the previous day, confirmation something had gone awry on their end. After finding someone with the password for the dashboard, they raised a support ticket and got the server running again! Unfortunately that was only the start of the problems!

As the server had unexpectedly gone off line, the file system had a few errors and so had been mounted read only until we could run FSCK over it to correct any problems. Being a hosted server, this had to be requested from the ever helpful support team. That done, we managed approximately half an hour before the server switched the file system back to read only mode! After several attempts to stabilise things, the decision was made to request a new server image and perform an emergency migration… Not something to be taken lightly, given the server was still running Ubuntu 10.04!

With the new server freshly running 14.04 and updated, the long slow process of installing the LAMP stack commenced, followed by the reinstatement of the databases and web site pages. By Tuesday evening, everything appeared to be running. Or so it seemed! It turns out the website was relying on features disabled in the currently installed version of PHP! After trying a few code kludges to work around the matter, time was pressing on and so a downgrade looked the best option. But how to carry it out? A good old compile from source! Which always takes forever in a server environment, given they aren’t geared for development and so package after package had to be added before it was finally compiled and installed and back up and running!

So, by Wednesday evening, the majority of the functionality had been reinstated…  A problem reading created Excel spreadsheets was traced to bugs in a no longer supported PHP module (http://pear.php.net/bugs/bug.php?id=19284&edit=3) and usability issues relating to cookie usage across domains were rectified (rather than respond to several addresses, the site now forwards requests to one domain) and so we’re up and ready for the weekend!

So what did I learn from the week?

  • Always keep up to date backups of the /etc/ directory! Luckily I had a copy I’d made last year available, but it would have been much easier if it had been kept up to date!
  • PHP is evil…
  • And PHP code from last decade isn’t going to be happy on a fresh server.
  • Ask for passwords for the control panel of the server! I hadn’t asked as I didn’t forsee a need for it…

So here’s to the weekend, and the 10 mile run on Sunday! (http://canterbury10.co.uk/)

With thanks to:

The support staff at Hosting UK (https://hostinguk.net/)  who did all they could to ensure we were back up and running as quickly as possible.

My colleagues at AUKWEB (http://www.aukweb.net/) all volunteers who set up the old server, coded the site and assisted where they could in the migration.

Here’s to another decade of uptime!

Trouble with WordPress automatic updates?

Well, I’ve just spent a good half an hour trying to jog my memory on how exactly I got WordPress to update itself the last time I tried. Googling for a solution didn’t really help either, as the general consensus was “Do it manually!”.

Not one to give up on a problem I tried to remember what I had done… I do recall having set up something via FTP… Did I need a server running for the update? No… All I would get was an error saying the download had timed out. This told me my file permissions, that do seem to cause a lot of issues, were good. But why was the download failing?

The file it was trying to down load was http://downloads.wordpress.org/release/wordpress-4.4.1-new-bundled.zip. I checked the firewall, outbound HTTP traffic was fine, attested to the fact I’d successfully updated the rest of the system only minutes earlier. What was the problem? One sure fire way to find out – WGET, a command line function that will download a file from a web server… And what did it tell me? http:// was no longer supported on the server, trying https:// Ah, at last! I’d opened port 80, but SSL uses port 443! I opened the outgoing port et voila! Update successful!

So just remember, if you do get any error messages, try recreating the error outside of wordpress, it can help immensely!



Two weeks to update?

So what are my thoughts on WordPress now I’ve had it installed for two weeks? Make sure you set the ownership of the installation correctly!

Given the need to ensure any software visible to the internet at large is as secure as possible, updates should be applied as soon as they are available to ensure any bugs and vulnerabilities are patched.

So, having installed my copy of WordPress, one of the first things I looked at was how to make sure I could easily update the software. Thankfully, WordPress provide an easy way to update the software through the integrated dashboard. Though clicking revealed I required an FTP server running on the web server to perform the updates? Not keen on setting up and FTP server on my production server, I put off the update until I had an afternoon free to install a server and get the updates carried out.

Following the Ubuntu Documentation’s suggestion of installing vsftpd (https://help.ubuntu.com/lts/serverguide/ftp-server.html) I went on to add a user whose home account was set to the directory I’d installed WordPress, to enable the files to be directed to the right place. Changing the owner of the files, I carried out the updates and then wondered why exactly they felt the need to force users to install an FTP server to carry out the updates?

Needless to day, A quick search lead me to a topic that had already discussed the issue… http://stackoverflow.com/questions/640409/can-i-install-update-wordpress-plugins-without-providing-ftp-access revealed that WordPress will only attempt to upgrade over FTP when the web server tries and fails to write to the /wp-content directory! I had already disabled the FTP server and blocked the ports again, though lesson learned: Make sure file permissions and ownership are set properly from the start!