How to switch from Ksplice to KernelCare without a Reboot: A Step-by-Step Guide

Whether you are a start-up or rapidly growing enterprise, your server fleet evolves along with the Linux flavors and versions you use on your machines. An enterprise network is rarely homogeneous. Instead, servers run several flavors of Linux depending on the purpose of the server laid out by administrators. Regardless of the kernel installed, each server needs the proper vulnerability scans and security patches installed to protect from the latest CVE findings. You could purchase licenses and install patch management solutions that deal with each Linux kernel individually, or you could consolidate kernel patching into one agnostic solution using KernelCare. If you’ve decided to switch from Ksplice to KernelCare, we’ll show you how.

Contents

1. Challenges with Heterogeneous Environments

2. Ksplice Description

3. KernelCare’s Agnostic Approach to Patching

4. How to Migrate from Ksplice to KernelCare Step-by-Step

Challenges with Heterogeneous Environments

In the late 90s and early 2000s, a homogenous network environment was popular, but IT has evolved to adopt a heterogeneous environment and the benefits it offers. Administrators might prefer a specific flavor of Linux, or software projects might require testing and solutions based on a specific Linux kernel. Whatever the reason, every operating system on the network must be safeguarded from exploits regardless of version and kernel vendor. 

As an example, CentOS is arguably a better server distribution than Ubuntu. CentOS supports cPanel, which Ubuntu lacks. It’s also generally more reliable and stable due to its target server market and fewer updates. Ubuntu, however, has larger community support and is generally regarded as a good beginner distribution. For rapidly growing organizations, it’s possible that they start with an Ubuntu server and later provision CentOS or Red Hat servers. This means that the organization needs two live patching solutions (e.g. Canonical and Red Hat Enterprise Linux, which includes live patching in versions 7 and 8). Now, add several more distributions on the network, and the number of live patching solutions could be as many as distributions installed.

It’s not uncommon for an organization to start with one Linux kernel and install a corresponding patch management system specific to the vendor. To run every patching solution for each Linux kernel is expensive and unnecessary, but servers must be patched within a small window of vulnerability to avoid data breaches. If you have Oracle-based kernels, it’s likely that you have Ksplice, which is an expensive solution but common in these environments.

Ksplice Description

Ksplice is the original rebootless patching system developed in 2009 by a student at MIT. It was later purchased by Oracle in 2011 and supported Oracle-based versions of Linux, which is a derivative of Red Hat. At the time, major Linux vendors asked server administrators to apply security patches several times a month, which meant that servers required a reboot and downtime was unavoidable. Ksplice gave administrators the ability to patch several times a month without the downtime.

Even though Oracle Linux derives from Red Hat, Oracle stopped support for Red Hat (it’s still available for RHEL, however), which left a hole in rebootless Linux patching. After Oracle’s purchase of Ksplice, several other vendors developed their own live patching application specific to their kernels. Several options were released to the public, but they supported patching for a very limited number of distributions.

KernelCare’s Agnostic Approach to Patching

KernelCare was released in May 2014 after a very successful beta run in March 2014. It’s unique approach to live patching  is to offer an agnostic approach that lets customers patch any flavor of Linux using one solution, so they no longer need several expensive applications. If another Linux kernel is added to the environment, customers don’t need to worry about finding a live patching solution as it’s likely covered by KernelCare. KernelCare supports Oracle Linux, CentOS, CloudLinux OS, Debian, Red Hat, Virtuozzo, and others.

KernelCare runs on the client’s server and periodically polls a distribution server to identify if any patches are available. If a patch is available, KernelCare downloads the code and applies changes to the running code making sure not to interfere with CPU execution when switching to a new version.

How to Migrate from Ksplice to KernelCare Step-by-Step

Since Ksplice only supports very few Linux distributions, customers want to migrate to KernelCare. Luckily, the migration from Ksplice to KernelCare is pretty straightforward, quick, and does not require any downtime.

Migration has three steps:

1. Uninstall Ksplice.
2. Install KernelCare.
3. Enjoy your free time.

You could perform these three steps manually, but KernelCare has made it even easier. We created a script that lets you perform the first two steps and begin the third step even faster. 

Here’s is how to do it:

1. Download and run the following script:

wget https://downloads.kernelcare.com/ksplice2kcare

1. Run the following command: 

bash ksplice2kcare [YOUR KERNELCARE KEY]

1. If you use IP-based licenses, execute the following command:

bash ksplice2kcare IP

After you run the script and the above commands, you can find the log file at /var/log/ksplice2kcare.com.

That’s it! You’re now ready for KernelCare support and live patching and your servers will be secured from the latest kernel vulnerabilities.

Conclusion

Using KernelCare eliminates the need for several live patching solutions and provides a way for administrators to keep the Linux kernel safeguarded against known vulnerabilities. It patches several more kernels compared to Ksplice, so that administrators who work with different flavors of Linux can ensure the cybersecurity of every server.