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.
