On Nov 04, Jan Kowalsky wrote: Hello, and welcome to the mailing list as well as to the DebOps project! The old '<role>: False' variable style was used long ago to enable/disable roles in the common playbook without the need to modify it. However I found issues with Ansible interpreting the 'ferm' variable name during package installation so I changed the style of the variables to '<role>__enabled' to avoid collisions. In the early days, some of the DebOps roles like 'debops.postfix' generated ferm configuration files directly in the '/etc/ferm/ferm.d/' directory when more involved rules were required. Since I didn't want to have to create that directory in each role separately, as well as include separate handlers to restart ferm, the 'debops.ferm' role became sort of a required dependency and directory creation was done even when the firewall itself was disabled so that other roles wouldn't break when the directory was missing. Over time I updated the 'debops.ferm' role to support more advanced configurations via role dependent variables and management of the firewall rules directly by other roles became unnecessary. This means that it should be now possible to update the 'debops.ferm' role so that disabling it skips all relevant tasks, the 'ferm' package is not installed, directories are not created, etc. This hopefully can open up the possibility of making the 'debops.ferm' role a non-essential role, so that it could be replaced by say, 'debops.nftables' role when it's created. However keep in mind that DebOps is focused on a production environment, where having a proper firewall on a host is essential, especially with IPv6 where most of the IP addresses are publicly reachable even when IPv4 NAT is used. This makes a firewall choice a tricky subject, since you would want to add support for multiple firewalls at once to each role that requires it (for example 'debops.nginx', 'debops.mariadb_server', etc.) and pick the active one to configure service access. There is precedence for that with roles like 'debops.gitlab' supporting different database engines which are picked out either automatically or by the user during deployment, so that's definitely possible in the future. Right now, when 'debops.ferm' role is disabled, even when the 'ferm' package is installed, it should be completely disabled and shouldn't affect the host's firewall. I think that it should be possible to easily use 'firehol' alongside DebOps. Since other roles defer to 'debops.ferm' role to manage the firewall, they shouldn't change its state as well. Cheers, Maciej