puppetlabs-firewall
puppetlabs-firewall copied to clipboard
"iptables" parser error (random was meant to be a boolean but received value: true-fully) when running Puppet on RHEL 8.6 Nodes
Describe the Bug
When running Puppet on an RHEL 8.6 node, the run fails with the following error:
Error: Could not prefetch firewall provider 'iptables': Parser error: random was meant to be a boolean but received value: true-fully.
Error: Failed to apply catalog: Parser error: random was meant to be a boolean but received value: true-fully.
This results in no resources being applied. Running servers on other RHEL 8 versions (8.5 for example) and have experienced no issues.
Expected Behavior
Should be able to parse the IPTABLES rules as per Rhel 8.5 (see above)
Steps to Reproduce
Steps to reproduce the behavior: Will provide more details shortly.
Environment
- Version latest 3.5.0
- Platform Rhel 8.6
Some more information from the customer:
Please find below some code snippets from our firewall resource:
# == Class: profile::base::ossettings::firewall::firewall
#
class profile::base::ossettings::firewall::firewall {
stage { 'fw_pre': before => Stage['main']; }
stage { 'fw_post': require => Stage['main']; }
class { 'profile::base::ossettings::firewall::pre':
stage => 'fw_pre',
}
class { 'profile::base::ossettings::firewall::post':
stage => 'fw_post',
}
# The firewall purge is destructive for docker hosts; use for all other systems
if $facts['docker_binary_exist'] == false {
resources { 'firewall':
purge => true
}
}
}
# == Class: profile::base::ossettings::firewall::pre
#
class profile::base::ossettings::firewall::pre {
# Default firewall rules
firewall { '000 accept all icmp':
proto => 'icmp',
action => 'accept',
}
firewall { '001 accept all to lo interface':
proto => 'all',
iniface => 'lo',
action => 'accept',
}
firewall { '002 accept related established rules':
proto => 'all',
state => ['RELATED', 'ESTABLISHED'],
action => 'accept',
}
# Allow SSH
firewall { '100 allow ssh access':
dport => '22',
proto => tcp,
action => accept,
}
# Allow HTTP and HTTPS
firewall { '100 allow http and https access':
dport => [80, 443, 8080],
proto => tcp,
action => accept,
}
#Allow Samba
firewall { '101 allow samba':
source => '0.0.0.0/0',
dport => '445',
destination => $::ipaddress,
proto => tcp,
action => 'accept',
}
# Avoid removing Docker rules
if $facts['docker_binary_exist'] == true {
firewallchain { 'FORWARD:filter:IPv4':
purge => true,
ignore => [ 'DOCKER', 'docker', ' br-' ],
}
firewallchain { 'DOCKER:filter:IPv4':
purge => false,
}
firewallchain { 'DOCKER-ISOLATION-STAGE-1:filter:IPv4':
purge => false,
}
firewallchain { 'DOCKER-ISOLATION-STAGE-2:filter:IPv4':
purge => false,
}
firewallchain { 'DOCKER-USER:filter:IPv4':
purge => false,
}
firewallchain { 'OUTPUT:nat:IPv4':
purge => true,
ignore => [ 'DOCKER' ],
}
firewallchain { 'DOCKER:nat:IPv4':
purge => false,
}
firewallchain { 'POSTROUTING:nat:IPv4':
purge => true,
ignore => [ 'DOCKER', ' br-', '169.254.' ],
}
firewallchain { 'PREROUTING:nat:IPv4':
purge => true,
ignore => [ 'DOCKER' ],
}
# Avoid removing RTPENGINE rules
if $facts['servertype'] == 'INSERT_SERVER_NAME HERE' *****THIS HAS BEEN REPLACED*******
{
#ignore RTPENGINE rules when input rules are cleaned out
firewallchain { 'INPUT:filter:IPv4':
ensure => present,
purge => true,
ignore => [ 'RTPENGINE' ],
}
}
else
{
#ensure input rules are cleaned out
firewallchain { 'INPUT:filter:IPv4':
ensure => present,
purge => true,
}
}
}
}
# == Class: profile::base::ossettings::firewall::post
#
class profile::base::ossettings::firewall::post {
firewall { '999 drop all other requests':
action => 'drop',
}
}
There are other minor firewall resources used in other modules, however, I believe these are only to add further rules. The bulk of the firewall configuration is done in the above snippets.
@gmcgrillan It look's like random is being retrieved strange, but I'm having some trouble replicating.
Could you ask them to check the machine causing the problems and do a iptables -L
?
They can censor all the port and ip numbers. I just want to see if any of the rules have random/random-fully set and if so, how exactly they are returning.
will ask now! Apologies didn't see this
Folks - I have the iptables but there are some customer-facing fqdn's I'd like to either sanitise or pass to you @david22swan independently.
Give me a shout on slack @david22swan
@gmcgrillan Could you get back to the customer and this time ask them to run iptables-save
and send the results back.
It should give a bit more information and hopefully show what the issue is.
@david22swan - I've sent you that directly on slack! G...
Think I've got an idea what the issue is.
Look's like --random-fully
is being retrieved and then misidentified as --random
.
So that when true is appended after it to keep Puppet happy it's instead turning --random-fully
into --random true-fully
.
Not sure why this is popping up on RHEL 8.6 specifically..... both variables are tested so this doesn't happen and run green on RHEL 8 + 9
@gmcgrillan Hey, have gotten a potential fix for this issue if you could ask the customer to pull it down and try it out: https://github.com/puppetlabs/puppetlabs-firewall/pull/1058
The customer responded in a new support ticket, the fix works as expected! Can we expect this to get merged and released once the tests have been fixed?
Being used for internal tracking: https://tickets.puppetlabs.com/browse/CONT-23
Fix merged, release should go out sometime today
Release has gone out