How often do you upgrade your kernel?
How often do you upgrade your kernel?
|
Almost never...
The one that is in my head: never...
My Linux ones: Only when I'm forced to do it(newer kernel needed by new software). |
Every three years, when I upgrade my distro.
|
Quote:
|
Quote:
|
Agree with the above, unfortunately there aren't any options for that in your poll.
|
If there's a security update, I'll install it but not reboot until I have another reason for it.
|
The only correct answer for a machine that's connected to the net is "each time there's a new stable release". Unfortunately there's no such option in the poll, I will vote more than once a month because that's roughly every two weeks I think.
|
I'm pretty much with Jesús above -- I follow the patches on kernel.org, and when one either is security related, or fixes or improves something related to my hardware (or in the case of major (?) version increases like from 2.6.30 -> 2.6.31), I generally patch up to that release and rebuild. Sometimes this means rebuilding more than once per month, and sometimes less often. I voted for option 4.
Sasha |
Believe it or not, due to office change control procedures and/or politics, it's not always possible to perform frequent kernel upgrades. It's easy to take a hard line on this (which I agree with, BTW), but when the boss man refuses and you have a mortgage to pay, you'll likely adhere to the formal policy.
I voted "once a year". That's what it realistically is on certain production systems. |
Indeed business agreements dictate different upgrade routines but for a net-facing SOHO machine to only receive updates on a yearly basis or more just does not seem right IMHO. For me personally it's within 24 hours of time of update for (almost all) machines.
|
Quote:
I've been using fanout to run a yum update and then reboot multiple servers at once. Then I have fanout run uname to make sure the kernel upgrade took effect. Sometimes I have to change grup, or yum has a dependency problem that needs fixing. |
For workstations that don't contain anything critical you can live with the same kernel for 20 years if that's your boss' wish, but for a production machine that's exposed to the net, that's just plain wrong. If that's the boss' policy, so be it, but that doesn't make it any better.
I know you have no control over that, but it like everything wrong in life: you can ignore it or try to change it. |
Quote:
|
Quote:
In general, I never neglect any machine, even if it's function is apparently trivial. |
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. |
Quote:
|
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. |
Quote:
|
Quote:
|
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.
|
Quote:
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.
|
Whenever there is a new version
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. |
Quote:
That's just me, though. |
Quote:
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) Code:
#!/bin/bash |
All times are GMT -5. The time now is 01:03 PM. |