Add $in_none and $out_none

[LionelCons]

One can currently get an empty firewall configuration (which is very useful to have full control on it) by setting a bunch of variables like $in_ssh or $out_http to false.

However, this is fragile and may break when a new version of this module adds a new variable that defaults to true.

Please add two "master variables" $in_none and $out_none that have precedence over the other $in_* and $out_* variables. Setting $out_none to true would mean "I want none of the outgoing rules" which is the same thing as setting all the $out_* variables to false.

[nbarrientos]

I personally wouldn't prioritise this much as the current interface allows skimming the firewall rules quite a lot but perhaps it makes sense to protect users against new base stuff being added (rather unlikely?). It's kind of easy to implement. I can look into providing a patch if there's an agreement.

[lelutin]

it would be more disruptive to the interface but something better might be to have two parameters that define the in and out rules as arrays.

users could override to an empty array to get the behaviour described by the OP and the API of the main class would not get cluttered with lots of different arguments for similar things.

e.g. something like this:

class nftables (
  Array[String] $in_rules => [ 'icmp', 'ssh' ],
  Array[String] $out_rules => [],
[...]
) {
  $in_rules.each |String $rule| {
    # create the rule somehow, maybe with create_resources or include
  }
[...]

[decibelhertz]

I had the same thought. EG.

  # Conditionally call pre-defined rule classes when configured
  $in_rules.each  |$i| { include "nftables::rules::${i}" }
  $out_rules.each |$o| { include "nftables::rules::out::${o}" }

Using include would mean that other includes in nftables::inet_filter would not conflict and it would generally allow for more user control.