From owner-freebsd-stable Mon Jan 28 19:19:34 2002 Delivered-To: freebsd-stable@freebsd.org Received: from veldy.net (veldy-host33.dsl.visi.com [209.98.200.33]) by hub.freebsd.org (Postfix) with ESMTP id 9AADF37B417 for ; Mon, 28 Jan 2002 19:19:24 -0800 (PST) Received: from cascade (cascade.veldy.net [192.168.1.1]) by veldy.net (Postfix) with SMTP id B89411A187; Mon, 28 Jan 2002 21:19:23 -0600 (CST) Message-ID: <001e01c1a873$bdf12f10$0101a8c0@cascade> From: "Thomas T. Veldhouse" To: , "Nate Williams" Cc: "Freebsd-Stable" References: Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Date: Mon, 28 Jan 2002 21:19:19 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 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 What would the expected functionality be for this? ipfw_enable=no ipfw_firewall_enable=yes And what would the expected funcationality be for this? ipfw_enable=yes ipfw_firewall_enable=no I would expect the former to not load the ipfw module, so what does the firewall enable option do? I would expect the latter to load the ipfw module and the latter to not run the firewall script. Seems to make sense, except what happens when you have IPFIREWALL built into the kernel? Tom Veldhouse veldy@veldy.net ----- Original Message ----- From: "Andrew Cowan" To: "Nate Williams" Cc: "Freebsd-Stable" Sent: Monday, January 28, 2002 9:04 PM Subject: RE: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message