Messages in this thread | | | Date | Wed, 21 Sep 2005 01:07:21 +0200 | From | Jesper Juhl <> | Subject | Re: Hot-patching |
| |
On 9/21/05, John Richard Moser <nigelenki@comcast.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jesper Juhl wrote: > > 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. > > Yeah. Not always feasible though; let's say the bug manifests in > something Apache tells the kernel to do (there's quite a lot of > syscalls) based on stuff passed to CGI scripts. Firewalls and > everything, but slide in a "legitimate" port 80 or port 443 access and BLAM. > > Shell servers like compile farms are also interesting, if you want to > talk about firewalling not being all that great. That's of course if > you care about local attacks; personally if I have 10000 employees or > clients using a machine I don't want to trust them all to be nice. >
Firewalls are not a panacea, no. But for many (not all) issues, good firewalling can eliminate the immediate need to patch a server.
> > > > 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. > > > > Beautiful setup that, and surprisingly cost effective if 1) you can do > it yourself, and 2) you're using just 2 nodes. I'd prefer 3 nodes for a > minimal set-up of course, so if I upgrade one and the other goes down I > still have a third; I'm obsessive about perfectly stable environments, > it has to be able to stand up to a bomb blast or the ending scene from > Hackers with all the blackhats in the world tearing ass at the system. >
A few links you may want to take a look at :
http://www.linuxvirtualserver.org/ http://www.linux-ha.org/ http://lcic.org/ha.html http://openmosix.sourceforge.net/
-- 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/
| |