WireGuard Archive on lore.kernel.org
 help / color / Atom feed
From: Marc Fawzi <marc.fawzi@gmail.com>
To: Steven Honson <steven@honson.id.au>
Cc: wireguard@lists.zx2c4.com
Subject: Re: RFC: wg syncpeers wg0 wireguard.conf
Date: Tue, 11 Jun 2019 17:25:54 -0700
Message-ID: <CACioZiuMHZRVxT+_aE9L3dDkn_fADrZCyC8MPgqZ_V5yECxNoQ@mail.gmail.com> (raw)
In-Reply-To: <16a64aa0-924c-4497-8252-cc965a04a740@www.fastmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 1312 bytes --]

<<
I'm very much in favour of this (updating `setconf` to use this new
syncronisation approach), if anything it feels more logical and is how I
initially (wrongly) assumed `setconf` behaved when starting out with
WireGuard a while back.
>>

+1 ... it's better to keep the same command if its definition can be
expanded (fewer things to remember and less mental clutter)

p.s. does this overlap with similar planned in wg-dynamic?



On Tue, Jun 11, 2019 at 5:23 PM Steven Honson <steven@honson.id.au> wrote:

> On Wed, 12 Jun 2019, at 3:56 AM, Jason A. Donenfeld wrote:
> > 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'm very much in favour of this (updating `setconf` to use this new
> syncronisation approach), if anything it feels more logical and is how I
> initially (wrongly) assumed `setconf` behaved when starting out with
> WireGuard a while back.
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #1.2: Type: text/html, Size: 1930 bytes --]

<div dir="ltr">&lt;&lt;<div>I&#39;m very much in favour of this (updating `setconf` to use this new syncronisation approach), if anything it feels more logical and is how I initially (wrongly) assumed `setconf` behaved when starting out with WireGuard a while back.<br></div><div>&gt;&gt;</div><div><br></div><div>+1 ... it&#39;s better to keep the same command if its definition can be expanded (fewer things to remember and less mental clutter)</div><div><br></div><div>p.s. does this overlap with similar planned in wg-dynamic?</div><div><br></div><div> <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 11, 2019 at 5:23 PM Steven Honson &lt;<a href="mailto:steven@honson.id.au">steven@honson.id.au</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 12 Jun 2019, at 3:56 AM, Jason A. Donenfeld wrote:<br>
&gt; The other thing I was wondering is: aside from performance and races<br>
&gt; as described above, why not just make this the functionality of<br>
&gt; `setconf`? Then there&#39;s be no need to introduce a new subcommand. In<br>
&gt; otherwords, the idea would be to make `setconf` not destroy existing<br>
&gt; peers if we&#39;re going to be re-adding them again.<br>
<br>
I&#39;m very much in favour of this (updating `setconf` to use this new syncronisation approach), if anything it feels more logical and is how I initially (wrongly) assumed `setconf` behaved when starting out with WireGuard a while back.<br>
_______________________________________________<br>
WireGuard mailing list<br>
<a href="mailto:WireGuard@lists.zx2c4.com" target="_blank">WireGuard@lists.zx2c4.com</a><br>
<a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer" target="_blank">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br>
</blockquote></div>

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

  reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-09 19:59 Lonnie Abelbeck
2019-06-10 12:34 ` Rene 'Renne' Bartsch, B.Sc. Informatics
2019-06-11 17:28 ` Jason A. Donenfeld
2019-06-11 21:06   ` Lonnie Abelbeck
2019-06-11 21:41     ` Kalin KOZHUHAROV
2019-06-12  0:22   ` Steven Honson
2019-06-12  0:25     ` Marc Fawzi [this message]
2019-06-14 18:01       ` Jason A. Donenfeld
2019-06-16 19:43         ` Marc Fawzi
2019-06-13 23:15   ` Lonnie Abelbeck
2019-06-14 18:09   ` Jason A. Donenfeld
2019-06-14 20:48     ` Lonnie Abelbeck
2019-06-14 21:14     ` Ivan Labáth

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACioZiuMHZRVxT+_aE9L3dDkn_fADrZCyC8MPgqZ_V5yECxNoQ@mail.gmail.com \
    --to=marc.fawzi@gmail.com \
    --cc=steven@honson.id.au \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com zx2c4-wireguard@archiver.kernel.org
	public-inbox-index wireguard


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


AGPL code for this site: git clone https://public-inbox.org/ public-inbox