Comments (8)
@Ramesh7 thanks for looking into this, but I don't think @corporate-gadfly's firewallchain
issue is related to the original PR issue of zero-prefix-length source
or destination
parameters on firewall
resources causing the resource to be corrected on every agent run. Just wanted to make sure the original issue was also being looked into.
from puppetlabs-firewall.
@Ramesh7 : Any chance this issue can be looked at? I'm not sure how specs work in this module, but shouldn't idempotent_apply
calls catch these issues?
from puppetlabs-firewall.
With Puppet 8.5.1, and module 8.0.0, firewall rules were not idempotent as well.
To compensate, wherever state
was used, I had to replace:
state => ['NEW'],
with
state => 'NEW',
In addition, anywhere where I had used ranges in sport
or dport
, I had to replace -
with :
, e.g.:
dport => '7937-9936',
with
dport => '7937:9936',
After that, firewall rules were idempotent. In that regards PR #1189 was not necessary, in my case.
Hope that helps someone.
from puppetlabs-firewall.
firewallchain resources with Puppet 8.5.1 and module version 8.0.0 are behaving non-idempotent for me, at the moment.
To reproduce, try:
puppet apply -e 'firewallchain {"PREROUTING:mangle:IPv4": ensure=>"present"}'
from puppetlabs-firewall.
Here is the difference in debug output when executing:
puppet apply -e 'firewallchain {"PREROUTING:mangle:IPv4": ensure=>"present"}' --debug
With firewall v6.0.0:
Debug: Found in cache :production (ttl = 0 sec)
Debug: /Firewallchain[PREROUTING:mangle:IPv4]: [validate]
Debug: Creating default schedules
Debug: Loaded state in 0.02 seconds
Info: Using environment 'production'
Debug: Loaded state in 0.02 seconds
Info: Applying configuration version '1710342690'
Debug: Prefetching iptables_chain resources for firewallchain
Debug: Puppet::Type::Firewallchain::ProviderIptables_chain: [prefetch(resources)]
Debug: Puppet::Type::Firewallchain::ProviderIptables_chain: [instances]
Debug: Executing: '/sbin/iptables-save'
Debug: Puppet::Type::Firewallchain::ProviderIptables_chain: [instance] 'INPUT:filter:IPv4' accept
Debug: Puppet::Type::Firewallchain::ProviderIptables_chain: [instance] 'FORWARD:filter:IPv4' accept
Debug: Puppet::Type::Firewallchain::ProviderIptables_chain: [instance] 'OUTPUT:filter:IPv4' accept
Debug: Executing: '/sbin/ip6tables-save'
Debug: Executing: '/sbin/ebtables-save'
Debug: Finishing transaction 12460
Debug: Storing state
With firewall v8.0.0:
Debug: Found in cache :production (ttl = 0 sec)
Debug: Creating default schedules
Debug: Loaded state in 0.03 seconds
Info: Using environment 'production'
Debug: Loaded state in 0.02 seconds
Debug: Executing: 'iptables-save'
Debug: Executing: 'ip6tables-save'
Info: Applying configuration version '1710342515'
Debug: Current State: {:title=>"PREROUTING:mangle:IPv4", :ensure=>:absent}
Debug: firewallchain: Checking whether 'ensure' is out of sync
Notice: /Stage[main]/Main/Firewallchain[PREROUTING:mangle:IPv4]/ensure: defined 'ensure' as 'present'
Debug: Target State: {:name=>"PREROUTING:mangle:IPv4", :ensure=>"present", :purge=>false, :ignore_foreign=>false}
Debug: firewallchain[PREROUTING:mangle:IPv4]: Updating: Start
Notice: firewallchain[PREROUTING:mangle:IPv4]: Updating: Finished in 0.000071 seconds
Debug: /Stage[main]/Main/Firewallchain[PREROUTING:mangle:IPv4]: The container Class[Main] will propagate my refresh event
Debug: Class[Main]: The container Stage[main] will propagate my refresh event
Debug: Finishing transaction 12600
Debug: Storing state
from puppetlabs-firewall.
@Ramesh7 : Any chance this issue can be looked at? I'm not sure how specs work in this module, but shouldn't
idempotent_apply
calls catch these issues?
Hey @corporate-gadfly, sorry for delay in response, I will have look in upcoming week on idempotent_apply.
from puppetlabs-firewall.
Hi @corporate-gadfly, I have tried on RHEL/Ubuntu and was able to reproduce the issue with given steps. Have dig more into that and here is my observations :
- The firewall module uses
ip(6)tables-save
command to check the current set of chains - The expectation of command output is to return all default firewall chains but it return nothing
# iptables-save
#
- So when the
firewallchain
resource converging (applying) it checks for current state, as the command returns no output so it assumes the chains are absent and it tries to create it on every run. - So the issue seems to be with command which doesn't return the expected output.
Later I tried to create a random chain and re-run the iptables-save
command, it return respective table's chain :
- Creating random chain
# puppet apply -e 'firewallchain {"TEST:mangle:IPv4": ensure=>"present"}'
Notice: Compiled catalog for litmus-e6912e0100115ac3.c.ia-content.internal in environment production in 0.05 seconds
Notice: /Stage[main]/Main/Firewallchain[TEST:mangle:IPv4]/ensure: defined 'ensure' as 'present'
Notice: firewallchain[TEST:mangle:IPv4]: Creating: Creating Chain 'TEST:mangle:IPv4' with {:name=>"TEST:mangle:IPv4", :ensure=>"present", :purge=>false, :ignore_foreign=>false, :chain=>"TEST", :table=>"mangle", :protocol=>"IPv4"}
Notice: firewallchain[TEST:mangle:IPv4]: Creating: Ensuring changes to 'TEST:mangle:IPv4' persist
Unable to persist firewall rules: Execution of '/usr/libexec/iptables/iptables.init save' returned 1: Error: Could not execute posix command: No such file or directory - /usr/libexec/iptables/iptables.init
Notice: firewallchain[TEST:mangle:IPv4]: Creating: Finished in 0.014551 seconds
Notice: Applied catalog in 0.04 seconds
After creating custom chain tried running same command :
# iptables-save
# Generated by iptables-save v1.8.10 (nf_tables) on Tue May 28 13:19:36 2024
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:TEST - [0:0]
COMMIT
# Completed on Tue May 28 13:19:36 2024
Then tried rerunning same manifest which turn out to be idempotent :
# puppet apply -e 'firewallchain {"PREROUTING:mangle:IPv4": ensure=>"present"}'
Notice: Compiled catalog for litmus-e6912e0100115ac3.c.ia-content.internal in environment production in 0.05 seconds
Notice: Applied catalog in 0.04 seconds
...
# puppet apply -e 'firewallchain {"TEST:mangle:IPv4": ensure=>"present"}'
Notice: Compiled catalog for litmus-e6912e0100115ac3.c.ia-content.internal in environment production in 0.05 seconds
Notice: Applied catalog in 0.04 seconds
Later I tried same on CentOS where have observed things are working as expected.
Conclusion :
- I think the behaviour of
ip(6)tables-save
misleading the current state of machine because of that firewallchain tries to create it and makesfirewallchain
resource non-i idempotent - For some machines (CentOS) have observed things are working fine
- Don't think so we need to create the default chains, as these are created when the package gets installed. So we can ignore default chain and can create custom chain if needed.
Please let me know if any questions or thoughts?
Thanks
from puppetlabs-firewall.
@Ramesh7 Is there any update on this please? As per what @nabertrand said above this issue is separate to the issue that was fixed at #1206
from puppetlabs-firewall.
Related Issues (20)
- Use nftables instead of iptables where it is supported.
- Getting problems on the firewall on redhat 8
- No value is detected for nflog-prefix HOT 2
- Allow --reject-with tcp-reset for TCP rules
- Could not evaluate: `proto` must be set to `tcp` for `isfragment` to be true.
- firewall.toports expects an undef value or a match for Pattern[/^\d+(?:-\d+)?$/], got Integer
- Hyphen in the ipset's hash name breaks a firewall resource
- Add path option for cgroup
- Add back IPv6 protocol support for recent rule masks HOT 1
- Add support for parsing and using socket parameters
- issue with match_mark regex HOT 1
- Performance degradation in resource_api version
- single quotes in rule comments produces errors HOT 4
- puppet generate types fail on versions >= 7.0.0 HOT 2
- Non idempotent logs for empty firewall chains HOT 8
- hostnames with multiple address are not handled completely
- Link in CONTRIBUTING.md returns a 404.
- Defining a state as an array can cause an unnecessary updating action
- Using a LOG jump with a log_level of 4 causes an unnecessary updating action
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from puppetlabs-firewall.