KernelCare warnings in cPanel v68

[rpvw]

So v68 bought a lot of eagerly anticipated new features.......and seemed to have gone backwards at the same time.

First off......KernelCare !

Suddenly I get warnings in the Security Advisor that :

The system kernel is at version “2.6.32-773.26.1.lve1.4.43.el6”, but is set to boot to version “2.6.32-773.26.1.lve1.4.35.el6.x86_64”.
You must take one of the following actions to ensure the system is up-to-date:

• Wait a few days for KernelCare to publish a kernel patch.
• Reboot the system.

Well I ran yum upgrade - nothing to do.... so I ran kcarectl --update which told me the Kernel is Safe.....so I rebooted to be presented with exactly the same warning. Now this isn't some virtual box....this is a dedicated 'real' metal server....so how has this seeming regression happened ?

[Mod Note - Separated additional issues into their own threads]
Second Issue - New Thread - PDNS run levels
Third issue - New Thread - SSL Notifications in cPanel 68

Hope this feedback is constructive and someone takes notice

 

[sparek-3]

cPanel really has seemed to overstep their bounds (or at least a boundary they weren't prepared for) with their security advisories regarding server reboots.

This is where you really have to have knowledge as a server administrator to understand your own system. You can't depend on some third party system (like cPanel) to know every little thing about your server.

If you have KernelCare installed (or I suppose K-Splice, is that still around?) and you have it set to auto apply updates, then you need to know that, and you need to know that you can ignore any warnings or advisories that cPanel tells you regarding your up-to-date-ness of your kernel.

If you don't have KernelCare or K-Splice installed, then you have to realize that when you upgrade your kernel, you have to reboot (and reboot into that kernel) for the update to take affect. Depending on the severity of the kernel update and your own schedule, you would need to reboot your server at your earliest convenience.

If you have KernelCare or K-Splice installed and you are not using auto updates, then you need a system to tell you when a new KernelCare update is available and apply that update. Luckily, few people do this, and if they do do this, then they are more likely to be aware of this need and how to do it.

Perhaps cPanel was seeing too many servers where users were not rebooting or were not updating the kernel on their system and they felt the need to provide these security advisories. I do not know.

I tend to not take everything cPanel (and CloudLinux, Configservers, etc) tell me to do as the holy-word-or-be-banished sermon. That doesn't mean you ignore the advisories, but you read the advisories and figure out how or if they apply to you and your situation. This is a lost art in today's hosting world and maybe I'm just a relic of 20 years ago, but that's how I do it.

 

[sparek-3]

Suddenly I get warnings in the Security Advisor that :

The system kernel is at version “2.6.32-773.26.1.lve1.4.43.el6”, but is set to boot to version “2.6.32-773.26.1.lve1.4.35.el6.x86_64”.

This would seem to be indicating that you have a mismatch with what kernel you are using and what kernel grub is set to boot into.

2.6.32-773.26.1.lve1.4.43.el6 would seem to be a kernel from CloudLinux's beta channel. Perhaps that is your intention to be running a beta kernel.

2.6.32-773.26.1.lve1.4.35.el6 is the latest version of CloudLinux 6's production level kernel.

 

[rpvw]

I have never used anything from the Cloudlinux beta channel. I currently run 2.6.32-773.26.1.lve1.4.35.el6.x86_64 with Kernel Care:

# kcarectl -i
kpatch-state: patch is applied
kpatch-for: Linux version 2.6.32-773.26.1.lve1.4.35.el6.x86_64 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC) ) #1 SMP Tue Sep 26 06:34:34 EDT 2017
kpatch-build-time: Fri Oct 27 18:17:07 2017
kpatch-description: 3-;2.6.32-773.26.1.lve1.4.43.el6

My grub.conf most recent kernel is 2.6.32-773.26.1.lve1.4.35.el6.x86_64 and the only mention I can see of the 4.43 kernel is from the kpatch-description which obviously, is completely misleading, and probably shouldn't be being used as a metric for security advisories.

Being over 60 myself, and having worked in IT since we programmed with punched cards, and having spent a number of years with a reasonably important open source project, I both respect and, to a large extent, sympathize and agree with what you said about the lost art.

I am a firm believer that 'good-enough' or 'close-enough' is NEVER enough - and if software is going to perform, it must perform correctly.

We wouldn't put up with a phone that arbitrarily dialed a different number than the one you had in the address book - so why should one have to suffer misleading error messages or advisories.

This is a very binary process - it is either right or it is wrong ! (At least I don't think cPanel has moved to quantum computing ......... yet)

At the end of the day, if we can't trust the GUI, either fix it, or scrap it and all go back to the CL where at least we seem to get accurate information.

 

[sparek-3]

What does

kcare-uname -r

show?

Unfortunately, I'm not really all that involved in CloudLinux and KernelCare. CloudLinux (and KernelCare by extension) seems to have a lot of the right hand doing something the left hand doesn't know it's doing. And it just adds complexities that I really don't want to deal with. This is getting off on a bit of a tangent in regards to this topic. But 2.6.32-773.26.1.lve1.4.43.el6 would appear to be a beta kernel, perhaps they incorporate beta kernels into their KernelCare product? Or perhaps you are on a beta channel for KernelCare? I really don't know in that regards.

If they are incorporating beta kernels into KernelCare, then that's just really a shake-my-head moment for me. It's another case of the left hand not knowing what the right hand is doing.

 

[rpvw]

For the record, if it helps anyone....... (and I repeat I am NOT deliberately using beta anything !!)

# kcare-uname -r
2.6.32-773.26.1.lve1.4.43.el6.x86_64

and

# uname -r
2.6.32-773.26.1.lve1.4.35.el6.x86_64

 

[sparek-3]

It looks like CloudLinux just released an updated kernel - 2.6.32-773.26.1.lve1.4.43.el6 - so I'm guessing that they patch that into KernelCare before releasing a new kernel (or before the new kernel reaches their repositories).

So this would seem to be a cPanel issue. Your kernel is up to date, but cPanel is not aware that you have KernelCare installed and is not acting appropriately. Whether this is by design or not, I do not know.

If cPanel is going to check for KernelCare, then it probably needs to run kcarectl --check to see if the kernel is up to date instead of advising you to reboot your server. uname -r is always going to report back what the base system kernel is running. kcare-uname -r is going to report back what KernelCare has patched you up to. This would appear to be where cPanel is doing something wrong.

If you are running KernelCare and kcarectl --check says you have the latest applied patches, then you are fine. (Or at least fine in terms of what KernelCare says).

If you kcarectl --check says you are not running the latest patches, then you probably have auto updates disabled and would need to update via kcarectl --update.

If you aren't running KernelCare and if uname -r reports something other than the latest kernel, then you need to reboot. If grub is reporting the default kernel isn't the latest version, then you need to update your kernel before rebooting.

All of this is stuff that I believe should be left up to the server administrator and really shouldn't involve cPanel. But cPanel is more and more marketing their product to people with zero server administration experience, so they are baking in all of these server administration tasks into cPanel.

 

[cPanelMichael]

Hi @rpvw,

Could you open a support ticket using the link in my signature so we can take a closer look at your system?

Thank you.