fixes#232505
Implements the new option `security.acme.maxConcurrentRenewals` to limit
the number of certificate generation (or renewal) jobs that can run in
parallel. This avoids overloading the system resources with many
certificates or running into acme registry rate limits and network
timeouts.
Architecture considerations:
- simplicity, lightweight: Concerns have been voiced about making this
already rather complex module even more convoluted. Additionally,
locking solutions shall not significantly increase performance and
footprint of individual job runs.
To accomodate these concerns, this solution is implemented purely in
Nix, bash, and using the light-weight `flock` util. To reduce
complexity, jobs are already assigned their lockfile slot at system
build time instead of dynamic locking and retrying. This comes at the
cost of not always maxing out the permitted concurrency at runtime.
- no stale locks: Limiting concurrency via locking mechanism is usually
approached with semaphores. Unfortunately, both SysV as well as
POSIX-Semaphores are *not* released when the process currently locking
them is SIGKILLed. This poses the danger of stale locks staying around
and certificate renewal being blocked from running altogether.
`flock` locks though are released when the process holding the file
descriptor of the lock file is KILLed or terminated.
- lockfile generation: Lock files could either be created at build time
in the Nix store or at script runtime in a idempotent manner.
While the latter would be simpler to achieve, we might exceed the number
of permitted concurrent runs during a system switch: Already running
jobs are still locked on the existing lock files, while jobs started
after the system switch will acquire locks on freshly created files,
not being blocked by the still running services.
For this reason, locks are generated and managed at runtime in the
shared state directory `/var/lib/locks/`.
nixos/security/acme: move locks to /run
also, move over permission and directory management to systemd-tmpfiles
nixos/security/acme: fix some linter remarks in my code
there are some remarks left for existing code, not touching that
nixos/security/acme: redesign script locking flow
- get rid of subshell
- provide function for wrapping scripts in a locked environment
nixos/acme: improve visibility of blocking on locks
nixos/acme: add smoke test for concurrency limitation
heavily inspired by m1cr0man
nixos/acme: release notes entry on new concurrency limits
nixos/acme: cleanup, clarifications
the schema files referenced in the current preStart are empty.
other ones exist, but don't apply cleanly either.
calling update.php with --update-schema works for initial setup and
updates. if the database schema is already up to date, it's idempotent.
- Avoid false-positives on package sets that contain a `terminfo` derivation,
like `haskellPackages` and `sbclPackages`.
- Directly provide a list of names that can be used to update the NixOS module,
rather than a list of derivations which is hard to read in the REPL.
When not setting `settings` and setting `openFirewall = true`
evaluation would fail because it tries to access `settings.bind_port`
while `settings == null`
it should be checking that it is not a broken symlink but bash
conditionals are difficult
-d was causing the directory to not be created if it does not exist
```
$ install -m 0755 -d $PWD/hello
$ ls
hello/
$ ln -s something notexist
'notexist' -> 'something'
$ ls -l
lrwxrwxrwx artturin artturin 9 B Sat Sep 9 06:59:44 2023 notexist@ ⇒ something
drwxr-xr-x artturin artturin 2 B Sat Sep 9 06:59:36 2023 hello/
$ install -m 0755 -d $PWD/notexist
install: cannot change permissions of ‘/home/artturin/nixgits/my-nixpkgs/test/notexist’: No such file or directory
```
This avoids the possible confusion with `passwordFile` being the file
version of `password`, while it should contain the password hash.
Fixes issue #165858.
Relying on the built-in UEFI console here was already necessary, so we
are losing nothing by removing the needless `serial` call, which hung
some systems.
This also makes the implementation much easier to understand.
Also, no ugly-font menu anymore!
This helps keep logic simpler, as what we do is forcing text mode, which
means the non-default case is `truthy`, making things easier to digest
in the config file.
Also renaming this option is considered "internal", since it lives only
within the `iso-image` namespace, and also not a breaking change since
it was not part of a stable release.
Which ***anyway*** was not disabled correctly. Following changes will
actually disable it.
What this did was disable the "themed" menu driver, but still continued
relying on the gfxterm infra, which in itself is why things were ugly
and weird.
The `serial` console hangs on some systems. Unknown why.
Anyway, the way this worked right now relied on it telling the user on
the UEFI console how to enable it. So if I understand it correctly, it
will not cause any regression there.
This patch packages mu4e as an Emacs lisp package based on the mu4e
output of the multiple-output package mu, which makes mu4e a good
citizen of Emacs lisp packages in two aspects.
First, mu4e now utilizes the Emacs lisp package infrastructure in
Nixpkgs. This allows users who want to do AOT native compilation for
non-default Emacs variants[0] to build only mu4e itself instead of the
whole mu package[1].
Second, mu4e now conforms to the Emacs builtin package manager[2].
Without this patch, mu4e autoloaded commands do not work
out-of-the-box[3] because its directory is added to load-path by
site-start.el after the initialization of package-directory-list,
which causes package-activate-all to not load mu4e-autoloads.el. This
patch fixes this issue when mu4e is installed to Emacs using the
withPackages wrapper[4].
[0]: such as emacs-pgtk
[1]: mu.override { emacs = emacs-pgtk; }
[2]: package.el
[3]: either (require 'mu4e) or (require 'mu4e-autoloads) is needed to
be called before an autoloaded command is called
[4]: emacs-pgtk.pkgs.withPackages (epkgs: [ epkgs.mu4e ])
With this commit, the validation of `sshd_config`
is performed with `sshd -G` instead of `sshd -t`.
The former does not require a valid host key.
Checking the host key was never useful for us:
We just generated a dummy host key to
make the validation mechanism happy.
With this change the dummy key is no longer needed.
This change not only saves some CPU cycles
(avoid the generation of an RSA key),
but it also permits to set `RequiredRSASize` to a value
larger than the current rsa key default size (3072).
This is not unlikely to happen, given the enthusiasm shown by some users,
but we are not there yet, and this will save them from breaking their system.
