5d51ff6dd7
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 |
||
|---|---|---|
| .. | ||
| 0001-Add-support-for-random-fully-flag.patch | ||
| series | ||