nixos/acme: Disable bash tracing

[dasJ]

Motivation for this change

This is horrible if you want to debug failures that happened during
system switches but your 30-ish acme clients spam the log with the same
messages over and over again.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[m1cr0man]

Honestly I'm not too keen on disabling this. When it was introduced there was quite some discussion about it (see here for some of that). The main reason it is there is that ACME failures tend to be really hard to reproduce, and having the script's logs has always been really helpful in debugging.

With the module working reliably for quite some time now, I can understand that the value of having it enabled is probably being outweighed by the log spam. I'm still undecided though, I'd be keen to hear what other people think (@NixOS/acme & co).

[dasJ]

It's probably easier to opt in than to opt out because one can just do:

script = lib.mkBefore ''
  set -x
'';

This is not possible the other way around

[m1cr0man]

Ok well for a middle ground, how do you feel about adding security.acme.enableDebugLogs (or similar), and defaulting it to true? That way users who run into issues on their first few runs will have clear logs of what went wrong, and those with working systems with lots of logs can disable it.

[dasJ]

I hope this is close to what you had in mind

[m1cr0man]

Yeah this looks good! Lets see if someone can merge it so I can rebase my PR for acme

[m1cr0man]

This works yeah? I'm always adding brackets in an abundance of caution

[dasJ]

Yeah I've been doing this for years now ;)

[dasJ]

@m1cr0man Do you want me to remove the backport label or are you fine with backporting this change?

[m1cr0man]

Actually.. I hate to be indecisive like this but maybe this is better as an option under security.acme.certs? In your PR description you point out the difficulty debugging if theres many acme clients. If its under the submodule options, that can be solved here too :)

[m1cr0man]

@m1cr0man Do you want me to remove the backport label or are you fine with backporting this change?

Keep it for now. I'm not entirely sure if #147784 will be backportable yet.

[m1cr0man]

Looks good now!

[dasJ]

@GrahamcOfBorg test acme

[github-actions]

Successfully created backport PR #149371 for release-21.11.