[bug#62401] Automatically mapping services from System to Home

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’.

> 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?

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

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’.