bug#68841: guix pack -f squashfs silently ignores symlinks

[Konrad Hinsen]

Let's make a basic Singularity file system containing certificates at
the place many programs expect them to be, i.e. /etc/ssl:

$ guix pack -S /etc/ssl=etc/ssl --format=squashfs bash nss-certs
/gnu/store/mxyc56nsrcgcclvm5qsz5c9fkqwdswpw-bash-nss-certs-squashfs-pack.gz.squashfs

There is no error message concerning the symlink, but it's not recorded
either:

$ guix shell squashfs-tools -- unsquashfs -l 
/gnu/store/mxyc56nsrcgcclvm5qsz5c9fkqwdswpw-bash-nss-certs-squashfs-pack.gz.squashfs
 | grep -v /gnu/store
squashfs-root
squashfs-root/.empty
squashfs-root/.empty_1
squashfs-root/.singularity.d
squashfs-root/.singularity.d/actions
squashfs-root/.singularity.d/env
squashfs-root/.singularity.d/env/90-environment.sh
squashfs-root/bin
squashfs-root/dev
squashfs-root/gnu
squashfs-root/gnu/.empty
squashfs-root/home
squashfs-root/proc
squashfs-root/sys

What *does* work is:

$ guix pack -S /etc=etc --format=squashfs bash nss-certs

which makes me suspect that linking /etc/ssl fails because there is no
/etc in the file system, but I don't much about squashfs, so maybe I am
wrong.

Cheers,
  Konrad

bug#68831: gnu: torbrowser: noscript gets picked up by icecat

[Clément Lassieur]

Hello André,

On Tue, Jan 30 2024, André Batista wrote:

> Hi guix!
>
> It seems that 'make-icecat-extension' is not sufficiently kosher. When
> torbrowser and icecat are both installed to the same user profile,
> noscript gets picked up by icecat too. The same also happens when
> mullvadbrowser is installed: ublock extension is picked up by torbrowser.
>
> Considering there is also a patch to add Librewolf to guix, which will
> probably also share the same extensions when installed on the same
> profile, I'm unsure if the proper way to solve this issue is to write
> similar make-{$browser_name}-extension procedures or to change the
> package definitions for those new browsers.
>
> WDYT?

I thought about it, and I even started working on a fix.  But I stopped
working on it because I thought it added too much complexity for too
little gain.  See:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68298

The default for Tor Browser and Mullvad Browser is that extensions are
not working because tabs are private.  Now if a user uses both Icecat
and Tor Browser and want a different set of extensions for each of them,
they can use 'guix shell', which works perfectly well.  (They can also
still add extensions to the Firefox profile.)  Having 4 versions of each
extension seems cumbersome.

Cheers,
Clément

bug#68835: Resolving package inheritance issue

[Sharlatan Hellseher]

Hi Guix!

> ./etc/teams.scm cc core
- g...@cbaines.net
- d...@jpoiret.xyz
- l...@gnu.org
- othac...@gnu.org
- rek...@elephly.net
- zimon.touto...@gmail.com
- m...@tobias.gr

Long story short, how to resolve package inheritance which would not
break CI ;-) ?

While reviewing and amending patch series from
 I've stabilized it on my local
checkout, which passed complete reconfigure and rebuild few times
(not...).

When I've pushed changes to 
the commit f8c2d8141efef4565d12d8247bade069889b720e broke CI
.

