Automatically mapping services from System to Home

Automatically mapping services from System to Home

[Ludovic Courtès]

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

One idea I toyed with is automatic translation of service types from
System to Home.  The service itself would look like this:

--8<---------------cut here---------------start------------->8---
(define-module (gnu home services syncthing)
  #:use-module (gnu home services)
  #:use-module (gnu services syncthing)
  #:export (home-syncthing-service-type)
  #:re-export (syncthing-configuration
               syncthing-configuration?))

(define home-syncthing-service-type
  (system-service-type->home-service-type syncthing-service-type))
--8<---------------cut here---------------end--------------->8---

The code to do that is attached below.  The key here is that we’d define
mappings, like:

  (define-service-type-mapping
    shepherd-root-service-type => home-shepherd-service-type)

The rest of the service type graph would be automatically constructed
from this.

I feel like it would be worth pursuing this path so that there’s as
little duplication as possible between Home and System.

OTOH, it doesn’t take care of things like #:user in
‘make-forkexec-constructor’ calls and the like.

Thoughts?

Ludo’.


[-- Attachment #2: Type: text/x-patch, Size: 4599 bytes --]

diff --git a/gnu/home/services.scm b/gnu/home/services.scm
index b7ea6f08dd..b32e7395b1 100644
--- a/gnu/home/services.scm
+++ b/gnu/home/services.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2021 Andrew Tropin <andrew@trop.in>
 ;;; Copyright © 2021 Xinglu Chen <public@yoctocell.xyz>
+;;; Copyright © 2022 Ludovic Courtès <ludo@gnu.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -31,8 +32,10 @@ (define-module (gnu home services)
   #:use-module (guix diagnostics)
   #:use-module (guix i18n)
   #:use-module (guix modules)
+  #:use-module (guix memoization)
   #:use-module (srfi srfi-1)
   #:use-module (ice-9 match)
+  #:use-module (ice-9 vlist)
 
   #:export (home-service-type
             home-profile-service-type
@@ -46,6 +49,9 @@ (define-module (gnu home services)
             fold-home-service-types
             home-provenance
 
+            define-service-type-mapping
+            system-service-type->home-service-type
+
             %initialize-gettext)
 
   #:re-export (service
@@ -396,6 +402,77 @@ (define home-activation-service-type
 reconfiguration or generation switching.  This service can be extended
 with one gexp, but many times, and all gexps must be idempotent.")))
 
+\f
+;;;
+;;; Service type graph rewriting.
+;;;
+
+(define (service-type-mapping proc)
+  (define (rewrite extension)
+    (match (proc (service-extension-target extension))
+      (#f #f)
+      (target
+       (service-extension target
+                          (service-extension-compute extension)))))
+
+  (define replace
+    (mlambdaq (type)
+      (service-type
+       (inherit type)
+       (location (service-type-location type))
+       (extensions (filter-map rewrite (service-type-extensions type))))))
+
+  replace)
+
+;; (define (service-type-extensions-rewriting replacements)
+;;   (define replace
+;;     (let ((replacements (alist->vhash replacements hashq)))
+;;       (lambda (type)
+;;         (match (vhash-assq type replacements)
+;;           (#f type)
+;;           ((_ . replacement) replacement)))))
+
+;;   (service-type-mapping replace))
+
+(define system-service-type->home-service-type
+  (let ()
+    (define (replace type)
+      (define replacement
+        (hashq-ref %system/home-service-type-mapping type
+                   *unspecified*))
+
+      (if (eq? replacement *unspecified*)
+          type
+          replacement))
+
+    (service-type-mapping replace)))
+
+(define %system/home-service-type-mapping
+  (make-hash-table))
+
+(define-syntax define-service-type-mapping
+  (syntax-rules (=>)
+    ((_ system-type => home-type)
+     (hashq-set! %system/home-service-type-mapping
+                 system-type home-type))))
+
+(define-syntax define-service-type-mappings
+  (syntax-rules (=>)
+    ((_ (system-type => home-type) ...)
+     (begin
+       (define-service-type-mapping system-type => home-type)
+       ...))))
+
+(define-service-type-mappings
+  (system-service-type => home-service-type)
+  (activation-service-type => home-activation-service-type))
+
+;; (define system->home-service-type
+;;   (service-type-extensions-rewriting
+;;    `((,system-service-type . ,home-service-type)
+;;      (,activation-service-type . ,home-activation-service-type)
+;;      (,shepherd-root-service-type . ,home-shepherd-service-type))))
+
 \f
 ;;;
 ;;; On-change.
diff --git a/gnu/home/services/shepherd.scm b/gnu/home/services/shepherd.scm
index 7a9cc064bb..21b73d8cdf 100644
--- a/gnu/home/services/shepherd.scm
+++ b/gnu/home/services/shepherd.scm
@@ -131,4 +131,5 @@ (define-public home-shepherd-service-type
                 (default-value (home-shepherd-configuration))
                 (description "Configure and install userland Shepherd.")))
 
-
+(define-service-type-mapping
+  shepherd-root-service-type => home-shepherd-service-type)
diff --git a/gnu/services/syncthing.scm b/gnu/services/syncthing.scm
index 7c3d5b027d..130a87705e 100644
--- a/gnu/services/syncthing.scm
+++ b/gnu/services/syncthing.scm
@@ -57,7 +57,7 @@ (define syncthing-shepherd-service
       (shepherd-service
        (provision (list (string->symbol (string-append "syncthing-" user))))
        (documentation "Run syncthing.")
-       (requirement '(loopback))
+       ;; (requirement '(loopback))
        (start #~(make-forkexec-constructor
                  (append (list (string-append #$syncthing "/bin/syncthing")
                                "-no-browser"

Re: Automatically mapping services from System to Home

[Attila Lendvai]

> Thoughts?

my gut reaction is that whatever the automatic mapping does should be captured/reified into the code that defines a service... factoring out the common parts, and adding on top of that whatever is necessary in the two different contexts.

but then i'm not sure i fully understand the differences between these two contexts, and i don't have a proposal.diff either, so...

BTW, what are the differences?

 - a possible call to setuid/setgid, and their values in the config if
   the service is not to be started as root?

 - the default values of the config file and log file(s)? possibly
   some service-specific values in the config whose default value
   depend on the user/group under which the service is running?

maybe the user/group should be a mandatory value under the hood, and the service code should dispatch on their values and the current effective user/group id, and act accordingly?

what am i missing?

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The moral law is one of the basic laws of the universe. It is likewise called the principle of Karma, the result of cause and effect, or action and reaction. There is nothing vindictive about this principle. It works impersonally like any law of nature. As the fruit is contained in the seed, so the consequences are inherent in the act. This principle guides the destinies of both people and nations. Knowledge of this principle gives human beings the power to control our own destiny.”
	— Thor Kiimaletho

Re: Automatically mapping services from System to Home

[Bruno Victal]

Hi Ludo’,

On 2023-03-28 17:18, Ludovic Courtès wrote:
> One idea I toyed with is automatic translation of service types from
> System to Home.  The service itself would look like this:
> 
> --8<---------------cut here---------------start------------->8---
> (define-module (gnu home services syncthing)
>   #:use-module (gnu home services)
>   #:use-module (gnu services syncthing)
>   #:export (home-syncthing-service-type)
>   #:re-export (syncthing-configuration
>                syncthing-configuration?))
> 
> (define home-syncthing-service-type
>   (system-service-type->home-service-type syncthing-service-type))
> --8<---------------cut here---------------end--------------->8---
> 
> The code to do that is attached below.  The key here is that we’d define
> mappings, like:
> 
>   (define-service-type-mapping
>     shepherd-root-service-type => home-shepherd-service-type)
> 
> The rest of the service type graph would be automatically constructed
> from this.
> 
> I feel like it would be worth pursuing this path so that there’s as
> little duplication as possible between Home and System.
> 
> OTOH, it doesn’t take care of things like #:user in
> ‘make-forkexec-constructor’ calls and the like.
> 

I've been thinking that shepherd services should, in general, come with a
preamble in their configuration record-types. (perhaps à la SRFI-136 parent-style records?)

Below is a non-exhaustive list of “things” that should almost always be configurable,
unless it's reasonable to omit it:

--8<---------------cut here---------------start------------->8---
;; These fields were listed based on “experience” in reworking,
;; repurposing and adding new (system) services within Guix.


(define-configuration example-configuration
  ;; Allow the package to be overridden.
  (package
    file-like
    "Lorem ipsum …")

  ;; Note that they're not strings. This allows for tailoring
  ;; the user-account used by the service (e.g. adding extra groups
  ;; for the daemon to have access to other directories, etc.
  (user
    user-account
    "Lorem ipsum …")

  ;; ^^^^^ Ditto.
  (group
   user-group
   "Lorem ipsum …")

  (shepherd-requirement   ; or shepherd-requirements, the former already has some presence in Guix
                          ; but could be phased-out in favor of the plural form
    list-of-symbols
    "Lorem ipsum …")

  ;; Uncommonly seen among services
  ;; but mpd-service-type is an example where this is important.
  (environment-variables
    list-of-env-vars
    "Lorem ipsum …")

--8<---------------cut here---------------end--------------->8---


Tossing another idea in the air, with <https://issues.guix.gnu.org/62298>
define-configuration could perhaps be enriched with additional parameters to 
hint that certain fields should be treated differently depending
on “context”? Naturally the service code will have to be adjusted
to use these hints, but overall it should result in a much cleaner
way to guide serializations and service-extension pruning.


It could be something of the sort:

--8<---------------cut here---------------start------------->8---
(define-configuration example-configuration
  …

  (user
    user-account
    "Lorem ipsum …"
   (attributes 'system-service)
  …)

;; or
(define-configuration example-configuration
  …

  (user
    user-account
    "Lorem ipsum …"
    system-only
  …)


;; or
(define-configuration example-configuration
  …

  (user
    user-account
    "Lorem ipsum …"
    (system #t)
    (home #f)
  …)
--8<---------------cut here---------------end--------------->8---


Cheers,
Bruno

[bug#62401] [PATCH] home: Add home-syncthing-service-type.

[Ludovic Courtès]

Hi Bruno, Sergey, and all,

<https://issues.guix.gnu.org/65119> is an attempt to provide a
consistent and simple way to “port” System services to Home, including
Syncthing, as discussed in this thread.

Let me know what you think!

Ludo’.