ansible-ferm
ansible-ferm copied to clipboard
debops
Beginner-friendly documentation
This great playbook supports a variety of usecases. Unfortunately, it is rather difficult for a beginner to get started.
- A few simple examples will be rather helpful. For inspiration, see https://github.com/nickjj/ansible-ferm#example-app-play-in-your-playbook
- The different filter.input.d templates should have a short doc string explaining what they do
@StephanErb debops.ferm is currently being redesigned to use more subdirectories, documentation will probably be next on my plate, and it will be included on http://docs.debops.org/ site as well as in the docs/ directory in the role repository. You can check out other roles like MariaDB roles, or debops.preseed to see how it will look like.
I'm currently trying to setup a router with help of debops.ferm. Unfortunately I'm a bit struggling with the same problem as @StephanErb. There were a lot of features implemented in the recent months, but documentation is barely non-existent. As most of the new ferm templates are also missing comments, it's nearly impossible to use them without a lot of try and error. I would really much appreciate, if the template authors could take some time to add a little documentation especially mentioning, what the templates are meant for, maybe a small example and what is still missing.
One urgent question: Is there already a simple way to specify OUTPUT rules? I guess this could be done via custom template, but I fail to see how to parametrize this correctly.
You can specify OUTPUT rules just like other firewall rules stored in ferm__*_rules variables. The default OUTPUT policy rule is specified in the variables, all you need to do in your own rules is to mark them to be put in the OUTPUT chain (the INPUT is default if no chain i specified). Unless I'm mistaken and you need some more customization with these rules (haven't really messed with OUTPUT chain yet, not sure what's needed there). If so, let me know and some additional options or custom template could be easily added.
Documentation is slowly coming along. My current process is to basically rotate between updating existing roles, adding new ones when needed, and fixing bugs in existing "updated" roles. Lately I've added debops.gitlab_runner to replace the obsolete GitLab CI roles and debops.logrotate to better manage logs, at the moment I'm working on updating debops.rsyslog to support remote, encrypted logging (most likely with customizations for Elasticsearch and Graylog available by default). After that, I'll probably start working on a bind9 role, which is long overdue.
Example debops.ferm usage can be found in many existing DebOps roles where it's used as a dependency. I know that this is not the best solution right now, and updating debops.ferm documentation to the new format with better examples is definitely on my mind.
Ok, thanks for the explanation. I'll definitely try what you mentioned.
Is bind9 already decided or could I change your mind to have a look at gdnsd? It's also part of Debian, has some nice features and doesn't bring the security burden of bind9. If I follow the constant flow of security advisories in bind9, I don't feel happy to run an authoritative DNS server towards the Internet with bind9.
I'll start converting the current documentation of debops.ferm in the new format and then add stuff as I find out. Expect some PR from me soon.
Let's put it this way - I'm not opposed to having multiple DNS servers in DebOps, I imagine that each one has its own pros and cons (for example dnsmasq doesn't protect against DNS reflection attacks). At the moment I'm using BIND at my workplace and an option to switch to a new managed version looks nice. Having an authoritative and resolving nameserver in one service without the need to mess with different ports if I want to setup both on one host sounds easy as well.
So for now, I plan to write a BIND9 role. If you want a gdnsd role, I'm not opposed to including one in DebOps - when there's time, I might look into writing one myself, although PowerDNS as an alternative seems more likely at the moment.