Both `ferm_ansible_controllers` and `tcpwrappers_ansible_controllers` need to be set

[htgoebel]

After setting ferm_ansible_controllers, I still was not able to access my server. I then found that I additionally need to set tcpwrappers_ansible_controllers. Both ferm and tcpwrappers are common roles, active by default.

Possible solutions I see:

1. Merge both variables into debops_ansible_controllers (or so)
2. Make both variables default to debops_ansible_controllers (which defaults to an empty list)
3. If bot roles are active, do not activate tcpwrappers for sshd.

[drybjed]

If you use both roles (or the DebOps playbook), easier way to use them would be use debops.sshd role to configure ssh service. With that role, you can set ssh_allow list (or ssh_group_allow / ssh_host_allow) which in turn configures both ferm and tcpwrappers at the same time. *_ansible_controllers variables are meant to be used when ferm or tcpwrappers roles are used separately from rest of the DebOps roles.

As for tcpwrappers active specifically with ssh - at the moment debops.ferm role allows limited ssh access (too many connections in a specified time period and the host is blocked). But because debops.tcpwrappers lacks similar feature, use of both was cumbersome. I've deisgned a way to automatically allow access from all hosts in tcpwrappers, similar to what ferm does - it will be merged later in the day. After that, if you don't specify any hosts/networks in ssh_*_allow lists, access to ssh service in tcpwrappers will be allowed from all hosts by default.

debops_* variable namespace is already taken by debops.debops role, but I'm thinking of doing something similar as in debops.ansible role - change the name of variables to role_debops_* and reseve debops_* namespace specifically for playbooks / global variables. If you want to define global variables in inventory to use them in multiple roles without conflicts, I would use inventory_* namespace.

[htgoebel]

Thanks for the explanation. I just added a comment to both roles to make this clear.

In my case I ran both roles separately, because I stepped into problems (which I reported) when trying to run debops.