Date: Tue, 29 Jan 2002 04:18:03 +0000 From: Thomas Hurst <tom.hurst@clara.net> To: Andrew Cowan <andrew.cowan@hsd.com.au> Cc: Nate Williams <nate@yogotech.com>, Freebsd-Stable <freebsd-stable@FreeBSD.ORG> Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Message-ID: <20020129041803.GA69785@voi.aagh.net> In-Reply-To: <NEBBJIKPNGEHLCBOLMDMMEBOFPAC.andrew.cowan@hsd.com.au> References: <15445.54755.551301.284078@caddis.yogotech.com> <NEBBJIKPNGEHLCBOLMDMMEBOFPAC.andrew.cowan@hsd.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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/<script>
or so, of course :)
Making something like that a standard location for firewall scripts
would be nice imo.. better, at least, than just making the user pick
some random location.
> 4. Version 5 will soon replace 4 - this is as good an
> opportunity as we'll ever get.
Until version 6, of course :)
> I appologise if parts of this have been said elsewhere, I just wanted
> to put my view across.
This thread's rather annoyingly long, and having read most of it I can
say that most useful stuff was said near the latter end :)
--
Thomas 'Freaky' Hurst - freaky@aagh.net - http://www.aagh.net/
-
Out of the crooked timber of humanity no straight thing can ever be made.
-- Immanuel Kant
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020129041803.GA69785>