From owner-freebsd-arch@FreeBSD.ORG Wed Jul 23 10:56:35 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1CA037B405 for ; Wed, 23 Jul 2003 10:56:35 -0700 (PDT) Received: from mail.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC0DC43F3F for ; Wed, 23 Jul 2003 10:56:34 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 25027 invoked from network); 23 Jul 2003 17:56:34 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 23 Jul 2003 17:56:34 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h6NHuWGI046305; Wed, 23 Jul 2003 13:56:32 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030723043410.GA45652@kokeb.ambesa.net> Date: Wed, 23 Jul 2003 13:56:49 -0400 (EDT) From: John Baldwin To: Mike Makonnen cc: Steve Kargl cc: freebsd-arch@freebsd.org Subject: Re: Things to remove from /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2003 17:56:36 -0000 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 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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/