All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gordon Fisher <gordfisherman@gmail.com>
To: "netfilter@vger.kernel.org" <netfilter@vger.kernel.org>
Subject: Re: Trying to provision flowtable returns error
Date: Tue, 10 Nov 2020 07:04:17 -0800	[thread overview]
Message-ID: <5FAAABF1.8060407@gmail.com> (raw)
In-Reply-To: <CANf9dFPU8e8OC5aJci-0D+awcyNpKL+tCkCZi+0TUZjQ1=p9xg@mail.gmail.com>

On 11/6/2020 7:24 AM, 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
The above could also be condensed into a single line (assuming a 
Bourne-based shell):

$ { echo 'nft flush ruleset'; nft list ruleset; } > backup.nft

Which can be useful for writing backup.nft in one go.

>      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.
-- 
gfish

  parent reply	other threads:[~2020-11-10 15:04 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
2020-11-06 19:20                             ` Martin Gignac
2020-11-10 15:04                           ` Gordon Fisher [this message]
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=5FAAABF1.8060407@gmail.com \
    --to=gordfisherman@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.