From owner-freebsd-stable Mon Jan 28 19: 6:10 2002 Delivered-To: freebsd-stable@freebsd.org Received: from hsd.com.au (CPE-144-132-42-44.vic.bigpond.net.au [144.132.42.44]) by hub.freebsd.org (Postfix) with ESMTP id EF54237B419 for ; Mon, 28 Jan 2002 19:05:46 -0800 (PST) Received: from ariel by hsd.com.au with SMTP (MDaemon.v3.0.1.R) for ; Tue, 29 Jan 2002 14:04:58 +1100 Reply-To: From: "Andrew Cowan" To: "Nate Williams" Cc: "Freebsd-Stable" Subject: RE: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Date: Tue, 29 Jan 2002 14:04:57 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <15445.54755.551301.284078@caddis.yogotech.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MDaemon-Deliver-To: freebsd-stable@FreeBSD.ORG X-Return-Path: andrew.cowan@hsd.com.au X-MDRcpt-To: freebsd-stable@FreeBSD.ORG Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sorry, but: ipfw_enable=no ipfw_firewall_enable=yes Will still be confusing to newbies. I had to read the descriptions to see what they did as they should like they do the same thing. It is really to much work to change the script variable names in current, so that they relate exactly to what they do? eg. ipfw_load_firewall_rules={yes,no} ipfw_firewall_rules_file={open,simple,etc,/etc/myfirewall.rule} If ipfw_firewall_rules_file is not specified then it does not load one. (defaults to kernel setting or deny_all I think) If ipfw_load_firewall_rules is no then module is not loaded (handles ipfw not in kernel) (The ipfw_load_firewall_rules could be replaced by checking if the file is specified, but it would be too confusing again) Could old and new variables be used to handle the transition. I just don't like the idea of not fixing something that needs it. As long as it handle old configs then its fine right? To summarise: 1. Functionality of system is not changed. 2. Configuration is made consistent with functionality. 3. System is backwards compatible with old configurations via adding new variables rather than the changing of old ones. (just requires duplication of code in network script) 4. Version 5 will soon replace 4 - this is as good an opportunity as we'll ever get. The old script variables can be made defunct in 5 if you wish I appologise if parts of this have been said elsewhere, I just wanted to put my view across. Regards, Andrew Cowan > > > > : Yes, and I think having this is a good thing. However, what are the > > : default values for the variables? > > > > In previous mail I suggested: > > > > ipfw_enable=no > > ipfw_firewall_enable=yes > > Gotcha, I confused ipfw_enable with ipfw_firewall_enable. > Unfortunately, it's not obvious which one the users should use to enable > the functionality. > > Now we have two variables that *appear* to be redundant.... > > > Nate > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message