
KernelCare – Kernel updates without rebooting the system - yiedyie
http://kernelcare.com/
======
sciurus
LWN has recently covered different methods of doing this that SuSE and Red Hat
have developed.

The initial kGraft submission:
[https://lwn.net/Articles/596854/](https://lwn.net/Articles/596854/)

The first kpatch submission:
[http://lwn.net/SubscriberLink/597407/cd7861dacf2be0e9/](http://lwn.net/SubscriberLink/597407/cd7861dacf2be0e9/)

Bask in 2008 they covered how ksplice works:
[https://lwn.net/Articles/280058/](https://lwn.net/Articles/280058/)

------
Already__Taken
Not that this isn't a cool product, isn't it important to know your server can
reboot?

~~~
mrweasel
I really agree.

You need to be able to reboot a server to patch it. If it's so important that
your server do not reboot, it shouldn't be accessible by the general public.

Assuming that you run some sort of website or internet service, you need to be
able to deal with failing hardware/software anyway. Either you big enough to
have redundant servers or you small enough that a reboot won't matter.

I have a similar feelings towards backup and OS upgrades. You should be able
to do a clean install and deploy your "stuff" on a blank server or vm somewhat
quickly. If you 100% rely on say VMWare snapshots, you're doing something
wrong.

~~~
SoftwareMaven
In many cases, you do not need to be able to reboot a server to patch it. We
patch the kernel regularly, allowing our customers to be protected without the
hassle of rebooting.

Applying patches to the kernel to fix security vulnerabilities is orthogonal
to knowing you can reboot your server. Rebooting servers is more than "will it
come back up", it also includes all the headache of scheduling and the risk of
what happens if it doesn't come right back up. But, because servers can and do
crash, hardware needs to be upgraded, etc., you certainly need to know you can
bring your system back up from a cold state.

Applying a hot fix means you are immediately protected from a vulnerability.
Unless you are running at massive scale, few companies have an infrastructure
that allows random servers to reboot (good on all those that do, regardless of
scale!). Instead, most companies have systems and processes that make
rebooting painful, especially for the IT guys who wind up working at 10pm on
Saturday so they don't affect most people. And, until the reboot window opens
up (whenever it is), your server is vulnerable.

Disclaimer: I work on the Oracle Ksplice team.

------
fleitz
Shouldn't one design their systems so that a single machine rebooting is not
fatal?

Generally I make my servers reboot at least once every 24 hours.

~~~
chris_wot
Depends on the environment. If you are a big enough business, then yes this
would be a good idea. Otherwise, if you are small and don't have much money
for infrastructure then perhaps not.

Though I have to ask: why do you reboot your servers every 24 hours?

~~~
valarauca1
I was gonna say 24 hours is short. I think a good time is about ~1 month. I
know HP-UX suggests 2 weeks, and that OS has a history of 10-15 years up time,
stupid y2K bug killing server up times.

------
rwmj
How does this relate to ksplice/kpatch/kgraft?

~~~
dsr_
It's in the FAQ.

>>Q: Are you using same technology as the one from Oracle, Red Hat or Suse?

>>No, Our technology was fully developed in house, and uses different methods
to generate the patche as well as to apply the patch. We believe that our
method of generating patchines is significantly more efficent that what we
have seen or read up to date from other vendors.

But here's the concerning thing:

>>Q: Do you apply all the patches from the newest kernels?

>>We apply only security patches. Sometimes we might decide to apply patches
for critical bugs.

That sounds like the kernel you run will slowly diverge from upstream.
Different security teams make different decisions. I would value this service
more if it came with the blessing and cooperation of my distro's security and
kernel teams.

~~~
yiedyie
Unfortunately critical bugs can also be major security issues in many ways.

~~~
michaelmior
Agreed. Although the policy implies that if that is the case, then a patch
would be made available for those bugs.

------
Fizzadar
The site is pretty light on details; I'd want to know more how it works before
moving from kSplice...

------
pxsta
We can download the kernel module. It seems so simple.
[http://patches.kernelcare.com/kmod_kcare.tar.gz](http://patches.kernelcare.com/kmod_kcare.tar.gz)

~~~
yiedyie
Yes but we still need to make sure that on the next restart the kernel is
patched.

------
orf
looks good, our servers stay up for years at a time with KSplice, but now
oracle owns it and it's not available to new customers means I think we might
have to find something new soon.

------
akx
The drawings are pretty shoddy and amateurish.

Doesn't inspire too much confidence in me...

~~~
huhtenberg
I don't know why you are in gray, but this is a valid argument.

If I am about to entrust some company with an access to the _kernel_ on my
live boxes, you bet I'd be looking very closely at who the hell they are and
be expecting them to be a reputable and stable entity. These silly
illustrations would've been OK if they were on RedHat's site, but if you are
just starting up, I would strongly suggest to put (much) more effort into
establishing your credibility.

~~~
teacup50
I hope you can see the irony of your position when you're talking about the
_Linux_ kernel.

~~~
huhtenberg
If you are referring to the Tux, then you are missing the point. Submitted
project has very ambitious goals but comes from an unknown source and no
history. It also makes a deliberate effort to look silly, which is the exact
opposite of what they should be doing if they are aiming at the actual
production use in live environments.