--8<---cut here---start->8---
In unknown file:
   6 (primitive-load-path "gnu/packages/web" #)
In ice-9/eval.scm:
619:8  5 (_ #f)
   626:19  4 (_ #)
   173:55  3 (_ #(#(#(# "minify") 
#) #))
159:9  2 (_ #(#(#(# "minify") 
#) #))
   223:20  1 (proc #(#(#(# "minify") 
#) #))
In unknown file:
   0 (%resolve-variable (7 . go-github-com-tdewolff-minify-v2) 
#)

ERROR: In procedure %resolve-variable:
error: go-github-com-tdewolff-minify-v2: unbound variable
--8<---cut here---end--->8---

My rational was to keep golang module in (gnu packages golang-web) and
the new inherited package providing executable in (gnu packages web)
which introduced the regression.

Here it is that bad boy!
--8<---cut here---start->8---
(define-public minify
  (package
(inherit go-github-com-tdewolff-minify-v2)
(name "minify")
(arguments
 (substitute-keyword-arguments
 (package-arguments go-github-com-tdewolff-minify-v2)
   ((#:install-source? _ #t) #f)
   ((#:import-path _ "github.com/tdewolff/minify/v2")
"github.com/tdewolff/minify/cmd/minify")))
(inputs
 (list go-github-com-djherbis-atime
   go-github-com-dustin-go-humanize
   go-github-com-fsnotify-fsnotify
   go-github-com-matryer-try
   go-github-com-spf13-pflag
--8<---cut here---end--->8---

Having that all too close to my heart I've pushed revert commit
c4687f5437ad89a7e87deed1933b60f6eac83176 wich fixed CI and `guix pull`.

I've started reviewing what could be wrong and maybe the current split
process of (gnu packages golang) into logical modules e.g. golang-xyz,
golang-check, golang-crypto, golang-web introduced deep level of
circular dependencies among Guile modules.

I search for solutions to mitigate the introduced issue.

My plan is to start cleaning up dependency to (gnu packages golang) for
each recently introduced module by moving packages away from it into
groups.

I would be appreciated on any documentation link or examples in code
where package inheritance is used to source package from other module
^.^

Regards,
Oleg


signature.asc
Description: PGP signature

bug#46961: Nginx and certbot cervices don't play well togther

[Clément Lassieur]

Removing guix-devel.

On Tue, Jan 30 2024, Carlo Zancanaro wrote:

> +(define (file-contains? file string)
> +  (string-contains (call-with-input-file file
> + get-string-all)
> +   string))
> +
> +(define (connection-error?)
> +  (file-contains? "/var/log/letsencrypt/letsencrypt.log"
> +  "Failed to establish a new connection"))
> +
> +(let ((script-code 0))
>(for-each
> (match-lambda
>   ((name . command)
>(begin
>  (format #t "Acquiring or renewing certificate: ~a~%" 
> name)

Here we could add ‘(force-output)’, because otherwise those logs arrive
after the certbot logs, and it's hard to understand anything.

> -(set! code (or (apply system* command) code)
> -   '#$commands) code)))
> +(unless (zero? (status:exit-val (apply system* command)))
> +  ;; Certbot errors are always exit code 1, but we'd like
> +  ;; to separate connection errors from other error 
> types.
> +  (if (connection-error?)
> +  ;; If we have a connection error, then bail early
> +  ;; with exit code 2. We don't expect this to
> +  ;; resolve within the timespan of this script.

Could we have a (log + force-output) here too?  (I imagine within a
‘begin’)
> +  (exit 2)
> +  ;; If we have any other type of error, then 
> continue
> +  ;; but exit with a failing status code in the end.

and here?
> +  (set! script-code 1))

And maybe a log also in case the command succeeds.  (So that would mean
to replace ‘unless’ with ‘if’).

> +   '#$commands)
> +  (exit script-code
>  
> +   (let loop ((attempt 0))
> + (let ((code (status:exit-val
> +  (system* #$(certbot-command config)
> +   (cond
> +((and (= code 2)  ; Exit code 2 means connection 
> error
> +  (< attempt 12)) ; 12 * 10 seconds = 2 minutes
 ^--
This comment is not true because certbot takes time to execute (around
15s on my vm).  I don't think there is a need to be that precise.  Maybe
you can just add in in the let form, as in (let ((code ...)
 (max-attempts 12)).

> + (sleep 10)
> + (loop (1+ attempt)))
> +((zero? code)
> + ;; Success!
> + #t)
> +(else
> + ;; Failure.
> + #f))

Also could you update the example in the docs?

>From the doc:
>> @defvar certbot-service-type
>> A service type for the @code{certbot} Let's Encrypt client.  Its value
>> must be a @code{certbot-configuration} record as in this example:
>> 
>> @lisp
>> (define %certbot-deploy-hook
>>   (program-file "certbot-deploy-hook.scm"
>> (with-imported-modules '((gnu services herd))
>>   #~(begin
>>   (use-modules (gnu services herd))
>>   (with-shepherd-action 'nginx ('reload) result result)
   ^
This part isn't useful anymore.  However, we could add a
nginx-service-type and a dhcp-client-service-type so that people have an
idea of what the minimal config is, maybe like I did in my first review:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46961#23.

>> (service certbot-service-type
>>  (certbot-configuration
>>   (email "foo@@example.net")
>>   (certificates
>>(list
>> (certificate-configuration
>>  (domains '("example.net" "www.example.net"))
>>  (deploy-hook %certbot-deploy-hook))
>> (certificate-configuration
>>  (domains '("bar.example.net")))
>> @end lisp

We are almost there, thanks!
Clément

bug#46961: Nginx and certbot cervices don't play well togther

[Clément Lassieur]

I removed guix-devel, not sure we need to spam it.

On Tue, Jan 30 2024, Carlo Zancanaro wrote:

> +(define %default-deploy-hook
> +  (program-file
> +   "reload-nginx.scm"
> +   (with-imported-modules '((gnu services herd))
> + #~(begin
> + (use-modules (gnu services herd))
> + (with-shepherd-action 'nginx ('reload) result result)
> +
>  (define-record-type* 
>certificate-configuration make-certificate-configuration
>certificate-configuration?
> @@ -65,7 +74,7 @@ (define-record-type* 
>(cleanup-hookcertificate-cleanup-hook
> (default #f))
>(deploy-hook certificate-configuration-deploy-hook
> -   (default #f))
> +   (default %default-deploy-hook))
>(start-self-signed?  certificate-configuration-start-self-signed?
> (default #t)))

I'd reload within ‘certbot-deploy-hook’, between ‘rename-file’ and “(if
deploy-hook-script” so that people don't get surprised, when they use a
deploy-hook for unrelated reasons, that the nginx doesn't reload
anymore.

Plus, reloading nginx is harmless.

bug#46961: [PATCH v2 0/4] Make certbot play more nicely with nginx

[Wojtek Kosior via Bug reports for GNU Guix]

I sympathize with your approach (I, too, have been supplementing
Certbot with self-signed certs for some time).

What would also be cool is not to have `certbot-service-type` depend on
`nginx-service-type` in the first place.  So that one can more easily
use another HTTP server.  It can of course be achieved with
`remove-service-extensions` from `(gnu services)`, it's just less
elegant than having it supported directly.

Perhaps some variant of the "dependency inversion principle" would fit
here?  How about the following set of service types?

- certbot-tool-service-type — does what `certbot-service-type` used to
  do until now except it doesn't extend `nginx-service-type` and
  can itself be extended with not just ``s
  but also ``
- certbot/nginx-service-type — takes in ``,
  extends both `certbot-tool-service-type` and `nginx-service-type`
- certbot/httpd-service-type — takes in ``,
  extends both `certbot-tool-service-type` and `httpd-service-type`
- certbot-service-type — deprecated, functions as an alias for
  `certbot/nginx-service-type`

Your proposals are of course useful as well, regardless of this being
done

Best :)
Wojtek


-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)


On Wed, 31 Jan 2024 08:48:54 +1100 Carlo Zancanaro  
wrote:

> Hi Felix,
> 
> On Tue, Jan 30 2024, Felix Lechner wrote:
> > On Tue, Jan 30 2024, Carlo Zancanaro wrote:  
> >> certbot can't produce certificates without a functional nginx  
> >
> > Yes, it can. The option is called --standalone. [1]  
> 
> You are correct, of course. If I had been more precise I would 
> have said "with our current configuration, certbot can't produce 
> certificates without a functional nginx".
> 
> > Maybe another way to bootstrap the certificates would be to hold 
> > off on starting Nginx or Apache until all certificates are 
> > obtained?  
> 
> This could work, but I see a few downsides.
> 
> As Clément has already mentioned, this would make nginx dependent 
> on certbot. This causes problems for servers disconnected from the 
> general internet, but it also shifts complexity into the nginx 
> service without much benefit over the patch series I'm proposing. 
> We'd need to add more configuration on the nginx side to control 
> whether to delay startup based on whether we actually want 
> certificates. This would delay the startup of the whole nginx 
> process, even if some server configurations don't require new 
> certificates.
> 
> For renewal, we would also have two options: (1) use --standalone, 
> and require a period of downtime for our web server; or (2) use 
> --webroot, and maintain two code paths for the two cases. I think 
> it's a bad idea for Guix to make a decision that requires downtime 
> of user systems if there's an alternative, so I don't like (1). 
> Maintaining two "similar but different" code paths for (2) doesn't 
> seem like a clear advantage over the patch series I'm proposing.
> 
> > Anyway, that's what I do manually.  
> 
> I use the DNS challenge type, with hooks which automatically 
> create/remove DNS records. This solves all the problems I'm 
> bringing up (i.e. doesn't require nginx, doesn't involve downtime, 
> has a single code path), but I don't think Guix can assume that 
> all users have the ability to do this. My aim with this patch 
> series is to make the default certbot configuration work for the 
> common case of a simple web server, without manual intervention.
> 
> Carlo
> 


pgp7PgAIN953d.pgp
Description: OpenPGP digital signature

bug#68831: gnu: torbrowser: noscript gets picked up by icecat

[André Batista]

Hi guix!

It seems that 'make-icecat-extension' is not sufficiently kosher. When
torbrowser and icecat are both installed to the same user profile,
noscript gets picked up by icecat too. The same also happens when
mullvadbrowser is installed: ublock extension is picked up by torbrowser.

Considering there is also a patch to add Librewolf to guix, which will
probably also share the same extensions when installed on the same
profile, I'm unsure if the proper way to solve this issue is to write
similar make-{$browser_name}-extension procedures or to change the
package definitions for those new browsers.

WDYT?

bug#68811: build hash inconsistency

[Zacchaeus Scheffer]

Hi Josselin,

Alas, the problem persists ~.~

Device A:
~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- 
build qtwebengine --derivations --system=aarch64-linux --no-grafts --dry-run
/gnu/store/gnrk76mlrv3ipm2k3lpmy1533mn9dqc3-qtwebengine-6.5.2.drv

Device B:
~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- 
build qtwebengine --derivations --system=aarch64-linux --no-grafts --dry-run
/gnu/store/qpb6d1qqx357rkydk0xv6ail6b9dcqs6-qtwebengine-6.5.2.drv

The fact that Device A finds substitutes for nearly everything while
Device B doesn't makes me think that B is "wrong".  Device A is a 3GiB
RAM Librem 5 (made in China), and Device B is a 4GiB RAM Liberty Phone
(made in USA).  (Maybe US backdoor bots need to up their stealth game?)
You can find info on how I set up guix at
https://zacchae.us/guix-usd.org, specifically the section "Setting up
guix home"


-Zacchae


PS - I see your response on issues.guix.gnu.org, but didn't get an
email.  I thought submitting bugs automatically subscribed me?

bug#46961: [PATCH v2 0/4] Make certbot play more nicely with nginx

[Carlo Zancanaro]

Hi Felix,

On Tue, Jan 30 2024, Felix Lechner wrote:

On Tue, Jan 30 2024, Carlo Zancanaro wrote:

certbot can't produce certificates without a functional nginx


Yes, it can. The option is called --standalone. [1]


You are correct, of course. If I had been more precise I would 
have said "with our current configuration, certbot can't produce 
certificates without a functional nginx".


Maybe another way to bootstrap the certificates would be to hold 
off on starting Nginx or Apache until all certificates are 
obtained?


This could work, but I see a few downsides.

As Clément has already mentioned, this would make nginx dependent 
on certbot. This causes problems for servers disconnected from the 
general internet, but it also shifts complexity into the nginx 
service without much benefit over the patch series I'm proposing. 
We'd need to add more configuration on the nginx side to control 
whether to delay startup based on whether we actually want 
certificates. This would delay the startup of the whole nginx 
process, even if some server configurations don't require new 
certificates.


For renewal, we would also have two options: (1) use --standalone, 
and require a period of downtime for our web server; or (2) use 
--webroot, and maintain two code paths for the two cases. I think 
it's a bad idea for Guix to make a decision that requires downtime 
of user systems if there's an alternative, so I don't like (1). 
Maintaining two "similar but different" code paths for (2) doesn't 
seem like a clear advantage over the patch series I'm proposing.



Anyway, that's what I do manually.


I use the DNS challenge type, with hooks which automatically 
create/remove DNS records. This solves all the problems I'm 
bringing up (i.e. doesn't require nginx, doesn't involve downtime, 
has a single code path), but I don't think Guix can assume that 
all users have the ability to do this. My aim with this patch 
series is to make the default certbot configuration work for the 
common case of a simple web server, without manual intervention.


Carlo

bug#68747: Extending postgresql-role-service-type as shown in manual leads to crash

[Josselin Poiret via Bug reports for GNU Guix]

Hi Maxim,

I guess this is not explained that well, but the service-extension
snippet is supposed to go under the (extensions ...) field of a
 record.  If you want to extend this in your system
config, you want (simple-service ...) instead, with e.g.

--8<---cut here---start->8---
(simple-service 'alice-role postgresql-role-service-type
(postgresql-role
 (name "alice")
 (create-database? #t)))
--8<---cut here---end--->8---

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68760: I guess I found a bug in "guix pull" ?

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

jbranso--- via Bug reports for GNU Guix  writes:

>  message: "error parsing derivation 
> `/gnu/store/3nppfdxy9vgg9ls6qi8j8pkzw2khi98h-git-minimal-2.41.0.drv': 
> expected string `Derive(['"
>  status: 1
> guix pull: error: You found a bug: the program 
> '/gnu/store/m9z876jpmpbslc6qaikbp9fk5dv01y3n-compute-guix-derivation'

Looks like the elusive "empty drv" bug (maybe caused by fs corruption?).
Can you `guix gc -D` that drv and retry?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68811: build hash inconsistency

[Josselin Poiret via Bug reports for GNU Guix]

Hi Zacchaeus,

Can you try the same, but this time with the --no-grafts option?  That
could be a source of issues.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#46961: [PATCH v2 0/4] Make certbot play more nicely with nginx

[Clément Lassieur]

On Tue, Jan 30 2024, Felix Lechner via Bug reports for GNU Guix wrote:

> Hi Carlo,
>
> On Tue, Jan 30 2024, Carlo Zancanaro wrote:
>
>> certbot can't produce certificates without a functional nginx
>
> Yes, it can. The option is called --standalone. [1]
>
> Maybe another way to bootstrap the certificates would be to hold off on
> starting Nginx or Apache until all certificates are obtained?

Yes but if we do this and there is no internet, nginx won't start right?

Carlo's solution allows to have a working nginx even when certbot fails.

(If I understand well)

> Anyway, that's what I do manually.
>
> Kind regards
> Felix
>
> [1] https://eff-certbot.readthedocs.io/en/latest/using.html#standalone

bug#68811: build hash inconsistency

[Zacchaeus Scheffer]

Saku Laesvuori  writes:

> Those hashes are not comparable: i9ir..nd (A) is the hash of the built
> store item and 6n9aq..qn (B) is the hash of the derivation that builds
> the store item.

Ah, rookie mistake :|

> But I do think it is weird if the derivation is not present on the
> machine that build qutebrowser. Would you mind sending the output of
> `guix time-machine ... -- build --derivations ...` from both machines?
> If they return a different hash you could maybe also check the returned
> `/gnu/store/...-qutebrowser-2.5.4.drv` files to see what is the
> difference between them.

The derivations returned by guix build are still different:

Device A:
~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- 
build qutebrowser --derivations --dry-run
/gnu/store/vyk5zfr2bjh4cilw4zk3d5xkjiar99h0-qutebrowser-2.5.4.drv

Device B:
~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- 
build qutebrowser --derivations --dry-run
The following derivations would be built:
  /gnu/store/6n9aq7l5x26xfgrbvws7gvscbzvq5gqn-qutebrowser-2.5.4.drv
  /gnu/store/05wj7wf7bdlkm1ar58kpakvp52drrz7p-qtwebengine-5.15.10.drv
  /gnu/store/7nmv55qqw62jwzrd650vm434s3wpi7i3-python-pyqtwebengine-5.15.9.drv

I wanted to build the .drv for qutebrowser as you suggested, but trying
to do so caused qtwebengine to actually begin to build (not an option).
I decided to try and build the .drv for qtwebengine on both devices and
got even more interesting differences (see below).  Main things I
noticed: qtwebengine-everywhere-src has different hashes but they are
both found on substitute servers, the qtwebengine .drv file also has
different hashes, oh no that's a lot of thing my device is trying to
build.

I get errors if I try to build for armhf-linux, so I don't think I
installed the wrong version of Guix.  Could it be a difference in
guix-daemon version?  I have Guix on foreign distro, but I modified the
guix-daemon service to point to /var/guix/../root/../guix daemon instead
of /usr/bin/guix-daemon.  Those root profile versions could be quite
different between the two devices (though in theory that shouldn't
matter).


-Zacchae


Device A:
~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- 
build qtwebengine --derivations --dry-run
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivation would be built:
  /gnu/store/gnrk76mlrv3ipm2k3lpmy1533mn9dqc3-qtwebengine-6.5.2.drv
470.1 MB would be downloaded:
  /gnu/store/yw7r6bzl0yya0s0h9glz06vy2j88f14d-python-soupsieve-2.2.1
  /gnu/store/i42j0d1797cw6jh3mnrdfgwz2mvsgnv7-clang-14.0.6
  /gnu/store/2ghh4x5j4hsanan9rpka80lxdh1kxnrq-lld-wrapper-0
  /gnu/store/9ylcnhf8rcgwd3jazghz72jcq67kb7hs-lld-14.0.6
  /gnu/store/zsa0xdc4pqjils8j8gn6s0cgcf22j48c-ld.lld-wrapper-0
  /gnu/store/bjd1gyvag1fjwbm4q8fdkx4ci348khwn-lld-as-ld-wrapper-14.0.6
  /gnu/store/b3j2dabjfk3z8vrcdn04dxdr4m8834hs-openh264-2.3.0
  /gnu/store/ymjvjq5cyi8cclsrkqmmih6jsmxidjwp-cmake-minimal-3.24.2
  /gnu/store/66anfjz8bv5a5rf9ii9fd66dzga9dlv6-jsoncpp-1.9.5
  /gnu/store/b2bkchln7na32bk5mfd1gl896ac2ng9d-clang-runtime-14.0.6
  /gnu/store/na1xngg46bwpxh9jl74hnsw5gp5q8mbp-python-beautifulsoup4-4.11.1
  /gnu/store/i5hhylp02w3qqf2xjyws9kbii93jjqcs-libxkbfile-1.1.0
  /gnu/store/cy356bl5cj9sd915pwzvx1l2njvvh80l-qtmultimedia-6.5.2
  /gnu/store/w3ja0fcg7x2g8pr0l5ggzpbjbs1sxzw2-python-html5lib-1.1
  /gnu/store/8c5al6nn6ihqm6vv71fszv0k3pm0zy4b-llvm-14.0.6
  /gnu/store/i74mgypyv2j7i6p28x5z5r1l7mn3q11d-python-chardet-5.1.0
  /gnu/store/x0j572gnp5az71lcxs58274z11g27rsg-qtwebchannel-6.5.2
  /gnu/store/yqppj5kr0fzph6wvbhxlq6v6ynpa5xsq-protobuf-3.21.9
  /gnu/store/0cwx6qvc0jl5amb6lcanninis5xwsm49-md4c-0.4.8
  /gnu/store/a51gd25m22p623c3mwpbsc0bah30r534-qtbase-6.5.2
  /gnu/store/xylrvhrdv72x62vi94f73m7wdq8361r6-qtlanguageserver-6.5.2
  /gnu/store/6m5andsmqhxk7jrk1f0fmsa5012jmiw9-qtdeclarative-6.5.2
  
/gnu/store/qi88j5lvxg2cmc391frvvlz91m4jv3ij-qtwebengine-everywhere-src-6.5.2.tar.xz
  /gnu/store/733pxaaxhdqs95a7qp7ydh831a77lyzp-ninja-1.11.1
  /gnu/store/qjby2hz1d2154jx06755x8wxyfi5ycmd-python-webencodings-0.5.1
  /gnu/store/1ik19yadbhc959nbk42gb548139vypp3-node-18.19.0

Device B:
~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- 
build --derivations qtwebengine --dry-run
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivations would be built:
  /gnu/store/qgk0k5312p9bfikhgi87644rdb9h71g5-qtwebengine-6.5.2.drv
  /gnu/store/3kr5g43593v5x42nhz2396hb8a4sp7k8-qtwebchannel-6.5.2.drv
  /gnu/store/1waf6s55grvdx686nn4fg5mfsxz0567g-qtwebsockets-6.5.2.drv
  /gnu/store/lffwivm3lgk8p5sgifa49wx3j29srlc7-qtdeclarative-6.5.2.drv
  /gnu/store/082dd9z9d8n5s09x4m6k4d1ckxx4yzj2-qtshadertools-6.5.2.drv
  

bug#68474: [Guix-Past]: openssl@1.0.2u does not pass tests

[Ludovic Courtès]

Hi,

Jean-Pierre De Jesus Diaz  skribis:

> And the from the error file that the test writes:
>
> $ cat /tmp/guix-build-openssl-1.0.2u.drv-0/openssl-1.0.2u/test/cms.err
> Verification failure
> 140737353281920:error:21075075:PKCS7 routines:PKCS7_verify:certificate
> verify error:pk7_smime.c:335:Verify error:certificate has expired

This is a typically “time trap”.  Options are: use libfaketime to run
“make check”, change the certificates so they don’t expire, or skip
those tests.

Would you like to give it a try?

Thanks,
Ludo’.

bug#68822: Channel dependencies picked at the wrong commit

[Ludovic Courtès]

When a channel is specified both implicitly, as the dependency of
another channel, and explicitly, in the user-provided channels file, the
“most specific” one wins—the one that has a non-#f ‘commit’ field.

However, the dependencies of that channel may be read from the wrong
one—the least-specific one.  And they can be wrong.

Here’s an example that illustrates this corner case with ‘guix
time-machine’ taken from current Guix
(ca. 65dc2d40cb113382fb98796f1d04099f28cab355).

--8<---cut here---start->8---
$ guix time-machine -C channels.pinned.scm -- describe
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Updating channel 'guix-hpc-non-free' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-hpc-non-free.git'...
Updating channel 'guix-hpc' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-hpc.git'...
Updating channel 'guix-science-nonfree' from Git repository at 
'https://github.com/guix-science/guix-science-nonfree.git'...
Updating channel 'guix-science' from Git repository at 
'https://github.com/guix-science/guix-science.git'...
Updating channel 'guix-past' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-past'...
Updating channel 'guix-science-nonfree' from Git repository at 
'https://github.com/guix-science/guix-science-nonfree.git'...
Updating channel 'guix-past' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-past'...
Updating channel 'guix-hpc' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-hpc.git'...
Computing Guix derivation for 'x86_64-linux'... /
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://guix.bordeaux.inria.fr'... 100.0%
The following derivations will be built:
  /gnu/store/m54f7d5prrnilnlkp6iqr9h0wqb70pk2-profile.drv
  /gnu/store/4bkkgq25zgc93iz8d1rzjf63y394ya9d-guix-science-nonfree.drv
  /gnu/store/cnqz5j3mp0qahwvlhv0ykq5bc3m5knnx-inferior-script.scm.drv
  /gnu/store/5agf7bgp7k4sddi5ll6g972cyv5jaksq-module-import-compiled.drv
  /gnu/store/8aql4dp23w2k4dvz26dbkxxix6l2rx7v-guix-past.drv
  /gnu/store/zzb5g3lfvmhmbw9vf6zzz1pdjmy5zikl-inferior-script.scm.drv
  /gnu/store/w8ga4919913v1s3flg21pij60hwsndg4-guix-hpc-non-free.drv
  /gnu/store/lj20q8hc772fm9kh148lxi0zxdral7bv-inferior-script.scm.drv
  /gnu/store/lvmnbdl4d008dyjdf8i4dbzrd5lvbn2m-module-import-compiled.drv
  /gnu/store/yykh03drscwzra0fjnc0657c3fhjn7bh-guix-science.drv
  /gnu/store/7s850hb4zv0wn9hclpsq3gykmxmcrcbc-profile.drv
  /gnu/store/as87m36426pk6bfx7f2aix4kdsk1ials-inferior-script.scm.drv

builder for `/gnu/store/pjrgzdpndm31m0kg6jgrlmkzxnbhp0pz-guix-science' failed 
previously (cached)
build of /gnu/store/yykh03drscwzra0fjnc0657c3fhjn7bh-guix-science.drv failed
View build log at 
'/var/log/guix/drvs/yy/kh03drscwzra0fjnc0657c3fhjn7bh-guix-science.drv.gz'.
$ cat channels.pinned.scm
(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch "master")
(commit
  "597f1cd1c46ffb92c3e0145de0071545a4c64865")
(introduction
  (make-channel-introduction
"9edb3f66fd807b096b48283debdcddccfea34bad"
(openpgp-fingerprint
  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"
  (channel
(name 'guix-hpc-non-free)
(url "https://gitlab.inria.fr/guix-hpc/guix-hpc-non-free.git;)
(branch "master")
(commit
  "372c5f471448b32c9204f79c1d46e9b984d03c07"))
  (channel
(name 'guix-science-nonfree)
(url "https://github.com/guix-science/guix-science-nonfree.git;)
(branch "master")
(commit
  "9a3f3824d8ed289832d706679410edadac1202ae")
(introduction
  (make-channel-introduction
"58661b110325fd5d9b40e6f0177cc486a615817e"
(openpgp-fingerprint
  "CA4F 8CF4 37D7 478F DA05  5FD4 4213 7701 1A37 8446"
  (channel
(name 'guix-past)
(url "https://gitlab.inria.fr/guix-hpc/guix-past;)
(branch "master")
(commit
  "1e25b23faa6b1716deaf7e1782becb5da6855942")
(introduction
  (make-channel-introduction
"0c119db2ea86a389769f4d2b9c6f5c41c027e336"
(openpgp-fingerprint
  "3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5"
  (channel
(name 'guix-hpc)
(url "https://gitlab.inria.fr/guix-hpc/guix-hpc.git;)
(branch "master")
(commit
  "3ffe8f79a2f128111785fb1107d5f803e00bf00c")))
$ zcat /var/log/guix/drvs/yy/kh03drscwzra0fjnc0657c3fhjn7bh-guix-science.drv.gz
(repl-version 0 1 1)
WARNING: (guix-science build bazel-build-system): imported module (guix build 
utils) overrides core binding `delete'
(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value 

bug#30130: Add ‘guix whereis’ command

[Ricardo Wurmus]

I’m closing this because we now have “guix locate”.

-- 
Ricardo

bug#68195: flite fails to build on core-updates

[Simon South]

This was obsoleted by commit 5528123265f9, "gnu: flite: Disable parallel
build."

-- 
Simon South
si...@simonsouth.net

bug#46961: [PATCH v2 0/4] Make certbot play more nicely with nginx

[Felix Lechner via Bug reports for GNU Guix]

Hi Carlo,

On Tue, Jan 30 2024, Carlo Zancanaro wrote:

> certbot can't produce certificates without a functional nginx

Yes, it can. The option is called --standalone. [1]

Maybe another way to bootstrap the certificates would be to hold off on
starting Nginx or Apache until all certificates are obtained?

Anyway, that's what I do manually.

Kind regards
Felix

[1] https://eff-certbot.readthedocs.io/en/latest/using.html#standalone

bug#46961: [PATCH v2 2/4] services: certbot: Create self-signed certificates before certbot runs.

[Carlo Zancanaro]

* gnu/services/certbot.scm (): Add
start-self-signed? field.
(generate-certificate-gexp): New procedure.
(certbot-activation): Generate self-signed certificates when
start-self-signed? is #t.
* doc/guix.texi (Certificate services): Document start-self-signed?.

Change-Id: Icfd85ae0c3e29324acbcde6ba283546cf0e27a1d
---
 doc/guix.texi|  6 
 gnu/services/certbot.scm | 62 ++--
 2 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index b134d45a16..58a65fe0b7 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -32690,6 +32690,12 @@ Certificate Services
 contain a space-delimited list of renewed certificate domains (for
 example, @samp{"example.com www.example.com"}.
 
+@item @code{start-self-signed?} (default: @code{#t})
+Whether to generate an initial self-signed certificate during system
+activation.  This option is particularly useful to allow @code{nginx} to
+start before @code{certbot} has run, because @code{certbot} relies on
+@code{nginx} running to perform HTTP challenges.
+
 @end table
 @end deftp
 
diff --git a/gnu/services/certbot.scm b/gnu/services/certbot.scm
index 3926d0551a..10b99f5630 100644
--- a/gnu/services/certbot.scm
+++ b/gnu/services/certbot.scm
@@ -35,6 +35,7 @@ (define-module (gnu services certbot)
   #:use-module (guix records)
   #:use-module (guix gexp)
   #:use-module (srfi srfi-1)
+  #:use-module (ice-9 format)
   #:use-module (ice-9 match)
   #:export (certbot-service-type
 certbot-configuration
@@ -64,7 +65,9 @@ (define-record-type* 
   (cleanup-hookcertificate-cleanup-hook
(default #f))
   (deploy-hook certificate-configuration-deploy-hook
-   (default #f)))
+   (default #f))
+  (start-self-signed?  certificate-configuration-start-self-signed?
+   (default #t)))
 
 (define-record-type* 
   certbot-configuration make-certbot-configuration
@@ -91,7 +94,10 @@ (define-record-type* 
 (define (certbot-deploy-hook name deploy-hook-script)
   "Returns a gexp which creates symlinks for privkey.pem and fullchain.pem
 from /etc/certs/NAME to /etc/letsenctypt/live/NAME.  If DEPLOY-HOOK-SCRIPT is
-not #f then it is run after the symlinks have been created."
+not #f then it is run after the symlinks have been created.  This wrapping is
+necessary for certificates with start-self-signed? set to #t, as it will
+overwrite the initial self-signed certificates upon the first successful
+deploy."
   (program-file
(string-append name "-deploy-hook")
(with-imported-modules '((guix build utils))
@@ -108,7 +114,8 @@ (define (certbot-deploy-hook name deploy-hook-script)
  "/etc/letsencrypt/live/" name "/fullchain.pem")
   #$(string-append "/etc/certs/" name "/fullchain.pem.new"))
 
- ;; Rename over the top of the old ones, if there are any.
+ ;; Rename over the top of the old ones, just in case they were the
+ ;; original self-signed certificates.
  (rename-file #$(string-append "/etc/certs/" name "/privkey.pem.new")
   #$(string-append "/etc/certs/" name "/privkey.pem"))
  (rename-file #$(string-append "/etc/certs/" name "/fullchain.pem.new")
@@ -184,6 +191,47 @@ (define (certbot-renewal-jobs config)
#~(job '(next-minute-from (next-hour '(0 12)) (list (random 60)))
   #$(certbot-command config
 
+(define (generate-certificate-gexp certbot-cert-directory rsa-key-size)
+  (match-lambda
+(($  name (primary-domain other-domains ...)
+challenge
+csr authentication-hook
+cleanup-hook deploy-hook)
+ (let (;; Arbitrary default subject, with just the
+   ;; right domain filled in. These values don't
+   ;; have any real significance.
+   (subject (string-append
+ "/C=US/ST=Oregon/L=Portland/O=Company Name/OU=Org/CN="
+ primary-domain))
+   (alt-names (if (null? other-domains)
+  #f
+  (format #f "subjectAltName=~{DNS:~a~^,~}"
+  other-domains)))
+   (directory (string-append "/etc/certs/" (or name primary-domain
+   #~(when (not (file-exists? #$directory))
+   ;; We generate self-signed certificates in /etc/certs/{domain},
+   ;; because certbot is very sensitive to its directory
+   ;; structure. It refuses to write over the top of existing files,
+   ;; so we need to use a directory outside of its control.
+   ;;
+   ;; These certificates are overwritten by the certbot deploy hook
+   ;; the first time it successfully obtains a letsencrypt-signed
+   ;; certificate.
+   (mkdir-p #$directory)
+   (chmod #$directory #o755)
+   

bug#46961: [PATCH v2 4/4] services: certbot: Add one-shot service to renew certificates.

[Carlo Zancanaro]

* gnu/services/certbot.scm (certbot-renewal-one-shot): New procedure.
(certbot-service-type)[extensions]: Add it to shepherd-root extension.
(certbot-command): Make connection errors return a different exit code.
(certbot-activation): Remove message with certificate renewal instructions.

Change-Id: I614ac6214a753dba0396e2385a75926c8355caa1
---
 gnu/services/certbot.scm | 77 +---
 1 file changed, 65 insertions(+), 12 deletions(-)

diff --git a/gnu/services/certbot.scm b/gnu/services/certbot.scm
index 490b9e8d6d..d6354c86d3 100644
--- a/gnu/services/certbot.scm
+++ b/gnu/services/certbot.scm
@@ -183,15 +183,37 @@ (define certbot-command
(program-file
 "certbot-command"
 #~(begin
-(use-modules (ice-9 match))
-(let ((code 0))
+(use-modules (ice-9 match)
+ (ice-9 textual-ports))
+
+(define (file-contains? file string)
+  (string-contains (call-with-input-file file
+ get-string-all)
+   string))
+
+(define (connection-error?)
+  (file-contains? "/var/log/letsencrypt/letsencrypt.log"
+  "Failed to establish a new connection"))
+
+(let ((script-code 0))
   (for-each
(match-lambda
  ((name . command)
   (begin
 (format #t "Acquiring or renewing certificate: ~a~%" name)
-(set! code (or (apply system* command) code)
-   '#$commands) code)))
+(unless (zero? (status:exit-val (apply system* command)))
+  ;; Certbot errors are always exit code 1, but we'd like
+  ;; to separate connection errors from other error types.
+  (if (connection-error?)
+  ;; If we have a connection error, then bail early
+  ;; with exit code 2. We don't expect this to
+  ;; resolve within the timespan of this script.
+  (exit 2)
+  ;; If we have any other type of error, then continue
+  ;; but exit with a failing status code in the end.
+  (set! script-code 1))
+   '#$commands)
+  (exit script-code
 
 (define (certbot-renewal-jobs config)
   (list
@@ -200,6 +222,40 @@ (define (certbot-renewal-jobs config)
#~(job '(next-minute-from (next-hour '(0 12)) (list (random 60)))
   #$(certbot-command config
 
+(define (certbot-renewal-one-shot config)
+  (list
+   ;; Renew certificates when the system first starts. This is a one-shot
+   ;; service, because the mcron configuration will take care of running this
+   ;; periodically. This is most useful the very first time the system starts,
+   ;; to overwrite our self-signed certificates as soon as possible without
+   ;; user intervention.
+   (shepherd-service
+(provision '(renew-certbot-certificates))
+(requirement '(nginx))
+(one-shot? #t)
+(start #~(lambda _
+   ;; This needs the network, but there's no reliable way to know
+   ;; if the network is up other than trying. If we fail due to a
+   ;; connection error we retry a number of times in the hope that
+   ;; the network comes up soon.
+   (let loop ((attempt 0))
+ (let ((code (status:exit-val
+  (system* #$(certbot-command config)
+   (cond
+((and (= code 2)  ; Exit code 2 means connection error
+  (< attempt 12)) ; 12 * 10 seconds = 2 minutes
+ (sleep 10)
+ (loop (1+ attempt)))
+((zero? code)
+ ;; Success!
+ #t)
+(else
+ ;; Failure.
+ #f))
+(auto-start? #t)
+(documentation "Call certbot to renew certificates.")
+(actions (list (shepherd-configuration-action (certbot-command 
config)))
+
 (define (generate-certificate-gexp certbot-cert-directory rsa-key-size)
   (match-lambda
 (($  name (primary-domain other-domains ...)
@@ -243,9 +299,7 @@ (define (generate-certificate-gexp certbot-cert-directory 
rsa-key-size)
 
 (define (certbot-activation config)
   (let* ((certbot-directory "/var/lib/certbot")
- (certbot-cert-directory "/etc/letsencrypt/live")
- (script (in-vicinity certbot-directory "renew-certificates"))
- (message (format #f (G_ "~a may need to be run~%") script)))
+ (certbot-cert-directory "/etc/letsencrypt/live"))
 (match config
   (($  package webroot certificates email
   server rsa-key-size default-location)
@@ -261,10 

bug#46961: [PATCH v2 1/4] services: certbot: Symlink certificates to /etc/certs.

[Carlo Zancanaro]

* gnu/services/certbot.scm (certbot-deploy-hook): New procedure.
(certbot-command): Pass new deploy hook to certbot.
* doc/guix.texi: Replace "letsencrypt/live" with "certs" throughout.

Change-Id: I2ba5e4903d1e293e566b732a84b07d5a134b697d
---
 doc/guix.texi| 26 +-
 gnu/services/certbot.scm | 36 ++--
 2 files changed, 47 insertions(+), 15 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index bb0af26d93..b134d45a16 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -43,7 +43,7 @@
 Copyright @copyright{} 2017, 2018, 2019 Clément Lassieur@*
 Copyright @copyright{} 2017, 2018, 2020, 2021, 2022 Mathieu Othacehe@*
 Copyright @copyright{} 2017 Federico Beffa@*
-Copyright @copyright{} 2017, 2018 Carlo Zancanaro@*
+Copyright @copyright{} 2017, 2018, 2024 Carlo Zancanaro@*
 Copyright @copyright{} 2017 Thomas Danckaert@*
 Copyright @copyright{} 2017 humanitiesNerd@*
 Copyright @copyright{} 2017, 2021 Christine Lemmer-Webber@*
@@ -28135,7 +28135,7 @@ Messaging Services
 them.  See @url{https://prosody.im/doc/letsencrypt}.
 
 @example
-prosodyctl --root cert import /etc/letsencrypt/live
+prosodyctl --root cert import /etc/certs
 @end example
 
 The available configuration parameters follow.  Each parameter
@@ -28846,8 +28846,8 @@ Telephony Services
   (welcome-text
 "Welcome to this Mumble server running on Guix!")
   (cert-required? #t) ;disallow text password logins
-  (ssl-cert "/etc/letsencrypt/live/mumble.example.com/fullchain.pem")
-  (ssl-key "/etc/letsencrypt/live/mumble.example.com/privkey.pem")))
+  (ssl-cert "/etc/certs/mumble.example.com/fullchain.pem")
+  (ssl-key "/etc/certs/mumble.example.com/privkey.pem")))
 @end lisp
 
 After reconfiguring your system, you can manually set the mumble-server
@@ -28965,12 +28965,12 @@ Telephony Services
 File name of the SSL/TLS certificate used for encrypted connections.
 
 @lisp
-(ssl-cert "/etc/letsencrypt/live/example.com/fullchain.pem")
+(ssl-cert "/etc/certs/example.com/fullchain.pem")
 @end lisp
 @item @code{ssl-key} (default: @code{#f})
 Filepath to the ssl private key used for encrypted connections.
 @lisp
-(ssl-key "/etc/letsencrypt/live/example.com/privkey.pem")
+(ssl-key "/etc/certs/example.com/privkey.pem")
 @end lisp
 
 @item @code{ssl-dh-params} (default: @code{#f})
@@ -32685,7 +32685,7 @@ Certificate Services
 Command to be run in a shell once for each successfully issued
 certificate.  For this command, the shell variable
 @code{$RENEWED_LINEAGE} will point to the config live subdirectory (for
-example, @samp{"/etc/letsencrypt/live/example.com"}) containing the new
+example, @samp{"/etc/certs/example.com"}) containing the new
 certificates and keys; the shell variable @code{$RENEWED_DOMAINS} will
 contain a space-delimited list of renewed certificate domains (for
 example, @samp{"example.com www.example.com"}.
@@ -32694,8 +32694,8 @@ Certificate Services
 @end deftp
 
 For each @code{certificate-configuration}, the certificate is saved to
-@code{/etc/letsencrypt/live/@var{name}/fullchain.pem} and the key is
-saved to @code{/etc/letsencrypt/live/@var{name}/privkey.pem}.
+@code{/etc/certs/@var{name}/fullchain.pem} and the key is
+saved to @code{/etc/certs/@var{name}/privkey.pem}.
 @node DNS Services
 @subsection DNS Services
 @cindex DNS (domain name system)
@@ -37381,9 +37381,9 @@ Version Control Services
  (listen '("443 ssl"))
  (server-name "git.my-host.org")
  (ssl-certificate
-  "/etc/letsencrypt/live/git.my-host.org/fullchain.pem")
+  "/etc/certs/git.my-host.org/fullchain.pem")
  (ssl-certificate-key
-  "/etc/letsencrypt/live/git.my-host.org/privkey.pem")
+  "/etc/certs/git.my-host.org/privkey.pem")
  (locations
   (list
(git-http-nginx-location-configuration
@@ -38508,9 +38508,9 @@ Version Control Services
(nginx-server-block
  (nginx-server-configuration
(ssl-certificate
- "/etc/letsencrypt/live/myweb.site/fullchain.pem")
+ "/etc/certs/myweb.site/fullchain.pem")
(ssl-certificate-key
- "/etc/letsencrypt/live/myweb.site/privkey.pem")
+ "/etc/certs/myweb.site/privkey.pem")
(listen '("443 ssl http2" "[::]:443 ssl http2"))
(locations
  (list
diff --git a/gnu/services/certbot.scm b/gnu/services/certbot.scm
index 0c45471659..3926d0551a 100644
--- a/gnu/services/certbot.scm
+++ b/gnu/services/certbot.scm
@@ -6,6 +6,7 @@
 ;;; Copyright © 2020 Jack Hill 
 ;;; Copyright © 2020 Tobias Geerinckx-Rice 
 ;;; Copyright © 2021 Raghav Gururajan 
+;;; Copyright © 2024 Carlo Zancanaro 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -87,6 +88,35 @@ (define-record-type* 
   (body

bug#46961: [PATCH v2 0/4] Make certbot play more nicely with nginx

[Carlo Zancanaro]

Hi Guix,

This patch series is a few changes to make certbot default to doing
"the right thing" in the common case of wanting certificates for an
nginx web server.

The initial change (in v1 of these patches) was to solve the certbot
bootstrapping problem. Nginx won't start without valid certificates,
but certbot can't produce certificates without a functional
nginx. This is solved by generating self-signed certificates to start
with, and then replacing them once certbot has run. Doing this
requires storing certificates in a different location (because certbot
is very particular). I've chosen /etc/certs/.

The other two changes (new to v2 of this series) make things a bit
easier to use: a one-shot shepherd service to renew certificates when
the machine starts up, and a default deploy-hook to reload the nginx
configuration (which picks up the new certificates). I think these
changes make certbot "do the right thing", at the expense of being
slightly more magical.

On IRC podiki suggested I should copy guix-devel and Brice (the
original bug reporter), so I've done that, too.

Carlo Zancanaro (4):
  services: certbot: Symlink certificates to /etc/certs.
  services: certbot: Create self-signed certificates before certbot
runs.
  services: certbot: Add a default deploy hook to reload nginx.
  services: certbot: Add one-shot service to renew certificates.

 doc/guix.texi|  38 ++---
 gnu/services/certbot.scm | 178 ---
 2 files changed, 188 insertions(+), 28 deletions(-)


base-commit: 144c95032e517bb8ce466b930fe91506bcc92b2b
-- 
2.41.0

bug#46961: [PATCH v2 3/4] services: certbot: Add a default deploy hook to reload nginx.

[Carlo Zancanaro]

* gnu/services/certbot.scm (%default-deploy-hook): New variable.
()[deploy-hook]: Use it as default deploy hook.
* doc/guix.texi (Certificate services): Document new default deploy hook.

Change-Id: Ibb10481170a6fda7df72492072b939dd6a6ad176
---
 doc/guix.texi|  6 +-
 gnu/services/certbot.scm | 13 +++--
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 58a65fe0b7..0f372a460f 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -32681,7 +32681,7 @@ Certificate Services
 additionally @code{$CERTBOT_AUTH_OUTPUT} will contain the standard output
 of the @code{auth-hook} script.
 
-@item @code{deploy-hook} (default: @code{#f})
+@item @code{deploy-hook} (default: @code{%default-deploy-hook})
 Command to be run in a shell once for each successfully issued
 certificate.  For this command, the shell variable
 @code{$RENEWED_LINEAGE} will point to the config live subdirectory (for
@@ -32690,6 +32690,10 @@ Certificate Services
 contain a space-delimited list of renewed certificate domains (for
 example, @samp{"example.com www.example.com"}.
 
+The default deploy hook calls the @code{reload} action of the
+@code{nginx} Shepherd service, to reload the newly generated
+certificates.
+
 @item @code{start-self-signed?} (default: @code{#t})
 Whether to generate an initial self-signed certificate during system
 activation.  This option is particularly useful to allow @code{nginx} to
diff --git a/gnu/services/certbot.scm b/gnu/services/certbot.scm
index 10b99f5630..490b9e8d6d 100644
--- a/gnu/services/certbot.scm
+++ b/gnu/services/certbot.scm
@@ -37,7 +37,8 @@ (define-module (gnu services certbot)
   #:use-module (srfi srfi-1)
   #:use-module (ice-9 format)
   #:use-module (ice-9 match)
-  #:export (certbot-service-type
+  #:export (%default-deploy-hook
+certbot-service-type
 certbot-configuration
 certbot-configuration?
 certificate-configuration))
@@ -49,6 +50,14 @@ (define-module (gnu services certbot)
 ;;; Code:
 
 
+(define %default-deploy-hook
+  (program-file
+   "reload-nginx.scm"
+   (with-imported-modules '((gnu services herd))
+ #~(begin
+ (use-modules (gnu services herd))
+ (with-shepherd-action 'nginx ('reload) result result)
+
 (define-record-type* 
   certificate-configuration make-certificate-configuration
   certificate-configuration?
@@ -65,7 +74,7 @@ (define-record-type* 
   (cleanup-hookcertificate-cleanup-hook
(default #f))
   (deploy-hook certificate-configuration-deploy-hook
-   (default #f))
+   (default %default-deploy-hook))
   (start-self-signed?  certificate-configuration-start-self-signed?
(default #t)))
 
-- 
2.41.0