Date: Mon, 28 Jan 2002 21:19:19 -0600 From: "Thomas T. Veldhouse" <veldy@veldy.net> To: <andrew.cowan@hsd.com.au>, "Nate Williams" <nate@yogotech.com> Cc: "Freebsd-Stable" <freebsd-stable@FreeBSD.ORG> Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Message-ID: <001e01c1a873$bdf12f10$0101a8c0@cascade> References: <NEBBJIKPNGEHLCBOLMDMMEBOFPAC.andrew.cowan@hsd.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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" <andrew.cowan@hsd.com.au>
To: "Nate Williams" <nate@yogotech.com>
Cc: "Freebsd-Stable" <freebsd-stable@FreeBSD.ORG>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001e01c1a873$bdf12f10$0101a8c0>