9

We have two separate managed web servers. One is running CentOS 6.2 and is used as a production environment for a number of sites. The second one runs CentOS 6.4, and hosts some internal applications, such as our wiki, gitlab and issue tracker.

I would like to also use the secondary one as a staging environment for sites we develop, to test before they go into production. Ideally, both environments should have an identical setup in terms of OS.

My options seem to be;

  1. Upgrade live box to 6.4 - We have client sites on there currently, so this seems a bit risky.
  2. Downgrade the secondary box to 6.2 - I am nervous about messing up the things we have on there currently, I do not want to have to reinstall the development tools that are used daily.
  3. Ignore the difference and hope that it isn't a big deal.

Option 3 is tempting, but as I can't really find the differences between the two versions, I don't know whether or not it is wise, can anybody advise please?

2 Answers 2

20

This has got to be one of the most misunderstood things about RHEL/CentOS (the two are effectively interchangeable for the purposes of this post).

CentOS is an OS. CentOS 6 is a version of that OS; it's very different from CentOS 5. CentOS 6.1 isn't an OS version, it's just a patch level of CentOS 6. To understand that, you have to understand Red Hat's packaging and patching policy.

Red Hat pick the version of any given tool they'll use when they launch a version of RHEL. For RHEL 6, this included Apache 2.2.15, the 2.6.32 kernel, php 5.3.3, and so on. For the rest of the life of RHEL6, these will not be upgraded; Red Hat will instead backport any necessary patches (and occasionally, as dsumsky points out, improvements which are felt to be desirable) to the version they have picked. That means that you'll be running software whose version number suggests it's vulnerable to certain well-known exploits, but which has been patched to avoid those vulnerabilities (in case you want an authoritative reference, Red Hat explain this in their own words here). It's amazing how many security auditors don't understand this, some of them even after it's been explained slowly and in short words.

This patching policy causes lots of people to post to SF asking how they can get the latest PHP on their C6 box, but it also causes great stability.

Now, versioning: on a given day, Red Hat effectively draw a line through the current patch state of RHEL6, and declare that to be (say) RHEL6.4. They make ISOs of it, but it's not really a version of RHEL 6, it's just RHEL 6 at the state of patch on that day. If you want a fully-up-to-date RHEL box, it's quicker to install from the RHEL 6.4 ISOs and patch than it is to install from the RHEL 6.0 ISOs and patch, but you end up with the same thing either way - RHEL 6.4.

CentOS, following upstream as they do, do likewise.

This means that, provided you haven't installed anything off piste (as it were), and you have all your config files safely backed up, you can go from C6.2 to C6.4 without any major fear.

Moreover, not only is it not a bad idea to upgrade, it's a very good one. At this point, C6.2 is effectively past end of life. It's getting no patches, it's unsupportable and unsupported, because if you bring a C6.2 box up to patch, it's C6.4. There's no way to run a fully-patched C6.2 box without it being C6.4 1.

1 This isn't entirely true; you can bend over backwards not to upgrade the redhat-release package, which controls the file that determines version, but the only reason you'd do this is if you're running some batshit insane piece of commercial software that insists on a particular point release of RHEL/CentOS. If you're running such a thing, get rid of it. It's unfit for purpose, and written (or, more likely, marketed) by morons.

5
  • 4
    tl;dr: bad sysadmin, why aren't you keeping your patchwork up to date?! :-) Sep 2, 2013 at 10:46
  • @ThatGraemeGuy, that made me laugh :) I wish it always was that easy though.
    – wzzrd
    Sep 2, 2013 at 11:50
  • 1
    True. Some of us are lucky enough to be working in environments where things are nicely architected so that service uptime is important and is mostly independent of individual system uptime. When you spend enough time in such an environment its easy to forget that not everyone has that luxury. Sep 2, 2013 at 12:38
  • Great, informative answer. Great explanation. I can't tell you how many times I've run into this misunderstanding. I'm going to bookmark this, share it and print a giant 4'x6' poster and stick it on the wall in the office for everyone to see. Aug 31, 2016 at 17:53
  • 1
    @StefanLasiewski thank you - I very much appreciate your kind comments. Also, feel free to send me a copy of the poster!
    – MadHatter
    Aug 31, 2016 at 21:10
0

Regarding RHEL/CentOS 6.3, this update brought mainly virtualisation improvements like more CPUs or memory for guests or virt-p2v tool for migrating physical machines to virtual machine. Otherwise, I'm not aware of any major changes which could affect your installed applications. I would just pre-check updated packages which are installed on the server and updated kernel drivers which are mandatory for running the server. In general, these updates include bug fixes or security fixes only.

Regarding RHEL/CentOS 6.4, I'm aware of a few important changes which are full suport for parallel NFS or updated drivers for running RHEL6.4 guests on Hyper-V/ESXi hypervisors better. Otherwise, I would check all the updated packages/kernel drivers like with 6.3.

In my opinion, I would give it a try and update the system to the latest release 6.4. I wouldn't expect any disaster...

1
  • 1
    // , Did you get a chance to read @MadHatter's answer? Apr 13, 2016 at 4:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .