The saying that Proper Planning Prevents Poor Performance is one often repeated; usually after someone rushes to do something and makes a mess of it.

The rush to patch exploits in OpenSSL and BASH have, in some cases, highlighted the fact that it’s very important to plan upgrades rather than performing a knee-jerk reaction to get systems up to date, including some that have been languishing behind the update curve for some time.

While the advice is to keep your system up to date, it’s important to think about the source of these updates and what requirements they have. On the flip side it’s important to look at applications and services that you run that may or may not work with these updates. It is unfortunately remarkably common to see an update of one application break functionality on another that was relying on an earlier version.

The good thing about the popular Linux distributions is that, while systems are within their support period, the distribution provider will usually provide bug fixes and security patches for applications installed from the repositories.

As these repositories will usually only supply one fixed version of each software package and generally not replace that version during the distribution’s lifetime, this means that security updates and bug fixes will generally not cause other applications installed from the repositories to break. They will also apply patches from newer versions of software to the previous versions, a process known as back-porting, that applies the patch without replacing the application with a newer one.

This means you don’t always need to upgrade to the latest greatest version of a distribution to be safe.  Unfortunately in response to some of the frantic attempts to patch these recent bugs, I’ve seen blogs advising people to update to applications from repositories for more recent versions of their distribution than the one they are using, or even to wholesale upgrade their distribution to the latest one.

The first of those is generally very bad advice and will often end up breaking a number of things in unpredictable ways.  The second is generally not advised, as although the upgrades can tend to work on everything that is in the repositories, if you are using any software installed from other sources you may find things don’t quite work as planned.

For example, an in-situ upgrade from CentOS 6 to 7 will break cPanel installations currently, similarly upgrading from Ubuntu 12.04 to 14.04 will break tools such as ISPmanager.

The first thing you need to do is stop and think about what you need to be upgrading and the best way to go about this.

So, if the version of your distribution is within the support period, installing the latest update from the repositories will generally be the best route to take. We’d also recommend installing packages selectively where possible, rather than updating everything in one hit, and taking backups before you do just in case.

On Debian, Ubuntu and related systems you’d use the apt-get command similar to:

sudo apt-get update

sudo apt-get install –only-upgrade <package-name>

On CentOS and Fedora based systems you’d use yum thus:

sudo yum update <package-name>

By replacing <package-name> with the name of the package you wish to upgrade, the systems will only upgrade that system and avoid installing if it’s not already installed.

Should you be out of the support period, the route we would generally recommend for a distribution upgrade would be to start a second server instance with the newer version of the distribution that you wish to use.

Consulting with the provider of the applications that you are using on your server should provide you with the information you require to choose which distribution to use, taking note to be sure, in the case of Ubuntu at least, to pick a version with long term support (LTS).

Once you have set the server up you can then look at porting your applications and data over to the new server before decommissioning the old one.  This should give you every chance to make sure that everything will work before moving your users over to the new system.