[bug#68675,v2] services: dhcp: Support the dhcpcd implementation.

From: Sören Tempel <soeren@soeren-tempel.net>

Prior to this commit, the isc-dhcp implementation was the only DHCP
implementation supported by dhcp-client-shepherd-service. This is
problematic as the ISC implementation has reached end-of-life in
2022(!). As a first step to migrate away from isc-dhcp, this commit
adds support for dhcpcd to dhcp-client-shepherd-service. Currently,
it has to be enabled explicitly via the package field of the
dhcp-client-configuration. In the future, it is intended to become
the default to migrate away from isc-dhcp.

While at it, also remove isc-dhcp from %base-packages as it is no
longer necessarily needed and it will be pulled in by the DHCP
client service if required.

See also: https://issues.guix.gnu.org/68619

* gnu/services/networking.scm (dhcp-client-shepherd-service): Add
  support for the dhcpcd client implementation.
* gnu/services/networking.scm (dhcp-client-account-service): New
  procedure.
* gnu/services/networking.scm (dhcp-client-service-type): Add optional
  account-service-type extensions (needed for dhcpcd).
* gnu/system.scm (%base-packages-networking): Remove isc-dhcp from
  %base-packages (will be pulled in by dhcp-client-shepherd-service).

Signed-off-by: Sören Tempel <soeren@soeren-tempel.net>
---
Changes since v1:

* Remove isc-dhcp from %base-packages

 gnu/services/networking.scm | 84 ++++++++++++++++++++++++++-----------
 gnu/system.scm              |  2 +-
 2 files changed, 61 insertions(+), 25 deletions(-)

soeren@soeren-tempel.net skribis:

> From: Sören Tempel <soeren@soeren-tempel.net>
>
> Prior to this commit, the isc-dhcp implementation was the only DHCP
> implementation supported by dhcp-client-shepherd-service. This is
> problematic as the ISC implementation has reached end-of-life in
> 2022(!). As a first step to migrate away from isc-dhcp, this commit
> adds support for dhcpcd to dhcp-client-shepherd-service. Currently,
> it has to be enabled explicitly via the package field of the
> dhcp-client-configuration. In the future, it is intended to become
> the default to migrate away from isc-dhcp.
>
> While at it, also remove isc-dhcp from %base-packages as it is no
> longer necessarily needed and it will be pulled in by the DHCP
> client service if required.
>
> See also: https://issues.guix.gnu.org/68619
>
> * gnu/services/networking.scm (dhcp-client-shepherd-service): Add
>   support for the dhcpcd client implementation.
> * gnu/services/networking.scm (dhcp-client-account-service): New
>   procedure.
> * gnu/services/networking.scm (dhcp-client-service-type): Add optional
>   account-service-type extensions (needed for dhcpcd).
> * gnu/system.scm (%base-packages-networking): Remove isc-dhcp from
>   %base-packages (will be pulled in by dhcp-client-shepherd-service).
>
> Signed-off-by: Sören Tempel <soeren@soeren-tempel.net>

Much welcome improvement!

Some comments:

> +     (let* ((package (dhcp-client-configuration-package config))
> +            (client-name (package-name package))
> +            (requirement (dhcp-client-configuration-shepherd-requirement config))
> +            (provision (dhcp-client-configuration-shepherd-provision config))
> +            (interfaces (dhcp-client-configuration-interfaces config)))

Instead of calling ‘package-name’, which would prevent the use of
something other than a <package> record (such as an <inferior-package>)
or a package with a different name (like “dhcpcd-next”), what about
checking in the gexp which of /bin/dhclient and /bin/dhcpcd exists?

>                (start #~(lambda _
> -                         (define dhclient
> -                           (string-append #$package "/sbin/dhclient"))
> +                         (use-modules (ice-9 popen)
> +                                      (ice-9 rdelim))

Instead of ‘use-modules’ within a function, which has ill-defined
semantics, add a ‘modules’ field to the ‘shepherd-service’ form.

> +                         ;; Returns the execution configuration for the DHCP client
> +                         ;; selected by the package field of dhcp-client-configuration.
> +                         ;; The configuration is a pair of pidfile and execution command
> +                         ;; where the latter is a list.
> +                         (define exec-config
> +                           (case (string->symbol #$client-name)
> +                             ((isc-dhcp)
> +                              (let ((pid-file "/var/run/dhclient.pid"))
> +                                (cons
> +                                  (cons* (string-append #$package "/sbin/dhclient")
> +                                         "-nw" "-I" "-pf" pid-file ifaces)
> +                                  pid-file)))
> +                             ((dhcpcd)
> +                              ;; For dhcpcd, the utilized pid-file depends on the
> +                              ;; command-line arguments.  If multiple interfaces are
> +                              ;; given, a different pid-file is returned.  Hence, we
> +                              ;; consult dhcpcd itself to determine the pid-file.
> +                              (let* ((cmd (string-append #$package "/sbin/dhcpcd"))
> +                                     (arg (cons* cmd "-b" ifaces)))
> +                                (cons arg
> +                                  (let* ((pipe (string-join (append arg '("-P")) " "))
> +                                         (port (open-input-pipe pipe))
> +                                         (path (read-line port)))
> +                                    (close-pipe port)
> +                                    path))))

That sounds quite complex.  Surely there must be a way to force the name
of the PID file or to determine its name without running dhcpcd in a
pipe?

> +                             (else
> +                               (error (G_ "unknown 'package' value in dhcp-client-configuration")))))

‘G_’ here is undefined, a ‘error’ doesn’t do what you perhaps think it
does (it throws to ‘misc-error’).

Instead, I would just print a message to the current error port (it’ll
be logged) and have ‘start’ return #f, meaning that the service failed
to start.
> +++ b/gnu/system.scm
> @@ -917,7 +917,7 @@ (define %base-packages-interactive
>  
>  (define %base-packages-networking
>    ;; Default set of networking packages.
> -  (list inetutils isc-dhcp
> +  (list inetutils

I would leave this change for a separate patch.

Or leave it out entirely: I find it useful to have a DHCP client at hand
just in case.  Thoughts?

Could you send updated patches?

Thanks,
Ludo’.

Hi Ludovic,

Thanks a lot for the feedback, really truly helpful! More comments below.

Ludovic Courtès <ludo@gnu.org> wrote:
> Instead of calling ‘package-name’, which would prevent the use of
> something other than a <package> record (such as an <inferior-package>)
> or a package with a different name (like “dhcpcd-next”), what about
> checking in the gexp which of /bin/dhclient and /bin/dhcpcd exists?

I think I haven't fully grasped G-Expressions yet. I do understand how
this would work inside the shepherd start gexp. However, I am not sure
how I would check if /bin/dhclient or /bin/dhcpcd exist in the package
within the dhcp-client-account-service since, at least as far as
I understand, the dhcp-client-account-service is itself not a gexp.

I think one could also argue that it might be preferable to check for
the package name as, just because a package provides /bin/dhclient,
doesn't necessarily mean that it is command-line compatible with the ISC
implementation. However, if you have any hints on updating the
account-service I would be willing to look into it.

> That sounds quite complex.  Surely there must be a way to force the name
> of the PID file or to determine its name without running dhcpcd in a
> pipe?

Unfortunately, I don't think there is any way to force the PID file
name. Furthermore, the pidfile path depends on the amount interfaces
specified. If there is only one interface, a single dhcpcd instance is
spawned and the pidfile refers to that. Otherwise, a management process
is started and the pidfile refers to the management process [1].

I think the best solution here would be to spawn dhcpcd as child process
of GNU shepherd and have shepherd supervise it that way. I have a service
doing that too, but its annoying to integrate with the existing dhclient
service [2]. Maybe that's something we can migrate to in the long run.

> Or leave it out entirely: I find it useful to have a DHCP client at hand
> just in case.  Thoughts?

I removed it, I agree that this change is best discussed separately.

> Could you send updated patches?

Apart from the two comments I discussed in greater detail above, I hope
I implemented all of your feedback as requested in the v3 revision of
this patchset. Please let me know if I missed anything.

Greetings
Sören

[1]: https://github.com/NetworkConfiguration/dhcpcd/blob/v10.0.6/src/dhcpcd.c#L2144
[2]: https://github.com/nmeum/guix-channel/blob/b1b80697a9d35ca015ce56ccf3031f91f2bf554f/src/nmeum/services/networking.scm#L130-L132

Hi Sören,

Apologies for the late reply.

Sören Tempel <soeren@soeren-tempel.net> skribis:

> Ludovic Courtès <ludo@gnu.org> wrote:
>> Instead of calling ‘package-name’, which would prevent the use of
>> something other than a <package> record (such as an <inferior-package>)
>> or a package with a different name (like “dhcpcd-next”), what about
>> checking in the gexp which of /bin/dhclient and /bin/dhcpcd exists?
>
> I think I haven't fully grasped G-Expressions yet. I do understand how
> this would work inside the shepherd start gexp. However, I am not sure
> how I would check if /bin/dhclient or /bin/dhcpcd exist in the package
> within the dhcp-client-account-service since, at least as far as
> I understand, the dhcp-client-account-service is itself not a gexp.

I meant, within the ‘start’ method, something like:

  (start #~(…
             ;; Check whether we’re dealing with ISC’s dhclient or dhcpcd.
             (let ((type (if (file-exists?
                              (string-append #$package "/bin/dhclient"))
                             'isc-dhcp
                             'dhcpcd)))
               (fork+exec-command …))))

Does that make sense?

>> That sounds quite complex.  Surely there must be a way to force the name
>> of the PID file or to determine its name without running dhcpcd in a
>> pipe?
>
> Unfortunately, I don't think there is any way to force the PID file
> name. Furthermore, the pidfile path depends on the amount interfaces
> specified. If there is only one interface, a single dhcpcd instance is
> spawned and the pidfile refers to that. Otherwise, a management process
> is started and the pidfile refers to the management process [1].
>
> I think the best solution here would be to spawn dhcpcd as child process
> of GNU shepherd and have shepherd supervise it that way. I have a service
> doing that too, but its annoying to integrate with the existing dhclient
> service [2]. Maybe that's something we can migrate to in the long run.

What do others do?  I guess it’s not possible to have a systemd .service
file given those PID file semantics, is it?

Thanks,
Ludo’.