<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 27, 2017 at 2:31 AM, Jean-Philippe Evrard <span dir="ltr"><<a href="mailto:jean-philippe@evrard.me" target="_blank">jean-philippe@evrard.me</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>For ppl who aren't iptables experts, firewalld module brings a lot of readability.<br></div><div>If we are doing the tasks equivalent with iptables, the readability will be brought in by variables (I mean variables to list ports_to_open are fairly easy to understand).</div><div><br></div><div>I am myself preferring to always use modules, and so, use the firewalld module (because it's already upstream, less tasks and therefore less error prone).</div><div>However, that would mean that we improve the module itself to grant what we need: Real ubuntu and python3 support.</div><div>Maybe it's a crusade that nobody wants to partake in, and using iptables would mean a path to least resistance, therefore easier to ship.</div><div>On top of it, if it's more a hassle to use the module due to complex rules (do we even need that?), I'd understand the move to iptables management. Is there already a role to handle this?</div></div></blockquote><div><br></div><div><br></div><div>I have been thinking about nftables for our use cases. iptables is (slowly) on its way out. firewalld does provide some abstraction from this, in that firewalld could provide an interface to translate from iptables to nftables without application changes. But, I am concerned that firewalld is not sophisticated enough to meet requirements, and I am hesitant to really invest in it if it is too simple for requirements.</div><div><br></div><div>Just some food for thought I had to offer...</div><div> </div></div>
</div></div>