From owner-freebsd-stable Mon Jan 28 20:18:22 2002 Delivered-To: freebsd-stable@freebsd.org Received: from voi.aagh.net (pc1-hart4-0-cust168.mid.cable.ntl.com [62.254.84.168]) by hub.freebsd.org (Postfix) with ESMTP id BA8B437B402 for ; Mon, 28 Jan 2002 20:18:13 -0800 (PST) Received: from freaky by voi.aagh.net with local (Exim 3.34 #1) id 16VPid-000IRp-00; Tue, 29 Jan 2002 04:18:03 +0000 Date: Tue, 29 Jan 2002 04:18:03 +0000 From: Thomas Hurst To: Andrew Cowan Cc: Nate Williams , Freebsd-Stable Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Message-ID: <20020129041803.GA69785@voi.aagh.net> Mail-Followup-To: Andrew Cowan , Nate Williams , Freebsd-Stable References: <15445.54755.551301.284078@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Organization: Not much. X-Operating-System: FreeBSD/4.5-PRERELEASE (i386) X-Uptime: 3:23AM up 39 days, 12:08, 4 users, load averages: 2.11, 2.04, 2.01 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 * Andrew Cowan (andrew.cowan@hsd.com.au) wrote: > 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} The -stable firewalls are scripts, not rule files. Rule files are a different thing again :) > If ipfw_firewall_rules_file is not specified then it does not load > one. (defaults to kernel setting or deny_all I think) Except ipfw_firewall_rules_file=open specifies a firewall *type*, not a file. > 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) We have a lot of different things being piled into these variables. We've got: * Disabled * Default rule names (open, simple, closed, ..) * Rule files * Firewall scripts These are currently handled like this: firewall_enable={yes, no} firewall_type={open, simple, closed .., /some/rule/file} firewall_script={/etc/rc.firewall, /some/firewall/script} I think it's fairly plain to see these are rather ugly, even without going into a discussion about what enabled actually means. How about something more along the lines of: ipfw_enable = {yes, no} ipfw_type = {script, rule, builtin} ipfw_rule = {/path/to/rule/file} ipfw_script = {/path/to/script} ipfw_builtin = {open, closed, simple, client} You could merge ipfw_enable with ipfw_type, but then you loose the generic YES/NO and the entire _enable looses it's meaning, which is customary throughout rc.conf. Aren't we reworking the rc system in -CURRENT anyway? This looks like something to start playing with there. > 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? Frankly, I think we need to concentrate on making all these changes to -CURRENT; that's a big enough version difference to fix things *properly* without worrying about breaking Joe User's -STABLE config. > 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) The way builtin firewalls are handled atm means people need to edit rc.firewall themselves to configure them.. I'd be careful about making major changes that might not merge very easily. CURRENT, of course, should pork away and move the individual scripts to /etc/ipfw/