A "Never Reboot" Service For Linux 321
An anonymous reader writes "Ksplice, the company based on the MIT Ksplice project, is now offering its 'never reboot' service for Red Hat, Debian, and other Linux distros. You subscribe and get real-time kernel security updates that apply in-memory instead of rebooting. Last summer we discussed the free service for Ubuntu. Cool tech, but will people really pay $4 a month for this?"
Re:How long till they.. (Score:5, Insightful)
Its a shame that MS never figured out how to actually implement this. How many times do I have to restart my computer to finish applying update?
Re:How long till they.. (Score:5, Insightful)
The patent on this was filed in 2002. Yet in 2010 I am still making a handsome profit in overtime rebooting customer systems on a "patch Tuesday" monthly frenzy.
Please MS, don't implement this one.
Rebooting is a Good Thing... (Score:3, Insightful)
Those who do not perform scheduled reboots of their servers do not know whether their servers will come back up properly after unscheduled reboots. How often have you seen someone add a service to a machine which becomes a critical part of your infrastructure then they forget to add it into the RC system?
hrm... (Score:5, Insightful)
Re:Huh? (Score:1, Insightful)
In critical services, 100% uptime is essential. Imagine a server used in air traffic control...
Re:So instead of doing it right... (Score:2, Insightful)
Advantages of a microkernel:
Modules can be rebooted/maintained separately from the core kernel .... check
The core kernel can be updated.....Nope but Linux has this anyway
In kernel bug isolation & security....Nope
Given there isn't a microkernel with 1/10 the other capabilities/hw support/usage of linux, doesn't it make sense to add stuff to linux instead of waiting for this mythical desktop microkernel.
4 bucks a month? (Score:3, Insightful)
Not expensive if the technology works. My time is more valuable and down servers cost money. The cost is paltry in comparison.
Re:Free? (Score:4, Insightful)
I've said it before, and I'll say it again:
Just because it's free software, doesn't mean that it's afraid of money.
Re:So instead of doing it right... (Score:4, Insightful)
Designing your own operating system isn't exactly a small feat.. Linux already has very good penetration into the server market, and offers the security that most organizations should have. Linux is what Windows should be. There's a LOT you can do with that kernel.
Obviously complexity makes security difficult, but there's nothing wrong with making something complex if you're actually capable of managing it. Is setting up a rock solid firewall difficult for the average person in IT? Should we just get rid of anything in security that is relatively complex? I'd much rather have more options (not necessarily obfuscation) than be pigeon holed into something just because it's simple. Security is not simple, and it never will be.
Ugh, just reboot (Score:3, Insightful)
99% of people I've seen bragging about long up-times tend to have perfectly patched and up-to-date OS installations on disk, and a dozen vulnerabilities still loaded into memory. And I'm not talking just about the OS kernel.
If you don't know exactly what an update touches, just reboot.
Re:So instead of doing it right... (Score:4, Insightful)
Re:So instead of doing it right... (Score:3, Insightful)
It would probably cost more than $4 a month to rewrite the Linux kernel to that extent. :)
Re:Huh? (Score:2, Insightful)
At an individual computer level it's not so bad, but in an enterprise it can be troubling.
A couple of examples: a zero-day exploit of Microsoft Windows (surely this would never happen) requires a patch be applied and the computers rebooted for thousands of users. Even assuming that the reboot can be enforced with 100% reliability (seldom to never), the 1-3 minutes will impact productivity for at least some users. Sure, desktops can be rebooted at night, but laptop users that take their machines with them and never have them powered up unless they are using them will be impacted. Imagine a company with an average productivity value of $10/hr, $20/hr, or $30/hr. Imagine this company has 100 laptop users or 1,000 or 10,000. Multiplication makes that 1-3 minutes each expensive.
A different scenario involving servers where services must be available: say web servers that require database servers and both require directory servers. There may be several of each of these for load balancing or fault tolerance, possibly clusters, and real world examples may be far more complex. Reboots must be coordinated based on which nodes of which clusters can be taken down without impacting service. Often, additional commands must be added to gracefully transfer service, notify a load balancer device, possibly tell a monitoring server that its in scheduled maintenance mode and not to send a bunch of emails to the support team because the server is down. Ideally one web server and one database server and one directory server go down and all come back up, followed by another set, etc, and cluster master roles are reallocated correctly, etc.
Obviously there are ways to script, automate, plan, and mitigate all of this, but if it didn't have to reboot in the first place... that would be nice, huh?
What is the use of such service? (Score:3, Insightful)
I don't really personally see any use of such service. If you need FT or HA system you need to design it as such from ground up. In this case paying 4 bucks just solves some problems with rebooting after kernel upgrade. I dont have problem with that. I just reboot in next service window. In normal situation mission critical systems have some sort of redundancy not only to cope with planned service reboots but with other unplanned disasters. So usually you have a N+1 redundant cluster in which you can reboot the servers using some procedure that was worked out while DESIGNING the system. Also I see quite few security issues with patching the kernel this way. In mission critical services you usually do test everything before rolling it out to the systems so using such feature just makes things more complicated (that just simply reboot the machine with my current procedures).
I cannot find anything about security details on their webpage. They state "Ksplice Uptrack uses cryptography to authenticate the update feed.". So what? Fedora also used cryptography and once their servers got rooted the whole chain collapsed. So if I was to use their service I wish to know how exactly their security is implemented since I would be getting kernel patches (quite critical stuff) from them. At least with RHEL I know a about their security procedures (quite rigorious). From support point of view. Does f.e. Red Hat or Oracle support systems patched this way?
It is a nice feature but IMO not suitable for enterprises yet.
Re:How long till they.. (Score:3, Insightful)
dont you mean once or twice a month?
these emergency IE patches are getting tiresome.
Re:How long till they.. (Score:5, Insightful)
Yeah, I love the updates that require a reboot so they can install another update that then requires another reboot.
making stuff up (Score:1, Insightful)
Well-controlled live changes are not inherent to microkernels. Monolithic design does not preclude well-controlled live changes; all you need is persistent memory and a kernel that can resume operation on that memory. Stage the new kernel and switch. This has been done for HA systems.
Can one argue that microkernels are more amenable to well-controlled live changes? Perhaps.
That's the best you can say about it. The rest is a fiction that exists exclusively in your head.
Re:How long till they.. (Score:3, Insightful)
You don't use IE actively??? Do you ever browse for files? You are using IE.
Re:It can be quite beneficial (Score:5, Insightful)
The occasional reboot, under controlled circumstances, is an excellent test of what will happen in an emergency situation. Mainly, it answers the question of whether the server and required services actually will all come back up by themselves.
More importantly, if your service architecture can't handle the scheduled outage of individual servers, then it is unquestionably broken.
If you are concerned with individual server uptimes having a bearing on anything except your e-penis, then You're Doing It Wrong.
Re:Huh? (Score:3, Insightful)
Some organizations who have operational requirements to provide a service continuously. For them there is no acceptable downtime.
And they've designed their systems properly such that not only the planned - but also unplanned - outage of a single server is both non-disruptive, and transparent.
"Service" and "server" are not synonymous. This is especially true once you move outside of trivial environments. If your HA service can't sustain the outage of an individual server, then its *fundamental architecture* is broken, and what OS is running barely even counts as semantics.
Re:Huh? (Score:3, Insightful)
In the ATC application I support the workstations are very important. They are used 100% of the time and unanticipated downtime is a critical problem.
Firstly, patching is in no way "unanticipated downtime".
Secondly, if your environment can't sustain workstations being unavailable *even on a schedule*, then it's not meeting the requirements it was supposedly designed for.
Re:hi, let me introduce you to the year 2010 (Score:3, Insightful)
Then... why did you go with this particular vendor instead of one that meets your needs?
Re:Yes, they are. (Score:3, Insightful)
Re:How long till they.. (Score:3, Insightful)
...which shows what is wrong with Microsoft's kernel
It's supposed to be a microkernel (or nearly one) but needs rebooting if services outside the kernel need updating....
Linux is not a mircokernel and normally only needs rebooting to update the kernel, and now not even that ...
Re:So instead of doing it right... (Score:3, Insightful)
A mythical desktop microkernel [wikipedia.org]?
What, you mean like this [apple.com]?
Re:Yes, they are. (Score:2, Insightful)
Redhat doesn't distribute anything they don't provide source for. They distribute the SRC RPMs and all the scripts needed to build RPMs identical to the ones Redhat distributes.
The GPL covers all embodiments of the covered work, and source code is required for compilation into any binary form whatsoever, whether a standalone program or not.