Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Jan 2002 14:08:57 -0700
From:      Nate Williams <nate@yogotech.com>
To:        "M. Warner Losh" <imp@village.org>
Cc:        cjm2@earthling.net, stable@FreeBSD.ORG, n@nectar.cc
Subject:   Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read]
Message-ID:  <15445.48617.802871.870971@caddis.yogotech.com>
In-Reply-To: <20020128.135120.11184725.imp@village.org>
References:  <20020128192930.GA86720@student.uu.se> <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> <20020128.135120.11184725.imp@village.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> How about renaming things a little more:
> 
> 	ipfw_load_rules={yes,no}
> 	ipfw_disable_firewall={yes,no}
> 	ipfw_kldload={yes,no}

I don't mind the first two, but I dislike the third for the following
reasons.

1) We are moving (slowly) to a kernel where things are loaded
  'automagically'.  In other words, the user shouldn't have to
  explicitly load a module if it's being used.  (All of the network
  adapters are moving in this direction.)

2) If possible (I've not analyzed this), it would be nice that if the
   firewall is 'enabled' (second variable), the script would determine
   *IF* the firewall module is in the kernel or not (like is done with
   the current network adapter modules), and if not, load it.

This obviates the need for the third rule.  That being said, I'd argue
for a rename of rule 2 to 'ipfw_enable_firewall', which when set to
'YES', loads the firewall capability (if necessary) and ensures that
it's sysctl is set correctly.  If set to NO, simply disables the sysctl
if it exists (no need to unload the module in the startup scripts, IMO).

The default behavior of the firewall would be related to how it was
configured statically in the kernel, or how the module was created.

No more confusion.  (Also, another reason for 'enable' vs. 'disable' is
it's more connsistent with the other variables we are using in the
rc.conf file.)



Nate

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?15445.48617.802871.870971>