firewalld offline option does nothing

[CendioOssman]

(migrated from https://github.com/ansible/ansible/issues/63337)

SUMMARY

Using the offline flag to the firewalld has absolutely no effect on behaviour. Looking at the code I can not find any reference to the option beyond parsing it.

ISSUE TYPE

• Bug Report

COMPONENT NAME

firewalld

ANSIBLE VERSION

ansible 2.8.5
  config file = /local/home/ossman/devel/ansible/ansible.cfg
  configured module search path = ['/home/ossman/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.7.3 (default, Mar 27 2019, 13:36:35) [GCC 9.0.1 20190227 (Red Hat 9.0.1-0.8)]

CONFIGURATION

[defaults]
stdout_callback = yaml

OS / ENVIRONMENT

Target is a Red Hat Enterprise Linux 7 machine. Ansible is run on a Fedora 30 machine.

STEPS TO REPRODUCE

- name: disable firewalld
  service:
    name: firewalld
    enabled: no
    state: stopped
- name: allow NRPE in firewall
  firewalld:
    service: nrpe
    permanent: yes
    immediate: yes
    offline: yes # firewalld might be disabled on some machines
    state: enabled

EXPECTED RESULTS

TASK [server : allow NRPE in firewall] ******************************************************************
ok: [host.example.com]

ACTUAL RESULTS

TASK [server : allow NRPE in firewall] ******************************************************************
fatal: [host.example.com]: FAILED! => changed=false 
  msg: firewall is not currently running, unable to perform immediate actions without a running firewall daemon

[maxamillion]

@CendioOssman first off, thank you for the bug report!

So a few things:

• Your observation appears to be correct and I'm not sure how/when/where that got lost in the mix but offline permanent changes work even without the paramerter which I think was the original intent of the parameter in the first place
• Technically the error you are getting is correct because you cannot inflict an immediate (runtime) change on a firewall that's not running ... however, I'm curious if that behavior should change such that immediate: yes would inherently mean "make the change immediately, if the firewall is running" and offline: yes would be "do what needs doing to an offline firewall and don't worry about immediate (runtime) changes"

I'd be interested in your thoughts on how you'd want/expect this to function as an user.

Thank you!

[jamescassell]

It's generally useful to separately configure runtime state from on-disk persistent state. Not sure how that looks here exactly.

[maxamillion]

@jamescassell - I'm honestly just leaning towards documenting that the offline parameter doesn't do anything, enhancing the documentation around the permanent and immediate params, and listing offline for deprecation on some date in the future

[maxamillion]

@jamescassell - I'm honestly just leaning towards documenting that the offline parameter doesn't do anything, enhancing the documentation around the permanent and immediate params, and listing offline for deprecation on some date in the future

That being said, I'm open to discussion on this... I do generally prefer explicit to implicit though.

[CendioOssman]

In our scenario firewalld has been completely disabled on some machine. We could make that task conditional, but maintaining an up to date list of those exceptions is doomed to fail.

So what we want is a clean way to say "it's okay if this fails, as long as the reason for the failure is that firewalld is disabled". This is the somewhat clumsy workaround we've implemented right now by first checking which services are active on the system.

With that said, I'd still like to see a functional offline setting that does indeed override immediate. If firewalld is only temporarily disabled, having these settings take effect once it is started again would avoid surprises. This is also how I interpreted the current documentation for this option: "Whether to run this module even when firewalld is offline."

[maxamillion]

@CendioOssman that seems fair, the idea of offline overriding immediate seems like a good one. I think we could even deal with that conditionally if needed based on the set of parameters and the state of the service daemon on the remote host.

[m0nkeyc0de]

Hello, I also got the issue as someone needed to stop firewalld service on a server to do some tests.

Here is the task that failed in that case:

- name: Disable DHCPv6 client firewall rule
  firewalld:
    service: dhcpv6-client
    permanent: yes
    immediate: yes
    zone: public
    state: disabled

Regarding immediate, we set it to true because we want the firewall to be applied immediately when the task is executed and not at an unknown random point of time in the future.

Deprecating offline doesn't seem to be the right solution.

For now I have following workaround, but this is boilerplate code:

- name: Populate service facts
  service_facts:

- name: Disable DHCPv6 client firewall rule
  firewalld:
    service: dhcpv6-client
    permanent: yes
    immediate: yes
    zone: public
    state: disabled
  when: ansible_facts['services']['firewalld.service']['state'] == 'running'

In my case, offline: no should have the same behavior as when: ansible_facts['services']['firewalld.service']['state'] == 'running' and it also seems to be your current conclusion.

[mkot02]

When firewalld service is actually stopped, firewalld module fails with following error (even if offline is set to true):

ERROR: Exception caught: 'FirewallConfig' object is not callable

OS: RHEL7 Ansible: 2.11.8 ansible.posix collection: 1.3.0