Messages in this thread | | | Date | Wed, 21 Sep 2005 00:47:56 +0200 | From | Jesper Juhl <> | Subject | Re: Hot-patching |
| |
On 9/21/05, John Richard Moser <nigelenki@comcast.net> wrote: [snip] > Besides getting rid of a pet peeve of mine (more rebooting than > absolutely necessary) and giving a way to continuously increase the size > of the running kernel with each bugfix, this has implications on servers > that don't want to reboot for whatever reason. For enterprise > applications, it would be possible to fix a kernel bug or security hole > that hasn't been triggered by loading a module with the bugfixes, > effectively hot-patching the kernel. > [snip]
If you have uptime demands like that I think a much better approach would be to make sure the box is heavily firewalled so importance of the security of the host itself drops. If there's no way to get to a box in a way that enables you to actually exploit a security hole, then it doesn't matter much that the hole is there at all.
Another option would be a clustered setup where you normally run the app(s) on nodeA, nodeB ... nodeN, then when you need to upgrade you move all running applications off of nodeA and upgrade it, move everything off of nodeB and then upgrade that, repeat for nr of nodes, finally redistribute the load properly again.
-- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |