Things to remove from /rescue

[Adam C. Migus]

Alexey Neyman said:
> Hi, there!
>
> On Tuesday 22 July 2003 19:30, Sheldon Hearn wrote:
>> I don't see this as an unreasonable requirement, and I can't see
>> what
>> great cost it incurs that would motivate us to remove support
foraccommodate
>> it.
>environments
> Can't all this be done in a "user needs it, user adds it" fashion?
> E.g., to
> add /etc/rescue.mk that will be .include'd in
> src/rescue/rescue/Makefile,compromise
> adding the required binaries to the CRUNCH_PROGS_bin,
> CRUNCH_PROG_sbin,
> CRUNCH_LIBS lists?
>
> E.g:
> --- /etc/rescue.mk ---
> CRUNCH_PROGS_sbin += chown
>
> This will allow the "base" list to be trimmed to some minimalist
> level, and
> will still allow the users to add whatever they [think they] need to
> restore
> their system.
>
> Regards,
> Alexey.
>
> --
> A quoi ca sert d'etre sur la terre
> Si c'est pour faire nos vies a genoux?
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to
> "freebsd-arch-unsubscribe at freebsd.org"
>

At the risk of throwing lighter fluid on smoldering ashes, some
thoughts:

The whole change to dynamic linking for / is a move to "modernize"
FreeBSD.  Thus /rescue is a "modern" attempt at creating a /stand. 
If we're going to be "modern" we ought to think about what "modern"
sysadmins need to "rescue" their systems.

Administrators as well as operating systems have gotten more
"modern" over time.  The days of fixing a system with 5 binaries and
a not so portable tape drive are gone for some and not even known
for others.  The tools in /rescue need to accomadate the
administrators of today.  If they don't, those administrators will
find an operating system they can fix more easily.

/rescue to me implies "what's needed to rescue you're hosed FreeBSD
system."  Given FreeBSD system could be a file server, a web server,
a firewall, a router or a VCR one could even say to rescue the
network.  Moreover, these systems could be deployed in a variety of
different locations and enviornments.  The set of tools required to
fix each of these systems and keep them safe while doing so, can be
quite different.

Finally, this argument essentially comes down to space savings vs.
ability to rescue the system.  Is 100K of disk space worth 2 hours
of time due to a missing tool?  One must be very cautious about
removing a tool more so than adding it.  On the other hand I have to
wonder about /rescue/wall...  :-)

Given these thoughts and some reflection on the previous posts I
have a comprimise building on the idea above.

Why not make the set of tools in /rescue easily configurable and
divide them into three sets:

1. Those that are in the crunch and linked in /rescue,
2. Those that are in the crunch but aren't linked in /rescue, and
3. Those that aren't yet in the crunch.

The first being tools everyone agrees are valuable, the second being
tools that at least one person thinks might be useful (not in excess
of what's there now), the last being tools everyone can agree are
useless (and thus aren't there now).

That way if an administrator complains about a missing tool someone
said might be useful, the answer is "just create a link."  If no one
thought of it, it's a PR, a headache for the administrator and a
lesson learned.

In either case the number of complaints for the tool can drive a
review process for inclusion in the next release.

--
Adam - (http://people.migus.org/~amigus/)
Migus Dot Org - (http://www.migus.org/)