Skip to main content

[CPANEL-21909] Is KernelCare's Free Symlink Protection free forever?

kabatak
I ask because I get a notification which says: Patch the kernel (run "kcarectl --update" on the command line). Update the system (run "yum -y update" on the command line), and reboot the system.
When I type kcarectl --update I get thefollowing: The IP x.x.x.x was already used for trialing on 2018-06-17 When I type yum -y update I get thefollowing: No packages marked for update Question is: Is KernelCare's Free Symlink Protection free forever? Or is it 1 month trial and we should uninstall it after the trial if we don't want it?

Comments

25 comments

Date Votes
  • vacancy
    The correct command is as follows. kcarectl --set-patch-type free --update
    0
  • kabatak
    The correct command is as follows. kcarectl --set-patch-type free --update

    Hmm, when I type that now get the following: 'free' patch type is unavailable for current kernel
    0
  • vacancy
    Please run this command, what's the output? uname -a
    0
  • kabatak
    Please run this command, what's the output? uname -a

    Linux myhostname 3.10.0-327.4.4.el7.centos.plus.x86_64 #1 SMP Wed Jan 6 00:35:56 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
    0
  • vacancy
    The kernel you are using is not recognized by kernelcare. Please try again after updating your kernel. You can use the following link for supported kernels.
    -1
  • kabatak
    The kernel you are using is not recognized by kernelcare. Please try again after updating your kernel. You can use the following link for supported kernels.
    0
  • vacancy
    Virtualized servers with OpenVZ or VZ do you use?
    0
  • kabatak
    Virtualized servers with OpenVZ or VZ do you use?

    KVM
    0
  • cPanelLauren
    Hi @kabatak Actually, your kernel does appear to be recognized by kernelcare: The bottom line is, yes it should be free forever and it shouldn't be giving notices about trial licenses. Thanks!
    0
  • sparek-3
    You're not using a stock CentOS kernel. You are using a kernel from CentOSPlus. According to
    0
  • kabatak
    @
    0
  • cPanelLauren
    @sparek-3 The problem is This issue is occurring on more than just systems running centos-plus kernels it's also occurring on CloudLinux systems which it shouldn't be. While it is possible they don't support the CentOS Plus Kernel the error that is output should not be noting that they've had a trial license. @kabatak If they don't support the CentOS Plus kernel - which is very plausible, it's not going to work for you
    0
  • kabatak
    @Add KernelCare's Free Symlink Protection" in red background (see attached). It's as if I never added it before.
    0
  • sparek-3
    @kabatak Well, I'm not saying that that's the case. Better to get information straight from the horse's mouth (i.e. the CloudLinux folks). But if it is the case, then yes, Kernelcare strictly for the free patch set isn't going to be helpful. Your other alternatives would be to install the stock CentOS kernel or purchase Kernelcare, which I assume would work with the CentOSPlus kernel. But again, I'm not associated with Kernelcare or CloudLinux and none of the cPanel folks here are either. So you'll want to get your information from CloudLinux to be sure. @cPanelLauren I'm giving to understand that when he typed: kcarectl --update that's when he got the error about it previously being used for trialing... which may very well be true. When he typed: kcarectl --set-patch-type free --update That's when he got the unrecognized kernel. I haven't followed the other thread at all. But it's my understanding, that unless /etc/sysconfig/kcare/kcare.conf contains the free patch set: PATCH_TYPE = free Then running kcarectl --update will try to update the full Kernelcare, which requires a license if it's outside it's 30 day (?) trial licensing period.
    0
  • sparek-3
    The kernelcare licensing is IP based. Someone else may have had the same server IP address before and used a Kernelcare trial license or had it licensed. It doesn't matter per se if YOU have never used Kernelcare. It matters if the server's IP address registered with Kernelcare at any time in history. (This is also true of cPanel trial licenses)
    0
  • vacancy
    The centos plus kernel that is used supports the kernelcare main patch, but does not support the symlink protection patch. Looking at the kernel, it seems to belong to 2016. Most likely there is no symlink patch for very old kernels.
    0
  • cPanelLauren
    Hi @sparek-3 So that logic makes sense to me but their output is confusing in this respect: [root@server /]# kcarectl --patch-info No patches applied, but some are available, run 'kcarectl --update'.
    So it's requesting that I run kcarectl --update when I don't have full kernelcare installed, just the symlink protection (which I installed specifically to test this). When running that I got: [root@server /]# kcarectl --update Downloading updates The IP was already used for trialing on 2018-05-14
    But I never had a kernelcare trial installed on this server. When I brought this output to CloudLinux/KernelCare team directly they indicated that it should not have done this - I'm using a CentOS Plus kernel on this test server in my opinion Symlink protection shouldn't have been available for installation, if it truly is the case that they're not supporting the CentOS Plus Kernel. But none the less a number of others are in this predicament as well and I'm hoping that once we get a definitive from CloudLinux we can progress from there to resolve issues on our end as well. Thanks!
    0
  • cPanelLauren
    The server has no CloudLinux ever since, if that matters. I remember opting in for KernerlCare Free Symlink Protection but what's confusing is that the Cpanel Security Advisor is telling me to "Add KernelCare's Free Symlink Protection" in red background (see attached). It's as if I never added it before.

    That would indicate that you're not covered by symlink protection. My assumption, based on the evidence, until I hear more on this, is that CloudLinux is allowing the installation of kernelcare on a trial when the kernel isn't supported by the free patch, which really isn't the correct behavior. What should happen in my opinion is that if you're using anything besides the stock CentOS kernel (i.e. anything unsupported) when you view the Security Advisor we should be informing the user of this or not offering the Symlink protection patch. I am waiting to take action on this specifically until I have an answer from them on how they're going to move forward though. Moving to the stock CentOS kernel I'll be will resolve this as it's looking like they definitely don't provide support for the CentOS Plus kernel.
    0
  • sparek-3
    @cPanelLauren What's the contents of /etc/sysconfig/kcare/kcare.conf (I'm on CentOS 6, this may be different in CentOS 7?) I'm going to guess that PATCH_TYPE = free isn't listed there, am I correct? I think when you install Kernelcare it doesn't care what kernel you have installed. It's only when you run kcarectl that it analyzes what kernel you are using and what kernelcare patches are available for it. Since "fully paid for Kernelcare" supports the CentOSPlus kernel. Then kcarectl --update is assuming you are wanting to install the "fully paid for Kernelcare". But since there's no valid license found for that server IP on Kernelcare/CloudLinux's licensing servers, then it's assuming you want a trial. But a trial has already been allowed for that IP address at some point. But I really don't know. Kernelcare/CloudLinux has always been a bit wonky to me. Not saying they are bad products... but seems the way of coding things leaves a bit to be desired.
    0
  • cPanelLauren
    What's the contents of /etc/sysconfig/kcare/kcare.conf (I'm on CentOS 6, this may be different in CentOS 7?) I'm going to guess that PATCH_TYPE = free isn't listed there, am I correct?

    Actually: # cat /etc/sysconfig/kcare/kcare.conf AUTO_UPDATE=True PATCH_TYPE = extra
    And the same behavior persists whether I've got extra or free present (in my case)
    I think when you install Kernelcare it doesn't care what kernel you have installed. It's only when you run kcarectl that it analyzes what kernel you are using and what kernelcare patches are available for it. Since "fully paid for Kernelcare" supports the CentOSPlus kernel. Then kcarectl --update is assuming you are wanting to install the "fully paid for Kernelcare". But since there's no valid license found for that server IP on Kernelcare/CloudLinux's licensing servers, then it's assuming you want a trial. But a trial has already been allowed for that IP address at some point. But I really don't know. Kernelcare/CloudLinux has always been a bit wonky to me. Not saying they are bad products... but seems the way of coding things leaves a bit to be desired.

    I agree with you, I don't think it cares since the full version does support CentOS Plus kernels but my issue with this in the context of our users is: if they are going to *Only* support stock CentOS 6 & 7 kernels (which it looks like is the case) then the installation needs to notify the user and/or we need to stop offering it on unsupported kernels. Which is why I'm waiting to see what comes of their case.
    0
  • sparek-3
    Maybe I'm missing something. Is cPanel installing Kernelcare some where? My guess would be that if a server is not using a stock CentOS/RHEL/CloudLinux kernel, then cPanel should not recommend installing the free symlink Kernelcare patch. In the case of a CloudLinux kernel being used, then the free symlink Kernelcare patch isn't needed. Actually, my recommendation would be that whoever has root on the server should know whether they are using a stock kernel or something else. But apparently, that's asking an awful lot. Additionally, if someone is running a non stock CentOS/RHEL kernel, then running kcarectl --set-patch-type free --update should return an error that Kernelcare does not support the free patchset for that kernel. Probably would be helpful if Kernelcare/CloudLinux provided someway to send them the output of uname -r and then send back what Kernelcare patchsets are available for that kernel. This way cPanel wouldn't have to keep a list of active stock CentOS/RHEL kernels. cPanel could just query Kernelcare/CloudLinux, see if a free symlink patchset is available for that kernel and recommend that the user install it if it is not already installed and/or warn users that they are using an unsupported Kernelcare kernel and have no symlink protection (unless it's a stab, OpenVZ kernel... see how all of this gets wonky when you try to play everyone's server administrator?)
    0
  • sparek-3
    Something maybe kind of like: [plain]curl -s -k https://patches.kernelcare.com/`cat /proc/version | sha1sum | cut -d " " -f 1`/2/kpatch.free.info | grep kpatch-description:[/plain] which should return something about symlink protection if your current kernel supports the free symlink protection. Edit: Er, probably a bit more complicated than that. It looks like the 2 isn't necessarily constant. You would have to do a: [plain]curl -s -k https://patches.kernelcare.com/`cat /proc/version | sha1sum | cut -d " " -f 1`/latest.v2[/plain] Which should return a number (or an nginx file not found page if the kernel is not supported at all) with a number. Then use that number instead of 2 in my first command. Course, this then begs the question, what's the significance of latest.v2 and I don't know the answer to that... A prime example of, CloudLinux has the answer.. just a convoluted way of getting it.
    0
  • cPanelLauren
    Maybe I'm missing something. Is cPanel installing Kernelcare some where?

    The security advisor is now recommending it in favor of the previous suggestion. It's installable directly from the SA interface
    My guess would be that if a server is not using a stock CentOS/RHEL/CloudLinux kernel, then cPanel should not recommend installing the free symlink Kernelcare patch. In the case of a CloudLinux kernel being used, then the free symlink Kernelcare patch isn't needed.

    I opened a case this morning to just this effect - CPANEL-21909 - Security Advisor recommending KernelCare Symlink Protection on unsupported kernels
    Additionally, if someone is running a non stock CentOS/RHEL kernel, then running kcarectl --set-patch-type free --update should return an error that Kernelcare does not support the free patchset for that kernel.

    This is essentially why I wanted to discuss this with CloudLinux/KernelCare and was waiting for their response. The issue being that they should not be allowing the installation of the symlink protection patch on systems with unsupported kernels - there should be some indication to the user that they're running a kernel that the symlink protection will not cover. I also believe we should not be recommending the patch on systems running an unsupported kernel. I did hear back from them on this and they confirmed that the Symlink Protection Patch ONLY supports stock CentOS 6 & 7 as assumed in this thread previously. This means if you're running anything other you're getting a trial version of KernelCare, not the Symlink protection patch.
    Actually, my recommendation would be that whoever has root on the server should know whether they are using a stock kernel or something else.

    I agree with this 100% - hopefully this will show others as well that this is important to know. Thanks!
    0
  • sparek-3
    Perhaps something like this attached script would help, from cPanel perspective. mv kcaresupportedpatches.txt kcaresupportedpatches.sh bash kcaresupportedpatches.sh Basically, I think the key is taking the sha1sum of /proc/version and seeing what is available for that hash at [plainhttps://patches.kernelcare.com[/plain]. This may not be the most eloquent solution, but might give your developers something to code from. You may want to work with CloudLinux/Kernelcare on this, because I'm not sure what the significance of [plainhttps://patches.kernelcare.com/${VERSIONHASH}/latest.v2[/plain] not always being present is. Or where the arbitrary latest.v# comes in at. But something like this would allow cPanel to see what kernel is installed on a server and whether or not if the Free Patchset is available for that kernel, if it needs a full KernelCare license, or if it's an unsupported KernelCare kernel.
    0
  • cPanelLauren
    Hi Everyone, I wanted to update that while this case isn't in the Change Logs as being resolved the case is noted as having the "done" status and we can see the language in the perl module for kernelcare has been updated: Free KC tier symlink patcheset only supports CentOS 6 and Centos 7 # Note: This check implicitly ensures the system is not running CloudLinux sub system_supports_kernelcare_free { my $centos_version = Cpanel::Sys::OS::Check::get_strict_centos_version(); # checks /etc/redhat-release + boot kernel version pattern return undef if not defined $centos_version or ( $centos_version != 6 and $centos_version != 7 ); # deal breaker (must be CentOS 6 or CentOS 7) return 1; }
    With that being said kernelcare symlink protection should no longer be offered/recommended in cPanel's Security Advisor on servers NOT running stock CentOS 6/7 kernels. Please let us know if you experience any issues or have any concerns in regard to this. Thanks!
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post