Bug #22857
openService enabled test doesn't seem to work for service iptables on Debian 11
Description
Hello,
Both methods : “Service enabled at boot” and “Service action” with the “is-enabled” action seem to return “success” for service “iptables” (which loads iptables rules previously saved into /etc/iptables) on Debian 11, even though the service has been manually disabled.
After disabling the service and rebooting the machine, iptables rules will not be restored (which is expected), but Rudder still believes the service is enabled.
root@lab_test_1_agent1:/# systemctl disable iptables
Removed
root@lab_test_1_agent1:/# rudder agent run -I
2023-06-08T08:33:49+00:00 R: [INFO] Executing is-enabled on iptables using the systemctl method
A| compliant iptables_basic Enable iptables service iptables Ensure service iptables is enabled at boot was correct
Please also see attached image and relevant parts of a Rudder agent run log.
Files
Updated by Vincent MEMBRÉ over 1 year ago
- Target version changed from 7.3.3 to 7.3.4
Updated by Alexis Mousset over 1 year ago
- Status changed from New to In progress
- Assignee set to Alexis Mousset
Updated by Alexis Mousset over 1 year ago
# systemctl is-active iptables active # systemctl is-enabled iptables alias
our service manager manager does not know about aliases.
Updated by Alexis Mousset over 1 year ago
Updated by Alexis Mousset over 1 year ago
We want to be able to detect is a service is actually enabled.
The current behavior is just to run is-enabled
and to check the return code, which means aliases units are always considered enabled.
The right answer is to resolve the alias name but it is actually not trivial. A temporary workaround could be to make is-enabled on aliases considered a failure, with a message instructing the user to use the actual unit name...
Updated by Alexis Mousset over 1 year ago
- Status changed from In progress to Discussion
Updated by Michel BOUISSOU over 1 year ago
More complexity is added by the fact that a given service may be an actual service on some distros or versions of distros, and an alias on others.
Asking the user to use the real service name rather than resolving it ourselves might create the need for the user to create more different groups of machines or write complex techniques depending upon the nodes os and version.
Updated by Vincent MEMBRÉ over 1 year ago
- Target version changed from 7.3.4 to 7.3.5
Updated by Alexis Mousset over 1 year ago
- Target version changed from 7.3.5 to 7.3.6
Updated by Vincent MEMBRÉ over 1 year ago
- Target version changed from 7.3.6 to 7.3.7
Updated by Vincent MEMBRÉ over 1 year ago
- Target version changed from 7.3.7 to 7.3.8
Updated by Vincent MEMBRÉ about 1 year ago
- Target version changed from 7.3.8 to 7.3.9
Updated by Vincent MEMBRÉ about 1 year ago
- Target version changed from 7.3.9 to 7.3.10
Updated by Vincent MEMBRÉ about 1 year ago
- Target version changed from 7.3.10 to 7.3.11
Updated by Vincent MEMBRÉ 11 months ago
- Target version changed from 7.3.11 to 7.3.12
Updated by Vincent MEMBRÉ 10 months ago
- Target version changed from 7.3.12 to 7.3.13
Updated by Vincent MEMBRÉ 10 months ago
- Target version changed from 7.3.13 to 7.3.14
Updated by Vincent MEMBRÉ 8 months ago
- Target version changed from 7.3.14 to 7.3.15
Updated by Vincent MEMBRÉ 7 months ago
- Target version changed from 7.3.15 to 7.3.16
Updated by Vincent MEMBRÉ 6 months ago
- Target version changed from 7.3.16 to 7.3.17