You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running this formula with a pillar configuration definition containing SaveConfig: true within the Interface dict: file changes and service restart are always triggered on subsequent runs.
As the configuration file WireGuard saves contains no boilerplate, the formula detects changes, applies them and triggers a restart. This restart then triggers a stop, which saves the stripped config file again. The cycle continues.
Steps to reproduce the bug
Running the wireguard formula (from PR #4 to let installation succeed) twice on a CentOS Stream or Rocky Linux 8 machine with given pillar data.
Expected behaviour
It not overwriting files with slightly different ordering and/or no boilerplate comments.
Proposed fix
Given WireGuard configuration files have the INI file format, we can utilize the built-in ini_manage state.
That will make it resilient to small changes, while ensuring all pillar data is reflected.
The route of using ini_manage should only be taken when SaveConfig: true is set, as to remain behaviorally compatible with existing setups as well as guarantee no configuration drift on minions without SaveConfig: true.
Attempts to fix the bug
Removing SaveConfig from pillar data removes the circular config override issue, however, that will result in dropped connection states on service restart triggered by this formula. Which is not ideal.
Update: Tried the ini_manage route in my own fork: it's a no go. It doesn't handle duplicate sections with the same name. Next up: writing a custom execution module to do the heavy lifting of merging template with existing/runtime config.
The text was updated successfully, but these errors were encountered:
emansom
changed the title
[BUG] Configs with SaveConfig = true always yields file changes and service restart
[BUG] Configs with SaveConfig = true always yield file changes and service restart
May 20, 2022
emansom
changed the title
[BUG] Configs with SaveConfig = true always yield file changes and service restart
[BUG] Configs with SaveConfig = true always yield file changes
May 21, 2022
Your setup
Formula commit hash / release tag
b88246c / master
Versions reports (master & minion)
Pillar / config used
/srv/pillar/wireguard.sls
Bug details
Describe the bug
When running this formula with a pillar configuration definition containing
SaveConfig: true
within theInterface
dict: file changes and service restart are always triggered on subsequent runs.As the configuration file WireGuard saves contains no boilerplate, the formula detects changes, applies them and triggers a restart. This restart then triggers a stop, which saves the stripped config file again. The cycle continues.
Steps to reproduce the bug
Running the
wireguard
formula (from PR #4 to let installation succeed) twice on a CentOS Stream or Rocky Linux 8 machine with given pillar data.Expected behaviour
It not overwriting files with slightly different ordering and/or no boilerplate comments.
Proposed fix
Given WireGuard configuration files have the INI file format, we can utilize the built-inini_manage
state.That will make it resilient to small changes, while ensuring all pillar data is reflected.The route of usingini_manage
should only be taken whenSaveConfig: true
is set, as to remain behaviorally compatible with existing setups as well as guarantee no configuration drift on minions withoutSaveConfig: true
.Attempts to fix the bug
Removing
SaveConfig
from pillar data removes the circular config override issue, however, that will result in dropped connection states on service restart triggered by this formula. Which is not ideal.Update: Tried the
ini_manage
route in my own fork: it's a no go. It doesn't handle duplicate sections with the same name. Next up: writing a custom execution module to do the heavy lifting of merging template with existing/runtime config.The text was updated successfully, but these errors were encountered: