Hint about debops.sysctl

[ypid]

I just wanted to drop a line that we at @debops have written debops.sysctl. I added the sysctl_config and made it configurable. Maybe debops.sysctl could be used as dependency role for hardening.os-hardening?

[rndmh3ro]

Hi @ypid, thanks for the suggestion. However I don't think a dependency is a good idea. I'd really like to keep this role as simple as possible. And looking at the code of your sysctl-role, it does not seem very simple (I did not test it, though!).

However I'd really like to here more about why you choose to use template+command instead of the sysctl-module! Maybe in our gitter channel?

[drybjed]

Hi. Actually, I decided to switch to a template-based approach instead of using the sysctl module. The primary reason was because sysctl configuration can be kept in multiple files located in multiple directories. If you look at the sysctl(8) man page, you can find the description of the sysctl --system parameter:

       --system
              Load settings from all system configuration files.
              /run/sysctl.d/*.conf
              /etc/sysctl.d/*.conf
              /usr/local/lib/sysctl.d/*.conf
              /usr/lib/sysctl.d/*.conf
              /lib/sysctl.d/*.conf
              /etc/sysctl.conf

This means that in the event that other Ansible roles apply their own configuration that might override the parameters specified by the debops.sysctl role, these parameters are respected by the sysctl --system command and idempotent loops that switch between one value and another depending on what command is used (sysctl --system or sysctl Ansible module) won't happen.

Setting all desired variables in a templated file at once is also faster than configuring individual variables one at a time using sysctl module. You also don't need to specifically enable the option to ignore missing parameters, because sysctl --system automatically handles that for you.

As for the role complexity - this is how all DebOps roles are designed, in essence. The user is supposed to configure a role through Ansible inventory variables, which have a defined, easy to use format specified in the role documentation. The internal code used by the role in the tasks and templates is more complex but should be treated as a "private" code (think public and private functions in OOP model). Users are not supposed to modify DebOps roles on their own; instead a given role behaviour can be influenced through Ansible inventory.

[conorsch]

While I like the template approach in debops,sysctl, the role is not appropriate for inclusion as a dependency because it targets Debian-based distros specifically, whereas the dev-sec.os-hardening role works on a wide variety of Linux distros.

[ypid]

@conorsch You are right. DebOps is focused on Debian. But in this case it should be easy to update the role to support other distros as well. I would be willing to maintain that for other distros as well if that would allow @dev-sec to use the role.

[rndmh3ro]

Closing this as I'm not comfortable with injecting the another role as a dependency here. I want to try to keep this role lightweight and easily understandable.