Slashdot Mirror
Ksplice Offers Rebootless Updates For Ubuntu Systems
sdasher writes "Ksplice has started offering Ksplice Uptrack for Ubuntu Jaunty, a free service that delivers rebootless versions of all the latest Ubuntu kernel security updates. It's currently available for both the 32 and 64-bit generic kernel, and they plan to add support for the virtual and server kernels by the end of the month, according to their FAQ. This makes Ubuntu the first OS that doesn't need to be rebooted for security updates. (We covered Ksplice's underlying technology when it was first announced a year ago.)"
They appear to be releasing this licensed as GPL v2, but they have a "terms of service" click-through, according to their screenshot.
That doesn't give me great confidence that they really understand the GPL....
The technology looks pretty cool, though.
If you're a zombie and you know it, bite your friend!
This could actually be really awesome if it's truly production ready. What's that? 100% uptime?! AWRIGHT!
https://admin.fedoraproject.org/pkgdb/packages/name/fedora-ksplice
Colorless green Cthulhu waits dreaming furiously.
Now we need a ksplice for zombies instead of having to reboot to clear some of the nasty zombie processes.
This is something I've wondered for a while. Both Linux and Windows have the ability to modify images (executables and libraries) on the fly without rebooting, and most Linux updates do this but Windows usually doesn't. Now we're looking at not only that, but some pretty low level mucking around in the kernel, all while the machine is running.
I know partly why Microsoft doesn't normally do this for Windows, but why is it that Linux doesn't have the same problems described in that article? If you replace an executable you can restart it, sure, but what happens if you update libraries with various inter-dependencies?
Yes, rebooting is annoying, especially for important servers, but doesn't it make more sense to be 100% sure that the changes you're making aren't destabilizing the system (doubly for servers) than that few minutes of down time rebooting costs? Just wondering.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
Read up on Windows "Hot Patching". Windows Server 2003 supports this, and so has every version of NT since then.
Here are some links:
http://support.microsoft.com/kb/897341 -- Explains HotPatching, which revs of the NT kernel support it, and which patches are set up for hot patching.
http://msdn.microsoft.com/en-us/library/ms173507(VS.80).aspx -- Explains how to compile images for use with hotpatching in Visual C++
Seriously, get your facts straight. Windows has been doing this for 6 years.
Nice idea....I just wonder how long it'll be before somebody forks it? ;)
Requiem
It's nice to see them running it on Ubuntu 9.04, but if they want to make money they should go after the LTS releases and SLES / RedHat.
Looks cool though.
Help save the critically endangered Blue Iguana
You could update without a box reboot in windows 3.0, 3.1 and 3.11 =P
I did read up on this (via your links) and discovered:
and
So Windows does not even theoretically support this to the extent of the ksplice offering and in practice I still (and have since it's release and for the forseeable future) have to reboot 2003 and more recent releases when I apply MS patches.
Ksplice is still pretty neat, and worth playing around with (it's very very quick: after installing it's a little like boom boom boom, patches are applied). It also means that you can keep a fully patched kernel without having to compile one yourself every time a new patch comes out; a little different from being rebootless, but eminently useful for us mere mortals.
I've been bragging about this for months using kexec...
http://www.ibm.com/developerworks/linux/library/l-kexec.html
not exactly the same but does this mean that I'm not cool anymore?
Isn't that kinda the big thing with Jaunty other that the cooler looking login? They make the boot time real short and two months later "Oh hey you don't need to reboot." This is pointless.
AIX 6.1 seems to have been doing concurrent kernel updates for about a year now, also the power5 and 6 boxes has been doing concurrent firmware updates for better than 3 years now pretty neat features to see hope they get more mainstream.
Isn't this already available in AIX 6.1 released by IBM in which the kernel is actually mapped allowing modifications without rebooting? I believe something like 4/5 modules can be changed on the fly.
http://www.redbooks.ibm.com/redpapers/pdfs/redp4367.pdf (PDF) section 2.3.15
---
Question is Ksplice reliable enough for online servers. I'd rather manually upgrade and be there to fix the systems, than risk a shoody automatic system going down randomly.
---
Linux Feed @ Feed Distiller
get back to me when you have found a way to patch my network service without dropping the current open sessions, then i'll be really impressed.
If you mod me down, I will become more powerful than you can imagine....
you running that takes 13 minutes to boot up?
I've got server rooms that come up completely from power failures in less time than that. And that's staggered starts of switches, DNS, DHCP and AD before everything else.
And if it's a planned update, then your uptime percentage ain't affected anyway.
Trying to become famous by taking photos. Visit my homepage please.
you seriously think I can tell my customers that they will get rebooted next week and expect them to be OK with that? Sure, if you are running windows, your users are used to it, but I know for me, a reboot is a reboot is a reboot; and usually it is followed by a number of customers leaving. It's not just the downtime; many customers (I provide VPSs) configure services by hand, which means that when it comes back up, it's wrong.
That said, it will be a long time before I use Ksplice on the Dom0, just 'cause a planned reboot, while bad, is still much better than an unclean shutdown. I tend to be very conservative on those boxes.
outages from the uptime calculation? I thought only really shady companies; the type that put up the 'site is down for maintenance' page when something breaks, excluded planned downtime from the sla. I don't exclude planned downtime from my SLA http://book.xen.prgmr.com/mediawiki/index.php/SLA - in fact, the last time I paid out a SLA the downtime was planned; I was moving some servers from one rack to another.
I just can't imagine the phone company saying "oh, yeah. the phone outage was planned, so we still have 100% uptime"
does just about the same thing.
After reading Windows Can but Won't I am still unimpressed. This article tries to hide a substantial feature preset in Linux but not in Windows. Call it a misfeature, a bug, an engineering decision or a precaution but, as it seems, Microsoft's filesystems do not support file removal well. If a DLL is in use you can't remove it without dire consequence, you are left with modifying the original file.
On Linux, you can remove the DLL without destabilizing running applications. This is because the file is unlinked from the directory structure, appearing as if it was removed, and the old file contents is still accessible to running applications. On Linux, an update mechanism can remove the DLL and put a new DLL in its place without affecting any running applications. Running applications continue using the old DLL, posing no substantial stability risk.
The Linux way isn't perfect either because running applications do not benefit from the update. Such an application will effectively use the old DLL until it is restarted giving a false sense of security. If an affected service is not restarted, then the computer is still at risk.
Kid: Ever hear of Moore's Law?
Father: You insensitive clod! Get off my lawn!
I don't necessarily agree with everything Raymond says, but from your post I gather you missed the point a few times. ... programs that were still using A.DLL keep using the old version, but new programs will use the new one. ... interoperating with it.
>Windows actually can replace a DLL that is in use by renaming the original then copying the new file into place. However, the Windows world prefers not to do this. Why?
Your response makes no sense. Explaining how essentially the same operation is done on Linux doesn't explain why Windows preferes not to do this, nor does it explain why it is okay on Linux.
>Even if you replace a file that is in use, there may still be code in the system that wants to use the old version.
Actually, all Microsoft DLLs are compiled in such a way that all their functions can be patched safely, even if the processes using the DLL are not paused. Of course, if the internals of the function influence for example communication between processes or there is some other reason that all processes need to have the same version of the function, you must still let all processes leave the function, but that is doable, at least in principle, on Windows also. Plus, Microsoft owns a technology to patch functions in DLLs that aren't specially crafted which they mainly use internally when debugging programs that don't run correctly on a new version of Windows and stuff like that.
>Now a program
Here Raymond pretty much complains about the problem we just solved. Also note that in many cases as long as the binary protocol doesn't change you don't have to worry about these things. Followed by a snipe along the lines of "people complain that we're slow in developing patches, but we have to deal with all these problems (that we decided not to deal with after all)". I like many of Raymond's interesting and insightful articles, but sometimes he can be so boneheaded.
>So it's not that Windows has to restart after replacing a file that is in use. It's just that it would rather not deal with the complexity that results if it doesn't. Engineering is a set of trade-offs. Do you go to the effort of supporting older versions of yourself for a situation that isn't even a recommended steady-state configuration?
Translation: Windows could, but then we'd have to implement a small piece of software that coordinates the update. And we'd have to tell patch developers to mark if their patch has special needs. It's much easier for us if you reboot your machine, even if that does mean that you'll have to wait for your computer to reboot, reopen all your windows, and restart all long-running background processes, even if that means that if one of them takes longer than a month it will never be finished.
In ANY distro, kexec can provide rebootless updates!
The GPL is a license to copy, modify and distribute. When you download something, you do nothing of the sort.
In the broadest strokes, the GPL isn't that different from a EULA. The main difference is the scope of the agreement.
Meh, no. The GPL isn't an agreement.
BIG WARNING: I'm not a lawyer. I haven't read much law, but I try to soak up some principles from discussions on slashdot, talks by Lessig, Moglen and Stallman, etc.
The way copyright works is like this: you write some code. Everyone else is forbidden from doing certain things with that code, for a limited time. The GPL is a formal way of saying "I give you permission to do it anyways".
One of the things the GPL gives you permission to do is redistribute the binaries and source. It doesn't give you permission to redistribute the binaries alone*.
Note a key point, here: the GPL doesn't take any rights away from you that weren't already taken away by copyright law.
Next consider EULAs: they're contracts. They say "we will offer you permission to use this software, if in return you promise us to $TERMS_AND_CONDITIONS". (For instance, according to Bradley Kuhn (in his talks available on audio-video.gnu.org) states that as a term of the FrontPage EULA, you're not allowed to use the program to create pages which say bad things about Microsoft.)
One is a give. The other is a give-and-take.
I think the big deal about this is that with EULAs, contract law comes into play. That means the "buyer" (the party not creating the contract) has to have a reasonable chance of understanding it; it has to be negotiable; the parties must know what it says (or have had a reasonable opportunity to know what it says) before agreeing to it.
There's also a point to be made about contracts being for the benefit of the signing parties, whereas copyright is for the benefit of society. That might create some interesting legal implications.
I do get your point: licenses and EULAs are pieces of text that say what you can and can't do with the software in question. But, in a legal sense, they're different. I think it's valuable to be able to make this distinction, and have a way of thinking about the implications of the difference.
For desktop users what happens if the Kernel changes enough to screw up your graphics drivers? Crashing X is not going to be a popular option.
Even for servers - engineers need to design their farms so they can take servers down. Especially those who have commercial interests involved. Lack of proper redundancy so upgrades can be performed is poor planning and a problem waiting to happen. Reboots stress the hardware a bit, and if your server was on the verge of failing it may just do that or post a code. Splicing the kernel keeping up just increases the off chance that when you turn your back and want to enjoy your weekend the server goes up in smoke.
Thanks, sdasher, for submitting this story.
I very much like reading about cool new open source technology. Sure, the law, politics and biotech stories are cool too, but cool new tech stuff is (for me) the real meat of slashdot, which is sadly underrepresented these days.
Thanks for submitting, much appreciated :)
I read the link. In the Windows case, the issue is, well, stunning. I hadn't realized they still have problems with DLL hell. In the article you referenced, the problem is described this way: DLL A and DLL B are updated while program foo is running. So long as foo is still running, it's using the old versions. But, any program launched after the updates that uses A or B could be hosed, because the updated DLLs might not be backwards compatible.
In the Unix world, this problem was solved a long time ago. (20+ years?). Run time libraries libA.so and libB.so are actually symbolic links pointing at the latest major,minor,revsision libraries, libA.so.major.minor.revision, libB.so.major.minor.revision. So whenever any program is linked against a runtime library with say major version 3, minor version 2 (i.e. it's compatible with versions 3,4,and 5 of libA) then that program will run with any version of the library that supports version 3. So at run time it will always be looking for libA.so.3.*. If a newer version of library comes out that is not backwards compatible with version 3, libA.so will point to it sure, but the already compiled programs will still point at the old version of the library. Read the info page for libtool for more and better information.
Unfortunately for Microsoft I think they royally screwed themselves by their dogmatic insistence that programs from 20+ years must still work, no matter how shitty, bug ridden, take-them-out-back-and-shoot-them-please they might be. Specifically, it looks like their FAT 8.3 filename has screwed them because all of their dlls are of the form "foobaz.dll". Notice that the dlls don't have versioning number? They are so screwed. As Raymond states you can move the old DLLs to a different directory, but the programs that depended on them don't know that unless you do something with their environment. I'm not a Microsoft poweruser, so someone else will have to speak about how to deal with that. I'm surprised they didn't hire some Unix guys to tell them about version numbering dlls, but then again the decision they made about how to deal with DLLs must have happened 20+ years ago when they only had the FAT filesystem, and so it would never have occurred to "them" to leave themselves some wriggle room.
> This makes Ubuntu the first OS that doesn't need to be rebooted for security updates I'm pretty sure there are some types of patches that migth need a reboot (such as some updates to the thread scheduler or memory manager). There might not have been any of those since the last release, but there are likely to be some in the future. And Windows Server 2008 already provides hot patching capabilities for most types of updates. The reason why most patches cannot be applied hot is because making a fix a hot patch takes more developing and testing and thus many patches are released without this capability. If you want to find out which OS was the first one that could be deployed without reboots to get patched, any Linux or Windows OS at the time of its release was like that (as no patches were available then). If you watn to know which one was the first OS that provided hot patching capabilities for critical components that were active, Windows Server 2008 was that. What I think can be claimed about Ubuntu now is that it is the first OS that has a hot patching capability that covers all available patches at this time. Which is different.
Depends on how you negotiate the SLA.
In my mind, a planned outage is clearly defined. Two weeks notice on any system below core-critical, four weeks on core-critical; clearly defined reason for the downtime, including motivation as to why it cannot be done without downtime; clear indication of outage period and a full defined plan for both deployment of the change and recovery procedure. Clear communication to users is also essential.
Anything else is unplanned and needs to be penalized.
Emergency outages are permitted, but are not flagged as planned and count against the SLA metrics.
Out-of-band emergencies, like the nuclear power plant having a generator failure and the power utility shutting down swathes of the city for hours at a time, get flagged on the management system as not our fault and excluded. Too bad we cannot negotiate an SLA with the power company. Same with someone not being able to climb a mast because of 120km/h winds for three days straight.
Trying to become famous by taking photos. Visit my homepage please.
I used to work on a project that made server software for Linux/UNIX and DOS (this was a while back) and we had to be able to patch and restart the service while maintaining the current sessions. The end-user might see a little delay while things were coming back on-line, but other than that, it was pretty seemless. Granted, we were working with something less complex than a kernel, but I'm sure any server could be set up in a similar way. We were able to patch about once a week without taking the service off-line for about a year... then we had a hardware failure.
exclusions were funny. I mean, if I co-lo at a place that doesn't have redundant power, and the power outage takes you down, that is my responsability. Same if my upstream goes down; Only running through one upstream would be a complete dereliction of duty on my part.
but then, I always thought negotiation was a little funny, too; I mean, I can provide you service at a significantly lower price if I can provide you the exact service I'm providing to everyone else. I mean, I appreciate feedback; but negotiating with every customer seems funny. I'm giving the best deal to the customer who spends the most of my time at the expense of the silent majority who don't complain and pay on time? that seems backwards.
on the 'not our fault' issue, a SLA should really substitute 'I can't be expected to do anything about it, or to have prevented it' - sure if my immediate upstreams fail, I need to do something about it. same goes for power. But if the customer's dsl goes out, or some fishing trawler cuts the last trans-adlantic cable coming into your country, well, that's not really something I should be expected to fix. but that's hard to define precisely.
and I don't seem to have trouble achieving uptime north of a year. (I did a hardware refresh around the year mark, though, so I don't have much anything that has been up longer)
But to answer the question, yes, people want the best service, even if you tell them up front that your service has made some tradeoffs to keep prices down.
If anything, I think my customers, especially the new ones, are quicker to leave than they would be on a more expensive service; they are suspicious. I've lost more than one this week due to a 48 hour backlog provisioning new accounts.
Even better..
Apple and Orange Pie
Crap. What did the new CSS do with the "Post anonymously" option??
I hear this occasionally, that tomatoes are technically fruit, that something else is or isn't, so I took the time to look it up a year or so ago.
It turns out that the term fruit means "the ripened ovary of a flowering plant" and "Any sweet, edible part of a plant that resembles seed-bearing fruit, even if it does not develop from a floral ovary" and "a product of plant growth (as grain, vegetables, or cotton." (Wikipeida, Wiktionary, Merriam-Webster)
Interesting too, my first two references are driven by Open Source and pretty good, but for authoritative information, it is the closed source system of Merriam-Webster that I turn to.
I also checked out the OED definition: "1 the sweet and fleshy product of a tree or other plant that contains seed and can be eaten as food. 2 Botany the seed-bearing structure of a plant, e.g. an acorn. 3 the result or reward of work or activity. 4 informal, derogatory, chiefly N. Amer. a male homosexual."
B) Eliminate all the stupid users. This is frowned upon by society.
It seems to me that there is no mention of the security implications of making it easier for anyone (admin or attacker) to place code in a running kernel. Those of us who run hardened systems often go to great lengths to limit the attack vectors through which one might be able to modify a running kernel (disabling writable /dev/kmem, disabling LKM support, disabling privileged I/O, randomizing the kernel stack etc...). Furthermore, one of the most obvious events that trips alarms in the heads of many security professionals and paranoid admins, is the inexplicable rebooting of a machine. When one of my machines does this, the first thing I will do is examine the kernel image on the disk and compare its checksum to known-good checksums. I also know I am not alone in this practice. I don't think I want to utilize a tool which is designed to ease the circumvention of all of that so it isn't really viable to anyone who desires to harden their hosts against kernel-side rootkits. In my opinion, this is yet another example of security and convenience proving to be mutually exclusive.
This makes Ubuntu the first OS that doesn't need to be rebooted for security updates.
Sorry, but no. IBM has had that on iSeries (or what every they are calling it now) for a while. I think the mainframe also has online updates. In anycase, I once worked on the update code path for iSeries. We were able to patch it's 'kernel code' (being IBM we had to make up a different name for a kernel) at run time. There were very few things that could not be patched with an online fix.
All the same, I'm a linux bigot. If Gentoo would pick this up, I'd be able to go longer without a reboot. Now if only I could merge in a batch of updates without having to restart all my X apps.
**This makes Ubuntu the first OS ** I thought Linux was the OS and Ubuntu a distro.
Pshaw, I can yank CPUs out of my Sun E6500 without losing uptime. :)
I believe it was Solaris which first allowed live kernel updates without reboots... at the expense of a minor amount of memory being inaccessible until the box was rebooted. I think that was one of the big features of Solaris 7/8?