Package: guix-patches;
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Tue, 30 May 2017 22:00:02 UTC
Severity: important
Tags: patch
To reply to this bug, email your comments to 27155 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Tue, 30 May 2017 22:00:02 GMT) Full text and rfc822 format available.Ludovic Courtès <ludo <at> gnu.org>:guix-patches <at> gnu.org.
(Tue, 30 May 2017 22:00:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: guix-patches <at> gnu.org Cc: Alex Kost <alezost <at> gmail.com>, Ludovic Courtès <ludo <at> gnu.org> Subject: [PATCH 0/2] Support service extensions on the "final" service values Date: Tue, 30 May 2017 23:58:50 +0200
Hello!
This patch adds support for service extensions that modify the
"final" values of a service. This is meant to implement cross-cutting
concerns as well as system-wide customization as discussed with Alex
long ago:
https://lists.gnu.org/archive/html/guix-devel/2015-11/msg00623.html
https://lists.gnu.org/archive/html/guix-devel/2016-09/msg01505.html
To summarize, a "finalization extension" (for lack of a better name)
gets the final value of a service and returns a new value for that
service. This is in contrast with a "normal" extension which can only
contribute to the value of a target service, and not inspect the value
of that target service.
For example, for the /etc service, a "normal" extension can only add
entries for /etc. A "finalization" extension can instead inspect and
change all the /etc entries. IOW, it is a sort of a "sudo" for service
extensions; it's also quite inelegant compared to the "normal" extension
mechanism, but it's certainly useful.
A use case is given in the second patch: we change all the PAM services
to use pam_elogind.so or pam_limits.so. Likewise, the 'rename-etc-files'
service below shows how to rename all the files in /etc (for illustration
purposes only :-)):
(define rename-etc-files
(let ((rename (lambda (prefix entries)
(map (match-lambda
((name . rest)
(cons (string-append prefix name)
rest)))
entries))))
(service-type
(name 'rename-etc-files)
(extensions (list (service-extension etc-service-type
(const '())
rename))))))
(operating-system
;; ...
(services (cons* (service rename-etc-files "foo-")
...)))
I think this should fulfill the need that Alex had expressed, which is
to not only be able to add files to /etc, but also to have the ability
to inspect and modify what goes to /etc.
The first patch currently lacks doc. I'll work on it if there's consensus
on the approach.
Feedback welcome!
Ludo'.
Ludovic Courtès (2):
DRAFT services: Extensions can specify a "finalization" procedure.
system: pam: Remove custom API to transform PAM services.
gnu/services.scm | 52 ++++++++++++++++++++++++++++++++++++++----------
gnu/services/base.scm | 33 ++++++++++++++++--------------
gnu/services/desktop.scm | 23 +++++++++++----------
gnu/system/pam.scm | 44 ++++++++--------------------------------
tests/services.scm | 34 +++++++++++++++++++++++++++++++
5 files changed, 114 insertions(+), 72 deletions(-)
--
2.13.0
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Tue, 30 May 2017 22:06:02 GMT) Full text and rfc822 format available.Message #8 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: 27155 <at> debbugs.gnu.org Cc: Alex Kost <alezost <at> gmail.com>, Ludovic Courtès <ludo <at> gnu.org> Subject: [PATCH 1/2] DRAFT services: Extensions can specify a "finalization" procedure. Date: Wed, 31 May 2017 00:05:08 +0200
TODO: Add doc
* gnu/services.scm (<service-extension>)[finalize]: New field.
Rename 'service-extension' to '%service-extension'.
(right-identity): New procedure.
(service-extension): New macro.
(fold-services)[apply-finalization, compose*]: New procedures.
Honor finalizations.
* tests/services.scm ("fold-services with finalizations"): New test.
---
gnu/services.scm | 52 ++++++++++++++++++++++++++++++++++++++++++----------
tests/services.scm | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 10 deletions(-)
diff --git a/gnu/services.scm b/gnu/services.scm
index 5c314748d..4ebce753b 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -119,10 +119,24 @@
;;; Code:
(define-record-type <service-extension>
- (service-extension target compute)
+ (%service-extension target compute finalize)
service-extension?
- (target service-extension-target) ;<service-type>
- (compute service-extension-compute)) ;params -> params
+ (target service-extension-target) ;<service-type>
+ (compute service-extension-compute) ;value -> extension value
+ (finalize service-extension-finalize)) ;self other -> other
+
+(define (right-identity a b) b)
+
+(define-syntax service-extension
+ (syntax-rules ()
+ "Instantiate an extension of services of type TARGET. COMPUTE takes the
+value of the source service and returns the extension value of the target.
+Optionally, FINALIZE takes the value of the source service and the final value
+of the target, and returns a new value for the target."
+ ((_ target compute)
+ (%service-extension target compute right-identity))
+ ((_ target compute finalize)
+ (%service-extension target compute finalize))))
(define &no-default-value
;; Value used to denote service types that have no associated default value.
@@ -664,6 +678,21 @@ TARGET-TYPE; return the root service adjusted accordingly."
(($ <service-extension> _ compute)
(compute (service-value service))))))
+ (define (apply-finalization target)
+ (lambda (service)
+ (match (find (matching-extension target)
+ (service-type-extensions (service-kind service)))
+ (($ <service-extension> _ _ finalize)
+ (lambda (final)
+ (finalize (service-value service) final))))))
+
+ (define (compose* procs)
+ (match procs
+ (()
+ identity)
+ (_
+ (apply compose procs))))
+
(match (filter (lambda (service)
(eq? (service-kind service) target-type))
services)
@@ -671,15 +700,18 @@ TARGET-TYPE; return the root service adjusted accordingly."
(let loop ((sink sink))
(let* ((dependents (map loop (dependents sink)))
(extensions (map (apply-extension sink) dependents))
+ ;; We distinguish COMPOSE and EXTEND because PARAMS typically
+ ;; has a different type than the elements of EXTENSIONS.
(extend (service-type-extend (service-kind sink)))
(compose (service-type-compose (service-kind sink)))
- (params (service-value sink)))
- ;; We distinguish COMPOSE and EXTEND because PARAMS typically has a
- ;; different type than the elements of EXTENSIONS.
- (if extend
- (service (service-kind sink)
- (extend params (compose extensions)))
- sink))))
+ (value (if extend
+ (extend (service-value sink)
+ (compose extensions))
+ (service-value sink)))
+ (kind (service-kind sink))
+ (finalizations (map (apply-finalization sink)
+ dependents)))
+ (service kind ((compose* finalizations) value)))))
(()
(raise
(condition (&missing-target-service-error
diff --git a/tests/services.scm b/tests/services.scm
index 8484ee982..bb42e352a 100644
--- a/tests/services.scm
+++ b/tests/services.scm
@@ -88,6 +88,40 @@
(and (eq? (service-kind r) t1)
(service-value r))))
+(test-equal "fold-services with finalizations"
+ '(final 600 (initial-value 5 4 3 2 1 xyz 600))
+
+ ;; Similar to the one above, but this time with "finalization" extensions
+ ;; that modify the final result of compose/extend.
+ (let* ((t1 (service-type (name 't1) (extensions '())
+ (compose concatenate)
+ (extend cons)))
+ (t2 (service-type (name 't2)
+ (extensions
+ (list (service-extension t1
+ (cut list 'xyz <>)
+ (lambda (t2 t1)
+ `(final ,t2 ,t1)))))
+ (compose (cut reduce + 0 <>))
+ (extend *)))
+ (t3 (service-type (name 't3)
+ (extensions
+ (list (service-extension t2 identity)
+ (service-extension t1 list)))))
+ (t4 (service-type (name 't4)
+ (extensions
+ (list (service-extension t2 (const 0)
+ *)))))
+ (r (fold-services (cons* (service t1 'initial-value)
+ (service t2 4)
+ (service t4 10)
+ (map (lambda (x)
+ (service t3 x))
+ (iota 5 1)))
+ #:target-type t1)))
+ (and (eq? (service-kind r) t1)
+ (service-value r))))
+
(test-assert "fold-services, ambiguity"
(let* ((t1 (service-type (name 't1) (extensions '())
(compose concatenate)
--
2.13.0
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Tue, 30 May 2017 22:06:02 GMT) Full text and rfc822 format available.Message #11 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: 27155 <at> debbugs.gnu.org Cc: Alex Kost <alezost <at> gmail.com>, Ludovic Courtès <ludo <at> gnu.org> Subject: [PATCH 2/2] system: pam: Remove custom API to transform PAM services. Date: Wed, 31 May 2017 00:05:09 +0200
This specific way to extend 'pam-root-service-type' has been subsumed by
the "finalization extensions" of services.
* gnu/system/pam.scm (<pam-configuration>): Remove.
(/etc-entry): Adjust accordingly.
(extend-configuration): Remove.
(pam-root-service-type)[extend]: Set to 'append'.
(pam-root-service): Remove #:transform parameter. Adjust 'service'
form.
* gnu/services/desktop.scm (pam-extension-procedure): Rename to...
(elogind-pam-extension): ... this. Expect the complete list of
services and map over it.
(elogind-service-type): Change PAM-ROOT-SERVICE-TYPE extension to refer
to 'elogind-pam-extension'.
* gnu/services/base.scm (limits-pam-extension): New procedure.
(pam-limits-service-type): Remove 'pam-extension' procedure. Adjust
PAM-ROOT-SERVICE-TYPE extension accordingly.
---
gnu/services/base.scm | 33 ++++++++++++++++++---------------
gnu/services/desktop.scm | 23 ++++++++++++-----------
gnu/system/pam.scm | 44 ++++++++------------------------------------
3 files changed, 38 insertions(+), 62 deletions(-)
diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 7cd9a34ca..d36f5c410 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -1239,6 +1239,21 @@ information on the configuration file syntax."
(service syslog-service-type config))
+(define (limits-pam-extension limits-file pam-services)
+ "Modify some of PAM-SERVICES to use 'pam_limits.so'."
+ (map (lambda (pam)
+ (let ((pam-limits (pam-entry
+ (control "required")
+ (module "pam_limits.so")
+ (arguments '("conf=/etc/security/limits.conf")))))
+ (if (member (pam-service-name pam) '("login" "su" "slim"))
+ (pam-service
+ (inherit pam)
+ (session (cons pam-limits
+ (pam-service-session pam))))
+ pam)))
+ pam-services))
+
(define pam-limits-service-type
(let ((security-limits
;; Create /etc/security containing the provided "limits.conf" file.
@@ -1250,26 +1265,14 @@ information on the configuration file syntax."
(mkdir #$output)
(stat #$limits-file)
(symlink #$limits-file
- (string-append #$output "/limits.conf"))))))))
- (pam-extension
- (lambda (pam)
- (let ((pam-limits (pam-entry
- (control "required")
- (module "pam_limits.so")
- (arguments '("conf=/etc/security/limits.conf")))))
- (if (member (pam-service-name pam)
- '("login" "su" "slim"))
- (pam-service
- (inherit pam)
- (session (cons pam-limits
- (pam-service-session pam))))
- pam)))))
+ (string-append #$output "/limits.conf")))))))))
(service-type
(name 'limits)
(extensions
(list (service-extension etc-service-type security-limits)
(service-extension pam-root-service-type
- (lambda _ (list pam-extension))))))))
+ (const '())
+ limits-pam-extension))))))
(define* (pam-limits-service #:optional (limits '()))
"Return a service that makes selected programs respect the list of
diff --git a/gnu/services/desktop.scm b/gnu/services/desktop.scm
index 36049587d..6495bc94c 100644
--- a/gnu/services/desktop.scm
+++ b/gnu/services/desktop.scm
@@ -1,5 +1,5 @@
;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2014, 2015, 2016 Ludovic Courtès <ludo <at> gnu.org>
+;;; Copyright © 2014, 2015, 2016, 2017 Ludovic Courtès <ludo <at> gnu.org>
;;; Copyright © 2015 Andy Wingo <wingo <at> igalia.com>
;;; Copyright © 2015 Mark H Weaver <mhw <at> netris.org>
;;; Copyright © 2016 Sou Bunnbu <iyzsong <at> gmail.com>
@@ -637,21 +637,21 @@ include the @command{udisksctl} command, part of UDisks, and GNOME Disks."
"ELOGIND_CONF_FILE"
(elogind-configuration-file config))))
-(define (pam-extension-procedure config)
- "Return an extension for PAM-ROOT-SERVICE-TYPE that ensures that all the PAM
-services use 'pam_elogind.so', a module that allows elogind to keep track of
-logged-in users (run 'loginctl' to see elogind's world view of users and
-seats.)"
+(define (elogind-pam-extension config pam-services)
+ "Change PAM-SERVICES so that each of them uses 'pam_elogind.so', a module
+that allows elogind to keep track of logged-in users (run 'loginctl' to see
+elogind's world view of users and seats), and return that."
(define pam-elogind
(pam-entry
(control "required")
(module (file-append (elogind-package config)
"/lib/security/pam_elogind.so"))))
- (list (lambda (pam)
- (pam-service
- (inherit pam)
- (session (cons pam-elogind (pam-service-session pam)))))))
+ (map (lambda (pam)
+ (pam-service
+ (inherit pam)
+ (session (cons pam-elogind (pam-service-session pam)))))
+ pam-services))
(define elogind-service-type
(service-type (name 'elogind)
@@ -669,7 +669,8 @@ seats.)"
;; Extend PAM with pam_elogind.so.
(service-extension pam-root-service-type
- pam-extension-procedure)
+ (const '())
+ elogind-pam-extension)
;; We need /run/user, /run/systemd, etc.
(service-extension file-system-service-type
diff --git a/gnu/system/pam.scm b/gnu/system/pam.scm
index eedf93394..b1bfab7ba 100644
--- a/gnu/system/pam.scm
+++ b/gnu/system/pam.scm
@@ -1,5 +1,5 @@
;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2013, 2014, 2015, 2016 Ludovic Courtès <ludo <at> gnu.org>
+;;; Copyright © 2013, 2014, 2015, 2016, 2017 Ludovic Courtès <ludo <at> gnu.org>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -281,50 +281,22 @@ authenticate to run COMMAND."
;;; PAM root service.
;;;
-;; Overall PAM configuration: a list of services, plus a procedure that takes
-;; one <pam-service> and returns a <pam-service>. The procedure is used to
-;; implement cross-cutting concerns such as the use of the 'elogind.so'
-;; session module that keeps track of logged-in users.
-(define-record-type* <pam-configuration>
- pam-configuration make-pam-configuration? pam-configuration?
- (services pam-configuration-services) ;list of <pam-service>
- (transform pam-configuration-transform)) ;procedure
-
-(define (/etc-entry config)
+(define (/etc-entry services)
"Return the /etc/pam.d entry corresponding to CONFIG."
- (match config
- (($ <pam-configuration> services transform)
- (let ((services (map transform services)))
- `(("pam.d" ,(pam-services->directory services)))))))
-
-(define (extend-configuration initial extensions)
- "Extend INITIAL with NEW."
- (let-values (((services procs)
- (partition pam-service? extensions)))
- (pam-configuration
- (services (append (pam-configuration-services initial)
- services))
- (transform (apply compose
- (pam-configuration-transform initial)
- procs)))))
+ `(("pam.d" ,(pam-services->directory services))))
(define pam-root-service-type
(service-type (name 'pam)
(extensions (list (service-extension etc-service-type
/etc-entry)))
- ;; Arguments include <pam-service> as well as procedures.
+ ;; Arguments are <pam-service> objects.
(compose concatenate)
- (extend extend-configuration)))
+ (extend append)))
-(define* (pam-root-service base #:key (transform identity))
+(define* (pam-root-service base)
"The \"root\" PAM service, which collects <pam-service> instance and turns
-them into a /etc/pam.d directory, including the <pam-service> listed in BASE.
-TRANSFORM is a procedure that takes a <pam-service> and returns a
-<pam-service>. It can be used to implement cross-cutting concerns that affect
-all the PAM services."
- (service pam-root-service-type
- (pam-configuration (services base)
- (transform transform))))
+them into a /etc/pam.d directory, including the <pam-service> listed in BASE."
+ (service pam-root-service-type base))
--
2.13.0
ludo <at> gnu.org (Ludovic Courtès)
to control <at> debbugs.gnu.org.
(Wed, 31 May 2017 13:37:01 GMT) Full text and rfc822 format available.guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Thu, 01 Jun 2017 09:58:02 GMT) Full text and rfc822 format available.Message #16 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: Alex Kost <alezost <at> gmail.com> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 27155 <at> debbugs.gnu.org Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Date: Thu, 01 Jun 2017 12:57:09 +0300
Ludovic Courtès (2017-05-30 23:58 +0200) wrote:
> Hello!
>
> This patch adds support for service extensions that modify the
> "final" values of a service. This is meant to implement cross-cutting
> concerns as well as system-wide customization as discussed with Alex
> long ago:
>
> https://lists.gnu.org/archive/html/guix-devel/2015-11/msg00623.html
> https://lists.gnu.org/archive/html/guix-devel/2016-09/msg01505.html
>
> To summarize, a "finalization extension" (for lack of a better name)
> gets the final value of a service and returns a new value for that
> service. This is in contrast with a "normal" extension which can only
> contribute to the value of a target service, and not inspect the value
> of that target service.
>
> For example, for the /etc service, a "normal" extension can only add
> entries for /etc. A "finalization" extension can instead inspect and
> change all the /etc entries. IOW, it is a sort of a "sudo" for service
> extensions; it's also quite inelegant compared to the "normal" extension
> mechanism, but it's certainly useful.
Definitely!
> A use case is given in the second patch: we change all the PAM services
> to use pam_elogind.so or pam_limits.so. Likewise, the 'rename-etc-files'
> service below shows how to rename all the files in /etc (for illustration
> purposes only :-)):
>
> (define rename-etc-files
> (let ((rename (lambda (prefix entries)
> (map (match-lambda
> ((name . rest)
> (cons (string-append prefix name)
> rest)))
> entries))))
> (service-type
> (name 'rename-etc-files)
> (extensions (list (service-extension etc-service-type
> (const '())
> rename))))))
>
>
> (operating-system
> ;; ...
> (services (cons* (service rename-etc-files "foo-")
> ...)))
>
> I think this should fulfill the need that Alex had expressed, which is
> to not only be able to add files to /etc, but also to have the ability
> to inspect and modify what goes to /etc.
This is great! Just what I wanted, and thanks for this example! Based
on it, I made the following service:
(define replace-etc/profile-type
(let ((replace
(lambda (file entries)
(cons `("profile" ,file)
(map (match-lambda
((name . rest)
(cons (if (string= name "profile")
(string-append "original-profile")
name)
rest)))
entries)))))
(service-type
(name 'replace-etc/profile)
(extensions (list (service-extension etc-service-type
(const '())
replace))))))
(service replace-etc/profile-type (local-file ".../my-system-profile"))
So now I can use my own "/etc/profile", moreover I can look at the
"/etc/original-profile" anytime. I already use a system with this
service and I enjoy it, thanks a lot!
> The first patch currently lacks doc. I'll work on it if there's consensus
> on the approach.
I agree with this approach!
--
Alex
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Thu, 01 Jun 2017 11:25:02 GMT) Full text and rfc822 format available.Message #19 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Alex Kost <alezost <at> gmail.com> Cc: 27155 <at> debbugs.gnu.org Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Date: Thu, 01 Jun 2017 13:24:38 +0200
Hi Alex,
Alex Kost <alezost <at> gmail.com> skribis:
> This is great! Just what I wanted, and thanks for this example! Based
> on it, I made the following service:
>
> (define replace-etc/profile-type
> (let ((replace
> (lambda (file entries)
> (cons `("profile" ,file)
> (map (match-lambda
> ((name . rest)
> (cons (if (string= name "profile")
> (string-append "original-profile")
> name)
> rest)))
> entries)))))
> (service-type
> (name 'replace-etc/profile)
> (extensions (list (service-extension etc-service-type
> (const '())
> replace))))))
>
> (service replace-etc/profile-type (local-file ".../my-system-profile"))
>
> So now I can use my own "/etc/profile", moreover I can look at the
> "/etc/original-profile" anytime. I already use a system with this
> service and I enjoy it, thanks a lot!
Awesome, I’m glad you like it! It was long overdue.
Thanks for taking the time to test!
Ludo’.
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Sat, 03 Jun 2017 21:22:01 GMT) Full text and rfc822 format available.Message #22 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: 27155 <at> debbugs.gnu.org Cc: Alex Kost <alezost <at> gmail.com> Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Date: Sat, 03 Jun 2017 23:21:01 +0200
Ludovic Courtès <ludo <at> gnu.org> skribis:
> This patch adds support for service extensions that modify the
> "final" values of a service. This is meant to implement cross-cutting
> concerns as well as system-wide customization as discussed with Alex
> long ago:
>
> https://lists.gnu.org/archive/html/guix-devel/2015-11/msg00623.html
> https://lists.gnu.org/archive/html/guix-devel/2016-09/msg01505.html
>
> To summarize, a "finalization extension" (for lack of a better name)
> gets the final value of a service and returns a new value for that
> service.
I found a better name: “customizations”.
> For example, for the /etc service, a "normal" extension can only add
> entries for /etc. A "finalization" extension can instead inspect and
> change all the /etc entries. IOW, it is a sort of a "sudo" for service
> extensions; it's also quite inelegant compared to the "normal" extension
> mechanism, but it's certainly useful.
Not liking the “sudo” aspect of this patch, I thought it would be
natural if service types could control how customizations apply. That
way, the PAM or /etc service could still guarantee, for instance, that
customization does not add or remove entries, and so on.
In the end, this control by the service type makes it easier to reason
about what extensions do, whereas the “sudo” style means that an
extension can alter the service’s value in any possible way.
So I started modifying this patch set to add a ‘customize’ field to
<service-type>, next to ‘extend’. For the PAM and /etc services,
‘customize’ would compose and apply procedures that modify an entry, for
instance.
Then I realized that the only difference between ‘customize’ and
‘extend’ would be the meaning attached to it. IOW, both are some kind
of an extension.
So at this point, I started wondering whether we should just allow
service types to declare several extension points. So for PAM, we’d do:
--8<---------------cut here---------------start------------->8---
(define pam-service-addition
;; The extension point to add PAM services.
(service-extension-point
(compose concatenate)
(extend append)))
(define pam-service-cutomization
;; The extension point to customize PAM services.
(service-extension-point
(compose compose)
(extend append)))
(define pam-root-service-type
(service-type (name 'pam)
(extensions (list (service-extension etc-service-type
/etc-entry)))
(extension-points (list pam-service-addtion
pam-service-customization))))
--8<---------------cut here---------------end--------------->8---
But then ‘service-extension’ would need to specify not only the target
service type but also the target extension point, which means more
boilerplate, etc.
So after so much thought and hacking, I feel like the ad hoc solution at
<https://lists.gnu.org/archive/html/guix-devel/2016-09/msg01505.html>
was not that bad after all.
Sorry to bother you with philosophical design questions when we already
have two ways to solve the problem at hand, but I feel like there’s a
pattern worth looking for!
Ludo’.
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Sun, 04 Jun 2017 14:27:02 GMT) Full text and rfc822 format available.Message #25 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: Alex Kost <alezost <at> gmail.com> To: ludo <at> gnu.org (Ludovic Courtès) Cc: 27155 <at> debbugs.gnu.org Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Date: Sun, 04 Jun 2017 17:26:41 +0300
Ludovic Courtès (2017-06-03 23:21 +0200) wrote: > Ludovic Courtès <ludo <at> gnu.org> skribis: > >> This patch adds support for service extensions that modify the >> "final" values of a service. This is meant to implement cross-cutting >> concerns as well as system-wide customization as discussed with Alex >> long ago: >> >> https://lists.gnu.org/archive/html/guix-devel/2015-11/msg00623.html >> https://lists.gnu.org/archive/html/guix-devel/2016-09/msg01505.html >> >> To summarize, a "finalization extension" (for lack of a better name) >> gets the final value of a service and returns a new value for that >> service. > > I found a better name: “customizations”. I kinda like "finalization" more :-) But "customization" is fine with me, not a big deal. >> For example, for the /etc service, a "normal" extension can only add >> entries for /etc. A "finalization" extension can instead inspect and >> change all the /etc entries. IOW, it is a sort of a "sudo" for service >> extensions; it's also quite inelegant compared to the "normal" extension >> mechanism, but it's certainly useful. > > Not liking the “sudo” aspect of this patch, I thought it would be > natural if service types could control how customizations apply. That > way, the PAM or /etc service could still guarantee, for instance, that > customization does not add or remove entries, and so on. Ouch, that's what I don't like. I think a full control is better. You'll never know what a user might want to do, and giving a user a full freedom (even to break a system!) would be a great feature. So I'm against such guarantees that strict users in modifying their systems. > In the end, this control by the service type makes it easier to reason > about what extensions do, whereas the “sudo” style means that an > extension can alter the service’s value in any possible way. Right, "any possible way" is exactly what I want! > So I started modifying this patch set to add a ‘customize’ field to > <service-type>, next to ‘extend’. For the PAM and /etc services, > ‘customize’ would compose and apply procedures that modify an entry, for > instance. > > Then I realized that the only difference between ‘customize’ and > ‘extend’ would be the meaning attached to it. IOW, both are some kind > of an extension. > > So at this point, I started wondering whether we should just allow > service types to declare several extension points. So for PAM, we’d do: > > (define pam-service-addition > ;; The extension point to add PAM services. > (service-extension-point > (compose concatenate) > (extend append))) > > (define pam-service-cutomization > ;; The extension point to customize PAM services. > (service-extension-point > (compose compose) > (extend append))) > > (define pam-root-service-type > (service-type (name 'pam) > (extensions (list (service-extension etc-service-type > /etc-entry))) > > (extension-points (list pam-service-addtion > pam-service-customization)))) > > But then ‘service-extension’ would need to specify not only the target > service type but also the target extension point, which means more > boilerplate, etc. I don't have a deep understanding of services, but your suggestion seems (to me) to have the following downsides: - More additional work – to determine (and implement) what aspects of services should and what should not be modified by a user. - Less freedom (comparing to your previous solution) for users in modifying services. > So after so much thought and hacking, I feel like the ad hoc solution at > <https://lists.gnu.org/archive/html/guix-devel/2016-09/msg01505.html> > was not that bad after all. He-he :-) > Sorry to bother you with philosophical design questions when we already > have two ways to solve the problem at hand, but I feel like there’s a > pattern worth looking for! No problem, looking for patterns is always an interesting occupation! As for me, I agree with any solution that allows me to replace "/etc/profile". But in general, I vote for that solution that allows users to customize as much things as possible. -- Alex
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Mon, 05 Jun 2017 10:08:01 GMT) Full text and rfc822 format available.Message #28 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Alex Kost <alezost <at> gmail.com> Cc: 27155 <at> debbugs.gnu.org Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Date: Mon, 05 Jun 2017 12:06:51 +0200
Alex Kost <alezost <at> gmail.com> skribis: > Ludovic Courtès (2017-06-03 23:21 +0200) wrote: [...] >> Not liking the “sudo” aspect of this patch, I thought it would be >> natural if service types could control how customizations apply. That >> way, the PAM or /etc service could still guarantee, for instance, that >> customization does not add or remove entries, and so on. > > Ouch, that's what I don't like. I think a full control is better. > You'll never know what a user might want to do, and giving a user a full > freedom (even to break a system!) would be a great feature. So I'm > against such guarantees that strict users in modifying their systems. Just to be clear: I do want users to be able to modify their system as they see fit. The argument is about how we should structure these modifications. In the end, people can always define and use their own services, or even ‘set!’ things. But if we can provide users with control over their system in a structured way, I think it’s beneficial: they can do complex customizations of their system and still reason about them. >> So at this point, I started wondering whether we should just allow >> service types to declare several extension points. So for PAM, we’d do: >> >> (define pam-service-addition >> ;; The extension point to add PAM services. >> (service-extension-point >> (compose concatenate) >> (extend append))) >> >> (define pam-service-cutomization >> ;; The extension point to customize PAM services. >> (service-extension-point >> (compose compose) >> (extend append))) >> >> (define pam-root-service-type >> (service-type (name 'pam) >> (extensions (list (service-extension etc-service-type >> /etc-entry))) >> >> (extension-points (list pam-service-addtion >> pam-service-customization)))) >> >> But then ‘service-extension’ would need to specify not only the target >> service type but also the target extension point, which means more >> boilerplate, etc. > > I don't have a deep understanding of services, but your suggestion seems > (to me) to have the following downsides: > > - More additional work – to determine (and implement) what aspects of > services should and what should not be modified by a user. > > - Less freedom (comparing to your previous solution) for users in > modifying services. I see what you mean. Ludo’, who thinks some more.
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Mon, 05 Jun 2017 12:54:02 GMT) Full text and rfc822 format available.Message #31 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <rekado <at> elephly.net> To: 27155 <at> debbugs.gnu.org Cc: Ludovic Courtès <ludo <at> gnu.org> Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Date: Mon, 05 Jun 2017 14:52:50 +0200
I think it is useful to have the ability to add rewriters at the end of service composition. In my opinion it is always good to have an escape hatch, and this seems to fit the bill. But I agree that it is not an elegant solution, and I wouldn’t want to advocate using it. As to your second idea: it seems tedious for service writers to have to anticipate the ways in which services could be extended (here given by providing extension points). Would it make more sense to allow *extensions* to specify how they should be applied rather than letting services define extension points? This would shift the burden away from services to service extensions. Extensions would still need to provide a way of extending the parent service, but this could be optional. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Tue, 06 Jun 2017 23:08:02 GMT) Full text and rfc822 format available.Message #34 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <rekado <at> elephly.net> Cc: 27155 <at> debbugs.gnu.org Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Date: Wed, 07 Jun 2017 01:07:41 +0200
Hi Ricardo, Ricardo Wurmus <rekado <at> elephly.net> skribis: > I think it is useful to have the ability to add rewriters at the end of > service composition. In my opinion it is always good to have an escape > hatch, and this seems to fit the bill. But I agree that it is not > an elegant solution, and I wouldn’t want to advocate using it. Right. As discussed on IRC, one problem is ordering: if there are several users of this features for a given service, you can’t really tell what’s going to happen, unless the modifications happen to be commutable. > As to your second idea: it seems tedious for service writers to have to > anticipate the ways in which services could be extended (here given by > providing extension points). Boilerplate aside, I’m not sure it would be this tedious. > Would it make more sense to allow *extensions* to specify how they > should be applied rather than letting services define extension points? > This would shift the burden away from services to service extensions. > Extensions would still need to provide a way of extending the parent > service, but this could be optional. What would it look like? It seems to me there are two options: either service type specify how they can be extended, or they expose their raw values letting any extension alter it (the patch I sent). Thanks for your feedback! Ludo’.
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Thu, 15 Jun 2017 17:18:02 GMT) Full text and rfc822 format available.Message #37 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: iyzsong <at> member.fsf.org (宋文武) To: ludo <at> gnu.org (Ludovic Courtès) Cc: Ricardo Wurmus <rekado <at> elephly.net>, 27155 <at> debbugs.gnu.org Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Date: Fri, 16 Jun 2017 01:12:15 +0800
ludo <at> gnu.org (Ludovic Courtès) writes:
> Hi Ricardo,
>
> Ricardo Wurmus <rekado <at> elephly.net> skribis:
>
>> I think it is useful to have the ability to add rewriters at the end of
>> service composition. In my opinion it is always good to have an escape
>> hatch, and this seems to fit the bill. But I agree that it is not
>> an elegant solution, and I wouldn’t want to advocate using it.
>
> Right. As discussed on IRC, one problem is ordering: if there are
> several users of this features for a given service, you can’t really
> tell what’s going to happen, unless the modifications happen to be
> commutable.
>
>> As to your second idea: it seems tedious for service writers to have to
>> anticipate the ways in which services could be extended (here given by
>> providing extension points).
>
> Boilerplate aside, I’m not sure it would be this tedious.
>
>> Would it make more sense to allow *extensions* to specify how they
>> should be applied rather than letting services define extension points?
>> This would shift the burden away from services to service extensions.
>> Extensions would still need to provide a way of extending the parent
>> service, but this could be optional.
>
> What would it look like?
Maybe allow a service to override extensions specified by its
type?
It can be:
--8<---------------cut here---------------start------------->8---
(define etc-service-type
(service-type
(name 'etc)
(default-extensions (list ...))
(extension-points (list ...))))
(define builtin-etc-service
(... %base-services))
(define my-etc-service
(service etc-service-type
(service-value builtin-etc-service)
#:extensions
(list (service-extension
activation-service-type
activate-my-etc-files-in-my-way)
...)))
--8<---------------cut here---------------end--------------->8---
So we can change what service actually do, this is really powerful!
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Wed, 21 Jun 2017 13:07:01 GMT) Full text and rfc822 format available.Message #40 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: iyzsong <at> member.fsf.org (宋文武) Cc: Ricardo Wurmus <rekado <at> elephly.net>, 27155 <at> debbugs.gnu.org Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Date: Wed, 21 Jun 2017 15:06:34 +0200
Hi! iyzsong <at> member.fsf.org (宋文武) skribis: > Maybe allow a service to override extensions specified by its > type? > > It can be: > > (define etc-service-type > (service-type > (name 'etc) > (default-extensions (list ...)) > (extension-points (list ...)))) > > (define builtin-etc-service > (... %base-services)) > > (define my-etc-service > (service etc-service-type > (service-value builtin-etc-service) > #:extensions > (list (service-extension > activation-service-type > activate-my-etc-files-in-my-way) > ...))) > > So we can change what service actually do, this is really powerful! The problem as I see it is that this would be redundant with extensions in service types. Also, the “etc” service is one of the “special” services that are not in ‘%base-services’; instead they’re automatically added by ‘essential-services’ in (gnu system). Thanks for your feedback, Ludo’.
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Sun, 16 Mar 2025 11:48:03 GMT) Full text and rfc822 format available.Message #43 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: Rutherther <rutherther <at> ditigal.xyz> To: 27155 <at> debbugs.gnu.org Cc: Ricardo Wurmus <rekado <at> elephly.net>, Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo <at> gnu.org> Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" Date: Sun, 16 Mar 2025 12:47:21 +0100
Hello Ludo and Ricardo, what's the state of this? Why has this been abandoned? I am really missing a feature like this, so it pains me to see an abandoned thread that clearly states (and I agree) that this feature has been long overdue, but now it's been even 8 more years longer! For example, I would like to change the home mcron shepherd service so that it gets a wayland display env var. Currently it is possible to modify leaf services somewhat, as I can just override the service-type and change the service, but this won't be working with non-leaf one as the original service-type is extended. This complicates the process by a lot. I think that if this was merged, it would be possible to start adding other functions to guix that would be modifying shepherd services, ie. some sort of a general modify-shepherd-service and then on top of it functions to modify specific things, like dont-autostart-shepherd-service. I am willing to put some work into this just say what's missing here, because I don't know (apart from the obvious that this code probably won't cleanly apply - but I haven't tried to be honest). > > I think it is useful to have the ability to add rewriters at the end of > > service composition. In my opinion it is always good to have an escape > > hatch, and this seems to fit the bill. But I agree that it is not > > an elegant solution, and I wouldn=E2=80=99t want to advocate using it. > Right. As discussed on IRC, one problem is ordering: if there are > several users of this features for a given service, you can=E2=80=99t really > tell what=E2=80=99s going to happen, unless the modifications happen to be > commutable. As for ordering, since I was using NixOS, I know a way they solve issue like this. Your system config there is composed of many options that you set to values. One option can be set multiple times, and if that happens, there are two possibilities - either both have same priority and the type is composable, then both values are used and it is composed with a function (ie. if you have lines type and you add two values, it will get merged with \n). If it is not composable, and error is thrown. If both have different priorities, the higher priority is used. So using something like this for this case - finalization could accept functions along with priorities - maybe a record?. If same priority is used, (finalization1 (finalization2 original-config)) is used, if not, the one with higher priority is used. Imo this would allow for more use cases, even though of course it's not perfect - sometimes options just aren't composable well. This would solve an issue where if a service creator making a service in a channel decides to use this feature, the end user can still easily override the original finalization function, or deliberately make their change composable, so both finalization procedures can be called fine. Regards, Rutherther
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Thu, 10 Apr 2025 20:35:02 GMT) Full text and rfc822 format available.Message #46 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Rutherther <rutherther <at> ditigal.xyz> Cc: Ricardo Wurmus <rekado <at> elephly.net>, 27155 <at> debbugs.gnu.org Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" Date: Thu, 10 Apr 2025 21:32:44 +0200
Hello Rutherther, Rutherther <rutherther <at> ditigal.xyz> skribis: > what's the state of this? Why has this been abandoned? It was abandoned first because there wasn’t high demand (did people learn to live with a limitation? or is it that that limitation is acceptable in practice?) and second because I had second thoughts. My main concern is that it could make service composition much harder to understand. Currently, there’s a graph of services/service types where edges show what node influences each intermediate configuration value; you can follow the arrows and understand what originates where (demonstrated with <https://notabug.org/civodul/guix-explorer). With this extension, pretty much anything could happen. The extra flexibility could be put to good use, but we should also pay attention to the cost and see if we can come up with less invasive alternatives. > For example, I would like to change the home mcron shepherd service so that it gets > a wayland display env var. I think it’s an example that could be solved at the Shepherd level, by attaching essentially a key/value store to each service (the mcron service would query the ‘wayland-display’ value of the wayland service.) >> Right. As discussed on IRC, one problem is ordering: if there are >> several users of this features for a given service, you can=E2=80=99t really >> tell what=E2=80=99s going to happen, unless the modifications happen to be >> commutable. > > As for ordering, since I was using NixOS, I know a way they solve issue > like this. Your system config there is composed of many options that > you set to values. One option can be set multiple times, and if that > happens, there are two possibilities - either both have same priority > and the type is composable, then both values are used and it is > composed with a function (ie. if you have lines type and you add > two values, it will get merged with \n). If it is not composable, > and error is thrown. If both have different priorities, the higher > priority is used. Interesting. Note that I was using NixOS too (but long ago), and the “ambient authority” in the NixOS module system is one thing I definitely wanted to avoid. By “ambient authority” I mean that any module can change any option of the global system config; there’s no way to track which module does what, nor whether an option that is set is used at all. Anyway, I’m glad you’re looking into this with a fresh mind. Hopefully we can revisit it and find an option that brings flexibility without chaos. :-) Thanks, Ludo’.
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Fri, 18 Apr 2025 15:05:06 GMT) Full text and rfc822 format available.Message #49 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: Rutherther <rutherther <at> ditigal.xyz> To: Ludovic Courtès <ludo <at> gnu.org> Cc: Ricardo Wurmus <rekado <at> elephly.net>, 27155 <at> debbugs.gnu.org Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" Date: Fri, 18 Apr 2025 17:04:29 +0200
Hello Ludo,
I appreciate your answer. I am sorry for getting back after longer time,
I had to think about this more deeply, I was writing something the first
day it came but the answer didn't feel right.
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hello Rutherther,
>
> Rutherther <rutherther <at> ditigal.xyz> skribis:
>
>> what's the state of this? Why has this been abandoned?
>
> It was abandoned first because there wasn’t high demand (did people
> learn to live with a limitation? or is it that that limitation is
> acceptable in practice?) and second because I had second thoughts.
>
> My main concern is that it could make service composition much harder to
> understand. Currently, there’s a graph of services/service types where
> edges show what node influences each intermediate configuration value;
> you can follow the arrows and understand what originates where
> (demonstrated with <https://notabug.org/civodul/guix-explorer).
>
> With this extension, pretty much anything could happen. The extra
> flexibility could be put to good use, but we should also pay attention
> to the cost and see if we can come up with less invasive alternatives.
We already have something like this in pam service, the transformer
field, I think that if other services started supporting that, it's
basically the same as making a generic interface like this, except
harder as each service has to do it on their own.
Yes, it drops the nice inspectionability, but even now it can be made
complicated depending on how the service's extension field sets up the
extend procedure.
>
>> For example, I would like to change the home mcron shepherd service so that it gets
>> a wayland display env var.
>
> I think it’s an example that could be solved at the Shepherd level, by
> attaching essentially a key/value store to each service (the mcron
> service would query the ‘wayland-display’ value of the wayland service.)
I think that anything we come up with can be solved at the service
level, but I think that is besides the point, the point being that this
is a generic interface to do that, without having to make complicated
support for everything in already existing services. The service-maker
can't think of everything the user might want, so they won't expose
every modification option under the sun.
>
>>> Right. As discussed on IRC, one problem is ordering: if there are
>>> several users of this features for a given service, you can=E2=80=99t really
>>> tell what=E2=80=99s going to happen, unless the modifications happen to be
>>> commutable.
>>
>> As for ordering, since I was using NixOS, I know a way they solve issue
>> like this. Your system config there is composed of many options that
>> you set to values. One option can be set multiple times, and if that
>> happens, there are two possibilities - either both have same priority
>> and the type is composable, then both values are used and it is
>> composed with a function (ie. if you have lines type and you add
>> two values, it will get merged with \n). If it is not composable,
>> and error is thrown. If both have different priorities, the higher
>> priority is used.
>
> Interesting.
>
> Note that I was using NixOS too (but long ago), and the “ambient
> authority” in the NixOS module system is one thing I definitely wanted
> to avoid. By “ambient authority” I mean that any module can change any
> option of the global system config; there’s no way to track which module
> does what, nor whether an option that is set is used at all.
I definitely agree, and it's one of the reasons I switched to Guix
System. But I don't think what this is adding is so similar to that
though, because you still get that 'link' between the services that can
be seen by the user in an 'extension' graph (or something new like
finalizer graph)
Also with this finalizers, it's still not possible to read values of
services like NixOS allows.
In NixOS, one 'service', A, can change B, and B can change A, leaving
us with a mess, this is also something that will still not be allowed
if finalizers are used.
Let me sketch few things I now lack in Guix System, all solvable by
this, or on per-service basis:
- Modifying shepherd services
- Auto start disable
- New env vars
- Ie. allowing programs to use GUI with DISPLAY
- Run as different user
- Security or convenience
- But this one suffers from another issue, where the user is
actually decided by the forkexec, so this one is more involved, it's
not trivial even with this change. So we will need shepherd support
- Modifying users
- Add a group to a user
- To share a common socket file between two services
- Modifying existing pam rules
The reason I would be in favor of this generic solution, rather than
'local' ones is that I don't see any disadvantages applying only to the
generic one, but see the massive advantage of not needing to solve this
on each individual service by defining interfaces for it.
Apart from those use cases, one I am missing the most is the possibility
to extend the least authority wrappers, but this one suffers from
similar issue as running services as different user. I am not sure how
to well go about that, we will probably still need something specific
for shepherd for that. It's the main reason I am not thinking about
migrating my server from NixOS to Guix System. NixOS uses systemd
hardening much more... And thanks to the fact that any service can
change any other option, it's possible to combine services like that,
ie. share a socket through shared tmp folder, while the real filesystem
stays hidden.
(not saying I would go and migrate right away
after this issue is somehow solved, I will have to write a lot of
services myself...)
>
> Anyway, I’m glad you’re looking into this with a fresh mind. Hopefully
> we can revisit it and find an option that brings flexibility without
> chaos. :-)
>
> Thanks,
> Ludo’.
Best regards,
Ruther
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Wed, 23 Apr 2025 10:33:01 GMT) Full text and rfc822 format available.Message #52 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: Ludovic Courtès <ludo <at> gnu.org> To: Rutherther <rutherther <at> ditigal.xyz> Cc: Ricardo Wurmus <rekado <at> elephly.net>, 27155 <at> debbugs.gnu.org Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" Date: Wed, 23 Apr 2025 12:00:20 +0200
Hi, Rutherther <rutherther <at> ditigal.xyz> writes: >> With this extension, pretty much anything could happen. The extra >> flexibility could be put to good use, but we should also pay attention >> to the cost and see if we can come up with less invasive alternatives. > > We already have something like this in pam service, the transformer > field, I think that if other services started supporting that, it's > basically the same as making a generic interface like this, except > harder as each service has to do it on their own. Yes, the ‘transformer’ field is exactly like this proposal, just limited to PAM. >> I think it’s an example that could be solved at the Shepherd level, by >> attaching essentially a key/value store to each service (the mcron >> service would query the ‘wayland-display’ value of the wayland service.) > > I think that anything we come up with can be solved at the service > level, but I think that is besides the point, Well yes, though I think that the WAYLAND_DISPLAY value is fundamentally a run-time value, so it has to be solved though run-time mechanisms, in the Shepherd. >> Note that I was using NixOS too (but long ago), and the “ambient >> authority” in the NixOS module system is one thing I definitely wanted >> to avoid. By “ambient authority” I mean that any module can change any >> option of the global system config; there’s no way to track which module >> does what, nor whether an option that is set is used at all. > > I definitely agree, and it's one of the reasons I switched to Guix > System. But I don't think what this is adding is so similar to that > though, because you still get that 'link' between the services that can > be seen by the user in an 'extension' graph (or something new like > finalizer graph) > Also with this finalizers, it's still not possible to read values of > services like NixOS allows. > In NixOS, one 'service', A, can change B, and B can change A, leaving > us with a mess, this is also something that will still not be allowed > if finalizers are used. I agree, finalizers are still less expressive than the NixOS module system (which I think is good). Yet, they can still do a lot and none of that can be inferred by looking at the extension graph. > Let me sketch few things I now lack in Guix System, all solvable by > this, or on per-service basis: > > - Modifying shepherd services > - Auto start disable > - New env vars > - Ie. allowing programs to use GUI with DISPLAY > - Run as different user > - Security or convenience > - But this one suffers from another issue, where the user is > actually decided by the forkexec, so this one is more involved, it's > not trivial even with this change. So we will need shepherd support > - Modifying users > - Add a group to a user > - To share a common socket file between two services Hmm. I think it would be interesting to prototype services that make use of finalizers, to get a better idea of the possibilities it would open. > - Modifying existing pam rules This one is handled by the ‘transformer’ field, right? :-) > Apart from those use cases, one I am missing the most is the possibility > to extend the least authority wrappers, but this one suffers from > similar issue as running services as different user. Extend how? Thanks, Ludo’.
guix-patches <at> gnu.org:bug#27155; Package guix-patches.
(Wed, 23 Apr 2025 16:41:03 GMT) Full text and rfc822 format available.Message #55 received at 27155 <at> debbugs.gnu.org (full text, mbox):
From: Rutherther <rutherther <at> ditigal.xyz> To: Ludovic Courtès <ludo <at> gnu.org> Cc: Ricardo Wurmus <rekado <at> elephly.net>, 27155 <at> debbugs.gnu.org Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final" Date: Wed, 23 Apr 2025 18:40:08 +0200
Hello,
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hi,
>
> Rutherther <rutherther <at> ditigal.xyz> writes:
>
>>> I think it’s an example that could be solved at the Shepherd level, by
>>> attaching essentially a key/value store to each service (the mcron
>>> service would query the ‘wayland-display’ value of the wayland service.)
>>
>> I think that anything we come up with can be solved at the service
>> level, but I think that is besides the point,
>
> Well yes, though I think that the WAYLAND_DISPLAY value is fundamentally
> a run-time value, so it has to be solved though run-time mechanisms, in
> the Shepherd.
Could you clarify what run-time mechanism you have in mind here? I was
thinking in terms of how home-x11-display service does this, where you
need to go and set #:environment-variables in other services. Do you
have something more 'robust' in mind? I know that systemd has a function
to import environment `systemctl import-environment`, on the other hand
I don't really like that you just import the env vars everywhere instead
of having more controlled approach where the service says what to get
from where.
>
>>> Note that I was using NixOS too (but long ago), and the “ambient
>>> authority” in the NixOS module system is one thing I definitely wanted
>>> to avoid. By “ambient authority” I mean that any module can change any
>>> option of the global system config; there’s no way to track which module
>>> does what, nor whether an option that is set is used at all.
>>
>> I definitely agree, and it's one of the reasons I switched to Guix
>> System. But I don't think what this is adding is so similar to that
>> though, because you still get that 'link' between the services that can
>> be seen by the user in an 'extension' graph (or something new like
>> finalizer graph)
>> Also with this finalizers, it's still not possible to read values of
>> services like NixOS allows.
>> In NixOS, one 'service', A, can change B, and B can change A, leaving
>> us with a mess, this is also something that will still not be allowed
>> if finalizers are used.
>
> I agree, finalizers are still less expressive than the NixOS module
> system (which I think is good). Yet, they can still do a lot and none
> of that can be inferred by looking at the extension graph.
I am not sure if my initial point got through, or not, so I will try to
rephrase, in case it already got through to you, and you just wanted to
extend on it, just ignore this:
Currently extensions can do transformations already, ie. the pam service
does that. This makes the extension graph less clear already in the same
way global finaliers would. But I would argue that the current approach
may be making the extension graph even less clear than a global
finalizers, because it's not known which services are extending the
'transformator' and which ones just the normal options. By having a more
global finalizer/transformer approach, it would be something that can be
marked in the graph, and we can distinguish between regular extensions
and finalizers. (of course only given that no one will make a
transformer-like extension support in their service, but at least in
Guix channel itself this could be made sure of, and I don't think anyone
would try that if there was a global approach)
>
>> Let me sketch few things I now lack in Guix System, all solvable by
>> this, or on per-service basis:
>>
>> - Modifying shepherd services
>> - Auto start disable
>> - New env vars
>> - Ie. allowing programs to use GUI with DISPLAY
>> - Run as different user
>> - Security or convenience
>> - But this one suffers from another issue, where the user is
>> actually decided by the forkexec, so this one is more involved, it's
>> not trivial even with this change. So we will need shepherd support
>> - Modifying users
>> - Add a group to a user
>> - To share a common socket file between two services
>
> Hmm. I think it would be interesting to prototype services that make
> use of finalizers, to get a better idea of the possibilities it would
> open.
>
Yeah, that makes sense. Unfortunately I won't be able to get to this any
time soon I am afraid.
>> - Modifying existing pam rules
>
> This one is handled by the ‘transformer’ field, right? :-)
Yeah, my point was that this makes it more generic.
>
>> Apart from those use cases, one I am missing the most is the possibility
>> to extend the least authority wrappers, but this one suffers from
>> similar issue as running services as different user.
>
> Extend how?
For example to share files, like sockets, between two services.
In NixOS I have opensmtpd, and it contacts my sourcehut instance
by a socket when an e-mail is received. Socket needs to be shared
between those two. I do this in my config:
```
systemd.services = {
listssrht-ingress = {
unitConfig.JoinsNamespaceOf = "opensmtpd.service";
};
todosrht-lmtp = {
unitConfig.JoinsNamespaceOf = "opensmtpd.service";
};
opensmtpd = {
# Needed for sharing the LMTP sockets with JoinsNamespaceOf=
serviceConfig.PrivateTmp = true;
};
};
```
Which will make /tmp of the services shared (this can be made in
multiple ways of course, this is just one possibility, it could also be
a commonly mapped folder, no need for it to be /tmp), so that the socket
under /tmp is visible by both and they can communicate with each other.
Best regards,
Rutherther
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.