| Message ID | 20201127084632.GA3077@zpidnp36 |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#44900] services: unattended-upgrade: Add 'search-paths' field. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | fail | View Laminar job |
| cbaines/issue | success | View issue |
Hi, Lars-Dominik Braun <ldb@leibniz-psychology.org> skribis: > I’m using a modular machine configuration, i.e. the scheme file returning the > operating system definition imports several other custom modules with service > definitions etc in the same directory. This does not work well with unattended > upgrades. The attached patch allows adding search paths to the unattended > upgrade service. I’m not sure this is the best solution though. Maybe the > preferred way to add these modules is to a custom channel? Did you see (info "(guix) Unattended Upgrades"): There are cases, though, where referring to ‘/run/current-system/configuration.scm’ is not enough, for instance because that file refers to extra files (SSH public keys, extra configuration files, etc.) via ‘local-file’ and similar constructs. For those cases, we recommend something along these lines: (unattended-upgrade-configuration (operating-system-file (file-append (local-file "." "config-dir" #:recursive? #t) "/config.scm"))) The effect here is to import all of the current directory into the store, and to refer to ‘config.scm’ within that directory. Therefore, uses of ‘local-file’ within ‘config.scm’ will work as expected. *Note G-Expressions::, for information about ‘local-file’ and ‘file-append’. I can see several options: 1. Use the trick above and add (say): (add-to-load-path (dirname (current-filename))) in your config file. Not pretty. 2. Turn your modules into a channel. Nice because there’s no need for a special case, modules are automatically updated at each upgrade, etc., but OTOH requires more paperwork. 3. What you propose. Easy to use but a bit low-level and users could be tempted to pass local file names instead of using ‘local-file’, in which case the process becomes more brittle (depends on things outside the store). > The second patch changes the default channels to #f, i.e. the system default > (/etc/guix/channels.scm), which feels more natural to me. I prefer being explicit here and keep ‘unattended-upgrade-configuration’ self-contained (/etc/guix/channels.scm could be modified behind our back). WDYT? Thanks, Ludo’.
Hi Ludo, > Did you see (info "(guix) Unattended Upgrades"): > 1. Use the trick above and add (say): > > (add-to-load-path (dirname (current-filename))) > > in your config file. Not pretty. yes, saw it, but I wasn’t sure how to load modules from that directory. And I agree, it’s not pretty, but probably better than option 3, because everything is in the store. > 2. Turn your modules into a channel. Nice because there’s no need for > a special case, modules are automatically updated at each upgrade, > etc., but OTOH requires more paperwork. I feel this might be the best option and I’ll give it a try. > I prefer being explicit here and keep ‘unattended-upgrade-configuration’ > self-contained (/etc/guix/channels.scm could be modified behind our > back). Okay, I can see that, but I’d like to use the same list of channels in that service and channels.scm. Since creating an etc-service for /etc/guix/channels.scm does not work, I was left with the other option, i.e. using that file for unattended upgrades. Are there any other options? Cheers, Lars
Hi! Lars-Dominik Braun <ldb@leibniz-psychology.org> skribis: >> I prefer being explicit here and keep ‘unattended-upgrade-configuration’ >> self-contained (/etc/guix/channels.scm could be modified behind our >> back). > Okay, I can see that, but I’d like to use the same list of channels in that > service and channels.scm. Since creating an etc-service for > /etc/guix/channels.scm does not work, I was left with the other option, i.e. > using that file for unattended upgrades. Are there any other options? I’d say that specifying the ‘channels’ field of ‘unattended-upgrade-configuration’ gives you that, no? Also, what doesn’t it work to populate /etc/guix/channels.scm via ‘etc-service-type’? Thanks, Ludo’.
Hi, > > Okay, I can see that, but I’d like to use the same list of channels in that > > service and channels.scm. Since creating an etc-service for > > /etc/guix/channels.scm does not work, I was left with the other option, i.e. > > using that file for unattended upgrades. Are there any other options? > I’d say that specifying the ‘channels’ field of > ‘unattended-upgrade-configuration’ gives you that, no? no, /etc/guix/channels.scm also functions as a default channel list for every users’ `guix pull`, which I also want to have. > Also, what doesn’t it work to populate /etc/guix/channels.scm via > ‘etc-service-type’? This snippet: ---snip--- (simple-service 'guix-channels etc-service-type (list `("guix/channels.scm" , (scheme-file "channels.scm" %guix-channels)))) ---snap--- Causes this error when reconfiguring: ---snip--- activating system... The following derivation will be built: /gnu/store/qqp3vz7r6i6fa7wckzdxs1613gvww4b6-switch-to-system.scm.drv building /gnu/store/qqp3vz7r6i6fa7wckzdxs1613gvww4b6-switch-to-system.scm.drv... making '/gnu/store/ykfn25vpvgmjkq4l8xygs7fwabgkgp2s-system' the current system... setting up setuid programs in '/run/setuid-programs'... populating /etc from /gnu/store/mdpbph8cpgwydy3hwfq0q6sk44bfbk93-etc... guix system: error: symlink: File exists: "/etc/guix" ---snap--- /gnu/store/mdpbph8cpgwydy3hwfq0q6sk44bfbk93-etc looks correct to me, i.e. it has a guix subdirectory with a correct channels.scm file in it. Cheers, Lars
Hi, Lars-Dominik Braun <ldb@leibniz-psychology.org> skribis: > This snippet: > > ---snip--- > (simple-service 'guix-channels etc-service-type > (list `("guix/channels.scm" , (scheme-file "channels.scm" %guix-channels)))) > ---snap--- > > Causes this error when reconfiguring: > > ---snip--- > activating system... > The following derivation will be built: > /gnu/store/qqp3vz7r6i6fa7wckzdxs1613gvww4b6-switch-to-system.scm.drv > > building /gnu/store/qqp3vz7r6i6fa7wckzdxs1613gvww4b6-switch-to-system.scm.drv... > making '/gnu/store/ykfn25vpvgmjkq4l8xygs7fwabgkgp2s-system' the current system... > setting up setuid programs in '/run/setuid-programs'... > populating /etc from /gnu/store/mdpbph8cpgwydy3hwfq0q6sk44bfbk93-etc... > guix system: error: symlink: File exists: "/etc/guix" > ---snap--- > > /gnu/store/mdpbph8cpgwydy3hwfq0q6sk44bfbk93-etc looks correct to me, i.e. it > has a guix subdirectory with a correct channels.scm file in it. Yes, somebody else reported that problem recently (and proposed a solution I think, was it on guix-devel?). The issue here is that /etc/guix is also partly stateful, so there’s ‘activation-service-type’, ‘etc-service-type’, and manual changes say to /etc/guix/machines.scm, are conflicting. Ludo’.
Hi, > > 2. Turn your modules into a channel. Nice because there’s no need for > > a special case, modules are automatically updated at each upgrade, > > etc., but OTOH requires more paperwork. > I feel this might be the best option and I’ll give it a try. I’ve implemented this now and it is indeed a very good solution. For anyone stumbling on this issue, I’m using the following service configuration: ---snip--- (unattended-upgrade-configuration (channels #~(cons* (channel (name 'psychnotebook-deploy) (url "https://github.com/leibniz-psychology/psychnotebook-deploy.git") (introduction (make-channel-introduction "02ae8f9f647ab9650bc9211e728841931f25792c" (openpgp-fingerprint "CA4F 8CF4 37D7 478F DA05 5FD4 4213 7701 1A37 8446")))) %default-channels)) (operating-system-file (scheme-file "config.scm" #~(@ (zpid machines yamunanagar os) yamunanagar-os))) (schedule "55 13 * * *") (services-to-restart '(nginx ntpd guix-publish ssh-daemon mcron))) ---snap--- So, I’m fine with closing this as wontfix. Cheers, Lars
From b425b012533de4a460cf22a14a4fcfbed78c0c2b Mon Sep 17 00:00:00 2001 From: Lars-Dominik Braun <ldb@leibniz-psychology.org> Date: Fri, 27 Nov 2020 09:42:11 +0100 Subject: [PATCH 2/2] services: unattended-upgrade: Change default for 'channels' field. * gnu/services/admin.scm (<unattended-upgrade-configuration>)[channels]: Default to #f. * doc/guix.texi (Unattended Upgrades): Document it. --- doc/guix.texi | 5 ++--- gnu/services/admin.scm | 2 +- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/doc/guix.texi b/doc/guix.texi index 7f42fe8867..5168d7d840 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -17058,10 +17058,9 @@ This is the schedule of upgrades, expressed as a gexp containing an mcron job schedule (@pxref{Guile Syntax, mcron job specifications,, mcron, GNU@tie{}mcron}). -@item @code{channels} (default: @code{#~%default-channels}) +@item @code{channels} (default: @code{#f}) This gexp specifies the channels to use for the upgrade -(@pxref{Channels}). By default, the tip of the official @code{guix} -channel is used. +(@pxref{Channels}). By default, the system’s default is used. @item @code{search-paths} (default: @code{'()}) This list specifies the extra search paths used. By default, no search paths diff --git a/gnu/services/admin.scm b/gnu/services/admin.scm index 87cf76c57f..a1c4abd3e2 100644 --- a/gnu/services/admin.scm +++ b/gnu/services/admin.scm @@ -204,7 +204,7 @@ Old log files are removed or compressed according to the configuration.") (schedule unattended-upgrade-configuration-schedule (default "30 01 * * 0")) (channels unattended-upgrade-configuration-channels - (default #~%default-channels)) + (default #f)) (search-paths unattended-upgrade-configuration-search-paths (default '())) (services-to-restart unattended-upgrade-configuration-services-to-restart -- 2.25.1