A problem may occur if puppet attempts to inject a firewall rule
while the underlying iptables/ip6tables has existing rules which
use the --random-fully flag in the NAT table.
The issue occurs because puppet-firewall first makes a call to
iptables-save/ip6tables-save to parse the existing rules
(to determine if the rule already exists). If it finds a rule
with --random-fully, it will immediately bail out.
The current version(s) of puppet-firewall in StarlingX are old
enough that they don't have parsing logic for the --random-fully
flag that was initially supported in iptables version 1.6.2+.
Now that StarlingX uses iptables 1.8.4, we must account for the
possibility that various components (ie. kubernetes) will make
use of --random-fully rules.
This feature has been implemented upstream in the following commits:
https://github.com/puppetlabs/puppetlabs-firewall/commits/
9a4bc6a81cf0cd4a56ba458fadac830a2c4df529
0ea2b74c0b4a451a37bae8c2ff105b72481ab485
The above commits have been ported back to:
CentOS: puppet-firewall-1.8.2
Debian: puppetlabs-firewall-1.12.0
Since StarlingX does not currently build it's own version
of puppet-firewall in either CentOS or Debian, this commit
also contains the infrastructure to do so.
Testing:
Note: Since the issue is intermittent on unlock, the functional
tests were performed with a custom runtime manifest that installed
a dummy iptables/ip6tables rule when an interface was modified.
At this time, it was guaranteed that there were rules with
the --random-fully flag present.
CentOS:
Package build: PASS
Present in iso: PASS
IPv4 functional test (iptables): PASS
IPv6 functional test (ip6tables): PASS
Debian:
Package build: PASS
Present in iso: PASS
IPv4 functional test (iptables): PASS
IPv6 functional test (ip6tables): PASS
Closes-Bug: #1971900
Signed-off-by: Steven Webster <steven.webster@windriver.com>
Change-Id: I7dbb9e1b99d95df0aa5a7db7aa22c3c314253788
5d51ff6dd7