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.
Originally, I only wanted to remove
"The logreader application doesn't work, as it was the case before.".
But then, the rest sounded a little weird, so I reworded the paragraph a
bit more ;-)
