I'm really not defending an infrequent kernel update policy. The way it goes here is: no tolerance for breakage on certain server systems. Kernel updates are evaluated case-by-case, and if a vulnerability is insidious enough, I can usually make a strong case for updating.

It is far from ideal, but we work on other ways to mitigate the risk.

Perhaps I misunderstood the question? I update immediately whenever the distro maintainers make it available. I just don't manually upgrade to newer versions.

In everything related to IT (and life), there's such a thing called mitigation. If you can't update (and the reasons may well vary), you evaluate the risk of updating (or not updating) based on the changes that need to be applied. You then make decisions based on the results of the evaluation. You can't always have it your way or the next individual's way. Each and every admin has to decide whether they can patch or not based on all the above, plus supervisor input and change management procedures. If you know that there's serious risk, argue to do the patching. If you can't perform the patching, mitigate the risk (harden against any discovered vulnerabilities. I really don't think (and this is my own professional opinion) you should blindly push every kernel major change/addition/removal without a proper evaluation of how it would affect a business (or a SOHO but critical system).

Do I have the very latest BIOS update for all of my systems? NO! I only update the BIOS if I need a particular feature/issue that the later version may address. Kernel updates aren't quite the same as MS Tuesay notifications. Most local kernel level exploits can be mitigated. You just need to be able to trust that your hardening is hard enough to keep unwanted people out of the systems.

I know of several critical Linux systems at my workplace that don't have the latest/greatest kernel. These systems are behind at least 5-6 hardware firewalls/IPSs, each system has its own software FW, ACLs are tighter than a python's knot, and they've been running for years. Is it right that they aren't semi-current? No, but again, the risks are mitigated. These boxes don't even go outbound to the internet...every connection is established via PTP VPN. When people know what they're doing, mitigation works.

It's a different approach but it works. Every system that I have control of, I try to make it as close to a bastion host as possible...that's the way it should be, IMO.

All of this is up for interpretation. There is no real standard and there shouldn't be. There is no right way (and there shouldn't be). If we become so rigid in addressing security, we only make it that much easier for crackers to do the things they do.

So, if your boss rejects updating a box's kernel, do you argue until you're fired? IMO, you do what you're hired to do, take direction from your boss (and cover your tracks), then let the boss take the fall if it comes to that. For SOHO environment where you're in charge, do it sensibly. If sensibly means postponing, then postpone (and mitigate the risk)! If one of your machines becomes compromised, learn from the experience, clean up the mess properly, then move on.

1 members found this post helpful.

As we're strictly taking kernel here I think you might have?

Not all kernel security updates address are required for every server so on the business side of things one needs careful assessment too. Also there's clients that pay for taking care of things and some that don't (pay easily, I mean). Meaning lots of risk management and discussion is involved to be able to even push updates. Even testing on staging might not reveal every risk in updating (servers showing a tendency to b0rk on reboot and always mysteriously) and multiple data centers doesn't mitigate things either (a client DoSsing his own infrastructure sounds nice except for the service manager and admin team being asked to fix things 3 in the morning). I know there is a part of the LQ Community that is (by experience) aware of what requirements need to be satisfied on the business side of things and I too have experienced it can't be any other but that way. But for the SOHO side of things it is and should remain "update as updates are released" IMO. (I mean, just in case anyone think they can misread all of this as their cue to slack off.)

At home I used to do it every release till I really got the hang of it. It was kinda fun playing with the options & learning. Now I only do it when my distro upgrades to a new stable version or if there is a security update that directly effects my setup. The production machines at my work we only update for security reasons.

OK, the original question was, "How often do you upgrade your kernel?"

Perhaps I was wrong, but I considered that to mean upgrading to a newer version. That I only do with my distro upgrade.

Updates (patches for the current version I'm using) are offered quite frequently. Those are installed ASAP.

Cheers

I chose a quarter, unless there're some critical security/bug fix.

Since the only thing you have to do (most of the time) is
make mrproper && cp oldconfig .config && make silentoldconfig
and since I also have made a script that takes care of the installing (including nvidia drivers), it is really a piece of cake to do the upgrading as often as possible.

The key words are, "most of the time". I'd rather not have to deal with the "what ifs" when scripting, even with such a simple combined command as that, as I know someone will eventually expound on such a suggestion to wget a kernel, unpack it, have the script crunch it and apply it, then create a cronjob for it, somehow. I'm a firm believer in keeping the human factor within everything I do. This is why I hate IPS technology and is why I still run Slackware. It's when things get broken that people begin to second-guess themselves. I'd much rather apply the hands-on approach.

That's just me, though.

Of course I have to deal with the results of 'make silentoldconfig', should there be any new features in the new version, but besides that, it has so far worked flawlessly. The scripts cannot run unattended, but you don't have to do anything more than just look at the result if there are no new features. I also edit lilo.conf manually.
The install script, which is called with the kernel version as argument: (I use two Nvidia variables, should I want to upgrade the nvidia module at the same time)