Since 25.05 dbtype no longer defaults to sqlite and this yields an error
that is understandable enough but not easy to properly address.
Add an assert that is more explicit.
Before:
```
error: The option `nodes.nextcloud.services.nextcloud.config.dbtype' was accessed but has no value defined. Try setting the option.
```
After:
```
error:
Failed assertions:
- `services.nextcloud.config.dbtype` must be set explicitly (pgsql, mysql, or sqlite)
Before 25.05, it used to default to sqlite but that is not recommended by upstream.
Either set it to sqlite as it used to be, or convert to another type as described
in the official db conversion page:
https://docs.nextcloud.com/server/latest/admin_manual/configuration_database/db_conversion.html
```
Link: https://github.com/NixOS/nixpkgs/pull/369242#issuecomment-3036296243
(cherry picked from commit 78a20758e0)
Upstream changes were checked by checking out the stable31 branch of the
https://github.com/nextcloud/documentation and comparing:
git diff c1c9b0a072537544769fdd6062989a631d4fb17c admin_manual/installation/nginx-root.conf.sample
Notably, this adds the text/javascript and application/wasm mime types to the list of
gzip'ed mime types, which improves nextcloud loading in our testing.
Also adds webp support.
(cherry picked from commit 0c7a8d5255)
This patch adds support for using systemd's LoadCredential
feature to read in a json file at a path defined in the
services.nextcloud.secretFile option.
This is a follow up to 2ce1e84103.
Disables the "Open updater" button in the admin overview and makes sure it is not possible to update the instance through the web interface.
Nextcloud runs from the source code in the nix store and should not try to update itself manually.
The only way to update Nextcloud is to update nixpkgs and therefore the web updater must be disabled.
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)
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.
* 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.
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>
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.
This patch adds support for using systemd's LoadCredential
feature to read various secret files used by nextcloud service
units.
Previously credentials had to be readable by the nextcloud user,
this is now no longer required.
The nextcloud-occ wrapper script has been adjusted to use
systemd-run for loading credentials when being called from
outside a service.
In detail this change touches various details of the module:
- The nix_read_secret() php function now takes the name of a
file relative to the path specified in the CREDENTIALS_DIRECTORY
environment variable.
- The nix_read_secret() now exits with error code 1 instead of
throwing a RuntimeException as this will properly error out
the nextcloud-occ script
- Only the nextcloud-setup service unit has the adminpass credential
added in addition to the other credentials
- Uses of ExecCondition= in nextcloud-cron and nextcloud-update-db
have been replaced by a shell conditional as ExecCondition currently
doesn't support credentials
- The phpfpm-nextcloud service now runs a preStart script to make
the credentials it gets readable by the nextcloud user as the
unit runs as root but the php process itself as nextcloud.
- To invoke occ notify_push:setup when using nextcloud notify_push
a new service has been added that replaces the preStart script
in nextcloud-notify_push.service. This has been done as the
main executable only needs the database password credential.
Co-authored-by: lassulus <lassulus@lassul.us>
This patch replaces the use of writeScriptBin for the nextcloud-occ
script with writeShellApplication, enabling shell checking.
This patch also updates various invocations of the script to
use lib.getExe.
I have no idea what this escape sequence even is, but it breaks the nix parser with cryptic errors if not used in a comment.
A friend let me know MacOS is prone to input weird spaces, not sure if that is the source.
Candidates were located and created with:
chr="$(echo -e '\xc2\xa0')"; rg -F "$chr" -l | xe sd -F "$chr" " "
There are some examples left, most being example output from `tree` in various markdown documents, some patches which we can't really touch, and `pkgs/tools/nix/nixos-render-docs/src/tests/test_commonmark.py` which I'm not sure if should be addressed
This helps supporting sudo-rs, which currently does not implement the
--preserve-env flag and probably won't so in the foreseeable future [1].
The replacement just sets both environment variables behind the sudo
invocation with env, as sudo-rs also doesn't implement env var lists.
The OC_PASS variable is dropped, as it is seemingly unused and would
leak through this approach through /proc.
[1] https://github.com/memorysafety/sudo-rs/issues/129
