3

So I am having a discussion with a coworker today, and he let something out that I thought was bizarre, as I'm getting ready to apply security updates to one of our production servers.

"You should never apply kernel updates." His line of reasoning is that you don't know if it's going to break any of the linked modules, which could subsequently cause pieces of the application to break down. I would buy into this if perhaps whatever you were running required you to build custom kernel modules - but for your standard apps is this really a concern? FWIW the box in question runs an apache webserver and a database.

I'm of the opinion that regularly applying security updates is necessary to protect against flaws, and that the risk he identified is outweighed by the benefit of having an up to date kernel in your production environment.

2
  • 6
    Apply patches after testing them - it's the only way forward.
    – user9517
    Apr 17, 2013 at 20:51
  • +1 to what lain said. That is why you should have exact QA/Dev environment to test any patches before you apply to production machines.
    – Raj J
    Apr 17, 2013 at 20:59

2 Answers 2

8

This is why you have a lab, a development or staging or testing environment that somewhat resembles or represents your production environment. Some machines loaded up with the same OS, patch levels, and applications, ideally... so you can be confident that any and all patches will be compatible with the software you're running in production.

Patches are released because they fix bugs, security issues, performance issues, etc.

Unless you don't want to fix those things... apply all your patches. After you've run them through your testing environment to ensure that they're safe.

PS for fun: Linus publically tore some dude a new hole because a kernel patch broke compatibility with a usermode app. It's apparently his motto (and a common OS design principle) that kernel patches should strive to never break external interfaces.

5
  • Exactly. You can compile your kernel modules for the new kernel after installation, but before the reboot. If something breaks in the test environment, just reboot into the old kernel and fix it. Document it for production. Apr 17, 2013 at 21:07
  • 1
    And this applies to all updates, not just the kernel. Test. Then apply. Apr 17, 2013 at 22:09
  • 2
    For those of us who work in shops that can't afford dev/QA/testing environments, I've never come across a Distro that didn't keep at least the last couple of kernels around after upgrading anyway... If it does break, boot the old kernel.
    – fukawi2
    Apr 17, 2013 at 23:42
  • We do have something of a Test/QA environment, but it's on different hardware and spec'd a bit differently. I'm currently pushing to get the business owner to free up some money to build out a virtual mock environment that I can refresh when we need to do something like this, but as others probably know in this business we don't always get what we want.
    – tdk2fe
    Apr 18, 2013 at 22:35
  • Here's the referenced Linus story. It's an interesting look into FOSS project administration at scale: developers.slashdot.org/story/12/12/29/018234/…
    – Zac B
    Apr 24, 2013 at 22:39
0

Actually we are doing Kernel update these days. Today alone we did Kernel updates to 50 VMs running in our Texas data centre. This kernel update is very important as it is regarding the "leap second" error on Java applications. We have Java applications running on Redhat 6.2 and there is an issue if leap second is introduced (middle of the year and end of the year), the applications panics and becomes completely unresponsive. So, we are updating all Redhat/CentOS 6.2 hosts before the middle of the year to avoid this error again. The kernel update was released by Redhat Corporation and is a very important update. We would like to get this done well before the middle of the year when a leap second is introduced.

You test your kernel update first in a test environment and see if it breaks anything. You just don't run any update on a production environment willy nilly.

You must log in to answer this question.

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