There comes a time that it’s necessary to make big changes to your server.  Such a time has come upon me and, over the last several weeks, I’ve been working hard to implement these changes.

On TV shows and in the media, we often seen socially-active young things making a couple of taps on a keyboard or a click of their mouse, and wondrous, magical things happen on the screen in a parade of glitz and colour.  It’s easy to think that this is all that computers are, but it isn’t.  In order for big things to look so easy on the fingers and colourful to the eyes, there are brilliantly technical-minded people hidden behind the imaginations of the glitz, working hard on technical intricacies so that we don’t have to worry about all of that.

Once upon a time, those people were known as geeks or nerds, but you don’t hear those terms these days.  You hear terms like hackers, or gamers, or you see those media-highlighted people who can do more things with a mouse click than Harry Potter could do with his magic wand.  But none of these images or negatively-phrased terms does justice to the people who really get into the guts of making computers work so that the rest of us don’t have to.  We get to enjoy our lives, whilst they work hard behind the scenes.

The time comes, however, when some of us need to dip our toes into the world of the unknown.  Of technical things we need to learn if we’re to continue doing what we do.  Times like now, when the server I run became in desperate need of updating.  Some of those changes include…

Server – Core Changes

In order for our websites and emails to actually work, the server itself needs to be running certain packages and those packages are sometimes deprecated, outdated, or simply no longer supported.

CentOS 6.9 to CentOS 7.3

CentOS is one of the many flavours (distros) of Linux, and one of the preferred distros for running on web-servers.

The last time I actually worked “hands-on” with CentOS was version 5, and it updated itself through the various updates of version 6 pretty much in the background.  Now we’re on version 7.3.

WHM/cPanel to Webmin/Virtualmin

Having let WHM/cPanel handle most of the server side stuff for years, it’s a bit of an eye-opener to move to a control panel system that encourages you to “get your hands dirty” and work more with the command-line. It’s much more of a learning experience, but it’s far more rewarding afterwards.

With WHM/cPanel, you’re almost too afraid to do anything outside of the WHM/cPanel ecosystem for fear of messing something up. In contrast Webmin/Virtualmin is largely just a convenient way to access the more common tasks that you’d use the command line for anyway, so you can do it either way.

As a result, you come away from Webmin/Virtualmin having learned much more than you thought you would, and with the confidence to try things out knowing that you can probably fix any mistakes you make by going into the command line.

PHP 5.3.29 to PHP 7.1.8

PHP 5.3 ceased being supported by the PHP community way back in 2014 but it’s always difficult to upgrade something like this on a server that runs several sites reliant on PHP. An update/upgrade too far can leave PHP sites falling over and no longer working, leading to urgent support calls and lots of work trying to give everyone priority.

A server change, however, necessitates a change like this and has led to weeks of updating websites. Making these changes as part of a server change allows both servers to run side-by-side whilst the updates are being done, meaning that the old websites can keep running until the new one on the new server is ready.

Running Multiple PHP versions

Where it’s not possible to update client websites (not having access to their logins, for example), it proved to be necessary to run an older version of PHP alongside the current 7.1 branch.

This being the first time I’ve contemplated running multiple versions of PHP side-by-side, it was something else I needed to learn but, fortunately, once installed, Webmin makes it relatively easy to pick and choose which PHP version to apply to client folders.

As a result, one of my servers now runs PHP 5.6 alongside 7.1. The 5.6 branch of PHP is, while no longer in development, currently in “security fixes only” support mode until the end of 2018. That should provide time to update those sites that aren’t yet fully PHP 7.1 compatible.

MySQL 5.5 to Maria DB 10.2

As with PHP, making major upgrades to the back-end database can bring down websites that rely on outdated functions. Although MySQL 5.5 is still, strictly speaking, supported, it was first released some seven years ago and has been superseded many times since.

A lot of modern web platforms require modern MySQL (and PHP) which means keeping to an older version prevents clients from installing up-to-date software. It’s a vicious circle. If you do upgrade, you break existing sites but, if you don’t, you can’t install modern software.

Making the upgrade to MySQL a little more complicated is that there is now MariaDB. Due to Oracle’s acquisition of MySQL, and concerns over its continuation as an open-source platform, the MySQL community created a fork from the 5.5 version of MySQL, called MariaDB. Although it was initially intended to be identical in all respects to MySQL (except that it would remain free under GNU GPL), the more time moves on the more chance there is that the fork will deviate from the original path.

MariaDB is the current database platform of choice for CentOS and is a necessary change.

Software

These days, there are many ways to create a website. Everything from hand-coding static HTML pages, to dabbling in a scripting language like PHP yourself, onto using a Content Management System, and utilising modern blogging platforms. Each of these present their own challenges when you’re having to upgrade scripting languages, core database, and everything else.

Some of the challenges I’ve had to work on over the last few weeks include:

Fixing hand-coded PHP/MySQL

Converting a hand-made PHP site that relied on deprecated MySQL commands so that it will run on PHP 7.1 and MariaDB 10.2 is a challenge, particularly when you need to work through someone else’s code to work out what it does before you can rewrite it in a fashion that supports modern PHP/MariaDV.

This conversion included manually changing the old deprecated MySQL code to use PDO instead, and updating PHP variable capture due to changes in PHP since PHP 5.3.

Updating OpenCart 2.2.0.0. to OpenCart 3.0.2.0

OpenCart is a popular open-source online commerce platform.  Historically, it’s been difficult to upgrade OpenCart – particularly when there are third-party themes and extensions installed.  The creators of OpenCart do their best to assist with updates but there’s no easy upgrade path between major versions such as from OpenCart 2 to OpenCart 3.

The update here required running OpenCart 3.0.2.0 on the new server whilst version 2.2.0.0. continued running on the old, before manually copying changes across, and manually updating each database table. Where changes have been made to the database tables between versions of OpenCart, this required manual handling.

Updating Joomla 2.5.4 to Joomla 3.7.5

Joomla is a content management system. Version 2.5.4 is no longer supported and trying to get it to run on PHP 7.1 would have been an exercise in futility. Fortunately, the upgrade path of Joomla core was relatively easy (requiring two “one-click” updates to the Joomla core).  This can only update the core, not any third-party add-ons.

Third-party extensions/templates present their own difficulties. In one case, the template used for Joomla 2.5.4 doesn’t support Joomla 3.7.5 and there is no template upgrade path. In addition, the template utilised a graphic “photo slider” which broke the site when run on PHP 7.1.

So, although the upgrade of Joomla was relatively easy, it required some hours of manually fixing the template to ensure the site would continue working without interruption.

Updating Joomla 1.5.25 to WordPress 4.8.1

Another client’s website ran an even older version of Joomla that ceased being supported way back in 2012 and wouldn’t run on any modern version of PHP or MySQL/MariaDB. There’s no easy upgrade path to cover the years of changes between Joomla 1.5 and Joomla 3.7. With the site itself being a relatively small site, I manually recreated the old site on the current version of WordPress 4.8.1.

Making this kind of change means that there’s no way to maintain the original template but WordPress is a flexible platform that handles future updates with relative ease while maintaining support for older server software. It made sense to chose this as a the platform to migrate to.

Conclusion

It’s been several weeks of iintensive technical work to migrate from the old server running outdated software to the new server in which (almost) everything is brand spanking new.

It’s been a necessary exercise because there’s only so long you can hang on to outdated software without the ever increasing threats to potential security issues, and a worthwhile one because I’ve learned a huge amount over this period, and have documented most of it, so I come away far more knowledgeable than I was before. If I’d been working for someone else, I might actually have been paid for all of this work too, but I guess knowledge is more important than finances sometimes.