These should be defaults as they're pretty reasonable to want to
override as a user. Unsure how to change the slice defaults to be
overridable, that should probably be a later conversation.
Follow-up to #269551
Avoid creating a new instance of nixpkgs to access two variables.
`pkgs.pkgsi686Linux` was being accessed whenever the feature is being
used or not.
A second instance of nixpkgs is being created in
`nixos/modules/config/stub-ld.nix` and can be disabled by setting
`environment.ldso32 = null` or `environment.stub-ld.enable = false`.
Both combined fixes this error:
error: attribute 'i686-linux' missing
- add 'package' option
- add 'game' and 'server' attrset
- reduce repetition by using functions bool and optionalSetting
- add default value for cfg.name
- revise some option descriptions
`error` and `warn` have always been valid log levels.
But because the upstream docs never mentioned those, we simply didn't
add them to the enum of our module option.
The upstream docs have been updated and now mention `error` and `warn`
as well.
Upstream PR: https://git.deuxfleurs.fr/Deuxfleurs/garage/pulls/716
The Express Data Path (XDP) is a way to circumvent the traditional Linux
networking stack and instead run an eBPF program on your NIC, that makes
the decision to provide Knot with certain packets. This is way faster
and more scalable but comes at the cost of reduced introspection.
Unfortunately the `knotc conf-check` command fails hard with missing
interfaces or IP addresses configured in `xdp.listen`, so we disable it
for now, once the `xdp` config section is set. We also promote the config
check condition to a proper option, so our conditions become public
documentation, and we allow users to deal with corner cases, that we have
not thought of yet.
We follow the pre-requisites documented in the Knot 3.3 manual, and set
up the required capabilities and allow the AF_XDP address family.
But on top of that, due to our strict hardening, we found two more
requirements, that were communicated upstream while debugging this.
- There is a requirement on AF_NETLINK, likely to query for and configure
the relevant network interface
- Running eBPF programs requires access to the `bpf` syscall, which we
deny through the `~@privileged` configuration.
In summary We now conditionally loosen the hardening of the unit once we
detect that an XDP configuration is wanted. And since we cannot
introspect arbitrary files from the `settingsFiles` option, we expose XDP
support through the `enableXDP` toggle option on the module.
Certain software stacks have no support for OpenSSL non-standard PEM format and will fail to use
our NixOS CA bundle.
For this, it is necessary to fallback on a 'compatibility' bundle which will contain no additional
trust rules.
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
Portals are global so we can just link them globally.
There might, in theory, be some unexpected system-path contamination
(e.g. when a portal package installs its executables to `/bin`)
but I think the risk is relatively minor compared to the added complexity.
While at it, let’s point the environment variable to system-path.
That will allow changes to installed portals to apply without having to re-log in.
x-d-p only looks for portal definitions in one of two places:
- datadir (which we cannot install anything to, since Nix packages are immutable)
- when `XDG_DESKTOP_PORTAL_DIR` environment variable is set, the path specified therein
(meant for tests, disables looking for portal configuration anywhere else)
Let’s introduce our own `NIX_XDG_DESKTOP_PORTAL_DIR` environment variable
that will only control the portal definitions lookup.
We will not use it for searching for configuration
because it would require looking in the parent directory
and `XDG_CONFIG_DIRS` variable is sufficient for us.
since this is no longer supported and we have a dedicated module for
forgejo for quite some time now.
Such warning is, however, becoming more and more important, since
forgejo is no longer a soft-fork of gitea, but rather a hard-fork.
And as such, it will slowly but surely no longer be a drop-in
replacement.
Additionally, I hope that this warning will prevent users from
reporting issues with forgejo to nixos/gitea maintainers.
The accompanying forgejo.md, from which the manual section is created,
will be updated over the next few weeks when forgejo officially
publishes their blog post about all this and the way forward, so we can
link to it.
PR #277382 didn't fix just an issue with .mjs files for the `forms` app,
but an underlying, more problematic issue: for `/nix-apps` &
`/store-apps`, the fcgi config for PHP and the block for assets were
never reached.
That meant that e.g. `/nix-apps/notes/lib/AppInfo/Application.php`
returned the PHP source code as text/plain. Considering that there was
never a fundamental change to how this config's structure, I'm pretty
sure that the issue was pretty much there since the module exists.
After consulting the NixOS security team we agreed that this is most
likely harmless because you'd have to use private apps with secrets in
the raw PHP code of said app. However, this is still problematic because
one important assumption - that PHP code is never sent to the browser -
is broken which is why we decided on not mentioning this impact in the
previous PR from December 2023.
To make sure that we don't regress our nginx config, I decided to add
the reproducer which fails on 8bbbb228b4
as testcase to our integration tests.
Similar to the `user` option, the added `group` option sets the group of
the executing process. If not `null`, it also sets `DynamicUser=false`.
In case `user` is set to `null` (the default), systemd would run the
service as root implicitly. As this is dangerous and most certainly not
what users want, we force them to set `user = "root"` explicitly if
that's really their intention. That's achieved through an assertion.
After 4b128008c5 it took me a while in a
test setup to find out why `root` didn't have the password anymore I
declared in my config.
Because of that I got reminded how the order of preference works for the
password options:
hashedPassword > password > hashedPasswordFile
If the user is new, initialPassword & initialHashedPassword are also
relevant. Also, the override is silent in contrast to any other
conflicting definition in NixOS.
To make this less surprising I decided to warn in such a case -
assertions would probably break too much that technically works as
intended.
Also removed the `initialHashedPassword` for `root`. This would cause a
warning whenever you set something in your own config and a `!` is added
automatically by `users-groups.pl`.
`systemd-sysusers` also seems to implement these precedence rules, so
having the warning for that case also seems useful.
The `github-runner` package only supports `nodejs_20` since `nodejs_16`
was removed in a2976db919.
It still makes sense to keep the `nodeRuntimes` option as this is
probably not the last Node.js we'll deprecate with at least some grace
period.
Exposes two options, `path` and `mode`, to configure the location and
permissions on the socket file.
The `mode` needs to be specified as string in octal and will be converted
into a decimal integer, so it correctly passes through the YAML parser
and arrives at the `os.chmod` call in the Twisted codebase. What a fun
detour.
Adds an assertion, that either `path` or `bind_addresses` and `port` are
configured on every listener.
Migrates the default replication listener of the main instance to a UNIX
domain socket, because it is more efficient.
Introduces the `enableRegistrationScript` option, to gracefully disable
the user registration script, when the client listener listens on a UNIX
domain socket, which is something the script does not support.
- Make the token a required option
- Drop the proto from the listen parameter
- Use systemd credentials to pass the token file
- Drop debug flag, use extraArgs instead
- Actually hook up extraArgs
- Escape shell arguments
- Drop overly broad `with lib` statement
Enables networkd instead of dhcpcd for DHCP/RA. It offers a solid base
for network configuration, that is much more extensible than dhcpcd and
also better maintained than our bespoke `networking.interfaces` modules.
Closes: #287269
Gitlab stays running at redis and postgresql restarts as if these
components were on a different host anyways. Handling reconnetctions is
part of the application logic.
Co-authored-by: Kim Lindberger <kim.lindberger@gmail.com>
for formatting fixes and test failure debugging.
right now, we have php81 and php (which points to php82), which means that:
- php-fpm uses php81
- the update preStart uses php81
- the actual updater uses php82
This change replaces the previously hard-coded `/boot` path with a
reference to `efiSysMountPoint` and more importantly this change makes
it possible to override these rules in scenarios in which they are not
desired.
One such scenario would be when `systemd-gpt-auto-generator(8)` is used
to automount the ESP. Consider this section from the mentioned manpage:
> The ESP is mounted to /boot/ if that directory exists and is not used
> for XBOOTLDR, and otherwise to /efi/. Same as for /boot/, an automount
> unit is used. The mount point will be created if necessary.
Prior to this change, the ESP would be automounted under `/efi` on first
boot, then the previous tmpfiles rules caused `/boot` to be created.
Following the quote above, this meant that the ESP is mounted under
`/boot` for each subsequent boot.
A recent release added systemd notify support, so I migrated our unit
towards that. The NixOS test did not reveal that the unit would not fully
activate.
Reverts: 165326d2c (partially)
Closes: #286977
