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