Ferm DSL is nice and featureful. There's a pretty sophisticated debops ferm role at [1] allowing for pretty sophisticated rule definitions [2]. Structurally I think the most important thing is having the ability to define rules in layers based on host_vars, group_vars, etc. and have them blended together by the firewall role using a weighting system. You can get really fancy with the rules definitions as shown by the rules.d template in debops-ferm [3].
My question now is what does ferm give us that iptables-save templating does not? Writing ferm configuration can differ pretty substantially from iptables-save syntax, and we add another language dependency (perl) in the process. I think for ferm to make sense, we should be able to argue pretty convincingly that there's some major advantages over laying down a consolidated templated iptables-save file. IMO we can have all of the same sophistication this way and expose it in a very nice interface through ansible vars. [1] https://github.com/debops/ansible-ferm [2] https://docs.debops.org/en/latest/ansible/roles/ansible-ferm/docs/ [3] https://github.com/debops/ansible-ferm/tree/master/templates/etc/ferm On Wed, Aug 2, 2017 at 3:47 PM, Major Hayden <ma...@mhtx.net> wrote: > On 08/02/2017 03:57 AM, Mark Goddard wrote: >> The solution we built used a conf.d/ mechanism layered on top of iptables. >> An advantage of this approach is that operators or co-resident software >> stacks could add their own rules to the firewall. AFAIK, this is not >> generally possible when using iptables-save/restore as it relies on a single >> configuration file which must be 'owned' by something - in this case >> presumably OSA. >> >> I'm not suggesting that you reimplement the solution I've described, but it >> does outline one benefit of firewalld - OSA would not need to entirely own >> the firewall configuration. > > Thanks for the feedback! I'm leaning away from firewalld now and looking at > something a little simpler with iptables. > > During a recent IRC meeting someone brought up ferm[0]. They have several > examples, but the workstation[1] one makes some sense. It would be fairly > easy to template the ferm DSL files. > > [0] http://ferm.foo-projects.org/ > [1] http://ferm.foo-projects.org/download/examples/webserver.ferm > > -- > Major Hayden > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev