On Mon, Jan 28, 2002 at 12:17 -0800, David Raistrick wrote:
>
> It IS confusing though.
>
> Especially when man rc.conf says:
>
>firewall_enable (bool) Set to ``NO'' if you do not want have firewall
> rules loaded at startup, or ``YES'' if you do.
>
> that sort of implies that it would dis
Nate Williams <[EMAIL PROTECTED]> types:
> > Note that "do not enable firewall" (which is implied by firewall_enable="NO")
> > is *not* equivalent to "disable firewall".
> Maybe we're having an English language question.
I'd say you are.
> If something isn't enabled, doesn't that imply that it'
On Mon, Jan 28, 2002 at 12:53:42PM -0700, Nate Williams wrote:
> > Note that "do not enable firewall" (which is implied by firewall_enable="NO")
> > is *not* equivalent to "disable firewall".
>
> Maybe we're having an English language question.
>
> If something isn't enabled, doesn't that imply
> : If I enable the clutch in my car, my car moves (assuming it's in gear).
> : If I disable it, the power is no longer going to the drive wheels.
>
> That's not quite right, but it is a good analogy. If you disable your
> clutch, then you are going to have to shift without it and deal with
> pu
On Mon, 28 Jan 2002, Nate Williams wrote:
> > Note that "do not enable firewall" (which is implied by firewall_enable="NO")
> > is *not* equivalent to "disable firewall".
>
> Maybe we're having an English language question.
>
> If something isn't enabled, doesn't that imply that it's disabled?
In message: <[EMAIL PROTECTED]>
Nate Williams <[EMAIL PROTECTED]> writes:
: If I enable the clutch in my car, my car moves (assuming it's in gear).
: If I disable it, the power is no longer going to the drive wheels.
That's not quite right, but it is a good analogy. If you disable yo
> Note that "do not enable firewall" (which is implied by firewall_enable="NO")
> is *not* equivalent to "disable firewall".
Maybe we're having an English language question.
If something isn't enabled, doesn't that imply that it's disabled? Last
I checked, enabled/disabled were binary operatio
Michael Sierchio wrote:
>
> Nate Williams wrote:
> >
> > > > See above. It can easily be done in a more standard way. (One can
> > > > argue that the '-z' should be the default flag, but so far I've failed
> > > > to convince Warner of this fact. :) :)
> > >
> > > Forgive me if I'm mistaken, bu
> > > > See above. It can easily be done in a more standard way. (One can
> > > > argue that the '-z' should be the default flag, but so far I've failed
> > > > to convince Warner of this fact. :) :)
> > >
> > > Forgive me if I'm mistaken, but the pccard_ether script (when last I
> > > looked at
Nate Williams wrote:
>
> > > See above. It can easily be done in a more standard way. (One can
> > > argue that the '-z' should be the default flag, but so far I've failed
> > > to convince Warner of this fact. :) :)
> >
> > Forgive me if I'm mistaken, but the pccard_ether script (when last I
>
> > See above. It can easily be done in a more standard way. (One can
> > argue that the '-z' should be the default flag, but so far I've failed
> > to convince Warner of this fact. :) :)
>
> Forgive me if I'm mistaken, but the pccard_ether script (when last I
> looked at it) seems to assume ex
I have to go along with common sense and logic with this one. I was once
burnt by it about 2 years ago. I compiled it in and set it to NO in
.rc and nothing going thru. Strange, NO means no right?, it is a control knob
to the kernel so NO must disable it right?. And disabled means the same
as not
On Sun, Jan 27, 2002 at 10:27:48AM -0700, M. Warner Losh wrote:
[snip]
> Right now what I have works. You are changing the semantics of a
> security related feature of the system in such a way that after this
> change what I have will not work. I agree that your work around will
> allow me to e
Gerhard Sittig <[EMAIL PROTECTED]> types:
> On Sun, Jan 27, 2002 at 11:57 -0600, David Syphers wrote:
> > [ ... surprise ... ] As others have pointed out this behavior is
> > documented, but we must remember that a variable name itself is the most
> > important and immediate documentation. And
In message: <[EMAIL PROTECTED]>
"Crist J. Clark" <[EMAIL PROTECTED]> writes:
: Warner, if the proposed change were to be made, you could get the same
: effect by doing,
:
: firewall_enable="YES"
: firewall_script="/dev/null"
:
: Which I think more accurately describes the behavio
Warner, if the proposed change were to be made, you could get the same
effect by doing,
firewall_enable="YES"
firewall_script="/dev/null"
Which I think more accurately describes the behavior you want (if
someone were to browse the rc.conf and try to understand your
configuration, they'd be m
In message: <[EMAIL PROTECTED]>
Nate Williams <[EMAIL PROTECTED]> writes:
: > You still haven't responded to my comment that I have it setup like
: > this on some of my boxes so that I can do things that don't fit in
: > well with the current firewall paradigm. Nor to my comment that
> You still haven't responded to my comment that I have it setup like
> this on some of my boxes so that I can do things that don't fit in
> well with the current firewall paradigm. Nor to my comment that we
> shouldn't be changing a security feature in a fail*UN*safe way.
Explain to me how disa
On Fri, 25 Jan 2002, Bob K wrote:
> > I could be mistaken, but it would seem to me that the number of
> > individuals that really want to deny all traffic to and from their
> > machine(which is the current result of setting firewall_enable to no)
> > is relatively small.
>
> If the variable name
On Fri, 25 Jan 2002, Mike Meyer wrote:
> Patrick Greenwell <[EMAIL PROTECTED]> types:
> > On Fri, 25 Jan 2002, Bob K wrote:
> > > The problem is that you're not taking into account the installed base of
> > > users who twiddle this knob. How many angry firewall admins will come
> > > into being
Patrick Greenwell <[EMAIL PROTECTED]> types:
> On Fri, 25 Jan 2002, Bob K wrote:
> > The problem is that you're not taking into account the installed base of
> > users who twiddle this knob. How many angry firewall admins will come
> > into being when the behaviour suddenly stops being, "don't lo
On Fri, Jan 25, 2002 at 05:40:04PM -0800, Patrick Greenwell wrote:
>
> > The problem is that you're not taking into account the installed base of
> > users who twiddle this knob. How many angry firewall admins will come
> > into being when the behaviour suddenly stops being, "don't load any
> >
On Fri, 25 Jan 2002, Bob K wrote:
> The problem is that you're not taking into account the installed base of
> users who twiddle this knob. How many angry firewall admins will come
> into being when the behaviour suddenly stops being, "don't load any
> firewall rules" and starts being, "disable
On Fri, Jan 25, 2002 at 05:05:48PM -0800, Patrick Greenwell wrote:
>
> You know, I continue to be amazed at the attitude that says that things
> should be kept counter-intuitive and anyone who doesn't like it that way
> is ignorant. What possible benefit is there in perpetuating mislabeled
> beha
On Fri, 25 Jan 2002, Thomas T. Veldhouse wrote:
> > > It only works the way
> > > complained about when you build your own custom kernel with IPFIREWALL
> and
> > > not with IPFIREWALL_DEFAULT_TO_ACCEPT. At that point, I think the admin
> > > needs to educate one self. I prefer to leave it as i
building a firewall.
I still believe the current knobs in rc.conf work just fine and I don't
believe they should be changed at all as they pertain to this discussion.
Tom Veldhouse
[EMAIL PROTECTED]
>
> > - Original Message -
> > From: "Crist J. Clark" <[
load an "open" rule
set, before I could flip 'net.inet.ip.fw.enable' off.)
> - Original Message -
> From: "Crist J. Clark" <[EMAIL PROTECTED]>
> To: "Patrick Greenwell" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent:
27 matches
Mail list logo
