Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security Software Upgrades Linux

Ksplice Offers Rebootless Updates For Ubuntu Systems 211

Posted by timothy from the uptime-preserver dept.
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.)"
This discussion has been archived. No new comments can be posted.

Ksplice Offers Rebootless Updates For Ubuntu Systems More

Ksplice Offers Rebootless Updates For Ubuntu Systems

Comments Filter:

  • GPL "terms of service"? (Score:5, Interesting)

    by innocent_white_lamb ( 151825 ) on Sunday June 28, 2009 @12:59AM (#28501431)

    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.

    • Re:GPL "terms of service"? (Score:5, Informative)

      by Ambush Commander ( 871525 ) on Sunday June 28, 2009 @01:09AM (#28501451)

      So, they're doing the common "commercial open source" thing where the software (the application, the kernel patcher) is open source, but it's also tied to a service (the actual kernel patches) which is not so (free for Jaunty, but if you want a different kernel you'll have to pay Ksplice for support). So the Terms of Service applies to the service, which is really quite sensible.

      • Also the code that they have written may be dual-licensed - GPL and , with the ToS mainly declaring the terms for and letting it be known there is a choice.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      In the broadest strokes, the GPL isn't that different from a EULA. The main difference is the scope of the agreement. When you use a typical EULA'd piece of software, you have to agree only to run it under certain conditions and not to redistribute it. When you use a GPL'd piece of software, you have to agree only to redistribute it only under certain conditions. You don't have to agree to anything to run it, but there are still terms and conditions for your use of the software (if "use" encompasses redistr

      • Re:GPL "terms of service"? (Score:4, Insightful)

        by _Sprocket_ ( 42527 ) on Sunday June 28, 2009 @01:46AM (#28501601)

        In the broadest strokes, the GPL isn't that different from a EULA.

        In the broadest strokes, an apple isn't that much different than an orange.

      • Re: (Score:3, Informative)

        by Anonymous Coward
        DLA != EULA The GPL is a Distributors License Agreement not an End User License Agreement.

      • Re: (Score:2)

        by mpe ( 36238 )
        In the broadest strokes, the GPL isn't that different from a EULA.

        The only thing they have in common is the letter "L". You might just as well claim that an instruction manual isn't that different from a novel.

      • 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 an

    • If it's GPL cant you just edit the terms out of it?

  • Great! (Score:2, Insightful)

    by jbacon ( 1327727 )

    This could actually be really awesome if it's truly production ready. What's that? 100% uptime?! AWRIGHT!

    • This can be great advertising:

      "Ubuntu: updating and restarting is cliche. Continue to work while staying updated and secure."

      I'm not a marketing person so let someone else handle that part. But the idea is clear though.

    • Re:Great! (Score:5, Funny)

      by darkpixel2k ( 623900 ) on Sunday June 28, 2009 @02:09AM (#28501707)
      I can see it now... "Kid. This was your fathers laptop. Cherish it as he did. It currently has just over 6 decades of uptime. With any luck, you'll be able to reach 13 or 14..."

    • Re: (Score:3, Interesting)

      by Anrego ( 830717 ) *

      It's a cool piece of kit, but I wouldn't use this in a production environment.

      If you are relying on one server to maintain 100% uptime in a high availability (which most production environments are) situation, you are probably doing it wrong.

      It's my opinion that in a ha environment, you _should_ be able to reboot a box with no loss of uptime to the system as a whole.

      I would even go as far as recommending a reboot every 3 months or so to test your clustering/failover setup (because I think a lot of people se

  • Fedora doing this since F9.. (Score:5, Informative)

    by gzipped_tar ( 1151931 ) on Sunday June 28, 2009 @01:16AM (#28501475) Journal

    https://admin.fedoraproject.org/pkgdb/packages/name/fedora-ksplice [fedoraproject.org]

    fedora-ksplice
    Script Collection for Using KSplice on Fedora Linux

    fedora-ksplice is a collection of shell scripts to use ksplice in a Fedora environment.

    The scripts allow to prepare a kernel for use it with ksplice.

    fedora-ksplice-prepare will download the source rpm of the current installed kernel. After this the kernel sources will be created in the rpm build directory. Additional the ksplice subdirectory with the System.map file will be created.

    Fedora-ksplice-create will apply a patch given as an argument to the kernel sources prepared by fedora-ksplice-prepare.

    • Re:Fedora doing this since F9.. (Score:5, Informative)

      by Ambush Commander ( 871525 ) on Sunday June 28, 2009 @01:47AM (#28501609)
      That's a collection of shell scripts around the free software Ksplice tool that merely automates the task of downloading the Fedora kernel. (The Ksplice software has been released for over a year, and is also packaged in Ubuntu [ubuntu.com] and in Debian [debian.org], although the ksplice.com apt repo has newer versions.) Ksplice's Uptrack service is a way to automatically apply Ksplice updates that have been vetted for safety by the Ksplice developers, which is a much more convenient thing unless you like reading every kernel patch daily and testing the resulting Ksplice patch yourself.

  • Left are the Zombies.. (Score:3, Funny)

    by htiawe ( 973440 ) on Sunday June 28, 2009 @01:17AM (#28501477)
    Now we need a ksplice for zombies instead of having to reboot to clear some of the nasty zombie processes.

    • someone just posted on debian-user that the way to kill zombies is to have the parent processes try to reap them and if that fails, they should get reparented up the chain until their parent becomes init. Then doing `telinit u` will cause init to restart (while maintaining state) and all the zombies will be dropped. I haven't had the chance to try it.

      • Re:Left are the Zombies.. (Score:4, Funny)

        by onefriedrice ( 1171917 ) on Sunday June 28, 2009 @02:31AM (#28501775)
        Actually, it's simpler than that. A child process whose parent dies will be adopted by init immediately (not re-parented up the chain). If the process is a zombie (because of a bad-behaving parent process), removing the zombie is as simple as killing the parent, at which point init will adopt and reap the zombie because init always waits on its children. Running "telinit u" might make init reap the zombie quicker, but it will happen eventually anyway so that command is very much optional (and not recommended since zombies are harmless anyway).

        • Re: (Score:3, Funny)

          by MrNaz ( 730548 ) *

          Zombies are not harmless! You obviously don't watch enough movies.

          • Re: (Score:3, Funny)

            by Tumbleweed ( 3706 ) *

            Zombies are not harmless! You obviously don't watch enough movies.

            Look, _clearly_ there are dangers inherent to zombies, but if YOU had watched enough movies, like, say, Shaun of the Dead, you'd realize they can be made into productive members of society (well, videogame consumers, anyway) if handled appropriately.

            As the tshirt says, "Reduce - Reuse - Reanimate. Reduce our dependency on the funerary industrial complex." Get with the program!

  • Difference between Linux and Windows (Score:5, Insightful)

    by nmb3000 ( 741169 ) on Sunday June 28, 2009 @01:22AM (#28501497) Journal

    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 [microsoft.com], 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.

    • Re:Difference between Linux and Windows (Score:5, Insightful)

      by 644bd346996 ( 1012333 ) on Sunday June 28, 2009 @01:36AM (#28501549)
      Most of the people who would want to patch a system without rebooting aren't upgrading to get new features - they're applying security fixes, which seldom break binary compatibility. That makes it pretty safe to replace an in-use library. Once the update has been installed, you can restart the affected services on a schedule of your choosing, rather than have several minutes of complete downtime. I would expect that the reason this isn't attempted as often under Windows is that DLLs don't follow any system-wide rigorous versioning system like what most Linux package managers impose. This, and the presence of closed-source software, makes it much harder to do this with confidence under Windows.

      • This is basically the reason, yes. Windows itself is not subject to being unable to move or replace a code image on-disk, of course (although it can cause some weird issues if forced--I've seen applications supposedly paged to disk try to hit up the new image from disk rather than from the page file and puke all over themselves), but really, for most uses it's just not worth the risk. .NET applications can, however, leverage the GAC to do essentially the same thing. As we see more and more movement toward t

        • Re: (Score:2)

          by Dog-Cow ( 21281 )

          I'd like to point out that the behavior you see is actually by design. Windows does not page executable pages to the pagefile because it knows that (under normal conditions) it can swap back in from the original file. When Windows requires the memory being consumed by an executable, it will simply drop those pages and reuse them.

          Linux does the exact same thing. The reason why you can replace the file while it's in use is because you are not actually overwriting the file. You are just reusing the name in

          • Oh, no, I know that. I was just mentioning what can happen if you do it. :) I don't think either is a good idea, especially with computers regularly having multiple gigabytes of memory.

            And, IIRC, Windows does, these days, operate similarly with regard to file handles, doesn't it?

      • Re: (Score:2)

        by Nimey ( 114278 )

        Also Windows doesn't let you over-write open files like Linux does.

    • Re: (Score:3, Informative)

      by Geoffreyerffoeg ( 729040 )

      Well, let's look at the issues raised in the article.

      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.

      Ksplice updates the running code of your kernel (by waiting until no thread is using the function to be patched, then calling the kernel's stop_machine_run function -- the same thing it uses when loading a new module -- while it edits the object code); it doesn't touch your /vmlinuz file on disk

      • Re: (Score:2)

        by Bert64 ( 520050 )

        I wouldn't bother so much with applying the patches on reboot, if you're going to reboot anyway you could just install the regular updates.

    • Microsoft's excuse for not updating (Score:5, Informative)

      by Mask ( 87752 ) on Sunday June 28, 2009 @04:13AM (#28502063)

      After reading Windows Can but Won't [microsoft.com] 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.

      • Re: (Score:2)

        by vdboor ( 827057 )

        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.

        this is a realy good point, and most people seam to forget that. After running updates, you can use this command to see which processes use old library versions:

        lsof | grep inode=

        I'd wish linux update tools/applets would check this too...

      • On Linux, you can remove the DLL without destabilizing running applications.

        Not if your running applications are using them, you can't. Everytime I update firefox with apt, firefox needs to be restarted because it starts doing weird crap (not opening new tabs, giving weird error messages). Same thing happens if I update gnome libraries.

        Don't get me wrong, I'm also unimpressed by "Windows Can but Won't." I update firefox and it starts behaving erratically, I restart firefox, I update gnome and it behaves badly, I restart everything in X. It's quick, it's painless and way quicker

        • I was just about to mention Firefox. I have updated other software while it's running, though, and those don't have any problems. Firefox just seems to do things differently.

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      > 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?

      Linux solves this with links. To pick a random example:

      lrwxrwxrwx 1 root root 17 2009-06-21 19:04 /usr/lib/libqt-mt.so.3 -> libqt-mt.so.3.3.7
      lrwxrwxrwx 1 root root 17 2009-06-21 19:04 /usr/lib/libqt-mt.so.3.3 -> libqt-mt.so.3.3.7
      -rw-r--r-- 1 root root 7534253 2008-03-02 12:04 /usr/lib/libqt-mt.so.3.3.7

      I'm showing here an

      • Re: (Score:2)

        by ettlz ( 639203 )

        For the other problems like:

        > When you write code that communicates between processes, you generally expect that the same version of the code will be running in each process

        Why would anyone make that assumption when designing an IPC mechanism?

    • Windows itself doesn't. But the virii and rootkits do this quite happily. TYVM. ^^

    • 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?

      Some systems you don't want down, ever. Emergency phone service, nuclear power plant control systems, air traffic control systems. Generally, if you don't lose revenue but lives, don't shut it down.

      Also, for some very important operations, one must imagine the operators have a test/staging server where they can test the changes before deploying on production systems.

      But the most important point: we're being rationalistic instead of empirical! It's possible to collect the numbers; that is, measure the dow

      • Re: (Score:2)

        by growse ( 928427 )
        Mission critical systems usually have redundant systems they can fail over to in almost real-time. Patch your hot-standby (after testing of course), fail over to that, then patch the other side.

  • Interesting start (Score:3, Interesting)

    by ErikTheRed ( 162431 ) on Sunday June 28, 2009 @01:38AM (#28501557) Homepage

    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.

  • For you geeks that don't "need" 100% uptime... (Score:3, Interesting)

    by Ambush Commander ( 871525 ) on Sunday June 28, 2009 @01:53AM (#28501641)
    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.

  • Less that 20 second reboot. (Score:3, Funny)

    by yourassOA ( 1546173 ) on Sunday June 28, 2009 @01:54AM (#28501657)
    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.
    • Pointless or improvement?
    • Pointless, eh? It lets me install security patches when I want, without rebooting. Yet I do reboot for reasons other than patching. I run Kubuntu, FreeBSD, OpenBSD, Slackware, and Windows. I like to test programs I write before releasing them. This lets me avoid rebooting when I don't want to, and the faster reboots with Jaunty make those times when I do want to reboot easier.

    • This is pointless.

      Not really. If I want to reboot, it's faster. If I don't want to reboot, I don't have to. At present I keep my system multi-booting between Jaunty and Gutsy, so I can use either the most recent version or the one with working low-latency audio. I also have a Haiku partition for testing things on real hardware without having qemu get in the way. I reboot quite a lot, and being able to get Jaunty up nice and quickly (although still too slow compared to Haiku) is useful.

      One other thing

  • Actually I haven't found i had to reboot ubuntu many times from updates, maybe 4 times a year, after a heavy patch of the Hal or the video drivers. Haven't said that i still haven't upgraded to jaunty. I waited when It was fresh upgrade, then didn't fine the time. Guess i've no excuse now, should be quick, but you have to leave the time, just in case it buggers up your live services.

    ---

    Question is Ksplice reliable enough for online servers. I'd rather manually upgrade and be there to fix the systems, th

    • Re: (Score:2)

      by Korin43 ( 881732 )
      Think of it in terms of uptime. 99.99% uptime means you're down for ~52 minutes per year [google.com]. Rebooting 4 times a year could mess that up.

      • 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.

        • Maybe he's using ext3. A fsck, given the size of modern disks, could take th 52 minutes in a single reboot. Of course, I guess you don't use ext3 if you need 99.99% uptime.

      • Well sure, but that's why nobody uses the output as 'uptime' as an SLA metric. You look at service availability, not 'time since last reboot.'

        If your service is important enough to require four or five nines of availability, you have some sort of redundancy built in, and can leave your main system on while you upgrade and test your backup or cluster member.

        Or, you were smart enough to allow for maintenance windows and what not.

  • load of wank (Score:3, Insightful)

    by timmarhy ( 659436 ) on Sunday June 28, 2009 @02:46AM (#28501799)
    if the fix affects a service i'm currently running, you still have to restart the service, so all this is doing is perpetuating the usual stupid uptime measurment of performance, which isn't indicative of the systems avaliablity.

    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.

    • Re: (Score:3, Interesting)

      by Geoffreyerffoeg ( 729040 )

      Actually, Ksplice provides live patches. The ones Uptrack distributes are all to the kernel, and obviously not restarting the system requires not restarting the kernel.

      The Ksplice technology [ksplice.com] itself is free software, and can be ported to userspace (but that hasn't been implemented yet by the Ksplice people). But if your network service is an NFS server or something, or you're fixing a security bug in the kernel, then Ksplice can apply it to a running system without affecting existing sessions / connections.

      • so if i'm running NFS with 1000 users connected to my mission critical system, and i apply a patch using ksplice, it will upgade my NFS service for all new connections (immediately without a restart of the service) and won't require dropping the existing connections? the only possible way i can see this working is some kind of virtual machine system because anything else would mean 2 services sharing a port (which won't work). and if it's a virtual machine it's going to mean a performance hit, which would b

        • Re: (Score:2)

          by Enleth ( 947766 )

          That's right. It's modifying the in-memory binary image (that is, the machine code), while it's actively up and running.

        • Re: (Score:3, Informative)

          by Lennie ( 16154 )

          This is about patching the kernel, it usually doesn't need to change the kernel structures, but it changes the functions. So it put the new function in kernel space and changes a pointer to the function. When doing this it temporarily slows down the kernel and calls the same function as is done when loading a module. That's what I think it does, but if you must know, read the PDF: http://www.ksplice.com/doc/ksplice.pdf [ksplice.com]

          For all those that think this company is doomed because they released all their code as op

    • Kernel level updates normally don't take effect until you reboot and load the new kernel. This includes a fair number of security updates.

    • How long does it take to restart Apache (or vsftpd or sshd), compared to how long it takes to reboot? Or if you are running multiple services and only need to restart one?

  • 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.

  • 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 :)

  • > 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 ho

    • Re: (Score:3, Informative)

      by ratboy666 ( 104074 )

      You would be correct. Linux isn't the first "hot patch" system.

      Multics (1965) was designed for 24/7/365 operation, and could replace any component by design. Hardware or software.

      http://www.multicians.org/ [multicians.org]

Slashdot Top Deals

It isn't easy being the parent of a six-year-old. However, it's a pretty small price to pay for having somebody around the house who understands computers.

Close