This reverts commit 80665d606a.
Parsing the package version broke our systemd-boot builder test.
i.e. it won't be able to parse systemd-boot efi binaries coming from
ubuntu
We no longer use the faulty systemd-boot version so this code should no
longer be needed.
For some time now the attrset returned by `evalModules` has
`type = "configuration"`.
This is a clean refactor because the name is not exposed.
(never is for simple lambda)
Add new test to check if kubo.passthru.repoVersion is set correctly.
Also split the existing NixOS VM test into two independent parts. The test already used two independent VMs but just one testScript. This made experimenting with just one of the two VMs slower than it needed to be. It should also increase parallelism slightly since both test scripts can now run at the same time.
PIE causes problems with static binaries on ARM (see 76552e9). It is
enabled by default on other platforms anyway when musl is used, so we
don't need to specify it manually.
These names are internal identifiers. They will be used as keys so that
users can reconfigure rules by merging a rule config with the same name.
The name is arbitrary. The built-in rules are named after the PAM where
practical.
Eliminates a redundancy between the 'rules' suboptions and the type
specified in each rule.
We eventually want to give each rule a name so that we can merge config
overrides. The PAM name is a natural choice for rule name, but a PAM is
often used in multiple rule types. Organizing rules by type and rule
name avoids name collisions.
This was causing the following warning before when building the manual:
warning: literalExample is deprecated, use literalExpression instead, or use literalMD for a non-Nix description.
Rather than using `literalExpression`, nothing is used. This option
expects a string and the example is a string, no special handling
required. Both `literalExample` from the docbook ages and
`literalExpression` now are only required if the example is
a Nix expression rather than a value of the option's type.
Right now there's no trivial way to override parts of synapse's log
config such as the log-level because the only thing that's changeable is
the path to the log-file used by synapse and its workers.
Now, there's a new option called `services.matrix-synapse.log`
which contains the default log config as Nix attribute-set (except
`handlers.journal.SYSLOG_IDENTIFIER`). It has default priority, so new
things can be added like
services.matrix-synapse.log = {
my.extra.field = 23;
}
without discarding the rest. If desired, this can still be done via
`lib.mkForce`.
If the log configuration for a single worker or synapse, but not all
workers should be changed, `services.matrix-synapse.settings.log_config`
or `services.matrix-synapse.workers._name_.worker_log_config`
can be used.
Closes#236062
The PR #236062 was submitted because of the following problem: a synapse
instance was running in a NixOS container attached to the host network
and a postgresql instance on the host as database. In this setup,
synapse connected to its DB via 127.0.0.1, but the DB wasn't locally set
up and thus not configured in NixOS (i.e.
`config.services.postgresql.enable` was `false`). This caused the
assertion removed in this patch to fail.
Over three years ago this assertion was introduced when this module
stopped doing autoconfiguration of postgresql entirely[1] because a
breaking change in synapse couldn't be managed via an auto-upgrade on
our side. To make sure people don't deploy their DB away by accident,
this assertion was introduced.
Nowadays this doesn't serve any value anymore because people with
existing instances should've upgraded by now (otherwise it's their job
to carefully read the release notes when missing upgrades for
several years) and people deploying fresh instances are instructed by
the docs to also configure postgresql[2].
Instead, it only causes issues in corner cases like #236062, so after
some discussion in that PR I think it's time to remove the assertion
altogether.
Also, there's no `Requires=` for `postgresql.service` in the systemd
units which means that it's not strictly guaranteed that the DB is up
when synapse starts up. This is fixed now by adding `requires`. To avoid
being bitten by above mentioned cases again, this only happens if
`config.services.postgresql.enable` is `true`.
If somebody uses a non-local postgresql, but has also deployed a local
postgresql instance on the synapse server (rather unlikely IMHO), it's
their job to opt out of this behavior with `mkForce` (this is precisely one
of the use-cases `mkForce` and friends were built for IMHO).
[1] https://github.com/NixOS/nixpkgs/pull/80447
[2] https://nixos.org/manual/nixos/stable/#module-services-matrix-synapse
First of all, a few cleanups were made to make it more readable:
* Reordered the sections by their priority so what you're reading in Nix
is also what you get in the final nginx.conf.
* Unified media/asset locations
Most notably, this fixes the
Your web server is not properly set up to resolve "/ocm-provider/".
warning since 27.1.2 where `ocm-provider` was moved from a static
directory in the source tarball to a dynamic HTTP route[1].
Additionally, the following things were fixed:
* The 404 checks for build/tests/etc. are now guaranteed to be before
the `.php` location match and it's not implicitly relied upon Nix's
internal attribute sorting anymore.
* `.wasm` files are supported properly and a correct `Content-Type` is
set.
* For "legacy" routes (e.g. `ocs-provider`/`cron`/etc) a `rewrite` rule
inside the location for fastcgi is used as recommended by upstream[2].
This also makes it easier to understand the purpose of the location
itself (i.e. use fastcgi for PHP code).
[1] https://github.com/nextcloud/documentation/pull/11179
[2] https://docs.nextcloud.com/server/27/admin_manual/installation/nginx.html
Currently, when setting a custom media_store_path, which lies outside of
cfg.dataDir, the current ReadWritePaths make it so that Synapse can't
access the media_store_path. So add the media_store_path to
ReadWritePaths to fix that.
- run conf-check iff keyFiles == [] (like in 23.05; this was my bug)
- support extraConfig + keyFiles
- but warning will still be shown if extraConfig is used,
and it might be slightly confusing
WakeOnLan= was configured when using the scripted backend but not the
networkd backend. The other link options are set in the .network file
when using networkd, but WakeOnLan= is only available in a .link file.
https://github.com/ipfs/kubo/releases/tag/v0.23.0
Support for /quic (Draft 29) was removed, so remove it from `services.kubo.settings.Addresses.Swarm`.
The changelog says that there have been some fixes to the FUSE mountpoint functionality but the test still requires the workaround, so leave that unchanged.
The logic for configuring a gateway without an interface specified adds
a route with Gateway= to *every interface* configured by NixOS for
networkd. This leads to nonsensical configurations like the following:
[Network]
DHCP=no
Address=192.168.0.1/24
[Route]
Gateway=10.0.0.1
GatewayOnLink=false
We remove this logic and make defaultGateway.interface required to
configure a default gateway when using networkd.
We can ignore the removal of GatewayOnLink because systemd defaults it
to "no" anyway.
When interface and address are both specified, we can set Gateway= on
the named interface. The existing logic assumes interface is not set
(since it's guarded by assertion) so we now disable it when interface
has a value.
As a bonus, we now support the defaultGateway.metric option when
interface is set.
The empty string is coerced to an attrset:
{ address = ""; interface = null; metric = null; }
The new defaultGateway logic (correctly) complains that interface must
be defined when using networkd. We instead clear defaultGateway by
setting it to its actual default value, which is null.
Before: `users.users.user1.group = "group-not-defined-anywhere-else"`
would result in user1 having the primary group `nogroup`, assigned at
activation time and only with a (easy to miss) warning from the
activation script. This behaviour is a security issue becase no files
should be owned by `nogroup` and it allows for unrelated users (and
services) to accidentally have access to files they shouldn't have.
After: The configuration above results in this eval error:
- The following users have a primary group that is undefined: user1
Hint: Add this to your NixOS config:
users.groups.group-not-defined-anywhere-else = {};
The default temp directories for nginx must not be removed by
systemd-tmpfiles-clean.service. This test lowers the age parameter for /tmp and
triggers a cleanup that would normally only occur after 10 days of nginx
inactivity. After that, the functionality of nginx that requires a temporary
directory is tested again.
nixpkgs currently mixes sgtpuzzles/sgt-puzzles across filenames,
packages, tests.
This inconsistency is frequently annoying.
Let's unify on "sgt-puzzles", on the basis that:
* "sgt-puzzles" is the package filename.
* Alpine/FreeBSD/Debian use "sgt-puzzles". No other distro uses
"sgtpuzzles". https://repology.org/project/sgt-puzzles/versions
This mitigates CVE-2023-4911, crucially without a mass-rebuild.
We drop insecure environment variables explicitly, including
glibc-specific ones, since musl doesn't do this by default.
Change-Id: I591a817e6d4575243937d9ccab51c23a96bed6f9
Specifically the following plugins:
fusuma-plugin-appmatcher
fusuma-plugin-keypress
fusuma-plugin-sendkey
fusuma-plugin-tap
fusuma-plugin-wmctrl
I've not enabled the other plugins available on rubygems for the
following reasons:
* remap : seems niche functionality and requires further configuration
to grant the user access permissions to event devices
* thumbsense : pulls in remap (see above)
* touchscreen : I've no way of testing. Note: enabling didn't appear
to cause any problems.
Ideally the plugin functionality would be made available as separate
pkgs, but that would require patching Fusuma to search outside of the
Gem directory. Enabling this subset of packages for what appears to be
widely useful functionality seems a good option.
A further bug to our strange multi-user.target depending on
network-online.target issue is that systemd recently changed the
behaviour of systemd-networkd-wait-online to no longer consider the
absence of interfaces with RequiredForOnline to be sufficient to be
online: https://github.com/systemd/systemd/pull/27825
On the advice of the systemd developers
(https://github.com/systemd/systemd/issues/29388), this commit changes
the configuration of systemd-networkd-wait-online to pass --any by
default, and lets the default DHCP interfaces be RequiredForOnline
as they would be by default if the option is omitted.
It is plausible that systemd-networkd-wait-online may still fail if
there are no interfaces at all. However, that probably cannot be
avoided.
systemd.network(5) describes Domains= as a "list of domains which should
be resolved using the DNS servers on this link." This setting is read by
systemd-resolved.service, and it's used to configure both search domains
and DNS query routing.
Adding the search domains from `networking.search` is unnecessary
because these are already configured globally in `resolved.conf` through
the default value of `services.resolved.domains`.
Adding the system's `networking.domain` to each network is unexpected
and probably incorrect. A user may not expect that the domain is in
effect automatically added to the search domains even if not specified
in `networking.search`.
Both of these network-level assignments are problematic in cases where
the NixOS networkd module is not managing every interface on the system.
In that scenario, the managed interfaces will have Domains= set while
the others do not. That will cause systemd-resolved to route DNS queries
for the search domains and the system domain to only those managed
interfaces.
Otherwise, in non-interactive contexts (e.g. systemd units), this
entry (the default) won't be in the list. Only the profile relative
ones would be, since they were already using session variables. This
is clearly not the correct behavior.
It's still in kernels-org.json, because even if I remove it the update
script will keep putting it back, but nothing references it, and it'll
be removed from that file when kernels are next updated after it's
been delisted from kernel.org.
linux_testing_bcachefs still needs to be updated for >6.4, so for now
I've just inlined the Linux 6.4 definition in linux_testing_bcachefs's
definition.
All the locate versions we have support LOCATE_PATH, so just use that
instead of adding indirections all over the place AND forcing people
to rebuild their locate implementation if they want the path changed.
Allow the user to disable overriding the fileSystems option with
virtualisation.fileSystems by setting
`virtualisation.fileSystems = lib.mkForce { };`.
With this change you can use the qemu-vm module to boot from an external
image that was not produced by the qemu-vm module itself. The user can
now re-use the modularly set fileSystems option instead of having to
reproduce it in virtualisation.fileSystems.
Gonic accesses external services (e.g. Listenbrainz or last.FM) for
scrobbling, but it was previously not allowed to read
`/etc/resolv.conf`.
This had the effect that, unless a local resolver was configured on
the system, any connection attempt would fail due to DNS resolution
being unavailable.
This also makes configuration available if you just run those tools locally.
Also use ruff instead of pylint because it's faster and more
comprehensive.
* `sort (<)` also works for strings (TIL!), so no need for comparing
length and whether all keys from `cfg.settings` exist in `cfg.order`
(slightly less overhead).
* Don't build another piece of JSON (`orderedSections`), simply use
`cfg.settings`/`cfg.order` with `__structuredAttrs` to ensure a
properly ordered TOML.
This also has the upside of not having to do quote hackery.
* Also, a freeform submodule isn't strictly needed because we don't have
any special options defined, so replacing that with
`attrsOf format.type`.
Co-authored-by: Silvan Mosberger <github@infinisil.com>
Since 008f9f0cd4
("nixos/test-driver: actually use the backdoor message to wait for backdoor"),
when boot is still computering, we can get a tons of empty strings in response to the shell.
This is not really useful to print and waste the disk space for any CI system that logs them.
We stop logging chunks whenever they are empty.
and remove nano from environment.defaultPackages. In addition also cleanup the file in general.
This is a follow up to #220481
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
Adds an option to configure a custom WakeOnLan policy instead of the
hard-coded "magic" policy. To ensure compatibility with current
behavior, "magic" is kept as default.
