Support for sysctl file provider

[myllynen]

The README states that tuned is the default provider for Fedora/RHEL, this is reasonable.

However, it looks like there are currently no other providers available, that might be worth pointing out. This also means using the role to operate on sysctl files is not possible. That might be helpful in cases where there are other applications and automation in play which deal only with sysctl files for kernel settings so from admin/user perspective keeping everything under /etc/sysctl.d would perhaps be more consistent.

I would consider this as a relatively low-priority RFE at this point. Thanks.

[richm]

The README states that tuned is the default provider for Fedora/RHEL, this is reasonable.

However, it looks like there are currently no other providers available, that might be worth pointing out. This also means using the role to operate on sysctl files is not possible. That might be helpful in cases where there are other applications and automation in play which deal only with sysctl files for kernel settings so from admin/user perspective keeping everything under /etc/sysctl.d would perhaps be more consistent.

I would consider this as a relatively low-priority RFE at this point. Thanks.

The main reason we use tuned is because it is the only thing on EL7 and later that has the capability to set sysfs settings at boot time i.e. make those settings persistent - otherwise, we would have to invent some sort of systemd service thing to apply them, because there isn't, afaik, a debian-like sysfsutils.service for EL.

A role to manage all files under /etc/sysctl.d would be pretty cool, but difficult.

[myllynen]

One additional data point is that some security profiles, like DISA STIG, forbid or at least are strongly against using tuned (see https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2021-06-14/finding/V-230561). So in those cases it may not be possible to rely on roles utilizing tuned.

[richm]

One additional data point is that some security profiles, like DISA STIG, forbid or at least are strongly against using tuned (see https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2021-06-14/finding/V-230561). So in those cases it may not be possible to rely on roles utilizing tuned.

It would be pretty easy to change the implementation of the kernel_settings role, at least the sysctl parameters, to use the sysctl module or even CLI - but how would I handle, persistently, the sysfs and other parameters?

[myllynen]

There seems to be two different suggestions coming up often:

1. Use systemd tmpfiles - https://sleeplessbeastie.eu/2022/11/18/how-to-create-persistent-sysfs-configuration-using-systemd/

2. Some sort of one-shot script to read settings e.g. from /etc/sysfs.conf. This might be better implemented as a separate project in upstream first and then adopt this a few RHEL releases later.

If other parameters means just boot parameters then grubby could be used for that on RHEL 7+, it's relatively straightforward to check and update boot parameters configuration with it.

Thanks.

[richm]

Another huge feature that the tuned implementation gives us is that it remembers the previous values, so reverting changes is trivial. It would be very difficult to implement this otherwise. When I recently had to refactor the role not to use tuned as a python library, I wanted to use sysctl directly with a one-shot script for sysfs persistence - but this test failed https://github.com/linux-system-roles/kernel_settings/blob/main/tests/tests_change_settings.yml because it isn't easy, without tuned, to remember the "default" settings. Without using tuned, we would need to implement our own daemon to remember the default settings.

[myllynen]

Perhaps that could be spelled out clearly as a known limitation - not ideal but it would still allow using the role in strictly-conforming environments where tuned cannot be allowed due to security policy compliance. But I admit I don't have any concrete numbers how often this really is an issue so perhaps this should be regarded as a nice-to-have RFE. Thanks.