Hi David, On Tue, Jan 23, 2018 at 01:40:03PM +0100, David Fabian wrote: > Hello Pablo, > > Dne úterý 23. ledna 2018 12:07:28 CET, Pablo Neira Ayuso napsal(a): > > I'm asking here because I would need to understand better how you've > > structured your scripts, if you could explain a bit more, we would > > appreciate. > > I have packed an excerpt of a playground FW with two VLANs 3 and 54. The > configuration already uses my redefine keyword. > > ftp://ftp.bosson.eu/pub/tmp/nftables_excerpt.tar.gz Thanks for this example ruleset. > The intended use case is to call nft -f fw-on and reload the firewall from > scratch every time there is a config change. I don't know how a cmdline > parameter would help us with it. Yes, command line won't help in this case. > Maybe if we would wrap nft calls with bash scripts but that would > defeat the purpose of using the nft scripting capabilities in the > first place. No bash, we don't want more shell scripts in place, the goal is indeed to add scripting capabilities to nftables. > The most important for us is to have the FW logically structured for every > customer and every FW rule related to a customer should be in his/her VLAN > config file. Variables are bound to their scope, so the following example works fine: # cat example.nft table ip xxx { define IP1 = 1.1.1.1 } table ip yyy { define IP1 = 2.2.2.2 } Given IP1 is bound to the table definitions. In your ruleset, you're using the flat ruleset notation, ie. add rule x y ip saddr $IP1 counter drop I see another three choices, apart from your 'redefine' proposal: 1) Add some explicit scoping, so you can do this, eg. begin-scope fw-vlan1 define IP1 = 1.1.1.1 add rule filter INPUT x y ip saddr $IP1 counter drop end-scope begin-scope fw-vlan32 define IP1 = 2.2.2.2 ... add rule filter INPUT x y ip saddr $IP1 counter drop end-scope Hm, but this doesn't look very nice... 2) Probably even cleaner is to look at 'local' scopes like in bash. define local IP1 = 1.1.1.1 so the symbol is bound to this file - consider the content of a file determines a given scope. This can be also useful to the nested notation. 3) You rework your ruleset to use the notation with nesting :-). But I think 2) can be useful for both the flat and nested notation. I'm not asking you to do 2), but I would like to see how a patch that adds explicit scoping for the flat ruleset representation looks like. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
