Things to remove from /rescue

[Mike Makonnen]

> So let me restate DES case without examples.
> 
> It may be that someone wishing to recover a hosed box will both
> 
> a) want access to some network-hosted resource, and

>From what I can see the only network resource one could access is an 
nfs mount, since it seems unlikely you could rely on anything
outside /rescue (such as ftp or ssh) being available.

> b) want to maintain network security while accessing that resource.

What security? There are no network services running in single-user,
so what is there to secure?

> 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 for it.
>
> And remember, this is just one aspect of your "trimming down /rescue".
> Nobody's insisting that we keep the bath water. :-)

I won't complain if it's kept, but I would prefer just the bare minimum
be kept in /rescue. Once you go beyond that and into "well s/he might
need..." territory then we might as well throw in everything in the
base system. IMO, /rescue should be the absolute essentials _only_.
Instead of theorizing reasons why someone might need ipfw and friends,
why don't we wait until we get a bug report about a specific situation
in which it was needed before we put it back in.

Also, while you're at it, David, I think you can get rid of rcorder
as well.  I don't know why one would need it to fix a hosed root,
and besides it's staticaly linked to begin with.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm at identd.net | D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9
mtm at FreeBSD.Org| FreeBSD - Unleash the Daemon!