Expanding the iptables module

[Fizzadar]

The current module provides a basic iptables.nat implementation (thank you @hoh!). Iptables is a massive and complex beast, and I don't think the module will ever cover every use case (complicated iptables setups are best left as scripts, IMO) - but the module can certainly cover the basics.

Facts:

• Add iptables.chain and iptables_chains fact to control chains and their policies
• Rename iptables fact to iptables_rules to fit with above
  • make it handle rules containing ! and single args like --syn
• Add type=4 kwarg to both

Modules:

• Rename iptables.nat -> iptables.rule to handle any rules on any table
  • has a type=4 kwarg to switch between iptables & ip6tables
  • default table='filter'
  • default append=True
  • no other defaults
• Add a iptables.chain(name, present=True, policy='ACCEPT')
• Possibly: iptables.nat, iptables.filter, iptables.raw, iptables.mangle & iptables.security shortcuts for more readable operations, all just pass to iptables.rule w/ table set?

[Fizzadar]

Majority of this is implemented @ https://github.com/Fizzadar/pyinfra/commit/ba793f934d7f2770c1618ba3417aba7cc9f989a7

Leave open for tests/any final tweaks before release.

[hoh]

Good to see. Shortcuts for specific use cases would definitely be appreciated by users.

[Fizzadar]

@hoh I'm a bit wary of adding specific use case shortcuts - the issue I foresee is that there are so many different use cases/arg-combinations which make it hard (beyond simple table shortcuts) to build more extensive shortcuts.

Perhaps something like:

def nat(type=[destination, source, port], target, **rule_kwargs)

Where type defines DNAT, SNAT or REDIRECT for the jump and target specifies the relevant --to-destination, --to-source or --to-ports?

Similarly there could be a logging shortcut:

def log(log_prefix, **rule_kwargs)

That sets jump=LOG and so on.

[hoh]

@Fizzadar an alternative would be to put that "sugar" in other packages, for example pip install pyinfra-easytable...

[Fizzadar]

@hoh I really like that idea, which leaves the pyinfra state management "clean" :) I'll close this issue now then.