

Ksplice launches rebootless Linux update service - $4/server/mo - compumike
http://www.ksplice.com/news/20100209-uptrack

======
compumike
Specifically, Ubuntu is free, but Red Hat, Debian, Centos, and a few others
are ~ $4 per month. Nice concept and good implementation (command line and GUI
options), and looks like a small price to pay for not having to worry about
kernel 0-days and other bugs. Had some issues with a custom kernel but
hopefully that will get worked out.

<http://www.ksplice.com/pricing>

~~~
Erwin
I've installed it on two RHEL/Centos machines so far, I'm planning to put it
in some production systems in a maintenance period just to be sure of no
issues (though I wouldn't be surprised if my datacenter vendor (whose name I
won't reveal but it rimes with backspace) would offer this as a "free" service
to the customers). It seems like just the thing for hosting vendors to buy for
their customers in bulk.

I'm happy to see someone making money off free software and I hope there'll be
more of it. There just isn't much software one can spend money on besides the
basic like RHEL. If I want to plunk down $5000 on high-performance something
it seems like commercial lisp vendors are the only ones that can give that to
you. I'd like to give $5000 for a faster Python.

------
mmelin
Very cool. I'd guess you still want to reboot every once in a while to clean
up memory, but since you won't have any security updates pending you can
schedule the reboot at your leisure.

The pessimist in me says to wait until a botched patch causes systems
worldwide to crash and burn, though. It would also be interesting to find out
more about Ksplice's own security as they are now in a position to create the
mother of all DoS attacks.

~~~
pbhjpbhj
> _wait until a botched patch causes systems worldwide to crash and burn_

I'm not following you here. Why does reboot-less updating of the kernel mean
that the patches won't be tested. Also what DoS attack were you thinking of?

Lastly, clean up memory? The top uptimes on Netcraft are >1000 days, is this
necessary, are there specific memory leaks you're considering?

~~~
mmelin
Using Ksplice means that you're letting a private company inject custom code
directly into your running kernel. The paper explains that most Linux security
updates are applied without modification, but some updates require Ksplice to
write custom code for the patches to work (specifically if the update changes
any data structures). My pessimistic side says that sooner or later this
custom-written Ksplice patch will contain a bug that causes your kernel to
crash - worst case would be if that crash happens after the kernel has been
running for a while.

I'm sure the people at Ksplice are much smarter than I am, but every time a
security update for the kernel is released they will be stressing to release a
Ksplice update to be able to provide value for their customers (the whole
point of a subscription is so that you get the security update faster than
planning a reboot takes).

The way Ksplice works is that it, for each update, injects all changed
functions into the kernel and replaces the old functions with a jump to the
new version of the same function. Even though it might not cause what you
would consider a production-threatening memory leak, I would still like to
clear out the old code from memory every once in a while.

~~~
pbhjpbhj
Thanks for the elucidation.

So, the reboot is required because the patches cause the old code to remain
but simply be long-jumped past to the injected new version of that block of
instructions. Got it.

I'm not sure I'm in with you on Ksplice having to be really fast. The benefit
is virtually no downtime but people are still going to test the patches on
their testing servers and thus will still be testing in the wild before
implementing fully.

------
kordless
When I used to run 10 servers or so, I might have used this service to make
upgrades easier. With potentially 100s of servers in the cloud at a time now,
I've already figured out how to bootstrap my image off a base install and
start and stop servers on a daily basis. Upgrading an image is as simple as
picking a new base image and applying my handy dandy boot scripts to it.

I don't see a huge value to IaaS customers as their infrastructures are mostly
ephemeral anyway, and are serviced by the likes of RightScale and Opscode who
both provide tools that help you get your cloud image booted and configured.

As for the larger own-their-datacenter customers, they'll likely have some
solution based on Chef (Opscode) or Puppet, and be more tolerant to reboots.

Smaller data center users might get a kick out of it though.

------
forkqueue
My first thoughts on reading this were that it was super-cool. Then I thought
about customers who could benefit from it (we provide Linux consultancy to a
number of medium-large enterprises), and I pretty much drew a blank.

If you're large enough for the downtime associated with a reboot to be a big
issue then you've presumably already got a minimum of two machines performing
the same function. That being the case, it's no problem to remove each node
from the cluster in turn, upgrade the kernel, reboot, test and add it back in.

That rather makes the service more of a convenience. For example, for
active/passive setups where a failover produces an undesirable amount of
downtime (say 30 seconds whilst services migrate), or single server setups
where uptime isn't critical, but downtime is still a pain.

Cool technology, but perhaps an example of a solution looking for a problem. I
think at $4/month the convenience aspect can probably justify the cost in many
cases.

~~~
DEinspanjer
Our IT department has twice weekly scheduled maintenance windows. Every month,
a couple of those windows will include taking down parts of the infrastructure
for kernel updates. Frequently, the services involved are clustered and
involve no user downtime, that said, it still takes a team of three or four
people a few hours to administrate the maintenance, monitoring to be sure
everything is going smoothly and putting out any fires that might arise. 3.5 *
~$100 * 1 hour * 2 times a month = ~$700 per month $700 / $3 per server = 200
servers that could potentially be reduced to seconds of maintenance
administration instead of an hour.

------
uggedal
Seems similar to FreeBSD's binary updates:
<http://www.freshports.org/security/freebsd-update/>

