Re: how to make Debian less fragile (long and philosophical)
Isn't it easier in the local case to just install sash? Then no matter
what happens, as long as you have a kernel and a filesystem, just add
init=/bin/sash to the kernel command line (eg, LILO:), and you have a
working shell, along with most common system utilities (ls, cp, ed, gzip,
tar, and a few dozen others). You also need ar to install .deb's, but
most anything else you need is in there. You might also want to check
the archives for the debate about creating a rescue package that went on
in debian-devel a week or so ago.
Making it work remotely is harder, but all it really needs is a static
ssh, maybe /sbin/login (doubt it), and root's login shell set to sash.
On Sun, Aug 15, 1999 at 01:42:08AM -0400, Justin Wells wrote:
>
> I think the recent problem with bash and libreadline are symptoms of
> a deeper problem with the way the Debian distribution is organized.
>
> Essentially, it's this:
>
> -- Core system management tools, including the package manager suites
> and anything they depend on (therefore, including /bin/sh)
> should be availble on / as statically linked binaries. Dynamic
> versions of these same programs may be available elswhere for
> normal use, but should not be used by core system management tools.
>
> Here is my reasoning, followed by some discussion of it:
>
> 1. During system failure the system administrator should have
> access to the basic tools necessary for system repair. Since
> the system is damaged, it is unreasonable to assume that /usr
> has been mounted, and it is unreasonable to assume that the
> link loader is working or that the C library is intact.
>
> 2. The static binaries should be available on /, since that is
> guaranteed to be present if the system can boot at all. And
> in particular, static binaries should not be available only
> on floppy as the administrator may be working from remote.
>
> 3. The package manager should not depend on anything it is
> operating on. If it does, you always face the risk of the
> package manger destroying its own ability to function.
> Instead, upgrading the package manager itself should be
> viewed as a bootstrapping problem: there are a variety
> of solutions--installing into a different directory,
> clever use of symlinks, etc.
>
> 4. The core system tools should be subject to more extensive QA
> testing than anything else. This is difficult when there are
> dynamic dependencies since any change to any dynamic library
> would require a new round of testing. With static binaries, you
> only need to retest extensively when the binary itself changes.
>
> 5. There is no performance issue here, since the package manager
> is not a heavily used tool. There will generally be only
> one copy of it running, and it will probably not be run
> more than once or twice a day. Dynamic linking is fundamentally
> an optimization, and optimizations are wrong when they
> increae complexity and reduce reliability without providing
> any actual performance benefit.
>
> Having the package manager depend on statically linked binaries only
> would have avoided the recent bash/libreadline catastrophe, which
> utterly ruins the system of anyone attempting an upgrade from
> slink to potato (bash and the C library get removed and not
> re-installed, leading to a level of failure where not even apt-get
> works.)
>
> If apt-get were statically linked, it could in theory be used
> to repair the damage. If bash were statically linked, it would
> not have depended on libreadline in the first place. Also, if
> bash were statically linked there would have been a root shell
> available for single-user mode operation, and enough other tools
> around that the system administrator could have fixed the problem
> without rebooting (or needing to be physically present at the
> machine to insert a rescue floppy).
>
> I am not suggesting that the bash people normally use should be
> statically linked. I am suggesting that a statically linked version
> be available. Perhaps /bin/bash is statically linked, but there
> exist a /usr/bin/bash that is dynamic (and potentially more up to
> date but less well debugged).
>
> This approach is essentially what is done in many other OS's, and
> I think we should learn from 30 years of Unix experience and do
> something similar.
>
> For example, FreeBSD has a set of statically linked tools in /stand,
> including its package manager. It goes even further, and everything
> in /bin is actually statically linked--on the theory that you might
> have / mounted but not /usr. FreeBSD provides a dynamically linked
> bash in its /usr/local directory (don't ask why it's /usr/local
> instead of somewhere else--a FreeBSD oddity that Debian avoided).
>
> Whether Debian should go as far as making everything in /bin static
> I don't know--that would be a substantial change, though it would
> have some benefits. However, perhaps not enough benefits to warrant
> the change, and there would be a few drawbacks too (binaries in /bin
> get used more frequently, possibly in situations where performance
> is a real issue.)
>
> It's clear that the current reliance on dynamic binaries for basic
> level system maintenance is dangerous, and makes the Debian OS
> fragile and unreliable. (Evidence: my slink system hosed itself
> when I tried to upgrade it to potato, leaving it utterly unusable
> without even a shell for single user mode, or a working C library).
>
> I would like Debian to be the most stable, most reliable Unix, with
> the smallest cost of ownership. In order to achieve that, this kind
> of fragility must be exorcised from the distribution.
>
> Does anyone here take this seriously?
>
> Or is stability, reliability, and therefore cost-of-ownership a
> non-issue with the Debian group?
>
> Justin Wells
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: