Subject: [bug#45905] [PATCH] IPFS service definition

From: Ludovic Courtès <[email-masked]>
Date: Mon, 22 Mar 2021 18:17:49 +0100

Hi Maxime,

Maxime Devos <[email-masked]> skribis:

> A patch defining simple ‘ipfs-service-type’ is attached. I've tested
> this in a VM, and will test it on a ‘real’ system later. The gateway
> is currently broken, it tries to redirect to non-existent subdomains
> of localhost. Correcting this might require fiddling with the DNS
> configuration.

OK.  That doesn’t prevent one from using it, right?

> From c441bca727df67837652eb2f0b5ad23528fd11a3 Mon Sep 17 00:00:00 2001
> From: Maxime Devos <[email-masked]>
> Date: Fri, 15 Jan 2021 21:46:42 +0100
> Subject: [PATCH] services: Add ipfs-service-type
>
> * gnu/services/networking.scm (ipfs-service-type)
>   (%ipfs-home-mapping, %ipfs-environment)
>   (%ipfs-accounts, %ipfs-home): New variables.
>   (ipfs-configuration, ipfs-configuration?)
>   (ipfs-configuration-package, ipfs-configuration-gateway)
>   (ipfs-configuration-api, ipfs-shepherd-service)
>   (ipfs-binary, %ipfs-activation): New procedures.
> * doc/guix.texi (Networking Services): Document it.

[...]

> +@lisp
> +;; part of the operating-system declaration

I think you can omit this line.

> +(service ipfs-service-type
> +              (ipfs-configuration
> +               (gateway "/ip4/127.0.0.1/tcp/8880")
> +               (api "/ip4/127.0.0.1/tcp/8881")))

Indentation is left (should be aligned with ‘ipfs-service-type’.)

> +      (start #~(make-forkexec-constructor/container
> +                #$ipfs-daemon-command
> +                #:namespaces '#$(fold delq %namespaces '(user net))
> +                #:mappings (list #$%ipfs-home-mapping)
> +                #:log-file "/var/log/ipfs.log"
> +                #:user "ipfs"
> +                #:group "ipfs"
> +                #:environment-variables #$%ipfs-environment))

Nice!

> +  ;; Run ipfs init and ipfs config from a container,
> +  ;; in case the IPFS daemon was compromised at some point
> +  ;; and ~/.ipfs is now a symlink to somewhere outside
> +  ;; %ipfs-home.
> +  (define container-gexp
> +    (with-extensions (list shepherd)
> +      (with-imported-modules (source-module-closure
> +                              '((gnu build shepherd)
> +                                (gnu system file-systems)))
> +        #~(begin
> +            (use-modules (gnu build shepherd)
> +                         (gnu system file-systems))
> +            (let* ((constructor
> +                    (make-forkexec-constructor/container
> +                     (list #$inner-script)
> +                     #:namespaces '#$(fold delq %namespaces '(user))
> +                     #:mappings (list #$%ipfs-home-mapping)
> +                     #:user "ipfs"
> +                     #:group "ipfs"
> +                     #:environment-variables #$%ipfs-environment))
> +                   (pid (constructor)))
> +              (waitpid pid))))))
> +  ;; The activation may happen from the initrd, which uses
> +  ;; a statically-linked guile, while the guix container
> +  ;; procedures require a working dynamic-link.
> +  (define container-script
> +    (program-file "ipfs-activation-container" container-gexp))
> +  #~(system* #$container-script))

That’s a bit involved, but it makes sense to me.

The patch LGTM.  However, we usually commit services along with a system
test under (gnu tests …).  The manual has info on how to run individual
system tests:

  https://guix.gnu.org/manual/en/html_node/Running-the-Test-Suite.html

Could you write a test that ensures that basic functionality works?  It
could be as simple as waiting for the service to be up, then invoking
‘ipfs add’ and ‘ipfs get’.  WDYT?

Thank you!

Ludo’.