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
Originally, I wanted to execute `nextcloud-occ` with a higher memory
limit because I needed to trigger an expensive operation by hand,
regenerating a bunch of previews.
While doing so, I realized how painful it is to put an invocation of
nextcloud-occ together for that, especially when you need to put it
into another systemd unit in Nix code.
That's why I decided to use the memory limit now for every
CLI invocation just in case. The stuff you do in those units (e.g.
running background jobs) is something you can also do by hand with
`nextcloud-occ` and you'll most likely want to have the same memory
limit there.
This option is actually useful when having a systemd unit invoking
`nextcloud-occ`, then you want to do something like
path = [ config.services.nextcloud.occ ]
This is possible today, but not documented (and the option completion
from nil doesn't pick it up as a result).
Closes#320381
Installation with a custom dbtableprefix is not allowed anymore for a
while[1] and we shouldn't advertise it as such.
The option is deprecated for now since I'm not sure if there are some
weird corner-cases where removing the option directly would break
existing installations from before <20 with a custom dbtableprefix. The
migration-path for such a case is as follows:
* Check if /var/lib/nextcloud/config/config.php has the correct
dbtableprefix set and if not, take care of it.
* Remove `dbtableprefix` from the NixOS configuration. It's effectively
state anyways.
After a bit of time to switch (perhaps after the next release
branchoff), the option can be removed.
[1] https://github.com/nextcloud/server/issues/24836
The memory limit is equal to what's configured in php-fpm. Given that we
run in a different environment, it seems reasonable to allow different
memory contraints here.
This service performs operations that significantly increase the
performance of Nextcloud, can take a while. These are designed however
to not require maintenance mode and can be executed during normal
operation[1].
Make nextcloud-cron a simple unit instead of oneshot: otherwise we risk
that it'll be stopped by the startup timeout (oneshot executes ExecStart
while "activating") which can be an issue for very long running tasks or
if Nextcloud needs to catch up if one task was broken for a while.
[1] https://docs.nextcloud.com/server/29/admin_manual/maintenance/upgrade.html#long-running-migration-steps
