Fix compatibility with previous versions by making sure all the uploads
and plugins end up in the correct directory. Add a test for the exact
path we care about to ensure that it doesn't work "on accident."
Discovered while updating instances to unstable.
mealie v2.8.0 no longer uses crfpp, but instead uses
ingredient_parser_nlp, which relies on nltk-data. If this environment
variable isn't available, mealie will just download the data instead.
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.
Maybe PrivateHome once existed? It doesn't now, though, and this is the
only instance of it in all of nixpkgs!
Mar 11 15:18:28 kala systemd[1]: /etc/systemd/system/outline.service:46: Unknown key 'PrivateHome' in section [Service], ignoring.
Wrong casing, doesn’t work with those not creating a local database, &
has a bug with implementation on how it should be overriding the
database support to the movim package.
Previously some modules used `config.environment.etc."ssl/certs/ca-certificates.crt".source`, some used `"/etc/ssl/certs/ca-certificates.crt"`, and some used `"${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt"`. These were all bad in one way or another:
- `config.environment.etc."ssl/certs/ca-certificates.crt".source` relies on `source` being set; if `text` is set instead this breaks, introducing a weird undocumented requirement
- `"/etc/ssl/certs/ca-certificates.crt"` is probably okay but very un-nix. It's a magic string, and the path doesn't change when the file changes (and so you can't trigger service reloads, for example, when the contents change in a new system activation)
- `"${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt"` silently doesn't include the options from `security.pki`
Co-authored-by: Shelvacu <git@shelvacu.com>
This 711-line file was expanded into 817-line file by nixfmt.
Readability was hurt as now I can’t see as much in my editor at a time;
this directly makes editing & reviewing slower as reading is harder. I
am upset about this change.
`nextcloud-notify_push.service` requires
`nextcloud-notify_push-setup.service`. If the latter fails (e.g. because
of Nextcloud not being there yet), the push service would also fail with
result 'dependency'.
RestartMode=direct doesn't put a unit into failed state IF it's about to
be restarted again. That way, `nextcloud-notify_push` will await several
restart attempts. Only if the unit fails due to a rate-limit (i.e. too
many restarts), the push service will also fail.
If the startup is still too slow, it may make sense for administrators to
configure higher intervals between the start attempts with RestartSec.
Enabling HSTS "just by default" when a module user requests HTTPS support to be enabled is prone to creating kind of DoS scenarios. This commit at least informs module users about this.
