Kernels... lots of them
Forum
  1. Forums
  2. CloudLinux and Control Panels
  3. CloudLinux and cPanel
  1. Scott Mutter
  2. Wednesday, 26 November 2014
  3.  Subscribe via email
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?
Rate this post:
  1. 26.11.2014 12:11:21
  2. # 1
Igor Seletskiy Accepted Answer
Posts: 1200
Joined: 09.02.2010
0
Votes
Undo
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.
  1. 26.11.2014 12:11:05
  2. # 2
Scott Mutter Accepted Answer
Posts: 60
Joined: 23.04.2014
0
Votes
Undo
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 don't have to reboot.  But shouldn't 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 isn't 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.
  1. 26.11.2014 12:11:19
  2. # 3
Igor Seletskiy Accepted Answer
Posts: 1200
Joined: 09.02.2010
0
Votes
Undo
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\'t 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\'t have any other kernels.

And if KernelCare is not working, running: kcarectl --update --> wll get you that info.
  1. 26.11.2014 12:11:21
  2. # 4
Scott Mutter Accepted Answer
Posts: 60
Joined: 23.04.2014
0
Votes
Undo
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 that's 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
  1. 26.11.2014 21:11:18
  2. # 5
Igor Seletskiy Accepted Answer
Posts: 1200
Joined: 09.02.2010
0
Votes
Undo
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.
  • Page :
  • 1


There are no replies made for this post yet.
Be one of the first to reply to this post!
Guest
Submit Your Response
Upload files or images for this discussion by clicking on the upload button below. Supports gif,jpg,png,zip,rar,pdf
• Insert • Remove Upload Files (Maximum File Size: 2 MB)
Captcha
To protect the site from bots and unauthorized scripts, we require that you enter the captcha codes below before posting your question.