24 thoughts on - CentOS 6.3 Packages Updates Options Without Upgrading.

• I believe there’s some confusion about how CentOS release versions work.

  You should read this FAQ entry:

  https://wiki.CentOS.org/FAQ/General#head-dcca41e9a3d5ac4c6d900a991990fd11930867d6 <https://wiki.CentOS.org/FAQ/General#head-dcca41e9a3d5ac4c6d900a991990fd11930867d6>

  Basically, there is no supported CentOS 6.3 release. Only a CentOS 6, with updates continuously released throughout its lifetime. Just because you used the installation media for CentOS 6.3 doesn’t mean that you will stay with it forever. You should change your repos to use /6/ and update to the latest release. There’s no other supported release of CentOS 6.

  Your system is horribly out of date and vulnerable to many MANY security vulnerabilities, both remote and local.

  Red Hat supported the EUS release of 6.3.z but even that ceased getting updates a while ago, I believe. I’m sure if you pay them enough money, they’d be willing to backport updates to 6.3.

  —
  Jonathan Billings

• yum update

  will bring the system up to the latest 6 with all updates, currently that’s 6.8 + assorted updates.

  the dot releases of CentOS, like 6.3, 6.8, are just quarterly(?) rollups where they put out a new ISO with all updates to that point.

• Hi, Thanks for your responses. Unfortunately, there’s not possibility in this specific situation to be able to update from 6.3 -> 6.8. But, it would be nice to be able to update specific packages to latest that’s available in 6.8 repo at

  http://mirror.CentOS.org/CentOS/6/os/x86_64/Packages/

  For example,

  nss-util-3.21.0-2.el6.i686.rpm
  <http://mirror.CentOS.org/CentOS/6/os/x86_64/Packages/nss-util-3.21.0-2.el6.i686.rpm>

  2016-05-12 10:48

  67K

  nss-util-3.21.0-2.el6.x86_64.rpm
  <http://mirror.CentOS.org/CentOS/6/os/x86_64/Packages/nss-util-3.21.0-2.el6.x86_64.rpm>

  2016-05-12 10:47

  67K

  nss-util-devel-3.21.0-2.el6.i686.rpm
  <http://mirror.CentOS.org/CentOS/6/os/x86_64/Packages/nss-util-devel-3.21.0-2.el6.i686.rpm>

  2016-05-12 10:48

  69K

  nss-util-devel-3.21.0-2.el6.x86_64.rpm
  <http://mirror.CentOS.org/CentOS/6/os/x86_64/Packages/nss-util-devel-3.21.0-2.el6.x86_64.rpm>

  2016-05-12 10:48

  69K

  Simply updating these packages on 6.3, would there be any issues w/o updating rest of the packages from 6.3 to 6.8? As I mentioned, ‘yum update’
  or updating to latest 6.8 packages from 6.3 is not currently plausible or even feasible for some reason. Or, please suggest any other options to be able to update such packages w/o updating rest of the userland on 6.3?

  Thank again very much.

• I suppose you could try it and see what happens. That comes with a two-part warranty: If it breaks, you own both pieces.

  As you have been told earlier, the only way to update your system properly is to run this command:

  yum update

  After that you will have the latest version of CentOS 6 on your system.

  Anything other method will leave you with a system that is definitely insecure and probably broken.

• Thanks Frank and all. Understood, but unfortunately, updating to latest version of CentOS 6 is not the option in this specific situation, in stead, we are taking a look into options of updating only hand picked packages on CentOS 6.3 to latest. Any other guidance is welcome and appreciated.

• any such external specifications that insist you run an old obsolete operating system are inherently broken. I hope this server isn’t connected to the internet, and isn’t providing any services to untrusted users.

  any RHEL/CentOS 6 compatible applications you have that work on 6.3 that won’t work on 6.8 are broken.

  * 6.8’s kernel is is still 2.6.32, same as 6.3.
  * 6.8’s glibc is still 2.12
  * 6.8’s php is still 5.3
  * 6.8’s mysql is still 5.1
  * 6.8’s PostgreSQL is still 8.4
  * 6.8’s perl is still 5.10
  * 6.8’s python is still 2.6.6
  * etc etc.

  all of these components have security and bug fixes from later releases backported to them.

