this patch adds the `services.flatpak.package` option to
allow overriding the package added by this module to
`environment.systemPackages` and the likes.
This is useful in scenarios where applications call the
flatpak binary to query information like writable directories
and there is a custom package returning different results
from the vanilla binary.
See https://github.com/crabdancing/nixpak-flatpak-wrapper
(cherry picked from commit af69223f46)
This adds options to set the users and groups as which cgit instances
run, allowing the use of an unprivileged user instead of root.
"root" is kept as the default user to avoid breaking existing setups,
but a warning is shown in that case to alert the user.
Backport of:
commit 4f2da6c9c1
nixos/fcgiwrap: add option migration instruction errors
(partial: move to instances)
commit 3d10deb7a5
nixos/cgit: fix GIT_PROJECT_ROOT ownership
commit 2d8626bf0a
nixos/cgit: configurable user instead of root
commit c5dc3e2034
nixos/fcgiwrap: adapt consumer modules and tests
commit 8101ae41f8
nixos/fcgiwrap: adapt consumer modules and tests
commit bf2ad6f48c
nixos/fcgiwrap: adapt consumer modules and tests
This makes the CGI part of smokeping run as the unprivileged
"smokeping" user like the rest of the service (instead of root).
This also sets proper permissions for the fcgiwrap control socket.
Backport of:
commit 4f2da6c9c1
nixos/fcgiwrap: add option migration instruction errors
(partial: move to instances)
commit c5dc3e2034
nixos/fcgiwrap: adapt consumer modules and tests
commit 8101ae41f8
nixos/fcgiwrap: adapt consumer modules and tests
commit bf2ad6f48c
nixos/fcgiwrap: adapt consumer modules and tests
This deprecates the use of the global shared instance of fcgiwrap,
due to its security issues (running as root by default, actually
insecure control socket, allowing local remote escalation privileges,
with no fix due to the multiple consumers).
A warning is added to encourage users to migrate to properly isolated
instances (`services.fcgiwrap.instances.*`).
This backports the options `services.fcgiwrap.instances.*`,
allowing to configure isolated instances of fcgiwrap,
as an alternative to the global shared one.
This prepares the deprecation of the latter.
Backport of:
commit efc7aebda7
nixos/fcgiwrap: require explicit owner for UNIX sockets
commit 4f2da6c9c1
nixos/fcgiwrap: add option migration instruction errors
(partial: move to instances)
commit 51b246a1ac
nixos/fcgiwrap: do not run as root by default
commit 81f72015f0
nixos/fcgiwrap: add unix socket owner, private by default
commit 289c1585c2
nixos/fcgiwrap: limit prefork type to positives
commit 3955eaf450
nixos/fcgiwrap: improve readability of CLI args
commit 022289f2fa
nixos/fcgiwrap: group options logically, fix doc
commit 41419ca288
nixos/fcgiwrap: refactor for multiple instances
It has started to take 10 minutes to get a match, and we open the starter more than once.
Let's just drop this check, ydotool helps alot with getting it open more reliably.
(cherry picked from commit 6e42f74cf9)
24.x is no longer maintained as of February 1, 2024[1].
It did not (yet?) receive a fix for CVE-2024-41110.
According to [1] 25.x will be the next LTS version, use that version to
reduce risk of possible breakage.
[1] https://github.com/moby/moby/pull/46772#discussion_r1686464084
We may want to clear NIX_PATH when channels are disabled, or maybe
it has to be a separate option.
This is just very frustrating to me.
(cherry picked from commit 3f76dcea93)
Warnings and descriptions for `virtualisation.docker.enableNvidia` and
`virtualisation.podman.enableNvidia` point erroneously to set
`virtualisation.containers.cdi.dynamic.nvidia.enable`. This NixOS
option has been deprecated and the recommended NixOS option is
`hardware.nvidia-container-toolkit.enable`.
(cherry picked from commit 3d2a21eddf)
This commit switches gitaly's git package from `pkgs.git` to the bundled
`git` package in order to maintain compatibility with the supported git
release by gitaly.
(cherry picked from commit feeb53a430)
dictd doesn't handle SIGTERM and terminates with code 143 (128 + 15
(SIGTERM) instead of 0. This results in systemd marking the service as
failed when a user stops it (with `systemctl stop dictd`). Fix it by
treating code 143 as success.
(cherry picked from commit 7db3dc0fa4)
A configuration such as:
programs.tsmClient.servers.backup.domain = [ "/dir1" "dir2" ];
...would previously result in an error ("cannot coerce a list to a
string"), since `makeDsmSysLines` would return a nested list.
(cherry picked from commit f52ee2af39)
The unstable package no longer uses `linuxPackages` for nvidia/cuda,
so when `services.ollama.package = unstable.ollama;` is set,
the unstable package is overridden with `linuxPackages` causing a build failure.
deconz doesn't handle SIGTERM and terminates with code 143 (128 + 15
(SIGTERM) instead of 0. This results in systemd marking the service as
failed when a user stops it (with `systemctl stop deconz`). Fix it by
treating code 143 as success.
(cherry picked from commit 5aab6344c2)
* nixos/gitlab-runner: Remove global with lib;
(cherry picked from commit 92a26526b9)
* nixos/gitlab-runner: Add support runner authentication tokens
Support for *runner registration tokens* is deprecated since GitLab
16.0, has been disabled by default in GitLab 17.0 and will be removed in
GitLab 18.0, as outlined in the [GitLab documentation].
It is possible to [re-enable support for runner registration tokens]
until GitLab 18.0, to prevent the registration workflow from
breaking.
*Runner authentication tokens*, the replacement for registration tokens,
have been available since GitLab 16.0 and are expected to be defined in
the `CI_SERVER_TOKEN` environment variable, instead of the previous
`REGISTRATION_TOKEN` variable.
This commit adds a new option
`services.gitlab-runner.services.<name>.authenticationTokenConfigFile`.
Defining such option next to
`services.gitlab-runner.services.<name>.registrationConfigFile` brings
the following benefits:
- A warning message can be emitted to notify module users about the
upcoming breaking change with GitLab 17.0, where *runner registration
tokens* will be disabled by default, potentially disrupting
operations.
- Some configuration options are no longer supported with *runner
authentication tokens* since they will be defined when creating a new
token in the GitLab UI instead. New warning messages can be emitted to
notify users to remove the affected options from their configuration.
- Once support for *registration tokens* has been removed in GitLab 18,
we can remove
`services.gitlab-runner.services.<name>.registrationConfigFile` as
well and make module users configure an *authentication token*
instead.
This commit changes the option type of
`services.gitlab-runner.services.<name>.registrationConfigFile` to
`with lib.types; nullOr str` to allow configuring an authentication
token in
`services.gitlab-runner.services.<name>.authenticationTokenConfigFile`
instead.
A new assertion will make sure that
`services.gitlab-runner.services.<name>.registrationConfigFile` and
`services.gitlab-runner.services.<name>.authenticationTokenConfigFile`
are mutually exclusive. Setting both at the same time would not make
much sense in this case.
[GitLab documentation]: https://docs.gitlab.com/17.0/ee/ci/runners/new_creation_workflow.html#estimated-time-frame-for-planned-changes
[re-enable support for runner registration tokens]: https://docs.gitlab.com/17.0/ee/ci/runners/new_creation_workflow.html#prevent-your-runner-registration-workflow-from-breaking
(cherry picked from commit 6f211d899d)
config.boot.loader.grub.device is just an alias that gets assigned to config.boot.loader.grub.devices.
If config.boot.loader.grub.device is set to null, it will fail with the following error
as described in https://github.com/nix-community/nixos-generators/issues/339
(cherry picked from commit d0126c0508)
The warning for nextcloud 29 does not apply here: It warns against
having a nextcloud install older than nixos 24.11 on installations
which are older than 24.11, which is superfluous.
Propagate the configuration setting through an envvar, check the envvar in the compositor.
Needed because querying AccountsSettings for this information fails, due to Ubuntu-only
"InputSources" interface. So you're stuck on US layout without this hack.
(cherry picked from commit 2735184f6d)
The accounts directory is based on the hash of the settings.
https://github.com/NixOS/nixpkgs/pull/270221 changed the default of
security.acme.defaults.server from null to the default letsencrypt URL
however as an unwanted side effect this means the accounts directory
changes and the ACME module will create a new a new account.
This can cause issues with people using CAA records that pin the
account ID or people who have datacenter-scale NixOS deployments
We allow setting this option to null again for people who want
to keep the old account and migrate at their own leisure.
Fixes https://github.com/NixOS/nixpkgs/issues/316608
Co-authored-by: Arian van Putten <arian.vanputten@gmail.com>
(cherry picked from commit d1f07e6382)
The original code tests output of `ip addr add` command to detect if an
adress already exists. The error message was changed in the past and the
test no longer works.
The patch replaces `ip addr add` with `ip addr replace`. The new command
replaces an existing address or creates a new one if there isn't any.
fixes 306841
(cherry picked from commit 71ce6b582b)
Use the `cfg.package.version` (string) instead of the entire package so
users don't see `error: value is a set while a string was expected`
instead of the intended assertion message.
(cherry picked from commit f7393d13fe)
When services.gollum.{user,group} was specified a value other than its
default (i.e. "gollum"), the build failed due to referencing a
non-existing user.
(cherry picked from commit b5c7987b52)
This prevents the post start script from running
before necessary sockets have been created.
It also prevents an unused shell from being kept around
by using `exec` to make `notify_push` the main process.
