1

In the process of writing playbooks to configure firewalld (on RHEL) with Ansible, we've encountered some issues with juggling the running config and the configuration written to /etc/firewalld/firewalld.conf, which is usually modified via firewall-cmd. We want the systems whose firewalls we're managing with Ansible to converge to the state we specify after every run of Ansible (i.e., after having the firewalld playbook(s) run against a host, both the running and written configs are in the desired state).

Ansible provides the firewalld module, which can manage many settings. Unfortunately, it can’t do everything that firewall-cmd can do, such as set things like DefaultZone (which is one of the options we want to be managing). While we initially though the solution to the shortcomings of the firewalld module would be to run firewall-cmd using the Ansible command module, we quickly realized that if you set the value of DefaultZone using the Ansible command plugin to run firewall-cmd and then someone else uses a text editor to modify the value of DefaultZone in firewalld.conf, Ansible will fail when trying to reset DefaultZone back to its original value, since firewall-cmd thinks the configuration option already has the desired value.

Does anyone know of a way to ensure that both the running and written configuration for firewalld are in the desired state after each run of Ansible? We’re more concerned about unloaded configuration changes surprising us than we are about someone making an ephemeral change to the running ruleset that will be replaced the next time firewalld rulesets are loaded from disk, but it would be ideal if we could manage everything with Ansible.

1 Answers1

1

I had the same problems and after a while I switched to self scripted solution based on templates (so any role can add a template and there is a single hook that collects the config and manages the iptables). But that wasn't the question.

First - you wrote, someone could modify a file with the text editor... Don't do that. Of course Ansible or any automatic process should be able to identify differences in files and would override them or ignore them. But for example using template and editing the same file with an editor would end in a mess - do it the one way or the other way. Don't mix manual and automatic processes. Hands-off is the new cool. You can f.e. argue with documentation reasons...

Second - firewalld is as many RedHat products designed to be used via executables to configure and run a service. Most other Linux tools can be configured via text files. This makes it harder to manage the service with Ansible. Because you can either run the command or shell scripts with all the problems with idempotence or you can use a modules - if it exists.

Third - the Ansible firewalld module isn't perfect (as many other). But - they are written in Python and writing your own module that fits your needs is much easier then expected. Of course - Python knowledge is necessary - but often enough you can just copy&paste existing module args and actions and just change the underlying command. Often the Ansible module calls itself the shell script or uses a Python lib.

So - the best approach would be to extend the module (and commit it to the community ;-)).

If you need an easy solution and templating isn't one, use command - that will work but is ugly because of the missing idempotence and because it's hard to identify the current state (register config output, parse it, etc.).

I tried templating the XML files, but that wasn't very stable. Often enough firewalld ignores them or overwrites them and often enough I locked me out myself...

TRW
  • 488
  • 3
  • 16
  • Shortly use the module or propose a fix for the case not covered by it. Now the module is no longer in core, which means it can be updated much faster. – sorin Feb 18 '21 at 08:05