Kernels... lots of them

[scott]

Why are there so many kernels for CloudLinux and Kernelcare? Is it too much to ask to have a single page set up some where that shows what the latest version of kernel should be?

I mean, if you are using CloudLinux 6, there is ONE latest kernel, correct? If you are wanting to stay up to date and you are using CloudLinux 6, then you should be using ________ kernel.

Same for CloudLinux 5

Same for Kernelcare for CloudLinux 6

Same for Kenelcare for CloudLinux 5

Same for Kernelcare for CentOS 6

Same for Kernelcare for CentOS 6 OpenVZ

How are we suppose to know if we are using the latest kernel, if the latest kernel could be anything?

[iseletsk]

Scott,

For some reason you are thinking you should be running latest kernel. This is not true. In the majority of cases there is absolutely no reason for large percentage of servers to run latest kernel.
Hence KernelCare

Also, it is pretty easy to read kernel versions, so doing yum update, or looking at patches.kernelcare.com should provide you with all the answers.
In patches.kernelcare.com --> they are already ordered from old to new.

[scott]

When security updates are made to the kernel, you should update and run the latest kernel.

CentOS releases 1 kernel for each architecture for each version of CentOS (CentOS 5, CentOS 6, CentOS 7)

The latest CentOS 6 kernel is 2.6.32-504.1.3.

Granted, kernelcare is there so you dont have to reboot. But shouldnt there be a single Kernelcare kernel (kcare-uname -r) that corresponds to 2.6.32-504.1.3? But instead there are how many "latest" kernelcare CentOS 6 kernels?

When a kernel exploit comes out, are we running the latest kernel to protect against this? Who knows! We are running A latest kernel, but not necessarily THE latest kernel.

What if kernelcare isnt working? What if a server is unable to download kernelcare updates? Being able to check to make sure you are running the latest kernelcare or latest kernel, should be something that can be done by system administrators.

[iseletsk]

Security updates are made in pretty much every release. Yet, do you need to upgrade your kernel if the security updates are for KVM (and you don use it) or USB, or xfs...

And we also release one kernel per platform, one for CL 5, one for CL6, one for CL6Hybrid.

We don have any other kernels.

And if KernelCare is not working, running: kcarectl --update --> wll get you that info.

[scott]

Does the + on the kernelcare kernel version corresponding to the underlying running kernel?

If the underlying kernel (uname -r) is 2.6.32-531.23.3.lve1.2.66.el6.x86_64 then 2.6.32-531.23.3.lve1.2.66.el6.x86_64+ would correspond to the latest kernelcare version? I suppose that makes some sense.

Was kernelcare always that way?

I thought when kernelcare first came out, the underlying kernel (uname -r) might be:

2.6.32-531.23.3.lve1.2.66.el6.x86_64

but the kernelcare kernel (kcare-uname -r) would show a single latest kernel version:

2.6.32-531.23.3.lve1.3.6.el6.x86_64

This makes more sense to me, from a continuity standpoint. Everybody thats running CloudLinux 6 and using Kernelcare would be able to run kcare-uname -r and see 2.6.32-531.23.3.lve1.3.6.el6.x86_64 and know they are on the latest version. Instead, they have to know what the underlying kernel is and match that to a corresponding kernelcare kernel version.

That is my point of contention, I expected all of my CloudLinux 6 servers that are using kernelcare to report

2.6.32-531.23.3.lve1.3.6.el6.x86_64

as the kernel when I run kcare-uname -r

[iseletsk]

The + sign means that patches added are beyond what is available in that kernel version.
So, if your
uname -r will show you
2.6.32-531.23.3.lve1.2.66.el6.x86_64

and
kcare-uname -r shows:
2.6.32-531.23.3.lve1.3.6.el6.x86_64

It means that your kernel (2.6.32-531.23.3.lve1.2.66.el6.x86_64) was patched with all the security patches from 2.6.32-531.23.3.lve1.3.6.el6.x86_64

kcare-uname -r shows:
2.6.32-531.23.3.lve1.3.6.el6.x86_64+

it means that your kernel was patched with all the patches from 2.6.32-531.23.3.lve1.3.6.el6.x86_64, as well as some additional patches that are yet to be available in kernels from that distribution.
This often happens when there is a security fix available in mainline kernel, but it is yet to propogate into CL, CentOS, RHEL (if we would propogate them as soon as they are availble, we would have to release new kernel every two weeks or so).
Yet, with KernelCare we can release patches every two weeks or so, without waiting for the next kernel from the distro. When we add such patch -- we add + to kernel version that KernelCare displays, to denote that we went above what currently available in the distribution.