My system does not use `bcache` and I sould prever my `systemPackages`
not to have bcache tools.
The change does not change the default but proviced usual `enable` knob.
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.
The module for Plasma 5 contained two pointless setuid wrappers:
* kscreenlocker_greet was introduced when the kscreenlocker package
dropped kcheckpass. However, this was actually replaced by making
proper use of PAM (which finally calls its unix_chkpwd setuid binary).
kscreenlocker_greet itself was never intended to be setuid.
Fortunately, this is not exploitable, because QCoreApplication
immediately aborts if it detects setuid. The wrapper is still
incorrect and pointless, so remove it.
* start_kdeinit can optionally use setuid root or setcap
CAP_SYS_RESOURCE to reduce its OOM killer score. However, with systemd
startup, start_kdeinit does not get used at all. So in this case, the
setuid wrapper is pointless, and so is removed as well. Ideally, the
case where systemd startup is not enabled would use a capability
wrapper instead, but since systemd startup is the default in NixOS and
kinit is deprecated upstream for KF6, I don't bother any more.
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.
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.
This implements proper merging of user-provided values and default
values for the settings option.
Without this, the user must provide a complete configuration file, as
changing a single setting replaces the entire JSON value, rendering the
default values completely useless. In fact, the bridge won't even start
using the default settings.
The DynamicUser mechanism does not allow share the bridge
registration.yaml file with matrix-synapse in any easy way:
1. the mautrix-whatsapp group under which the service runs is not in
/etc/group, so you can't add matrix-synapse to this.
This makes the group read bit on the file useless as the group is
effectively always empty.
2. It's not possible to use ACLs or copy the file during preStart or
postStart because the commands are executed with low priviledges.
By using a normal (static) user/group the secret can be shared with
synapse as follows:
services.matrix_synapse.settings.app_service_config_files =
[ "/var/lib/mautrix-whatsapp/whatsapp-registration.yaml" ];
users.users.matrix-synapse.extraGroups = [ "mautrix-whatsapp" ];
Since #246772, cross compiled NixOS is broken because the DateTime perl
package that was used in the update-users-groups.pl script depends on
Testutf8 which does not cross compile (see #198548).
This PR drops the DateTime dependency in favour of TimePiece, which has
less dependencies and whose closure does cross compile.
This change enables _FILE variants for all secrets in Healthchecks
configuration so they can be read from a file and not stored in
/nix/store.
In particular, it adds support for these secrets:
DB_PASSWORD, DISCORD_CLIENT_SECRET, EMAIL_HOST_PASSWORD,
LINENOTIFY_CLIENT_SECRET, MATRIX_ACCESS_TOKEN, PD_APP_ID,
PUSHBULLET_CLIENT_SECRET, PUSHOVER_API_TOKEN, S3_SECRET_KEY, SECRET_KEY,
SLACK_CLIENT_SECRET, TELEGRAM_TOKEN, TRELLO_APP_KEY, and TWILIO_AUTH.
Previously, if someone changed DB to postgres or mysql and forgot to
change DB_NAME, services.healthchecks would have used the hardcoded path
that was meant for the sqlite as DB_NAME.
This change introduces DB and DB_NAME options in
services.healthchecks.settings.
Underneath, systemd-networkd’s reload is just `networkctl reload`. Per
`man networkctl`, calling `reload` is expected to fully handle new,
modified, and removed .network files, but it only handles *new* .netdev
files. For simplicity, assume .network -> reload and .netdev -> restart.
It’s desirable to perform reload instead of restart, as restart has the
potential to bring down interfaces, resulting in a loss of network
connectivity.
Just like with system-wide tmpfiles, call `systemd-tmpfiles --create
--remove` for users during activation. This fixes an issue where new
entries in a user's tmpfiles are not reflected after activation, only at
boot when the user service systemd-tmpfiles-setup.service runs or only
after running systemd-tmpfiles manually.
This allows for other unmanaged tables to co-exist peacefully on the os,
by having the nixos-managed tables be re-created atomically and the other
tables will simply be left untouched.
Given that we are no longer inspecting the target of the /proc/self/exe
symlink, stop asserting that it has any properties. Remove the plumbing
for wrappersDir, which is no longer used.
Asserting that the binary is located in the specific place is no longer
necessary, because we don't rely on that location being writable only by
privileged entities (we used to rely on that when assuming that
readlink(/proc/self/exe) will continue to point at us and when assuming
that the `.real` file can be trusted).
Assertions about lack of write bits on the file were
IMO meaningless since inception: ignoring the Linux's refusal to honor
S[UG]ID bits on files-writeable-by-others, if someone could have
modified the wrapper in a way that preserved the capability or S?ID
bits, they could just remove this check.
Assertions about effective UID were IMO just harmful: if we were
executed without elevation, the caller would expect the result that
would cause in a wrapperless distro: the targets gets executed without
elevation. Due to lack of elevation, that cannot be used to abuse
privileges that the elevation would give.
This change partially fixes#98863 for S[UG]ID wrappers. The issue for
capability wrappers remains.
/proc/self/exe is a "fake" symlink. When it's opened, it always opens
the actual file that was execve()d in this process, even if the file was
deleted or renamed; if the file is no longer accessible from the current
chroot/mount namespace it will at the very worst fail and never open the
wrong file. Thus, we can make a much simpler argument that we're reading
capabilities off the correct file after this change (and that argument
doesn't rely on things such as protected_hardlinks being enabled, or no
users being able to write to /run/wrappers, or the verification that the
path readlink returns starts with /run/wrappers/).
Before this change it was crucial that nonprivileged users are unable to
create hardlinks to SUID wrappers, lest they be able to provide a
different `.real` file alongside. That was ensured by not providing a
location writable to them in the /run/wrappers tmpfs, (unless
disabled) by the fs.protected_hardlinks=1 sysctl, and by the explicit
own-path check in the wrapper. After this change, ensuring
that property is no longer important, and the check is most likely
redundant.
The simplification of expectations of the wrapper will make it
easier to remove some of the assertions in the wrapper (which currently
cause the wrapper to fail in no_new_privs environments, instead of
executing the target with non-elevated privileges).
Note that wrappers had to be copied (not symlinked) into /run/wrappers
due to the SUID/capability bits, and they couldn't be hard/softlinks of
each other due to those bits potentially differing. Thus, this change
doesn't increase the amount of memory used by /run/wrappers.
This change removes part of the test that is obsoleted by the removal of
`.real` files.
This change includes some stuff (e.g. reading of the `.real` file,
execution of the wrapper's target) that belongs to the apparmor policy
of the wrapper. This necessitates making them distinct for each wrapper.
The main reason for this change is as a preparation for making each
wrapper be a distinct binary.
with a config like this :
```
services.tts = {
servers = {
english = {
enable = true;
port = 5300;
model = "tts_models/en/ljspeech/vits"
};
};
};
```
You the WAVs tts creates contain an error message which will be read to
you before the text you typed in will be read to you.
This patch fixes that.
dwm is not in Java's internal list of non-reparrenting
window managers. Running Java GUI programs without this
variable on window managers (eg. jd-gui) causes the window
to be blank.
Before this commit there was no way to access (boot into) specialisation of previous generations from grub,even tho they are there.
This commit will add grub submenu for each generation if the generation has any specialisation.
Which will allow you to boot into them.
Co-authored-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
We should sometimes restart the units rather than reloading them so the
changes are actually applied. / and /nix are explicitly excluded because
there was some very old issue where these were unmounted. I don't think
this will affect many people since most people use fstab mounts instead
but I plan to adapt this behavior for fstab mounts as well in the future
(once I wrote a test for the fstab thingies).