Possible parse errors in hiera data input

[tnail]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.5.12
• Ruby: 2.5.5
• Distribution: RHEL 8.3
• Module version: 4.3.0

How to reproduce (e.g Puppet code you use)

Hiera data::
firewalld::ipsets:
appadmin:
type: 'hash:net'
options:
family: 'inet'
entries:

• '(redacted)' # Access Network

firewalld::services:
http:
ensure: present
service: http
zone: public
https:
ensure: present
service: https
zone: public

What are you seeing

We are trying to add firewall rules via hiera data. Puppet seems to parse the hiera data and create a rule set for it, but the resulting JSON blob fails to get added. The firewall fails open, with no rules (as expected), and we can't manually reload or affect rule changes from the command-line or from Puppet/Hiera. Error responses are of the form:

2020-12-16 05:15:43 ERROR: COMMAND_FAILED: 'python-nftables' failed: internal:0:0-0: Error: Could not process rule: Dire ctory not empty internal:0:0-0: Error: Could not process rule: Directory not empty internal:0:0-0: Error: Could not process rule: Directory not empty internal:0:0-0: Error: Could not process rule: Directory not empty internal:0:0-0: Error: Could not process rule: Directory not empty . . . (ellipsis mine)

With JSON blobs in the logfiles like:

JSON blob: {"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"set": {"family": "inet", "table": "firewalld", "name": "management", "type": "ipv4_addr", "flags": ["interval"]}}}, {"add": {"set": {"family": "ip", "table": "firewalld", "na me": "management", "type": "ipv4_addr", "flags": ["interval"]}}}, {"add": {"set": {"family": "ip6", "table": "firewalld" , "name": "management", "type": "ipv4_addr", "flags": ["interval"]}}}, {"flush": {"set": {"family": "inet", "table": "fi rewalld", "name": "management"}}}, {"flush": {"set": {"family": "ip", "table": "firewalld", "name": "management"}}}, {"f lush": {"set": {"family": "ip6", "table": "firewalld", "name": "management"}}}, {"add": {"element": {"family": "inet", "table": "firewalld", "name": "management", "elem": [{"prefix": {"addr": "10.32.9.32", "len": 27}}]}}}, {"add": {"element": {"family": "ip", "table": "firewalld", "name": "management", "elem": [{"prefix": {"addr": "10.32.9.32", "len": 27}}]}}}, {"add": {"element": {"family": "ip6", "table": "firewalld", "name": "management", "elem": [{"prefix": {"addr": "10.32.9.32", "len": 27}}]}}}, {"add": {"element": {"family": "inet", "table": "firewalld", "name": "management", "elem": ["10.32.9.51"]}}}, {"add": {"element": {"family": "ip", "table": "firewalld", "name": "management", "elem": ["10.32.9.51"]}}}, {"add": {"element": {"family": "ip6", "table": "firewalld", "name": "management", "elem": ["10.32.9.51"]}}}, {"add": {"element": {"family": "inet", "table": "firewalld", "name": "management", "elem": ["10.32.9.50"]}}}, {"add": {"element": {"family": "ip", "table": "firewalld", "name": "management", "elem": ["10.32.9.50"]}}}, {"add": {"element": {"family": "ip6", "table": "firewalld", "name": "management", "elem": ["10.32.9.50"]}}}, {"add": {"element": {"family": "inet", "table": "firewalld", "name": "management", "elem": [{"prefix": {"addr": "10.50.10.32", "len": 28}}]}}}, {"add": {"element": {"family": "ip", "table": "firewalld", "name": "management", "elem": [{"prefix": {"addr": "10.50.10.32", "len": 28}}]}}}, {"add": {"element": {"family": "ip6", "table": "firewalld", "name": "management", "elem": [{"prefix": {"addr": "10.50.10.32", "len": 28}}]}}}]}

There are errors in these blobs (e.g., "f lush", and ipv4 addresses in ipv6 elements) , which might be the cause of the issues we're seeing.

What behaviour did you expect instead

Expectation was that hiera data would be parsed and put into rulesets with firewalld being restarted with the new running rules in place. Manual intervention via the command-line would also be available.

Output log

see above.

Any additional information you'd like to impart

[tnail]

This has been resolved: we checked debug output against the hiera data we had on file and found an overlap in one of the ipsets between a network definition (e.g., 10.32.9.32/27) and a host IP within that network (e.g., 10.32.9.51/32). Removing the individual host IPs allowed the parser to work correctly.