GNU bug report logs - #73467
[PATCH] Wireguard: Add autostart? field.

Previous Next

Full log

Message #14 received at 73467 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Apoorv Singh <apoorvs569 <at> gmail.com>
Cc: 73467 <at> debbugs.gnu.org
Subject: Re: [bug#73467] [PATCH] Wireguard: Add autostart? field.
Date: Thu, 03 Oct 2024 21:37:24 +0900

Hello,

Apoorv Singh <apoorvs569 <at> gmail.com> writes:

> The following patch adds a record field autostart? which can be used
> by the user to configure weather the wireguard service should start
> automatically. This field is helpful for people who might have limited
> bandwidth and/or they don't want the wireguard service to start at
> boot which in turn starts the VPN without them knowing as it can
> result in un-desired usage of their bandwidth etc.
>
> I personally have limited bandwidth on the VPS I am running the
> wireguard VPN on and don't want to use it all the time, and this
> options will fix that, as I sometimes forget that I have it turned on

I guess you are also re-routing all of your traffic to your wireguard
interface?  I have such a setup, and I've configured wireguard via
NetworkManager for this case, as it's more conveniently turned on & off,
even from GNOME's UI [0].

[0]  https://lists.gnu.org/archive/html/help-guix/2024-09/msg00032.html

Also, by default, a Wireguard tunnel doesn't consume any data (no pings,
nothing) until traffic is sent to it, so it shouldn't be an issue until
you use it.

>>From 378f72413697e418061fe359acddf24d6afe1add Mon Sep 17 00:00:00 2001
> From: apoorv569 <apoorvs569 <at> gmail.com>
> Date: Wed, 25 Sep 2024 09:10:36 +0530
> Subject: [PATCH 2/2] Wireguard add autostart? field
>
> ---
>  gnu/services/vpn.scm | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/services/vpn.scm b/gnu/services/vpn.scm
> index 449909e34d..eee7e78c6d 100644
> --- a/gnu/services/vpn.scm
> +++ b/gnu/services/vpn.scm
> @@ -86,6 +86,7 @@ (define-module (gnu services vpn)
>              wireguard-configuration-pre-down
>              wireguard-configuration-post-down
>              wireguard-configuration-table
> +            wireguard-configuration-autostart?
>
>              wireguard-service-type))
>
> @@ -760,7 +761,9 @@ (define-record-type* <wireguard-configuration>
>    (post-down          wireguard-configuration-post-down ;list of strings
>                        (default '()))
>    (table              wireguard-configuration-table ;string
> -                      (default "auto")))
> +                      (default "auto"))
> +  (autostart?         wireguard-configuration-autostart?
> +                      (default #f)))

IIUC, this would mean the wireguard service would not longer start *by
default*, breaking users configs and more importantly expectations
(since it'd be different to most other services in this respect).

>  (define (wireguard-configuration-file config)
>    (define (peer->config peer)
> @@ -907,7 +910,8 @@ (define (wireguard-shepherd-service config)
>    (match-record config <wireguard-configuration>
>      (wireguard interface)
>      (let ((wg-quick (file-append wireguard "/bin/wg-quick"))
> -          (config (wireguard-configuration-file config)))
> +          (config (wireguard-configuration-file config))
> +          (autostart (wireguard-configuration-autostart? config)))
>        (list (shepherd-service
>               (requirement '(networking))
>               (provision (list (wireguard-service-name interface)))
> @@ -916,6 +920,7 @@ (define (wireguard-shepherd-service config)
>               (stop #~(lambda _
>                         (invoke #$wg-quick "down" #$config)
>                         #f))                       ;stopped!
> +             (auto-start? autostart)

Like Sergey, I agree it'd be useful to expose an auto-start? value, and
I'd also like to see some way to make this exposed to all services, as
something inherited (though I'm not sure how that could be achieved with
our current structure).

But as a start, if it's really useful (seem my first comment above
regarding bandwidth usage), we could do it this way, as long as it
doesn't change the default behavior (default #f)

It'd also need to be documented in doc/guix.texi.

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.