From: allen <aef@prismnet.com>
To: Stephane Ouellette <ouellettes@videotron.ca>,
netfilter-devel@lists.netfilter.org
Subject: Re: [NEW EXTENSION] Condition Match
Date: Fri, 1 Nov 2002 18:41:37 -0600 [thread overview]
Message-ID: <200211011841.37869.aef@prismnet.com> (raw)
In-Reply-To: <3DC1DE3F.7040404@videotron.ca>
On Thursday 31 October 2002 07:51 pm, Stephane Ouellette wrote:
> --- Harald Welte <laforge@gnumonks.org> wrote:
( snip )
> >> Where is the problem in having a couple of different rulesets (e.g.
> >> created with iptables-save) which are then loaded using an
> >> iptables-restore commandline or a script at the shell of the firewall?
>
> Harald,
>
> I have already tried the solution you propose on a production
> environment and it proved difficult to deal with. Using the condition
> match, it is far faster to enable/disable rule sets than it is with a
> set of scripts. It is also less error-prone on a management point of
> view as the firewall rules never change.
>
> I would suggest that the condition match makes it to P-O-M, and let the
> users try it.
Yeah.
After thinking more about it, yeah. It IS cool.
Note:
1. Already many things are adjusted via /proc mechanism
that are similar in that they are related to networking
parameters that need to be modified on the fly.
2. Making a modification to netfilter rules by dumping
and loading new rules is not cool and is prone
to error "during the switch".
This method is only straightforward, but actually
more complex in operation. ( The administrator
has to think more )
3. The other thing would be a libipq thing, and there
can be only one. And it is in userspace and
it can die.
I think the /proc concept in this case is better than
the load/modify/delete/add kind of concept.
I'm having a hard time thinking of a better "thing"
than /proc.
It seems like the next best alternative is yet again
some "new thing" that doesn't exist yet.
What new thing would be better than /proc ?
Who would "buy" something new ? so to speak...
For what it is worth, I second the motion here.
-AEF
next prev parent reply other threads:[~2002-11-02 0:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-01 1:51 [NEW EXTENSION] Condition Match Stephane Ouellette
2002-11-02 0:41 ` allen [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-10-29 18:54 Stephane Ouellette
2002-10-29 23:00 ` Brad Chapman
2002-10-30 2:52 ` Robin Johnson
2002-10-30 4:43 ` allen
2002-10-30 9:04 ` Harald Welte
2002-10-30 10:34 ` Peter Surda
2002-10-30 11:59 ` Brad Chapman
2002-11-01 1:34 ` Stephane Ouellette
2002-11-02 14:47 ` Harald Welte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200211011841.37869.aef@prismnet.com \
--to=aef@prismnet.com \
--cc=netfilter-devel@lists.netfilter.org \
--cc=ouellettes@videotron.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.