Slashdot Mirror
A "Never Reboot" Service For Linux
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?"
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?
I reject your reality
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.
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?
Color me stupid but wouldn't any application in which you'd rather not be rebooting (i.e. Router, firewall, file server, etc...) be the exact same application in which you'd NEVER want some 3rd party having access to your kernel? I mean, if a large percent of distros were using this I can just imagine it would be the A#1 target for every malicious coder in the world.
In critical services, 100% uptime is essential. Imagine a server used in air traffic control...
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.
Not expensive if the technology works. My time is more valuable and down servers cost money. The cost is paltry in comparison.
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.
Kid-proof tablet..
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.
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.
l4? qnx?
It would probably cost more than $4 a month to rewrite the Linux kernel to that extent. :)
Comment of the year
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?
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.
dont you mean once or twice a month?
these emergency IE patches are getting tiresome.
turn up the jukebox and tell me a lie
Yeah, I love the updates that require a reboot so they can install another update that then requires another reboot.
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.
You don't use IE actively??? Do you ever browse for files? You are using IE.
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.
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.
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.
Then... why did you go with this particular vendor instead of one that meets your needs?
Yes, but what would you rather do, patch your production server with a patch from a company you can sue or rather grab the patches from not-as-reliable semi-anonymous sources who are doing their own redistribution and just hope they weren't tampered with?
When ideas fail, words become very handy.
...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 ...
Puteulanus fenestra mortis
A mythical desktop microkernel?
What, you mean like this?
Specialist Mac support for creative pros, Melbourne
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.