Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: WireGuard in systemd-networkd
Date: Wed, 10 Jan 2018 02:09:35 -0500	[thread overview]
Message-ID: <87efmy42c0.fsf@fifthhorseman.net> (raw)
In-Reply-To: <CAHmME9qrfy4Lf78NkChdv6tPnSFTcGArwgsizAaapL9k=Tc31w@mail.gmail.com>

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

On Tue 2018-01-09 18:38:59 +0100, Jason A. Donenfeld wrote:
> On Tue, Jan 9, 2018 at 4:20 PM, Daniel Kahn Gillmor
> <dkg@fifthhorseman.net> wrote:
>> very cool!  systemd-networkd end up invoking wg(8)?  or does it interact
>> with the kernel directly?
>
> We taught systemd to talk the generic netlink protocol --useful for
> all sorts of new things cropping up in the kernel -- and then after
> that we taught it to talk wireguard, which builds on top of generic
> netlink. And, it doesn't introduce any build-time dependencies into
> systemd-networkd. So it's there for people who want it and not there
> for those who don't. I think this is the right approach for
> Linux-centric approaches like systemd.

cool.  this sounds very much like you've decided that the netlink
interface is now stable, which is good to hear :)  It becomes much
trickier to update the interface when you've got external tools (whose
release cycle you don't control) talking to them!

>> if doesn't need wg(8), then once the new release of systemd is made, we
>> may want to change the dependency recommendations for the wireguard
>> kernel module packages.
>
> Maybe? I'm not quite sure what the Debian semantics for
> recommendations are. If additional recommendations crowd out existing
> recommendations, or introduce some kind of automatic selection logic
> where only one has to be satisfied in an install-recommendations mode,
> then I'd be hesitant. The reason is that wg(8) allows users to see
> what's going on with the wireguard interface, whereas networkd only
> enables setting up the interface but after doesn't give much
> visibility into what's going on. So all users who run wireguard
> probably want wg(8), and only some users who run wireguard
> additionally will want systemd-networkd. But as I said, I don't know
> what the Debian recommendations are supposed to be precisely, so you
> can decide this better than me.

thanks for the explanation.  debian's semantics are:

   https://www.debian.org/doc/debian-policy/#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

Basically, Recommends: isn't the same as a hard Depends: -- it's
possible to ignore a Recommends: on systems you want to consciously keep
minimal.

The disjunction (A | B) means "if one of A or B is installed, don't bother
trying to satisfy the other; but if neither is installed, install A".


systemd-networkd is shipped (but by default disabled) in the systemd
package itself.

At the moment, wireguard-dkms (the kernel module package) Recommends:
wireguard-tools (which supplies wg(8)), which i'd write as:

  0)  Recommends: wireguard-tools

So i think we have several other choices:

  1)  Recommends: systemd | wireguard-tools

  2)  Recommends: wireguard-tools | systemd

  3)  Recommends: wireguard-tools, systemd

  4)  Recommends: wireguard-tools
      Suggests: systemd


Of the above, i think i'll probably either stick with 0 or move to 4.
given what you said above, i don't really like the idea of using the
disjunction; people already running systemd will have systemd-networkd
available; and i don't want the wireguard-dkms package to encourage
people to install systemd if they've already made a decision to avoid
the default and not use it.

oh, also, any reference to systemd here would probably be versioned to
be at least the first version that supports it.

let me know if you have any other preferences or suggestions.

   --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2018-01-10  7:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 13:49 Jason A. Donenfeld
2018-01-09 14:59 ` Matthias Urlichs
2018-01-09 15:20 ` Daniel Kahn Gillmor
2018-01-09 17:38   ` Jason A. Donenfeld
2018-01-10  7:09     ` Daniel Kahn Gillmor [this message]
2018-01-10  8:50       ` Matthias Urlichs
2018-01-10 22:30         ` Daniel Kahn Gillmor
2018-01-11  6:37           ` Stefan Tatschner
2018-01-11 13:43             ` Daniel Kahn Gillmor
2018-01-11 15:02               ` Jason A. Donenfeld
2018-01-11 23:38                 ` Daniel Kahn Gillmor
2018-01-12 15:50                   ` Egbert Verhage
2018-01-12 19:45                     ` Jason A. Donenfeld
2018-01-12  7:40               ` Stefan Tatschner
2018-01-10  8:59       ` Jonathon Fernyhough
2018-01-11 15:00       ` Jason A. Donenfeld
2018-01-09 17:19 ` Germano Massullo
2018-01-13 16:30   ` Some gossip M. Dietrich
2018-01-13 21:25     ` Jason A. Donenfeld
2018-01-30 12:07 ` WireGuard in systemd-networkd Jörg Thalheim

Reply instructions:

You may reply publicly 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=87efmy42c0.fsf@fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=Jason@zx2c4.com \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).