Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Adds iptables_raw module #21054
But the module also works from 1.9+.
This module makes it easy to manage
Here are a few examples how to use it:
# Allow all IPv4 traffic coming in on port 80 (http) - iptables_raw: name: allow_tcp_80 rules: '-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT' # Allow all IPv6 traffic coming in on port 443 (https) with weight 50 - iptables_raw: ipversion: 6 weight: 50 name: allow_tcp_443 rules: '-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT' # Remove the above rule - iptables_raw: state: absent ipversion: 6 name: allow_tcp_443 # Reset all IPv4 iptables rules in all tables and allow all traffic - iptables_raw: name: '*' table: '*' state: absent
Module has been heavily tested on CentOS 5, 6 and 7 and has been used in production (on these distributions) for almost a year now. It should work without any problems on Debian like distributions as well (iptables-persistent` package is needed), as well as on other distributions which use iptables.
On the implementation side this module keeps the state in a json file in
The module saves the generated rules into
When the module adds rules it automatically adds
- iptables_raw: name: allow_tcp_80 rules: '-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT'
generates this rule:
The module also implements a locking mechanism, so if you run the module on the same host at the same time, one instance will wait for the other to finish execution. This was done just in case so that state files don't get overwritten in a wrong order.
We also wrote integration tests for this module, but we will add them a little later.
This PR is mostly a migration from ansible/ansible-modules-extras#2531.
Feb 6, 2017
@AugustusKling @rosmo @mcv21 @DavidWittman @mulby @srvg @abulimov @dsummersl @EvanK @goozbach @nibalizer @groks @LinusU @risaacson @dagwieers @dougluce @tmshn @jasperla @saito-hideki @jhoekx @natefoo @mscherer @matze @maxamillion @davixx @ovcharenko @pyykkis @pmarkham @ @dankeder
As a maintainer of a module in the same namespace this new module has been submitted to, your vote counts for shipits. Please review this module and add
@LinusU The problem is that these two modules work a lot different, so merging them together would probably mean a full rewrite of both modules. But the biggest problem is that the syntax of the current
We should be able to merge the rules part, but we would still need to break backward compatibility because of the
One other reason why I'm against the merge is because I find the
Don't get me wrong, the
I would rather go a different route and maybe extract the managing of module state and how the rules are applied/tested in
While the preferred method is to merge the two modules, is that merely a preference or a requirement? The existing module is clearly lacking an important feature (saving state) and something needs to be done to address this missing need. Ansible folks @LinusU @alikins et al, please provide some direction so progress on this can continue.
@szhem it's not possible to prevent the creation of
The reason why the state file is needed is because it's not possible to put all information needed for the module to work correctly into iptables.
@nuklea I don't understand what is the example you are showing because you wrote an example for the
The error on the other hand displays that
@dagwieers it was already discussed in one of the core meetings and the majority was against merging thins module because it keeps state in a separate file on a remote host. A few of the core developers are against this approach.
A few weeks ago I found a way to not need this external file to keep state, but it will require a rewrite of the module, so that's what I decided to do. I also talked to a few core devs which were against the current module, and they liked the idea.
The best thing is that this rewrite will make the module code a lot more simple, while keeping all the current functionality and also add more flexibility (for example it will be able to work with dynamic iptables rules which are created by some external software like libvirtd, Docker, etc). I'm still not sure if I will just change this module, or write a completely new one, but I will update this issue anyway.