The manpage of dhcpcd says:
>If any interface reports a working carrier then dhcpcd will try to
>obtain a lease before forking to the background, otherwise it will fork
>right away.
Instead of duplicating the options from the upstream service file and letting
them get out of sync, use the file directly and only configure the needed
overrides. In particular, the upstream improvements include the mounts not
being globally visible any more, so they can't be used for bypassing nosuid and
the like, and the custom cleanup script that performed the unmount becomes
unnecessary.
As described in https://github.com/NixOS/nixpkgs/pull/394017,
grafana-agent does not build with Go 1.23 anymore, and Go 1.22 has been
removed.
grafana-agent has been deprecated by Grafana (in favour of Grafana
Alloy), and will be EOL on 2025-11-01, which would be part of the
upcoming 25.05 release.
Instead of leaving us with a broken package, drop it alltogether, and
add release notes.
The systemd.tmpfiles.settings.<name>.<path>.<type>.argument option may
contain arbitrary strings. This could allow intentional or unintentional
introduction of new configuration lines.
The argument field cannot be quoted, C‐style \xNN escape sequences are
however permitted. By escaping whitespace and newline characters, the
issue can be mitigated.
Follow-up on #169733
For `data`, Nextcloud checks on its own if everything is readable.
However, for `config` it's crucial that the ownership is actually
correct: otherwise, systemd-tmpfiles will refuse any operations inside
because of unsafe path transitions.
This can result in a subtly broken setup by the `override.config.php`
not being updated, but also not part of the system closure anymore
(another override.config.php is referenced now) which means it'll be
GCed eventually even though Nextcloud relies on it.
If this precondition is not met, the following error will be printed:
nextcloud-setup-start[972]: /var/lib/nextcloud/config is not owned by user 'nextcloud'!
nextcloud-setup-start[972]: Please check the logs via 'journalctl -u systemd-tmpfiles-setup'
nextcloud-setup-start[972]: and make sure there are no unsafe path transitions.
nextcloud-setup-start[972]: (https://nixos.org/manual/nixos/stable/#module-services-nextcloud-pitfalls-during-upgrade)
There was a systemd-tmpfiles warning about not being able to remove the
'plugins' directory. Squash this warning through removal of unnecessary
systemd-tmpfiles options, and write a test for it.
Add the {option}`services.mattermost.pluginsBundle` option to allow
overriding the plugin directory and also using it for tests. Update
wording in option documentation so it is more clear.
Use formats.json instead of builtins.toJSON so module merging works.
Make the tests go faster by pipelining shutdowns of nodes.
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
This was a workaround to begin with, as hardened kernel didn't support tracing.
Back then kernel level tracing was only available through debugfs, and now that
tracefs has been available on NixOS for a while now, enabled in
Link: https://github.com/NixOS/nixpkgs/pull/388751
This workaround can be removed and bpf can be used with tracefs.
Link: https://github.com/NixOS/nixpkgs/issues/360957
Signed-off-by: John Titor <50095635+JohnRTitor@users.noreply.github.com>
this assertion broke gnome sessions in very hard to debug way:
- gdm starts, but on successful login just returns to login screen
- journalctl isn't exactly helpful in this condition:
- a typical gnome login will involve many warnings and errors, that
aren't actually preventing login, but will lead affected users
on a merry chase for many hours
- the actual indicators in the log arent't even an errors, only info and warning
- graphical-session.target: Starting requested but asserts failed.
- Assertion failed for Current graphical user session.
startx is a power tool for power users, needing a certain level of
expertise for the user to even want it, let alone use correctly.
However, the expectation is, that the necessary expertise will be
contained within the domain of startx and that it not break tools for
regular users.
This partially reverts commit e1c3082085.
e-imzo: (fix, to be squashed) formatted accordingly using `nixfmt`
e-imzo: (fix, to be squashed) removed lib from options by @ FliegendeWurst
e-imzo: (fix, to be squashed) use lib.getExe as mainProgram is defined by @FliegendeWurst
e-imzo: (fix, to be squashed) formatted with `nixfmt-rfc-style` suggestion by @FliegendeWurst
Co-Authored-By: Arne Keller <arne.keller@posteo.de>
Previously, `http://` scheme was hard coded into the caddy config if
`webserver = "caddy"` was chosen. This is fine for local testing, but is
problematic if you want your nixos host to be public facing.
In the public facing case, you generally want to be using TLS. But since
the wordpress module generates the caddyfile rule, the user's nixos
config cannot easily change it to also allow https.
An alternative would be to reverse proxy an https rule to the generated
http rule, but that's somewhat questionable as there's not an internal
http endpoint to proxy to. It might be possible but I couldn't figure
it out.
So simplify by omitting the scheme. This causes caddy to use https by
default and 301 redirect any http requests to the https endpoint. Caddy
will just do the right thing if it's being hosted on a local/internal
hostname (self sign certificates).
This should be backwards compatible with previous default if users are
using reasonable browsers/tools.
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
It was noted in the TLS recommendations comment, but it actually should
be disabled everywhere if ACME is used as H2O has in enabled by default.
More info: <https://letsencrypt.org/2024/12/05/ending-ocsp/>
With release 6.0, the themes directory was moved to a different location
and thus the NixOS Redmine module needs to be adjusted. Assets seem to
be stored in public/assets now and so that needs to be handled by the
NixOS module as well.
[1] https://www.redmine.org/issues/41731
Signed-off-by: Felix Singer <felixsinger@posteo.net>
The previous fix had only been tested locally through a runtime edit of
the service, and the order in which @chown had been re-added was
different so commit cf498c1a61 ("nixos/cryptpad: fix service with
nodejs 22.11") did not actually fix the issue.
This properly orders @chown after @privileged so the rule is respected,
and also properly denies with EPERM instead of allowing the chown family
of syscalls: this will properly prevent seccomp from killing nodejs
while still disallowing fchown()
Fixes https://github.com/NixOS/nixpkgs/issues/370717
* Create a dedicated team. Before, information was inconsistent between
e.g. tests and package, module had none at all.
* Add maintainership from us to all trivially packaged apps. This is
only to make sure that we take care of them building and installing
and that's about it.
This has been deprecated since before 24.05 was released
and displaying a warning.
This change means that only "managed", i.e.
Nix-native configurations are supported.
This reverts commit a8b8f8f8c7.
It introduced a failure in the syncthing service, where it hangs at the
curl step, repeatedly printing this:
l3ijkvb20h5nnffg5q25i4nmcsbf7glx-merge-syncthing-config[1458]: curl: (22) The requested URL returned error: 404
l3ijkvb20h5nnffg5q25i4nmcsbf7glx-merge-syncthing-config[1458]: curl: (22) The requested URL returned error: 404
l3ijkvb20h5nnffg5q25i4nmcsbf7glx-merge-syncthing-config[1458]: curl: (22) The requested URL returned error: 404
[...]
This is unfortunately not detected by `nix-build -A syncthing.tests`.
Ref https://github.com/NixOS/nixpkgs/pull/390742
Running any occ command will create an empty config file automatically: f85154f1e1/lib/base.php (L194-L196)
This causes the current check to never execute the installation, in case any occ command was run before it (which itself fails because Nextcloud is not installled yet).
So any services which don't properly depend on nextcloud-setup.service cause Nextcloud to never be installed.
Add the options:
- lighthouse.serve_dns
- lighthouse.dns.host
- lighthouse.dns.port
Improve systemd capabilities handling:
- do not give CAP_NET_ADMIN when tunnel interface is disabled
- give CAP_NET_BIND_SERVICE when DNS is enabled
Add self as maintainer: I'm using Nebula on NixOS in prod.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
This is needed since clatd will use networkctl to attempt to obtain the
PLAT prefix, and networkctl uses UNIX domain sockets to communicate with
the systemd-networkd daemon over DBus.
This produced an unnecessarily infinitely deep config tree.
The "cut off" option can be written to, but not read from.
Being written to is important, because it allows users to
conveniently define vmVariant config without having to check
isVmVariant.
There's a small chance that someone *reads* from vmVariant config
in their normal config, and for them it will not be possible
to evaluate with `nixos-rebuild build-vm` anymore.
If this is a problem, we could perhaps make the vmVariant root
appear instead of the `throw` error.
This could also be done using mkOption apply.
Previously, this option was supposed to be a file of the form
`CLOUDFLARE_API_TOKEN=...`, which has a few problems:
- That's not an api token. It's an env file fit for passing to systemd's
`EnvironmentFile` option. The user could typo the variable name, or
intentionally/unintentionally include unrelated environment variables.
- It's not how secret files usually work in NixOS. Secret files are
usually just the secret, and don't leak details about how the secret
is passed to the service.
- This increases friction for people switching between cloudflare dyndns
services, such as `services.cloudflare-dyndns` and
`services.cfdyndns`, which both have a `apiToken` option, but (before
this change) with different semantics.
Previously, all generations for the primary system profile
read their data from the currently active one rather than
their own path, and specialisations in general all used
their parent bootspec rather than their own. This fixes both issues.
This commit still uses the parent path's build date for
specialisations, but this is more minor issue and the times
shouldn't be meaningfully different in most cases anyways.
Mar 19 21:35:05 mobilizon mobilizon[1324]: 21:35:05.504 [info] {"args":{},"attempt":19,"duration":130905,"error":"** (File.Error) could not write to file \"/var/lib/mobilizon/sitemap/sitemap-00001.xml\": no such file or directory","event":"job:exception","id":178203,"max_attempts":20,"meta":{},"queue":"background","queue_time":510620016,"source":"oban","state":"failure","tags":[],"worker":"Mobilizon.Service.Workers.BuildSiteMap"}
Some upstream systemd units are conditionally installed into the systemd
output, so we must make sure the feature that enables their installation
is enabled on our side prior to trying to use them.
Like for matrix-whatsapp use a static user so that the registration file can be automatically shared with synapse.
This also includes the registerToSynapse config option.
This is intended to be used to set secret environment variables for
navidrome, such as ListenBrainz/LastFM API keys.
Signed-off-by: Charlie Egan <charlieegan3@users.noreply.github.com>
The option has been added in 50029ed89c
but never had any effect. As far as I could tell, it was only added for
backward compatibility. I think it's safe to remove this after 3+ years.
I opted for removal instead of implementing it since the module will
just do nothing if no site is configure, thus no enable / disable switch
is needed. Especially on a per-site level.
docker-registry.service has a `After` dependency on gitlab-registry-cert.
On the first start, docker-registry.service fails to start as it already
runs when gitlab-registry-cert.service starts up, and not when it finished.
In afeb76d628, sshd.service and
sshd@.service were switched to Type=notify. This apparently works for
sshd.service, but not for sshd@.service. Given that the reason for
this working with sshd.service isn't exactly clear, let's revert it
for both of them for now, and revisit Type=notify later.
