On Mon, Aug 16, 1999 at 12:44:34PM -0400, Justin Wells wrote: May I summarise your proposal briefly?
* You want statically linked recovery stuff to be standard.
* You mainly want this so you can recover from your own mistakes
(or other less clueful admin's mistakes on the same box, say)
Your main argument is:
* Dynamic linking is a single point of failure, that can entirely
wreck your weekend, and static linking of the tools you need to
recover is a good way of avoiding it.
From the outset, I'd like to completely agree with your argument.
Eliminating risks is a damn good hobby. I'm not quite convinced that this
is the best way to go about it yet, though.
So here are some alternatives.
(1) Do nothing. Not very interesting.
(2) Make sash.deb priority standard, or at least make it more obvious so
that people who have any idea why static linking might be a good thing
can say "Ooooo. I want that" and be thankful for it later.
The first question is, is sash enough? It doesn't include dpkg or
apt-get's functionality, in particular. Is that really worthwhile
though? What sort of failure modes are there that a statically
linked dpkg/apt would help with that are actually plausible. I
assume minimising downtime for people who type "rm /lib/*" isn't a
particularly high priority (whereas minimising downtime due to bash
being removed by apt is much more reasonable).
(2a) Rather than statically linking apt, maybe it'd be better to
statically link snarf, which is both much smaller, and only
links against libc rather than the plethora of things apt-get
does. snarf is a simple little program that lets you get things
via ftp, http and gopher, and even copes with proxies and such.
(3) Make ash the default /bin/sh. ash links to libc6 and ld-linux, whereas
bash links to libreadline, ncurses, libdl, as well as libc6 and
ld-linux. Risk reduction isn't as good as risk removal, but it
ain't bad. Theoretically improves bootup speed, and probably means
bashisms become a lot less common.
(4) Make all the standard tools in /sbin and such statically linked. Stops
the problem, more or less, but bloats / terribly (by 25MB or so,
which is more than double what it currently is). Bloating / is not a
good thing. Which probably means this would have to be optional. Which
doesn't achieve the "part of a standard install" goal.
Anyway. Some other comments:
> "dpkg and apt are so effective that they eliminate all the problems"
> The ability to recover a system, and install it under adverse conditions,
> is so important that relying on dpkg and apt is an unacceptable risk
> which makes Debian far too fragile.
Erm. "The ability to recover a system, and install it under adverse
conditions, is so important that relying on the system still being
functional enough to work is an unacceptable risk." Therefore you should
keep a bootdisk handy.
Seriously.
Keeping a bootdisk handy also means you can recover your system even when
static binaries wouldn't work (rm -f /*/*, say). The above has already
been addressed. If you want it solved in another way, that's fine, but
then it's about trade offs (eg, convenience vs disk usage), not about
there being no way to recover.
> "We provide resecure boot floppies for this kind of situation"
> Boot floppies are an unacceptable response for three reasons:
> #1. The system administrator may be working for remote when
> the failure occurs; gaining physical access to the machine
> at 4am in the morning may take hours, or be impossible.
Then the sysadmin shouldn't do that. Upgrading to unstable, and rm'ing
things in /lib when you can't get physical access to the machine? It'd
be nice to fix, but it doesn't seem particularly unacceptable.
> #2. The downtime involved in rebooting from a boot floppy is
> likely to be substantially longer than if the problem can
> be resolved without rebooting
Again. Annoying, and nice to fix, but hardly unacceptable.
> #3. Critical applications may be running on the system, and
> there may be a very high cost involved in a reboot
As per (2).
> "You can install the sash package if that's what you want"
> The Debian policy states that anything which an experienced
> Unix administrator would expect to have available should be already
> installed by default on an ordinary system. There is common sense
> in that policy: most people won't think about this issue until they
> get burned; and sash only solves half the problem (it doesn't help
> the package manager survive under adverse conditions).
Such as?
> "OK, we need recovery tools--but apt-get and dpkg are different"
As per the above, dpkg I could understand (although I'd like to see a
couple of sample failure scenarios), but snarf or similar would seem a
better choice than apt-get for statically linking.
> The current reliance on dynamic linking is not acceptable for a production
> server that is administered remotely, or where downtime is to be avoided
> at all costs.
Please cut the hyperbole. Lots of people manage this well enough already
in just such a situation. Yes, having statically linked binaries would be
nice, but -- shock! horror! -- Debian already works fairly well without
them.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
pgphpV0DXlbgn.pgp
Description: PGP signature
