From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 30 May 2017 22:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 27155@debbugs.gnu.org Cc: Alex Kost , Ludovic =?UTF-8?Q?Court=C3=A8s?= X-Debbugs-Original-To: guix-patches@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14961815807772 (code B ref -1); Tue, 30 May 2017 22:00:02 +0000 Received: (at submit) by debbugs.gnu.org; 30 May 2017 21:59:40 +0000 Received: from localhost ([127.0.0.1]:45867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFpAy-00021I-2I for submit@debbugs.gnu.org; Tue, 30 May 2017 17:59:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFpAw-00020w-Pj for submit@debbugs.gnu.org; Tue, 30 May 2017 17:59:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dFpAq-0008Jp-Jz for submit@debbugs.gnu.org; Tue, 30 May 2017 17:59:33 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:40615) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dFpAq-0008Jh-Hx for submit@debbugs.gnu.org; Tue, 30 May 2017 17:59:32 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dFpAp-0001QN-1n for guix-patches@gnu.org; Tue, 30 May 2017 17:59:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dFpAo-0008JD-5H for guix-patches@gnu.org; Tue, 30 May 2017 17:59:31 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dFpAh-0008Hp-P6; Tue, 30 May 2017 17:59:23 -0400 Received: from reverse-83.fdn.fr ([80.67.176.83]:60352 helo=gnu.org) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dFpAh-0006Nk-0e; Tue, 30 May 2017 17:59:23 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Date: Tue, 30 May 2017 23:58:50 +0200 Message-Id: <20170530215850.7522-1-ludo@gnu.org> X-Mailer: git-send-email 2.13.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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 From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27155: [PATCH 1/2] DRAFT services: Extensions can specify a "finalization" procedure. References: <20170530215850.7522-1-ludo@gnu.org> In-Reply-To: <20170530215850.7522-1-ludo@gnu.org> Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 30 May 2017 22:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 27155@debbugs.gnu.org Cc: Alex Kost , Ludovic =?UTF-8?Q?Court=C3=A8s?= Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.14961819438419 (code B ref 27155); Tue, 30 May 2017 22:06:02 +0000 Received: (at 27155) by debbugs.gnu.org; 30 May 2017 22:05:43 +0000 Received: from localhost ([127.0.0.1]:45893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFpGo-0002Bi-W0 for submit@debbugs.gnu.org; Tue, 30 May 2017 18:05:43 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49163) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFpGn-0002BQ-GR for 27155@debbugs.gnu.org; Tue, 30 May 2017 18:05:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dFpGh-0001bM-4t for 27155@debbugs.gnu.org; Tue, 30 May 2017 18:05:36 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dFpGZ-0001ah-OH; Tue, 30 May 2017 18:05:27 -0400 Received: from reverse-83.fdn.fr ([80.67.176.83]:60370 helo=gnu.org) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dFpGY-0000ZU-UO; Tue, 30 May 2017 18:05:27 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Date: Wed, 31 May 2017 00:05:08 +0200 Message-Id: <20170530220509.8254-1-ludo@gnu.org> X-Mailer: git-send-email 2.13.0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) TODO: Add doc * gnu/services.scm ()[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 target compute) + (%service-extension target compute finalize) service-extension? - (target service-extension-target) ; - (compute service-extension-compute)) ;params -> params + (target service-extension-target) ; + (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." (($ _ compute) (compute (service-value service)))))) + (define (apply-finalization target) + (lambda (service) + (match (find (matching-extension target) + (service-type-extensions (service-kind service))) + (($ _ _ 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 From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27155: [PATCH 2/2] system: pam: Remove custom API to transform PAM services. Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 30 May 2017 22:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 27155@debbugs.gnu.org Cc: Alex Kost , Ludovic =?UTF-8?Q?Court=C3=A8s?= Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.14961819478430 (code B ref 27155); Tue, 30 May 2017 22:06:02 +0000 Received: (at 27155) by debbugs.gnu.org; 30 May 2017 22:05:47 +0000 Received: from localhost ([127.0.0.1]:45895 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFpGp-0002Bk-AV for submit@debbugs.gnu.org; Tue, 30 May 2017 18:05:47 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFpGn-0002BR-Iu for 27155@debbugs.gnu.org; Tue, 30 May 2017 18:05:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dFpGh-0001bH-39 for 27155@debbugs.gnu.org; Tue, 30 May 2017 18:05:36 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dFpGb-0001as-1p; Tue, 30 May 2017 18:05:29 -0400 Received: from reverse-83.fdn.fr ([80.67.176.83]:60370 helo=gnu.org) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dFpGa-0000ZU-9H; Tue, 30 May 2017 18:05:28 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Date: Wed, 31 May 2017 00:05:09 +0200 Message-Id: <20170530220509.8254-2-ludo@gnu.org> X-Mailer: git-send-email 2.13.0 In-Reply-To: <20170530220509.8254-1-ludo@gnu.org> References: <20170530220509.8254-1-ludo@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) This specific way to extend 'pam-root-service-type' has been subsumed by the "finalization extensions" of services. * gnu/system/pam.scm (): 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 +;;; Copyright © 2014, 2015, 2016, 2017 Ludovic Courtès ;;; Copyright © 2015 Andy Wingo ;;; Copyright © 2015 Mark H Weaver ;;; Copyright © 2016 Sou Bunnbu @@ -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 +;;; Copyright © 2013, 2014, 2015, 2016, 2017 Ludovic Courtès ;;; ;;; 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 and returns a . 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 make-pam-configuration? pam-configuration? - (services pam-configuration-services) ;list of - (transform pam-configuration-transform)) ;procedure - -(define (/etc-entry config) +(define (/etc-entry services) "Return the /etc/pam.d entry corresponding to CONFIG." - (match config - (($ 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 as well as procedures. + ;; Arguments are 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 instance and turns -them into a /etc/pam.d directory, including the listed in BASE. -TRANSFORM is a procedure that takes a and returns a -. 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 listed in BASE." + (service pam-root-service-type base)) -- 2.13.0 From debbugs-submit-bounces@debbugs.gnu.org Wed May 31 09:36:40 2017 Received: (at control) by debbugs.gnu.org; 31 May 2017 13:36:40 +0000 Received: from localhost ([127.0.0.1]:46325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG3nk-0007Uy-Fd for submit@debbugs.gnu.org; Wed, 31 May 2017 09:36:40 -0400 Received: from hera.aquilenet.fr ([141.255.128.1]:41823) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG3nj-0007Uq-2p for control@debbugs.gnu.org; Wed, 31 May 2017 09:36:39 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id C1B50B477 for ; Wed, 31 May 2017 15:36:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTebTKv2g3Hd for ; Wed, 31 May 2017 15:36:36 +0200 (CEST) Received: from ribbon (reverse-83.fdn.fr [80.67.176.83]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 6581E7B5F for ; Wed, 31 May 2017 15:36:36 +0200 (CEST) Date: Wed, 31 May 2017 15:36:35 +0200 Message-Id: <87o9u9du70.fsf@gnu.org> To: control@debbugs.gnu.org From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: control message for bug #27155 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) severity 27155 important From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values In-Reply-To: <20170530215850.7522-1-ludo@gnu.org> Resent-From: Alex Kost Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 01 Jun 2017 09:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 27155@debbugs.gnu.org Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.149631104014888 (code B ref 27155); Thu, 01 Jun 2017 09:58:02 +0000 Received: (at 27155) by debbugs.gnu.org; 1 Jun 2017 09:57:20 +0000 Received: from localhost ([127.0.0.1]:48453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGMr1-0003s3-MN for submit@debbugs.gnu.org; Thu, 01 Jun 2017 05:57:19 -0400 Received: from mail-lf0-f50.google.com ([209.85.215.50]:33969) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGMqz-0003ro-Td for 27155@debbugs.gnu.org; Thu, 01 Jun 2017 05:57:18 -0400 Received: by mail-lf0-f50.google.com with SMTP id 99so23406010lfu.1 for <27155@debbugs.gnu.org>; Thu, 01 Jun 2017 02:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-transfer-encoding; bh=oy3dGzxzxZZsMS1BL4xalpItj1i4M5dtuizfYqWuixM=; b=hhyKOcinljTN4iKJDdlIzGoKlUBpvPLD2269/ly3wh5LVyBcAnKjo0NX+D3Am02EgP I1rSVRQKYPv896kVjB3fJUsCHq8CTFIa1vOaLMOvERwIgZC2UmE2rW3zVfWGuVKgKnzl jtwcl8WTKWdugdX4q2d50tSYXDCXnDOX4NLVSCN6cRV4Di9YM9VoB3vFxAv1P2BxqXaQ 3W6uZsebfoPsMkMmQp9BNMUGFT24tTkTIb2JPsVeXCsm7vU7ZFjS1Taj8DTb0qSXJ7Sh DUt/xyOJbN5kT6HnYbuR06v+bCTKkb1TRp78wEOA+wcfR69D2HeSHhYlYj7Dcs71S1fY yB9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:message-id :user-agent:mime-version:content-transfer-encoding; bh=oy3dGzxzxZZsMS1BL4xalpItj1i4M5dtuizfYqWuixM=; b=fQu0WkoL1UNo/mKJvtA9tniHltnIyPepnYoHxVdfb1wlFJ4/hPQxow6IUmK94qySP5 SlTGMw0DJ8gLIe9TrI4tmHQu0WBqL78xcQaZnGb8ZMBE695Ok4b0q/DLtfnpkYXj+tJK XBoq9nWMvCbtSKdyW++TuUxpPPrH9lElTn4TkUnwk5oan7ArsRj57whiySrTDr4sBfEs NVp86CgNl2Krm0zH8OiZW86aGSAA4ZyheKm+5h+GXdh0vUXQKslLKfr7e7mYgBHB1BFE j333RkMy0GJj12eUpDovG0WfOK2YGH33Ta9RYBiOnnlZ8LKUTsu87AQpsWVpugp/YgeE LV7Q== X-Gm-Message-State: AODbwcBUlQU1FFpbc+Urb4HHhVGSNSzJAeIgd39VqsVRF2bFi1AAoQBo 9InHyX0qonTBzThm X-Received: by 10.46.69.8 with SMTP id s8mr241360lja.55.1496311031621; Thu, 01 Jun 2017 02:57:11 -0700 (PDT) Received: from leviafan ([217.107.194.134]) by smtp.gmail.com with ESMTPSA id v30sm4205842ljd.9.2017.06.01.02.57.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 01 Jun 2017 02:57:10 -0700 (PDT) From: Alex Kost References: <20170530215850.7522-1-ludo@gnu.org> Date: Thu, 01 Jun 2017 12:57:09 +0300 Message-ID: <8760ggrpxm.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Ludovic Court=C3=A8s (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=3D 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! --=20 Alex From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 01 Jun 2017 11:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Alex Kost Cc: 27155@debbugs.gnu.org Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.149631629123266 (code B ref 27155); Thu, 01 Jun 2017 11:25:02 +0000 Received: (at 27155) by debbugs.gnu.org; 1 Jun 2017 11:24:51 +0000 Received: from localhost ([127.0.0.1]:48606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGODj-00063C-Bg for submit@debbugs.gnu.org; Thu, 01 Jun 2017 07:24:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGODi-00062z-3q for 27155@debbugs.gnu.org; Thu, 01 Jun 2017 07:24:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGODZ-00048m-Pp for 27155@debbugs.gnu.org; Thu, 01 Jun 2017 07:24:45 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGODZ-00048i-Md; Thu, 01 Jun 2017 07:24:41 -0400 Received: from [193.50.110.69] (port=42310 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dGODZ-0007xN-2d; Thu, 01 Jun 2017 07:24:41 -0400 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <20170530215850.7522-1-ludo@gnu.org> <8760ggrpxm.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 13 Prairial an 225 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Thu, 01 Jun 2017 13:24:38 +0200 In-Reply-To: <8760ggrpxm.fsf@gmail.com> (Alex Kost's message of "Thu, 01 Jun 2017 12:57:09 +0300") Message-ID: <871sr43q89.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Hi Alex, Alex Kost 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=3D 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=E2=80=99m glad you like it! It was long overdue. Thanks for taking the time to test! Ludo=E2=80=99. From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sat, 03 Jun 2017 21:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 27155@debbugs.gnu.org Cc: Alex Kost Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.149652488026917 (code B ref 27155); Sat, 03 Jun 2017 21:22:01 +0000 Received: (at 27155) by debbugs.gnu.org; 3 Jun 2017 21:21:20 +0000 Received: from localhost ([127.0.0.1]:54237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHGU4-000704-3z for submit@debbugs.gnu.org; Sat, 03 Jun 2017 17:21:20 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHGU3-0006zs-68 for 27155@debbugs.gnu.org; Sat, 03 Jun 2017 17:21:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHGTw-0000Si-Nu for 27155@debbugs.gnu.org; Sat, 03 Jun 2017 17:21:13 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHGTp-0000P3-9S; Sat, 03 Jun 2017 17:21:05 -0400 Received: from reverse-83.fdn.fr ([80.67.176.83]:46438 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dHGTo-0004CG-IN; Sat, 03 Jun 2017 17:21:04 -0400 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <20170530215850.7522-1-ludo@gnu.org> Date: Sat, 03 Jun 2017 23:21:01 +0200 In-Reply-To: <20170530215850.7522-1-ludo@gnu.org> ("Ludovic \=\?utf-8\?Q\?Cour\?\= \=\?utf-8\?Q\?t\=C3\=A8s\=22's\?\= message of "Tue, 30 May 2017 23:58:50 +0200") Message-ID: <8737bgkbsy.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Ludovic Court=C3=A8s 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: =E2=80=9Ccustomizations=E2=80=9D. > 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 =E2=80=9Csudo=E2=80=9D aspect of this patch, I thought it wo= uld 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 =E2=80=9Csudo=E2=80=9D style means th= at an extension can alter the service=E2=80=99s value in any possible way. So I started modifying this patch set to add a =E2=80=98customize=E2=80=99 = field to , next to =E2=80=98extend=E2=80=99. For the PAM and /etc ser= vices, =E2=80=98customize=E2=80=99 would compose and apply procedures that modify = an entry, for instance. Then I realized that the only difference between =E2=80=98customize=E2=80= =99 and =E2=80=98extend=E2=80=99 would be the meaning attached to it. IOW, both ar= e 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=E2=80=99= 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 =E2=80=98service-extension=E2=80=99 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 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=E2=80=99s= a pattern worth looking for! Ludo=E2=80=99. From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Resent-From: Alex Kost Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 04 Jun 2017 14:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Cc: 27155@debbugs.gnu.org Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.149658641111608 (code B ref 27155); Sun, 04 Jun 2017 14:27:02 +0000 Received: (at 27155) by debbugs.gnu.org; 4 Jun 2017 14:26:51 +0000 Received: from localhost ([127.0.0.1]:55923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHWUU-00031A-Ti for submit@debbugs.gnu.org; Sun, 04 Jun 2017 10:26:51 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:35876) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHWUS-00030x-KO for 27155@debbugs.gnu.org; Sun, 04 Jun 2017 10:26:49 -0400 Received: by mail-lf0-f68.google.com with SMTP id x81so2400706lfb.3 for <27155@debbugs.gnu.org>; Sun, 04 Jun 2017 07:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=sAn5cuvrvObbrirdJ9LPZqlJB4AiM/uhIfkjT69O4Js=; b=lRaJMejmwM8V2Uj2x67099zV77jPXiM+ecQ1BsgScyuk2egQ+ssLcbd4QK840SieDn QZgKMEUx5Yi5ohU5hncO+6lsILahjdagUU6AApdt7k4qld8EaxlBFfsNXSKGXuvU9nPT i0IbVDH2o59ikKkhLyQ1/OrXq/MTwh8mmIyFGL0GHe45GdaVQmLCk0bbGTtPYazQaRfn FLD6xm7tOzdl6EAoMkrVZiQUBue8lyLpH4iPvwSQQZXeG4IkVTgcD0xoPCjayP/A72D5 1aXt0jRl0KNZfo8+Y8/QIJDtC1hloZQNQTg9uRbyjc+Ec3R0nX0wzjalwWcrH1cZXkmy fosA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=sAn5cuvrvObbrirdJ9LPZqlJB4AiM/uhIfkjT69O4Js=; b=l0DbojAmL51NW9hRRaLQcOH6rikKHPTGHuW+xe9YMlS5iLRDD2d9L00ZI+e/PbgPj9 QQK4i6yuL5RBduqfGSrI+wyDV/oXFJy+ew/hAWUuBx+LROTqWo56ISqHoIyr2Ebu1lBs WpEjlkrrls6UwMK41BU3UtNwNDfQ02sY4vUWihiXKBjArq732TF+cLC45NddcHVOxQo8 CA88nCyPJWRLnM4JqgTtW6shvqbYVlPxLcl+2n9nlEjwdIe3zSMk3sr8kj9i/OiUeCqQ guqwLZj2+h+WT0e9Lf47wIz/6qIyhLd8JTZH/+vg/5T1Z9i1BvC13GHrT3c5oaLoKZBH 4a4A== X-Gm-Message-State: AODbwcBIs6uqnfuGFSRklyEYj5fMHiUQNAgQM5ToyHcNIRoUkIJQiWGy 4+ZcxzW207Ie3mn5 X-Received: by 10.46.9.146 with SMTP id 140mr492592ljj.42.1496586402302; Sun, 04 Jun 2017 07:26:42 -0700 (PDT) Received: from leviafan ([217.107.194.134]) by smtp.gmail.com with ESMTPSA id x24sm6257631ljd.5.2017.06.04.07.26.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 04 Jun 2017 07:26:41 -0700 (PDT) From: Alex Kost References: <20170530215850.7522-1-ludo@gnu.org> <8737bgkbsy.fsf@gnu.org> Date: Sun, 04 Jun 2017 17:26:41 +0300 In-Reply-To: <8737bgkbsy.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sat, 03 Jun 2017 23:21:01 +0200") Message-ID: <87o9u3q15q.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Ludovic Court=C3=A8s (2017-06-03 23:21 +0200) wrote: > Ludovic Court=C3=A8s 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: =E2=80=9Ccustomizations=E2=80=9D. 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 =E2=80=9Csudo=E2=80=9D 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 =E2=80=9Csudo=E2=80=9D style means = that an > extension can alter the service=E2=80=99s value in any possible way. Right, "any possible way" is exactly what I want! > So I started modifying this patch set to add a =E2=80=98customize=E2=80= =99 field to > , next to =E2=80=98extend=E2=80=99. For the PAM and /etc s= ervices, > =E2=80=98customize=E2=80=99 would compose and apply procedures that modif= y an entry, for > instance. > > Then I realized that the only difference between =E2=80=98customize=E2=80= =99 and > =E2=80=98extend=E2=80=99 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=E2=80= =99d 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 =E2=80=98service-extension=E2=80=99 would need to specify not on= ly 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 =E2=80=93 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 > > 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=E2=80= =99s 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. --=20 Alex From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 05 Jun 2017 10:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Alex Kost Cc: 27155@debbugs.gnu.org Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.149665722621924 (code B ref 27155); Mon, 05 Jun 2017 10:08:01 +0000 Received: (at 27155) by debbugs.gnu.org; 5 Jun 2017 10:07:06 +0000 Received: from localhost ([127.0.0.1]:56491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHouf-0005hY-Mh for submit@debbugs.gnu.org; Mon, 05 Jun 2017 06:07:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHoud-0005h5-VC for 27155@debbugs.gnu.org; Mon, 05 Jun 2017 06:07:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHouV-0005xs-LJ for 27155@debbugs.gnu.org; Mon, 05 Jun 2017 06:06:58 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHouV-0005xo-I2; Mon, 05 Jun 2017 06:06:55 -0400 Received: from reverse-83.fdn.fr ([80.67.176.83]:58822 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dHouU-0001W1-UM; Mon, 05 Jun 2017 06:06:55 -0400 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <20170530215850.7522-1-ludo@gnu.org> <8737bgkbsy.fsf@gnu.org> <87o9u3q15q.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 17 Prairial an 225 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Mon, 05 Jun 2017 12:06:51 +0200 In-Reply-To: <87o9u3q15q.fsf@gmail.com> (Alex Kost's message of "Sun, 04 Jun 2017 17:26:41 +0300") Message-ID: <8760gag344.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Alex Kost skribis: > Ludovic Court=C3=A8s (2017-06-03 23:21 +0200) wrote: [...] >> Not liking the =E2=80=9Csudo=E2=80=9D 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 =E2=80=98set!=E2=80=99 things. But if we can provide users with control ov= er their system in a structured way, I think it=E2=80=99s beneficial: they can do co= mplex 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=E2=80= =99d 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 =E2=80=98service-extension=E2=80=99 would need to specify not o= nly 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 =E2=80=93 to determine (and implement) what aspect= s 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=E2=80=99, who thinks some more. From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values References: <20170530215850.7522-1-ludo@gnu.org> In-Reply-To: <20170530215850.7522-1-ludo@gnu.org> Resent-From: Ricardo Wurmus Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 05 Jun 2017 12:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 27155@debbugs.gnu.org Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.149666718318115 (code B ref 27155); Mon, 05 Jun 2017 12:54:02 +0000 Received: (at 27155) by debbugs.gnu.org; 5 Jun 2017 12:53:03 +0000 Received: from localhost ([127.0.0.1]:56595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHrVG-0004i0-KF for submit@debbugs.gnu.org; Mon, 05 Jun 2017 08:53:02 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHrVE-0004he-DA for 27155@debbugs.gnu.org; Mon, 05 Jun 2017 08:53:00 -0400 Received: from localhost (port-92-200-94-239.dynamic.qsc.de [92.200.94.239]) by mx.zohomail.com with SMTPS id 1496667174194614.686956108927; Mon, 5 Jun 2017 05:52:54 -0700 (PDT) User-agent: mu4e 0.9.18; emacs 25.2.1 From: Ricardo Wurmus X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Date: Mon, 05 Jun 2017 14:52:50 +0200 Message-ID: <87mv9m7g0t.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Spam-Score: -1.8 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) 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 From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: bug#27155: [PATCH 0/2] Support service extensions on the "final" service values Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 06 Jun 2017 23:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ricardo Wurmus Cc: 27155@debbugs.gnu.org Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.149679048012113 (code B ref 27155); Tue, 06 Jun 2017 23:08:02 +0000 Received: (at 27155) by debbugs.gnu.org; 6 Jun 2017 23:08:00 +0000 Received: from localhost ([127.0.0.1]:60011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dINZw-00039I-K7 for submit@debbugs.gnu.org; Tue, 06 Jun 2017 19:08:00 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49025) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dINZu-000394-Pn for 27155@debbugs.gnu.org; Tue, 06 Jun 2017 19:07:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dINZm-0008RT-KZ for 27155@debbugs.gnu.org; Tue, 06 Jun 2017 19:07:53 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dINZm-0008RK-HD; Tue, 06 Jun 2017 19:07:50 -0400 Received: from astlambert-651-1-208-19.w92-151.abo.wanadoo.fr ([92.151.64.19]:37568 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dINZl-0007QT-UU; Tue, 06 Jun 2017 19:07:50 -0400 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <87mv9m7g0t.fsf@elephly.net> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 19 Prairial an 225 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Wed, 07 Jun 2017 01:07:41 +0200 In-Reply-To: <87mv9m7g0t.fsf@elephly.net> (Ricardo Wurmus's message of "Mon, 05 Jun 2017 14:52:50 +0200") Message-ID: <87bmq07m0y.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Hi Ricardo, Ricardo Wurmus 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=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 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=E2=80=99m 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=E2=80=99. From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27155] [PATCH 0/2] Support service extensions on the "final" service values Resent-From: iyzsong@member.fsf.org (=?UTF-8?Q?=E5=AE=8B=E6=96=87=E6=AD=A6?=) Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 15 Jun 2017 17:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Cc: Ricardo Wurmus , 27155@debbugs.gnu.org Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.149754705618725 (code B ref 27155); Thu, 15 Jun 2017 17:18:02 +0000 Received: (at 27155) by debbugs.gnu.org; 15 Jun 2017 17:17:36 +0000 Received: from localhost ([127.0.0.1]:49867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLYOl-0004rx-WF for submit@debbugs.gnu.org; Thu, 15 Jun 2017 13:17:36 -0400 Received: from lb1.openmailbox.org ([5.79.108.160]:48800 helo=mail.openmailbox.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dLYOj-0004rn-IQ for 27155@debbugs.gnu.org; Thu, 15 Jun 2017 13:17:35 -0400 Received: by mail.openmailbox.org (Postfix, from userid 20002) id B1AA3525EC8; Thu, 15 Jun 2017 19:17:31 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ZDZR002 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, T_HEADER_FROM_DIFFERENT_DOMAINS, URIBL_BLOCKED autolearn=disabled version=3.4.0 Received: from gift (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 7685367a; Thu, 15 Jun 2017 17:12:15 +0000 (UTC) From: iyzsong@member.fsf.org (=?UTF-8?Q?=E5=AE=8B=E6=96=87=E6=AD=A6?=) References: <87mv9m7g0t.fsf@elephly.net> <87bmq07m0y.fsf@gnu.org> Date: Fri, 16 Jun 2017 01:12:15 +0800 In-Reply-To: <87bmq07m0y.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 07 Jun 2017 01:07:41 +0200") Message-ID: <87mv99rx8w.fsf@member.fsf.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Hi Ricardo, > > Ricardo Wurmus 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=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 rea= lly > tell what=E2=80=99s 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=E2=80=99m 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! From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27155] [PATCH 0/2] Support service extensions on the "final" service values Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 21 Jun 2017 13:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: iyzsong@member.fsf.org (=?UTF-8?Q?=E5=AE=8B=E6=96=87=E6=AD=A6?=) Cc: Ricardo Wurmus , 27155@debbugs.gnu.org Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.149805041025581 (code B ref 27155); Wed, 21 Jun 2017 13:07:01 +0000 Received: (at 27155) by debbugs.gnu.org; 21 Jun 2017 13:06:50 +0000 Received: from localhost ([127.0.0.1]:58972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dNfLO-0006eX-KX for submit@debbugs.gnu.org; Wed, 21 Jun 2017 09:06:50 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48435) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dNfLN-0006eJ-54 for 27155@debbugs.gnu.org; Wed, 21 Jun 2017 09:06:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dNfLD-0003k5-T8 for 27155@debbugs.gnu.org; Wed, 21 Jun 2017 09:06:43 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56700) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dNfLD-0003ju-Pb; Wed, 21 Jun 2017 09:06:39 -0400 Received: from reverse-83.fdn.fr ([80.67.176.83]:32868 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dNfLC-0001W5-Qx; Wed, 21 Jun 2017 09:06:39 -0400 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <87mv9m7g0t.fsf@elephly.net> <87bmq07m0y.fsf@gnu.org> <87mv99rx8w.fsf@member.fsf.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 3 Messidor an 225 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Wed, 21 Jun 2017 15:06:34 +0200 In-Reply-To: <87mv99rx8w.fsf@member.fsf.org> ("=?UTF-8?Q?=E5=AE=8B=E6=96=87=E6=AD=A6?="'s message of "Fri, 16 Jun 2017 01:12:15 +0800") Message-ID: <87h8z9ij6t.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Hi! iyzsong@member.fsf.org (=E5=AE=8B=E6=96=87=E6=AD=A6) 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 =E2=80=9Cetc=E2=80=9D service is one of the =E2=80=9Cspecial=E2= =80=9D services that are not in =E2=80=98%base-services=E2=80=99; instead they=E2=80=99re automatically add= ed by =E2=80=98essential-services=E2=80=99 in (gnu system). Thanks for your feedback, Ludo=E2=80=99. From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27155] [PATCH 0/2] Support service extensions on the "final" References: <20170530215850.7522-1-ludo@gnu.org> Resent-From: Rutherther Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 16 Mar 2025 11:48:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 27155@debbugs.gnu.org Cc: Ricardo Wurmus , Ludovic =?utf-8?Q?Court=C3=A8s?= Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.174212565521916 (code B ref 27155); Sun, 16 Mar 2025 11:48:03 +0000 Received: (at 27155) by debbugs.gnu.org; 16 Mar 2025 11:47:35 +0000 Received: from localhost ([127.0.0.1]:45835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ttmSr-0005hC-HU for submit@debbugs.gnu.org; Sun, 16 Mar 2025 07:47:34 -0400 Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::]:52638 helo=mail.ditigal.xyz) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ttmSo-0005fg-Nl for 27155@debbugs.gnu.org; Sun, 16 Mar 2025 07:47:31 -0400 Received: by cerebrum (OpenSMTPD) with ESMTPSA id f1377565 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); Sun, 16 Mar 2025 11:47:21 +0000 (UTC) From: Rutherther In-Reply-To: 20170530215850.7522-1-ludo@gnu.org Date: Sun, 16 Mar 2025 12:47:21 +0100 Message-ID: <87bju16vue.fsf@ditigal.xyz> MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz; i=@ditigal.xyz; q=dns/txt; s=20240917; t=1742125641; h=from : to : cc : subject : in-reply-to : date : message-id : mime-version : content-type : from; bh=qFtfE/fblWGAmmTQ7YAVV1/xXlrC9McRDzqmwn5ejk0=; b=SAnYyWW5eMThvtmImBoR4H9LGkCUnNk0Ih6CELBFwUgUHiLlnp8g2AEyOdFHQvwI1vsVW amH6m7Ru9qF+8Wf8yakF+Ts32d71mEkL3kTB8HcVY9sXTg4dMaaf/PdMaZohsMg4ex8Ppg0 BxUq77J+e3zR3VeFNYCCcxRPlRamhJU= X-Spam-Score: 1.4 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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 l [...] Content analysis details: (1.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.9 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: ditigal.xyz (xyz)] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.4 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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 l [...] Content analysis details: (1.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.9 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: ditigal.xyz (xyz)] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 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 From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27155] [PATCH 0/2] Support service extensions on the "final" Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 10 Apr 2025 20:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Rutherther Cc: Ricardo Wurmus , 27155@debbugs.gnu.org Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.174431728416783 (code B ref 27155); Thu, 10 Apr 2025 20:35:02 +0000 Received: (at 27155) by debbugs.gnu.org; 10 Apr 2025 20:34:44 +0000 Received: from localhost ([127.0.0.1]:47234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u2ybj-0004Ma-FE for submit@debbugs.gnu.org; Thu, 10 Apr 2025 16:34:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43582) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u2ybT-0004Lq-BP for 27155@debbugs.gnu.org; Thu, 10 Apr 2025 16:34:27 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u2ybM-0006hg-Oe; Thu, 10 Apr 2025 16:34:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=j2NEoB5YMbVSUkdiU+1aQCoDDyJwHX1UdzwdWlQRHWA=; b=T2XrhcRoBzYZKYEvZQhe PGseGS6OjbJtP4zXJ9dlPmygsdobs3u5QGD9DBEpBgLyl7/ir1ABSA2v9k0Mf2mMsz/MEZ71ovP2N 5WyXZTsSq72BXBnVeb3MofRdBEnVN8bgM5l8/hBaNlVTIjvDb8DXhUllxwQMCB7xTt+SQl30b0kA1 l0chtBtZUk43eNqyJbAXXmQiXIVPAknBzyBDtxOmF49+KmtxHjfyDFOLBk2YFK+5pbpq4rnzyiMbu /I98TR4LBqlK9PxlXwKsaSU7YdylH4SEa7cit3m7C7YWnEkzq8IEthOpORtChGlVHabucQ3EGvT7f 7wZ1yBy24lnLTQ==; From: Ludovic =?UTF-8?Q?Court=C3=A8s?= In-Reply-To: <87bju16vue.fsf@ditigal.xyz> (rutherther@ditigal.xyz's message of "Sun, 16 Mar 2025 12:47:21 +0100") References: <87bju16vue.fsf@ditigal.xyz> User-Agent: mu4e 1.12.9; emacs 29.4 X-URL: https://people.bordeaux.inria.fr/lcourtes/ X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu X-Revolutionary-Date: Primidi 21 Germinal an 233 de la =?UTF-8?Q?R=C3=A9volution,?= jour du Gainier Date: Thu, 10 Apr 2025 21:32:44 +0200 Message-ID: <875xjbstgj.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hello Rutherther, Rutherther skribis: > what's the state of this? Why has this been abandoned? It was abandoned first because there wasn=E2=80=99t 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=E2=80=99s a graph of services/service types w= here edges show what node influences each intermediate configuration value; you can follow the arrows and understand what originates where (demonstrated with For example, I would like to change the home mcron shepherd service so th= at it gets > a wayland display env var. I think it=E2=80=99s 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 =E2=80=98wayland-display=E2=80=99 value of the wayl= and service.) >> Right. As discussed on IRC, one problem is ordering: if there are >> several users of this features for a given service, you can=3DE2=3D80=3D= 99t really >> tell what=3DE2=3D80=3D99s going to happen, unless the modifications happ= en 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 =E2=80=9Cambient authority=E2=80=9D in the NixOS module system is one thing I definitely wan= ted to avoid. By =E2=80=9Cambient authority=E2=80=9D I mean that any module ca= n change any option of the global system config; there=E2=80=99s no way to track which m= odule does what, nor whether an option that is set is used at all. Anyway, I=E2=80=99m glad you=E2=80=99re looking into this with a fresh mind= . Hopefully we can revisit it and find an option that brings flexibility without chaos. :-) Thanks, Ludo=E2=80=99. From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27155] [PATCH 0/2] Support service extensions on the "final" Resent-From: Rutherther Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 18 Apr 2025 15:05:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Ricardo Wurmus , 27155@debbugs.gnu.org Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.174498870231145 (code B ref 27155); Fri, 18 Apr 2025 15:05:06 +0000 Received: (at 27155) by debbugs.gnu.org; 18 Apr 2025 15:05:02 +0000 Received: from localhost ([127.0.0.1]:52453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5nGz-00085Y-NQ for submit@debbugs.gnu.org; Fri, 18 Apr 2025 11:05:01 -0400 Received: from ditigal.xyz ([78.46.201.50]:41960 helo=mail.ditigal.xyz) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u5nGm-00081k-9i for 27155@debbugs.gnu.org; Fri, 18 Apr 2025 11:04:54 -0400 Received: by cerebrum (OpenSMTPD) with ESMTPSA id 62a20e40 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); Fri, 18 Apr 2025 15:04:30 +0000 (UTC) From: Rutherther In-Reply-To: <875xjbstgj.fsf@gnu.org> References: <87bju16vue.fsf@ditigal.xyz> <875xjbstgj.fsf@gnu.org> Date: Fri, 18 Apr 2025 17:04:29 +0200 Message-ID: <87v7r1tssi.fsf@ditigal.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz; i=@ditigal.xyz; q=dns/txt; s=20240917; t=1744988670; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding : from; bh=JJl7IPvkLV2wcbqHmZj2ahJ7TOgGzoSjBJvdOobhlcc=; b=pI1l7+4Ufq13ViRBhUMyiyTwXdTTw6d7R0tE2g5XgWWWBuSOGRqHM7hMpMmcIOcl4EnS8 cKPI4tAa8ByjrYmq7vnlHVesYE1bNws3nPWhgZMsduptPzOw/u2cKNcTV4YlD6CleTdu7/C R3gujJosVb6N0Hla8TTV3lEN97+p4I0= X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.46.201.50 listed in bl.score.senderscore.com] -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: ditigal.xyz (xyz)] 0.0 T_SPF_HELO_TEMPERROR SPF: test of HELO record failed (temperror) 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.46.201.50 listed in bl.score.senderscore.com] 0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.46.201.50 listed in sa-trusted.bondedsender.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: ditigal.xyz (xyz)] 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 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=C3=A8s writes: > Hello Rutherther, > > Rutherther skribis: > >> what's the state of this? Why has this been abandoned? > > It was abandoned first because there wasn=E2=80=99t high demand (did peop= le > 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=E2=80=99s 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 > 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 t= hat it gets >> a wayland display env var. > > I think it=E2=80=99s an example that could be solved at the Shepherd leve= l, by > attaching essentially a key/value store to each service (the mcron > service would query the =E2=80=98wayland-display=E2=80=99 value of the wa= yland 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=3DE2=3D80= =3D99t really >>> tell what=3DE2=3D80=3D99s going to happen, unless the modifications hap= pen 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 =E2=80=9Cambient > authority=E2=80=9D in the NixOS module system is one thing I definitely w= anted > to avoid. By =E2=80=9Cambient authority=E2=80=9D I mean that any module = can change any > option of the global system config; there=E2=80=99s 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=E2=80=99m glad you=E2=80=99re looking into this with a fresh mi= nd. Hopefully > we can revisit it and find an option that brings flexibility without > chaos. :-) > > Thanks, > Ludo=E2=80=99. Best regards, Ruther From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27155] [PATCH 0/2] Support service extensions on the "final" Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 23 Apr 2025 10:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Rutherther Cc: Ricardo Wurmus , 27155@debbugs.gnu.org Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.17454043327522 (code B ref 27155); Wed, 23 Apr 2025 10:33:01 +0000 Received: (at 27155) by debbugs.gnu.org; 23 Apr 2025 10:32:12 +0000 Received: from localhost ([127.0.0.1]:54157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u7XOm-0001xG-9c for submit@debbugs.gnu.org; Wed, 23 Apr 2025 06:32:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55862) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u7XOi-0001wg-AB for 27155@debbugs.gnu.org; Wed, 23 Apr 2025 06:32:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u7XOb-0005Vp-VJ; Wed, 23 Apr 2025 06:32:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=MPh8tr2GDLiMc+aaq6tOepzrL/Auo6LU0cVueQV5KPA=; b=eiZdmobVVGJAMTSvU4bj ChrsVSKzuZVQOk0bPk+ygn59LcUu8HREL71+y0jyMX00crH+LuUAh3uohfJXQSjMxOH5laAUjOt29 sUOAQGc9u0pqSzGFr4nEOquW1pRoTFWEqBnlGyrcUXQnv85nD0Nh4Dz2ADXXHUpVAxjOvtXMMMwTA KcuJ5KUZiu0ZZyZeqlGqj3cse6/02t87XxOUIfq0OHzw3YQ4cVfcJeOFKX9atRnc8KcyE3Z+c2Oca 88fNdjtC5iPR+r3W0GHmohmV9rNATDjwqAhAPryqjWvrWS6N2ihk1gZR/J7zQH53gsVOBmWiAzy7a p94XuzKUGlGPaA==; From: Ludovic =?UTF-8?Q?Court=C3=A8s?= In-Reply-To: <87v7r1tssi.fsf@ditigal.xyz> (rutherther@ditigal.xyz's message of "Fri, 18 Apr 2025 17:04:29 +0200") References: <87bju16vue.fsf@ditigal.xyz> <875xjbstgj.fsf@gnu.org> <87v7r1tssi.fsf@ditigal.xyz> User-Agent: mu4e 1.12.9; emacs 29.4 X-URL: https://people.bordeaux.inria.fr/lcourtes/ X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu X-Revolutionary-Date: Quartidi 4 =?UTF-8?Q?Flor=C3=A9al?= an 233 de la =?UTF-8?Q?R=C3=A9volution,?= jour de =?UTF-8?Q?l'Aub=C3=A9pine?= Date: Wed, 23 Apr 2025 12:00:20 +0200 Message-ID: <87bjsnp58r.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) Hi, Rutherther 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 =E2=80=98transformer=E2=80=99 field is exactly like this proposal,= just limited to PAM. >> I think it=E2=80=99s an example that could be solved at the Shepherd lev= el, by >> attaching essentially a key/value store to each service (the mcron >> service would query the =E2=80=98wayland-display=E2=80=99 value of the w= ayland 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 =E2=80=9Cambient >> authority=E2=80=9D in the NixOS module system is one thing I definitely = wanted >> to avoid. By =E2=80=9Cambient authority=E2=80=9D I mean that any module= can change any >> option of the global system config; there=E2=80=99s no way to track whic= h 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 =E2=80=98transformer=E2=80=99 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=E2=80=99. From unknown Fri Jun 13 11:04:51 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#27155] [PATCH 0/2] Support service extensions on the "final" Resent-From: Rutherther Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 23 Apr 2025 16:41:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27155 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Ricardo Wurmus , 27155@debbugs.gnu.org Received: via spool by 27155-submit@debbugs.gnu.org id=B27155.1745426427471 (code B ref 27155); Wed, 23 Apr 2025 16:41:03 +0000 Received: (at 27155) by debbugs.gnu.org; 23 Apr 2025 16:40:27 +0000 Received: from localhost ([127.0.0.1]:58590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u7d96-00006k-6o for submit@debbugs.gnu.org; Wed, 23 Apr 2025 12:40:27 -0400 Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::]:33690 helo=mail.ditigal.xyz) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u7d90-0008Td-CJ for 27155@debbugs.gnu.org; Wed, 23 Apr 2025 12:40:22 -0400 Received: by cerebrum (OpenSMTPD) with ESMTPSA id 93dbf53f (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); Wed, 23 Apr 2025 16:40:11 +0000 (UTC) From: Rutherther In-Reply-To: <87bjsnp58r.fsf@gnu.org> References: <87bju16vue.fsf@ditigal.xyz> <875xjbstgj.fsf@gnu.org> <87v7r1tssi.fsf@ditigal.xyz> <87bjsnp58r.fsf@gnu.org> Date: Wed, 23 Apr 2025 18:40:08 +0200 Message-ID: <87ldrqygpj.fsf@ditigal.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz; i=@ditigal.xyz; q=dns/txt; s=20240917; t=1745426411; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding : from; bh=CrE2TjxtvmoI4G2Ttm14MQ/3vzoDb2M0xMKnax6o9lY=; b=fwM70htnLuVgEytz67bETxD7arERy1XVgJ5An7ch6UKW1BYQ37sN1xo0XKbSqkx+LK3Xs BhtiS25WHLZFPFhhuHy96i6sF7zz8EqmqeEsA5sXr7BdHrh5Qf7dADRdgpWYtm853uVurgH +CjkheCH3q1Efvv5QKqbekB6i/w4CN4= X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello, Ludovic =?UTF-8?Q?Court=C3=A8s?= writes: > Hi, > > Rutherther writes: > >>> I think =?UTF-8?Q?it=E2=80=99s?= an example that could be solved at the Shepherd level, by >>> attaching essentially a key/value store to each service (the mc [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: ditigal.xyz (xyz)] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello, Ludovic =?UTF-8?Q?Court=C3=A8s?= writes: > Hi, > > Rutherther writes: > >>> I think =?UTF-8?Q?it=E2=80=99s?= an example that could be solved at the Shepherd level, by >>> attaching essentially a key/value store to each service (the mc [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: ditigal.xyz (xyz)] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Hello, Ludovic Court=C3=A8s writes: > Hi, > > Rutherther writes: > >>> I think it=E2=80=99s an example that could be solved at the Shepherd le= vel, by >>> attaching essentially a key/value store to each service (the mcron >>> service would query the =E2=80=98wayland-display=E2=80=99 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 =E2=80=9Cambient >>> authority=E2=80=9D in the NixOS module system is one thing I definitely= wanted >>> to avoid. By =E2=80=9Cambient authority=E2=80=9D I mean that any modul= e can change any >>> option of the global system config; there=E2=80=99s no way to track whi= ch 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 =E2=80=98transformer=E2=80=99 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 =3D { listssrht-ingress =3D { unitConfig.JoinsNamespaceOf =3D "opensmtpd.service"; }; todosrht-lmtp =3D { unitConfig.JoinsNamespaceOf =3D "opensmtpd.service"; }; opensmtpd =3D { # Needed for sharing the LMTP sockets with JoinsNamespaceOf=3D serviceConfig.PrivateTmp =3D 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