There are too many ways of maintaining a firewall, across all types of
admins, OS, etc.
However, I make use of a firewall role, I set ports when I attach it to
a host, and then, I made an executive decision that the 'app' I'm
configuring will use a particular type of firewall software.
However, I still allow for some variant across at least debian and
redhat; I use a when: in my role, and key off ansible_pkg_mgr(== 'yum'
or 'apt').
I really don't think it would be possible to have a completely generic
'firewall' module that handles all cases.
On 03/04/2014 10:51 AM, Aaron Hunter wrote:
Plus, the aforementioned groups that want to maintain their own
firewall configurations, which we suggest, and you can see an
example of here:
https://github.com/ansible/ansible-examples/blob/master/lamp_haproxy/roles/common/templates/iptables.j2
<https://github.com/ansible/ansible-examples/blob/master/lamp_haproxy/roles/common/templates/iptables.j2>
I disagree with the approach taken in this link because I do not
want to use the persistence file (ferm or ufw are much better) and
because I don't think their use of if/then is good design (see
http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html).
But this isn't really important.
I think the ferm approach used here is the best approach:
http://wiki.gema-soft.de/doku.php?id=it-administration:tools:ansible:ferm
Having each role add its own ferm snippet maintains encapsulation (no
hard to maintain if/then blocks) and uses a proper firewall management
tool. The problem is that since there is no global notification there is
no way to signal to Ansible to run the handler at the end. That is why I
asked about a module.
A chinstrap role that James mentions could work but it has no way of
knowing that a change has taken place (ie., a new snippet was added,
changed, or removed). At least none that I know of. The alternative is
simply to make the chinstrap role at the end always fire which would
work but you then lose idempotency.
A global notify would enable this. This is at least one case where it is
needed. There are probably more cases in which a final run cleanup step
could be useful. In fact, global handlers would have come in useful many
times in my experience.
--
You received this message because you are subscribed to the Google
Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/15300865-3d24-4675-a270-92a24baaa49c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Ansible
Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/53160699.8010603%40brainfood.com.
For more options, visit https://groups.google.com/groups/opt_out.
