Hi Maarten,
Thanks for your answer..
On 04/01/2021 21:05, Maarten de Vries wrote:
On 04-01-2021 19:41, Adrian Larsen wrote:
Hi Jason,
1) From a manual operation point of view, I feel more comfortable if
an Operator uses:
# wg set wg0 peer ... allowed-ips ...
# wg-quick save wg0
rather than editing manually the config file.
In case the Wire Guard is running multiple peers with production
traffic, I think an Operator can do less damage using the commands if
something goes wrong.
Another solution could be to have a command line tool that modifies
the configuration file. Kinda like `wg set` except for a config file
instead of a live interface. Would tooling like that alleviate your
concerns of an operator messing up the configuration file?
Yes, one of them. :-)
The second potential problem is if the change is wrong, it is better not
to permanent save it before to test. This is a common scenario:
1- The operator does a change using "wg set" on "x remote node"
2- The setting is incorrect and the "x remote node" becomes isolated.
The operator cannot access to it any more.
3- Last resource solution: Due to the change was not saved, rebooting "x
remote node" will allow the Operator to have access to it again.
2) From automation point of view, still I think that is easy to use
the commands (on an script):
# wg set wg0 peer ... allowed-ips ...
# wg-quick save wg0
rather than using "sed" or "awk" to modify the config file.
Yeah, sed and awk aren't necessarily the nicest solutions. Although
they would work fine in practice. But maybe a tool as mentioned above
could solve this. Even just a script as pretty front-end to the right
sed/awk commands could be useful here.
For automation, (re-)applying a config file does have an important
advantage over `wg set ... && wg-quick save ...`: you can be sure that
all changes are applied, even if the tunnel was temporarily gone for
some reason. Worst case, the changes are kept in the config file and
applied when the interface is created again.
If you try to do `wg set ... && wg-quick save ...` while the WireGuard
interface doesn't exist, the changes are lost. (Or you have to fall
back to modifying the config file by hand, but we didn't want that.)
This advantage may not matter for your application, I can't really
know that. I suppose that depends on the kind of changes that are made
to the configuration at runtime.
-- Maarten
My 2 cents.
Adrian
On 04/01/2021 16:16, Maarten de Vries wrote:
On 03-01-2021 20:59, Chris Osicki wrote:
On Sat, Jan 02, 2021 at 03:37:09PM +0100, Jason A. Donenfeld wrote:
Hi,
I was thinking recently that most people have switched from a
model of
updating the runtime configuration and then reading that back into a
config file, to editing the config file and then syncing that with
the
runtime config. In other words, people have moved from doing:
# wg set wg0 peer ... allowed-ips ...
# wg-quick save wg0
To doing:
# vim /etc/wireguard/wg0.conf
# wg syncconf wg0 <(wg-quick strip wg0)
I think this is mostly a positive change too in terms of reliability.
Reading back the runtime configuration was always a bit hit or miss,
and I suspect that more times than not people have been confused by
SaveConfig=true.
That raises the question: are there good uses left for
SaveConfig=true
and `wg-quick save` that warrant keeping the feature around?
Temporarily caching a roamed endpoint IP, perhaps, but how helpful is
that?
I haven't thought too deeply about this in order to be wedded to one
outcome over the other yet, but seeing some confusion today,
again, in
#wireguard over the feature made me wonder.
Any opinions on this? Any one on this list actively use this feature
and see replacements for it (e.g. syncconf) as clearly inferior?
Jason
Hi Jason
Being an old fashioned Unix admin, ~30 years spent in this job, I
vote for the traditional way of doing it:
change the config file and let the application reread it.
I think the KISS principle is still valid ;-)
I totally agree. Reloading the config file is much nicer :)
I also don't need to save roaming endpoints. All WireGuard tunnels I
use have at-least one side with a fixed endpoint. And if that's not
the case I imagine you probably need a more complicated solution
than wg-quick.
Thanks for the excellent software, Jason!
I also totally agree with this. WireGuard has made my life a lot
easier :)
Regards,
Maarten