• Excellent, and thanks John to clarify the above compatibility factor. It seems, any application that strictly depends on the 6.3 packages must not be updated to 6.8. And, outside of that dependency, I gather it should be safe to update any hand picked packages to the latest is my understanding here. It seems, in general RHEL tries to maintain ABI level compatibility but they may not be perfect and they may only test with the packages set current at the time. So, it’s worth testing and possibly updating to 6.8
  packages where there’s serious security fixes or such. But, yes, there’s no way to update the 6.3 to 6.8 as I repeatedly mentioned which is the only requirement/constraint.

  Thanks again!

• It occurs to me to ask what you consider to be version 6.3. If you update any of the rpms to the 6.8 version you are no longer running version 6.3. If the spec requires 6.3 and nothing else, then you will no longer be compatible with the spec as soon as you install the first 6.8 rpm.

  On the other hand, if you are allowed to install 6.8 rpms, then what’s keeping you back from doing a proper job instead of a halfway and half-assed one?

  Upgrading “selected packages only” will leave you with something that’s neither fish or fowl, and it won’t meet your requirements as stated either.

• What constraint is requiring you to run a highly vulnerable server?

• The specs may have certain dependency on subset of 6.3 packages, but not for all other packages/binaries, as I mentioned earlier. So, to keep things rather intact, we would simply meet requirements by only updating
  “selected packages only”. And, for now, that should be considered intermittent solution until we can safely land to a proper job as you mentioned. So, would there be any issue by upgrading “selected only packages” temporarily? For example, only updating nss-util or openssl to
  6.8 version. Thanks all, appreciated very much.

• Yes you would break all kinds of things. In a nutshell folks are saying you are free to try but when it blows up…you better have a total backup to restore the entire box. Your first priority should be getting whatever is holding you back from proper system updates and security out of the way.

• more specifically, it will be a completely untested configuration.
  considering that any single package can be updated 100s of times in the lifetime of a major release (rhel/CentOS 6 for example), and there’s
  1000s of packages, thats an exponential number of combinations, it would be insane for the distribution to test every possible combination of packages across multiple incremental updates.

• Thanks very much, understood. so, it seems, upgrading selected packages is probably going to be fine except where the compatibility matters where it would break all kinds of things. Something of such nature of request would need to be internally tested by simply updating the selected packages, test the applications previously running on 6.3 w/ these few selected 6.8
  packages updates. It seems, the answer is to try and see whether works or breaks. of course, currently, no way to update system properly to latest, hence further inquiries. Really appreciated some helpful pointers. Thanks kindly.

• If you require support at a point release, you should consult Red Hat:
  https://access.redhat.com/solutions/238533

• Please be realistic and professional. You simply can not run a professional business computer operating system like CentOS with some packages so old they are probably a major security risk and other packages up-to-date.

  What will your customer or user say when they discover their data has been hacked or corrupted simply because someone did not want to incorporate the latest safe versions of packages already installed ?

  If your car is recalled to fit a better and safer version of an already installed component, are you really going to refuse ?

  Your stance is very unwise and misinformed.

• Am 08.11.2016 um 07:14 schrieb Dipal Bhatt :

  Let me rephrase it, to be clear. Its NOT fine to update selected packages. Especially a mixture of 6.3 and 6.8 packages is completely untested and therefore considered as unstable.

  Please communicate what is exactly pinning you on 6.3. CentOS is for example not Fedora, where updates can break things. Its for the most cases absolutely save to continue updating CentOS to the latest and the only supported version inside the major release e.g. version 6.

  Upstream’s release notes will list changes that are important between the minor releases https://access.redhat.com/documentation/en/red-hat-enterprise-linux/?version=6/

  Show us this “no way to update system properly” to get a clear big picture that is allowing us to provide you with potentially better solutions.

• Thanks really Leon very much w/ a very resourceful info. esp release notes helps across minor versions. So, this is for a friend of mine, and I have been told that they will not currently consider updating their userland from 6.3 to 6.8 but only selected few packages. The picture seems to be that their company runs a lot of apps on 6.3 userland and might have some specific dependencies, etc., but more importantly, this environment has been running in customers’ environment for quite some time esp 1000s of customers, so updating system properly is not easily feasible for this scenario. However, they can hand pick packages seem fit for update that can be pushed out using their internal code fixes and updates for end users. SO, this seems to be the problem of trying to hand pick certain packages to be updated, if feasible w/o much adverse effects.

