From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Martin Gignac <martin.gignac@gmail.com>
Cc: Florian Westphal <fw@strlen.de>, netfilter@vger.kernel.org
Subject: Re: Trying to provision flowtable returns error
Date: Fri, 6 Nov 2020 17:21:47 +0100 [thread overview]
Message-ID: <20201106162147.GA3647@salvia> (raw)
In-Reply-To: <CANf9dFPU8e8OC5aJci-0D+awcyNpKL+tCkCZi+0TUZjQ1=p9xg@mail.gmail.com>
On Fri, Nov 06, 2020 at 10:24:35AM -0500, Martin Gignac wrote:
> I think I just answered my previous question:
>
> > Does prepending the "more destructive" 'flush ruleset' statement at
> > the very beginning of the 'firewall.nft' file still honor the
> > "atomicity" guarantee of running 'nft -f' again this file, or is this
> > guarantee only honored when prepending 'flush table' statements? In
> > other words, is there a minute period after running 'flush ruleset' in
> > my file where the node is unprotected?
>
> According to https://wiki.nftables.org/wiki-nftables/index.php/Operations_at_ruleset_level:
>
> BACKUP/RESTORE
>
> You can combine these two commands above to backup your ruleset:
>
> % echo "nft flush ruleset" > backup.nft
> % nft list ruleset >> backup.nft
>
> And load it atomically:
>
> % nft -f backup.nft
>
> I interpret this to mean that my original method of doing things is as
> atomic as using 'flush table <tablename>', even if it is more
> destructive. I guess going forward I will have to make sure to prepend
> 'flush table' statements for every individual table I refer to in my
> 'firewall.nft' file.
It is not "flush ruleset" that makes things atomic, this is just an
operation to tear down everything.
You achieve atomic ruleset updates by using `nft -f'.
Sorry, I'm getting a bit lost regarding what the problem is at this
stage regarding the flowtable infrastructure.
next prev parent reply other threads:[~2020-11-06 16:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-16 10:37 nftables iifname and currently unknown interfaces Robert Sander
2020-10-16 10:54 ` Pablo Neira Ayuso
2020-10-16 10:56 ` Florian Westphal
2020-10-16 11:10 ` Robert Sander
2020-10-28 22:25 ` Pablo Neira Ayuso
2020-11-04 5:30 ` Trying to provision flowtable returns error Martin Gignac
2020-11-05 0:53 ` Duncan Roe
2020-11-05 15:17 ` Martin Gignac
2020-11-05 15:38 ` Florian Westphal
2020-11-05 16:20 ` Martin Gignac
2020-11-05 17:07 ` Florian Westphal
2020-11-05 18:21 ` Martin Gignac
2020-11-05 18:41 ` Martin Gignac
2020-11-05 21:01 ` Pablo Neira Ayuso
2020-11-05 21:45 ` Martin Gignac
2020-11-06 10:58 ` Pablo Neira Ayuso
2020-11-06 15:13 ` Martin Gignac
2020-11-06 15:24 ` Martin Gignac
2020-11-06 16:21 ` Pablo Neira Ayuso [this message]
2020-11-06 19:20 ` Martin Gignac
2020-11-10 15:04 ` Gordon Fisher
2020-11-06 17:18 ` Pablo Neira Ayuso
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=20201106162147.GA3647@salvia \
--to=pablo@netfilter.org \
--cc=fw@strlen.de \
--cc=martin.gignac@gmail.com \
--cc=netfilter@vger.kernel.org \
/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.