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.
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.