• I think RHEL sells support packages for specific releases. Maybe they could pay for a RHEL license for 6.3 and then rebuild the updates for the CentOS 6.3 machines not covered in the RHEL support license.

  If they have thousands of customers, paying for RHEL license for some of them probably is not an un-reasonable thing to do.

• If everyone is running STANDARD CentOS there should be *no* problems updating to the latest C 6.8 version.

  (1) Save one complete installation.

  (2) Install it on a spare machine.

  (3) Change /etc/sysconfig/network-scripts/ifcfg-eth0 if necessary.

  (4) Do a: yum update

  (5) Test the applications

  (6) Wait a few weeks and if still no problems, then upgrade the others.

• thats a whole lot of words that boil down to nothing, they won’t update because they don’t want to, and are too lazy ?

• Unfortunately, that’s the constraint it seems hence, there’s inquiry of other options. But, looks like, any el6 package should work as long as we meet the dependencies?
  Kindly thanks for many help.

• mixing current 6.8 packages with very old 6.3 packages and libraries is a recipe for problems. these combinations are simply untested.
  If you’re willing to do such testing, go for it. be sure to regression test all the corner cases of the specific packages. One thing that would help significantly would be to uninstall all packages you don’t actually need for these systems. I always start with ‘minimal’, and install just the packages my application stack needs. That is a standard policy of security benchmarks such as CIS [1].

  how could someone deploy 1000s of computer systems in the field without a plan for regular security updates?!? that would be somewhat analogous to buying a fleet of airplanes without any plan or provisions for scheduled maintenance.

  [1]
  https://benchmarks.cisecurity.org/downloads/show-single/?file

• Yes, will pass on these excellent suggestions to my friend, but agreed with your analogy as well as concerns around security issues for such a large deployment, it seems. Thanks all.

• Hi Dipal,

  I compliment you on your unflagging politeness in the continual attempt to steer you to another, safer course.

  I’ve been faced with a similar situation, a vendor (Sungard)
  who would only qualify Red Hat 4 and Sun Server 6, and wouldn’t budge. The setting was a US$100 million annual budget enterprise with a CTO with very low risk tolerance. Our staff pushed the
  “don’t upgrade” strategy about as far as anyone could ever hope to take it. We hand patched our way through “heartbleed”, for example.

  In my case, wanting better outcomes, I accelerated the move to automated deployment (Cobbler + Puppet), and was then able to provide solid test environments that allowed developers to quickly re-deploy applications on newer versions of the OS. Initially the push-back was voiced as the whole idea being too costly. The new approach actually reduced costs, freed up developer time, and led to stable systems running in (mostly)
  supported configurations. When the vendor demanded a bug be demo’d on a Red Hat 4 system, we were able to spin one up. But they almost never asked. Apparently most of their customers had decided safety and convenience outranks stupidity on the part of the vendor, and as a practical matter their help desk strategically failed to notice the “unsupported” OS.

  I believe the approach you’ve been requested to assist with has an implicit wager that you’re almost certain to lose:

  > they can hand pick packages seem fit for update
  > that can be pushed out using their internal code
  > fixes and updates

  Consider, this is what Red Hat pays staff to do. Update some packages, test if anything breaks, act on reports from the field. When one makes a complete upgrade to 6 (current), one rides on the coattails of all the work of the Red Hat team to test and stabilize changes.

  On the other hand, if one omits the update to 6 (current), they have the identical problem but are foresaking the vendor’s sunk costs in testing and debugging. The implicit wager is that the few hand-picked packages will reduce exposure to changes, and so reduce labor, and increase your chances for a stable system. However, consider that glibc went through these changes

  CentOS 6.3 glibc-2.12-1.80
  CentOS 6.4 glibc-2.12-1.107
  CentOS 6.5 glibc-2.12-1.132
  CentOS 6.6 glibc-2.12-1.149
  CentOS 6.7 glibc-2.12-1.166
  CentOS 6.8 glibc-2.12-1.192

  and that just about everything links against glibc, and you can see that upgrading piecemeal is a good recipe for running into subtle problems. And that’s _one_ package.

  If you have a small set of specific breaking changes, better to get the devs off their butts and fix things or find work arounds than to take on the greater risks of piecing together odds and ends… which never stops.

  Apparently you’re in for an unending, unprofitable slog through the worst, most unsatisfying kind of sysadminery. Been there, done that, moved on!

  Best regards,