Re: itp: static bins / resolving static debian issues
Thursday, August 19, 1999, 12:59:17 AM, Justin wrote:
> Some of you may have missed the mounds of earlier discussion. The
> point of "live recovery" is to recover the system WITHOUT requiring
> a reboot, therefore any boot disk or LILO solution is not acceptable.
> Suppose you screw something up, but your database and webserver are
> still linked and loaded. Why bring them down?
> You need to get a root shell WITHOUT a reboot. So you need roots
> shell to be static, and you need a static su, and a static sulogin.
Because if you were so concerned about data integrity that you would not
leave a known crippled server in place where unforeseen complications could
cause data corruption.
Because if you were so concerned about the service's uptime you would be
operating in a redundant architecture so that the loss of a single machine
would not bring down the service.
One has to ask, BTW, how new httpds are being loaded if the machine is so
fucked that you can't even login or work without static binaries? Oh, wait,
you'd have them all statically linked as well. I get it now.
However, in your case, you'd risk data corruption and would accept a
single point of failure which *WILL* result in downtime due to hardware
failure (statically linked libraries don't help when a head meets platter at
high speed or the power supply blows) or from user error (ever rm -rf a
mounted root drive by accident? I have. Whoops, all those nice statically
linked binaries all go buh-bye!).
Again, if uptime of the *service* is paramount, you would already have an
architecture designed that would allow for swapping out the underlying
hardware in case of such unrecoverable errors.
Until you can convince me of a situation where that is otherwise, your
entire argument is bunk.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
Reply to: