Added basic validation for interface config

[thaasoph]

I have added a basic script that tries to validate the generated config.
If you have a working wireguard mesh, a single misconfigured host can corrupt the config on every peer. On restart of the service it won't come back up and therefore break the entire mesh. If you use SSH over the wireguard connection, this will lock you out.
This happened to me multiple times because the generation of my public key failed on one of my peers.

The script attempts to interactively apply the configuration to the interface. If that fails, the interface is at least not broken and the task fails. If the interactive configuration is successful the template module will copy it to its destination as usual and the service will be restarted.

I do not have terribly many constellations to check this works as intended without any unforeseen consequences. Do you think adding s.th. like this is a good idea or do you suspect it makes it more prone to unintended fails?

[mawalu]

Hi and sorry for my delayed response.

This sounds like a nice thing to have in the role, could you explain a bit how the script works? Also I think it might be a good idea to ether store the script in a more permanent location (/usr/local/bin or something similar?) or to remove it at the end of the role so we don't clutter /tmp

[thaasoph]

The important part in the script is wg syncconf $1 <(wg-quick strip ${symbolic_filename}).
Wireguard allows to synchronize the config of the running interface with a persisted version. That way, you can apply some changes to the interface without taking it down. While doing so, wireguard validates at least the syntax of the config.
If the sync was successful, I assume the config is valid.

Literally everything else in the script before wg syncconf $1 <(wg-quick strip ${symbolic_filename}) is to trick wireguard into attempting the sync.
The problem is, that wireguard expects a certain naming scheme on the files, while the copy module uses cryptic names to store the temporary files.

Ultimately the script is called via the validate option of the copy module. If successful, the copy module completes the step and overrides the original version of the config. If validate fails, the original version is preserved and the playbook fails.

In terms of where to store the script I have the problem that I don't want to clutter anything but at the same time I don't want the task to be marked as changed every time I run the playbook.