Things to remove from /rescue

John Baldwin jhb at FreeBSD.org
Wed Jul 23 10:56:36 PDT 2003


On 23-Jul-2003 Mike Makonnen wrote:
> On Tue, Jul 22, 2003 at 08:50:06PM -0700, Steve Kargl wrote:
>> 
>> Don't you need a network connection to use /rescue/rrestore to access
>> the dump of / on a tape drive in a remote system?  One may want a
>> secure connection to that remote system.
> 
> ahh yes, I also missed rcp. But, that doesn't change the situation
> much. Ipfw is a firewall. I don't see how it can have a useful
> impact on security in this situation. The point I was trying to
> make in the email is that there isn't much security that ipfw
> can offer you in this situation that is a compelling or even
> "must have" feature of rescue. Like I said, I don't object to
> having it in /rescue if that's the consensus, but I would much
> prefer if we left it out and see if any bug reports come in.
> There is nothing preventing us from including it in the future
> if it is really needed by our users.

If you prefer to be sitting at a machine's single user prompt
one day, going "dang, if only rescue had <foo> I wouldn't be
totally screwed, and gee, it only cost 5k in disk space as well"
rather than resurrecting a dead machine during that time, then
I find that rather odd.  Didn't the original rescue list come
from NetBSD in the first place where it has already gone through
one round of revisions?  Or do you all just think that NetBSD's
rescue is poorly designed and bloated so you need to one-up them
for some reason?  Maybe NetBSD has ipfw in their rescue because,
gee, they've gotten a bug report on it?  I wouldn't be so quick
to discount the experience put into software that we nab from
other places.  I also think that there should be some actual size
numbers of what we gain by trimming /rescue should be done prior
to commit.  It can only help to have added functionality for some
corner case if it only adds a couple of kb in size.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


More information about the freebsd-arch mailing list