immediate option missing

[RayMcAdmin]

As of version 1.0.1 it is possible to create a zone, however, until firewall is reloaded this zone is non-functional, so it can't be included in a dict with any rules that anticipate using it. I am anticipating that this would be remedied with the functionality of 'immediate' supplied by firewalld but perhaps not. Open to discussion!

For example, our dict might look like;

{"zone":"000_new_zone","state":"present"},{"permanent":"True","target":"ACCEPT","state":"enabled","zone":"000_new_zone"}
{"permanent":"True","source":"1.0.0.0/24","state":"enabled","zone":"000_new_zone"},{"permanent":"True","source":"2.0.0.0/28","state":"enabled","zone":"000_new_zone"}

(The excessive quotes comes from this being an array parameter from Red Hat Satellite which is running the role against target hosts)

So when the role is run, it successfully creates the zones but then will try to move through the rest of the dict and apply sources/services/whatever else to the newly created zone and fail because the zone is still invalid until the daemon is reloaded. Rerunning the role would not work as the failure results in firewall daemon never being reloaded.

So my question is, are we missing something with our intended usage here or is this missing a function such as detecting when a new zone is created and triggering a firewall-cmd --reload before proceeding with the creation of rule sets? Right now though, the role's ability to create zones appears not to be as useful as it could be

[richm]

Yeah, I think this is a bug in zone creation, that it doesn't take effect immediately. So for now, you have to

• create the zone
• reload firewalld
• use the newly created zone

[erig0]

FWIW, a firewalld --reload should not affect existing connections.

[RayMcAdmin]

FWIW, a firewalld --reload should not affect existing connections.

Right, the problem is not that we don't want to use --reload, it's that we are running this role from Satellite and targeting hosts, so we can't go through a process of creating the zone with this role, reload firewalld and then use the role again to do the rules. When you run ansible roles from Satellite it has one set of parameters to work with.

There's not really an option to create the zone (using this role) and manually reload firewall. At that point, it's already failed the job run

[RayMcAdmin]

So the role is either used to create zones and not rules or rules and not zones. It can't be used to create zones THEN used to create rules (in our context which requires both be done in a single run without manual intervention)

[erig0]

So maybe in the short term the role needs to do an implicit --reload. At least until firewalld can support adding new zones to the runtime.

[richm]

So maybe in the short term the role needs to do an implicit --reload. At least until firewalld can support adding new zones to the runtime.

I think it would have to be done in the module - the problem is that the role takes a list of firewall settings:

firewall:
  - zone: my_new_zone
    state: present
  - port: 54321
    zone: my_new_zone
    state: enabled

If you are using something like satellite, you do not have access to the playbook, so you cannot insert a task to reload between creating the zone and using the zone. so we need to add something here: https://github.com/linux-system-roles/firewall/blob/master/library/firewall_lib.py#L527 and https://github.com/linux-system-roles/firewall/blob/master/library/firewall_lib.py#L531 to reload the firewall or perhaps we need to improve the logic here: https://github.com/linux-system-roles/firewall/blob/master/library/firewall_lib.py#L775-L779 so that it will work in the add/remove zone case to make the changes take effect immediately

[richm]

fixed in https://github.com/linux-system-roles/firewall/pull/59