5 ms·

Ksplice launches rebootless Linux update service - $4/server/mo

23 points by compumike 17y ago

compumike 17y ago
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 http://www.ksplice.com/pricing
- Erwin 17y ago
  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 17y ago
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 17y ago
  >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 17y ago
    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 17y ago
      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.
uggedal 17y ago
Seems similar to FreeBSD's binary updates: http://www.freshports.org/security/freebsd-update/ http://www.freshports.org/security/freebsd-update/
forkqueue 17y ago
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 17y ago
  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.
kordless 17y ago
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.

23 points by compumike 17y ago

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 http://www.ksplice.com/pricing

Erwin 17y ago
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 17y ago

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 17y ago
>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 17y ago
  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 17y ago
    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.

uggedal 17y ago

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

forkqueue 17y ago

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 17y ago
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.

kordless 17y ago

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.