On Tue, Mar 4, 2014 at 9:47 AM, Aaron Hunter <aaron.hunt...@gmail.com>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. > You'd maybe be surprised but Fedora is used in production in some cases. It's used in some chip design clusters, super computing, and other places. > > >> >> 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. > Incorrect. What you produce with /sbin/iptables save can be in fact templated, and will be used when the service is restarted. It is in fact configuration. > > >> 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. > Ansible galaxy is a public site where anyone with a role on github can add it to the system, so it's basically the internet. Content there is not blessed or official in any way. The role can't really declare the ports it needs so easily either -- as those might be parameterized. And in many cases iptables configuration is more complicated than generically opening up a port on all interfaces. This is where basic management of a firewall starts to break down. There are many that would be scared if roles in Galaxy started poking holes in my firewall, which is why we don't do it by default. 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 > > 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. > Yep this is exactly the point I'm making as why we shouldn't just drill holes. I think we're getting somewhere here. Have you looked at the 'assemble' module for assembling a configuration file out of fragments? This isn't ideal in this case nor generalically applicable to Galaxy, but may be closer to what you are wanting. > > 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. > assemble is there to provide conf.d to systems that don't have it. http://docs.ansible.com/assemble_module.html I'm still against applying that generically for firewall setup to all galaxy roles and believe people should make their own choices in this regard. > > > >> On Tue, Mar 4, 2014 at 7:59 AM, Aaron Hunter <aaron....@gmail.com> 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 ansible-proje...@googlegroups.com. >>> To post to this group, send email to ansible...@googlegroups.com. >>> >>> 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 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/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 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/CAEVJ8QMD5BWViuQJN1tOM6DiF_wJfPFXcsn7WrWF_-36O4btLw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
