Continued use of `wg-quick save` and SaveConfig=true?

Continued use of `wg-quick save` and SaveConfig=true?

[Jason A. Donenfeld]

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

Re: Continued use of `wg-quick save` and SaveConfig=true?

[Chris Osicki]

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 ;-)

Thanks for the excellent software, Jason!

Regards,
Chris

Re: Continued use of `wg-quick save` and SaveConfig=true?

[Maarten de Vries]

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

Re: Continued use of `wg-quick save` and SaveConfig=true?

[Adrian Larsen]

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.

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.

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
>

Re: Continued use of `wg-quick save` and SaveConfig=true?

[Maarten de Vries]

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?


>
> 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
>>

Re: Continued use of `wg-quick save` and SaveConfig=true?

[Adrian Larsen]

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
>>>

Re: Continued use of `wg-quick save` and SaveConfig=true?

[Michael B. Williams]

[-- Attachment #1: Type: text/plain, Size: 4563 bytes --]

I agree with this commentary and would second keeping the functionality.

________________________________

Michael B. Williams
Glexia, Inc. - An IT Company
USA Direct: +1 978 477 6797
USA Toll Free: +1 800 675 0297 x101
AUS Direct: +61 3 8594 2265
AUS Toll Free: +61 1800 931 724 x101
Fax: +1.815-301-5570
Michael.Williams@glexia.com
https://www.glexia.com/
https://www.glexia.com.au/

Legal Notice:
The information in this electronic mail message is the sender's
confidential business and may be legally privileged. It is intended
solely for the addressee(s). Access to this internet electronic mail
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it is prohibited and may be
unlawful.


________________________________

Michael B. Williams
Glexia, Inc. - An IT Company
USA Direct: +1 978 477 6797
USA Toll Free: +1 800 675 0297 x101
AUS Direct: +61 3 8594 2265
AUS Toll Free: +61 1800 931 724 x101
Fax: +1.815-301-5570
Michael.Williams@glexia.com
https://www.glexia.com/
https://www.glexia.com.au/

Legal Notice:
The information in this electronic mail message is the sender's
confidential business and may be legally privileged. It is intended
solely for the addressee(s). Access to this internet electronic mail
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it is prohibited and may be
unlawful.



On Mon, Jan 4, 2021 at 1:49 PM Adrian Larsen
<alarsen@maidenheadbridge.com> 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.
>
> 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.
>
> 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
> >

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5326 bytes --]

Re: Continued use of `wg-quick save` and SaveConfig=true?

[Eicke Herbertz]

Hi,

I don't really want to advertise my stuff, but as I am running our server on systemd-networkd instead of wg-quick, I was in need and actually built a script [1] around awk.
It may be not particulary clean and I'm currently unsure if support for wg.conf-Syntax actually works, but it is probably still worth noting in this context.

Regards,
Eicke

[1] https://github.com/WolleTD/wg-setup

Am 4. Januar 2021 22:05:01 MEZ schrieb Maarten de Vries <maarten@de-vri.es>:
>
>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?
>
>
>>
>> 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
>>>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.