RFC: wg syncpeers wg0 wireguard.conf

[Lonnie Abelbeck]

> On Jun 11, 2019, at 12:28 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> I gave it a stab in this branch:
> https://git.zx2c4.com/WireGuard/commit/?h=jd/syncconf Try it out and
> let me know if it does what you had in mind?

Hi Jason,
This is *exactly* what I had in mind !  Impressive how little code it took you to add "syncconf", very elegant.

I spent over an hour testing this, trying to break it ... worked perfectly.  Active peers don't miss a beat and retain their counters.


> One of the things that always goes wrong with "sync" algorithms in
> software -- and the commit above at the moment is no exception -- is
> that they're kind of racey. In order to synchronize, we have to read
> the current state, compare it, and then set our new state. But in
> between, the state could have changed out from underneath us. One
> strategy for this is to just do nothing and put some notice in the man
> page. Another strategy is to read back the result at the end, compare
> it, and loop like this until we reach the stable state. This then
> requires implementing some equality function.

If "wg" does not offer "syncconf", users will be hacking together their own sync solution and it will no doubt be more racey than your tight code.

Just a simple mention in the man page stating something like:
Warning: unexpected results may occur with simultaneous background configuration changes during 'wg syncconf'

Possibly also add a hint on the command help... "(assume no background configuration changes)"
--
  syncconf: Synchronizes a configuration file to a WireGuard interface (assume no background configuration changes)
--


> The other thing I was wondering is: aside from performance and races
> as described above, why not just make this the functionality of
> `setconf`? Then there's be no need to introduce a new subcommand. In
> otherwords, the idea would be to make `setconf` not destroy existing
> peers if we're going to be re-adding them again.

I vote to keep "setconf" as is, with the addition of the "syncconf" subcommand.

This keeps "setconf" faster, and unchanged, typically used for initial configuration.

Then "syncconf" would typically be used for followup live updates.

Thanks again Jason!  Please merge syncconf -> master

Lonnie