I just wanted to expand on what Michael was saying about using assemble: For each role have a template snippet of firewall configuration and push it into /etc/iptables/snippets. Then in a final role that gets added after all other roles (call it a chinstrap role), use the assemble module to merge all the iptables snippets into a single iptables file and use a notify to restart iptables when the assembled file has changed.
- James On Tue, Mar 4, 2014 at 9:47 AM, Aaron Hunter <[email protected]>wrote: > > > On Tuesday, March 4, 2014 8:02:01 AM UTC-5, Michael DeHaan wrote: >> >> There's already a module for firewalld. >> >> Some folks, like the Fedora setup playbooks, use lokkit in their plays. >> > > I'm talking about production systems not Fedora. > > >> >> For complex installs, I still highly recommend writing a template for >> your iptables file (etc) and basing that on the group membership of your >> hosts, which is easy to do and appropriate. >> >> Drilling holes in your firewall doesn't really account for the "chained" >> nature of firewall rules and is a bit basic, and not always appropriate, >> nor does it model all they can do. >> > I don't know what kind of template you are referring to. iptables does not > have a conf file. It has its own persistence format but that is not the > same thing. > > >> Further, making the explicit choice about what you are letting through is >> important -- rather than letting some roles you downloaded from the >> internet decide. >> > I didn't reference "some roles you download from the Internet" I > referenced Ansible Galaxy. A proper role will provide sensible defaults > (like UDP 67,68 for DHCP) and allow the ports to be configured through > local variables. That is how all good roles should work. > > Yes, it takes an extra minute or two here or there -- but I think >> constructing your firewall rules via template is still worthwhile, and will >> make sure you are using the features you need to be using. >> >> Then it's just a "notify: restart iptables" away, and so forth. >> > > It isn't that simple nor does Ansible handle this case. The rule chains > are additive across roles and order is important. > The basic process is: > - Base role: Setup firewall and insert base rules > - Role1 : add rules > - Role 2: add rules > - Playbook is done. Add closing rules. Restart and save iptables. This > spans inventory groups in addition to roles. > > Maybe there is another way to do it. That's fine. The point is that the > roles be able to add their own custom rules without having to understand > what other roles are doing. This is a common Unix idiom where there is a > "conf.d" directory and applications place custom file snippets in it. If > order is important then they are often named 01file, 02file, etc. This is > the pattern I am arguing for implementing as an Ansible module. > > > >> On Tue, Mar 4, 2014 at 7:59 AM, Aaron Hunter <[email protected]> wrote: >> >>> Do the Ansible developers have plans to build a firewall module? I think >>> one is strongly needed. Right now we have to use a variety of kludges to >>> get it this to work. Firewall management is an essential sys admin task and >>> should be supported. >>> >>> Ansible Galaxy needs it because currently there is no standard way for a >>> server role to open the right ports. This means that they have to either >>> make up their own way or ignore it. Both of these are bad. The other CM >>> tools provide provide this capability so it is a standard feature. >>> >>> I think it should be a module because it spans roles. It also has a >>> global nature in that the handler should only run after all other roles >>> have finished. This is why it doesn't fit any of Ansible's current >>> patterns. The module should support iptables and, at least, Red Hat and >>> SUSE (the two commercial distros). >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/ansible-project/f4a14f65-f3d9-4940-b51b- >>> b9bd7f5cae47%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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/68cee385-3eb7-4743-8a12-000dbddf96c2%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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAJvmrNOOHFcp6d5Wiq4HPJoOxJdbL0ET63FrUttNBMU2%2Bud%2ByQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
