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
* PHP 8.3 seems supported, so let's go for it!
* The conditions for which Nextcloud will be the default were bogus: for
<24.11 I'd suggest to go for nextcloud29 already. The people on
unstable relying on the condition were on nextcloud28 so the upgrade
will work fine.
Also, it's unstable, so such upgrades are to be expected IMHO.
* Update the release notes to reflect that the new default is Nextcloud
29 and warn that only one major upgrade at a time can be done.
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
Closes#169733
The issue is that Nextcloud fails to start up after a GC because the
symlink from `override.config.php` is stale.
I'm relatively certain that this is not a bug in the Nix GC - that
would've popped up somewhere else already in the past years - and one of
the reporters seems to confirm that: when they restarted
`nextcloud-setup.service` after the issue appeared, an
`override.config.php` pointing to a different hash was there.
This hints that on a deploy `nextcloud-setup` wasn't restarted properly
and thus replacing the symlink update was missed. This is relatively
hard to trigger due to the nature of the bug unfortunately (you usually
keep system generations for a few weeks and you'll need to change the
configuration - or stdenv - to get a different `override.config.php`),
so getting pointers from folks who are affected is rather complicated.
So I decided to work around this by using systemd-tmpfiles which a lot
of other modules already utilize for this use-case. Now,
`override.config.php` and the directory structure aren't created by
`nextcloud-setup`, but by `systemd-tmpfiles`.
With that, the structure is guaranteed to exist
* on boot, since tmpfiles are always created/applied then
* on config activation, since this is done before services are
(re)started which covers the case for new installations and existing
ones.
Also, the recursive `chgrp` was used as transition tool when we switched
from `nginx` as owning group to a dedicated `nextcloud` group[1][2], but
this was several releases ago, so I don't consider this relevant
anymore.
[1] fd9eb16b24
[2] ca916e8cb3
The Nextcloud admin guide says that output buffering must be turned off
or otherwise PHP will return memory-related errors [1]. As the default
value for this PHP setting is 4096 and thus enabled the Nextcloud setup
is thus misconfigured by default. This misconfiguration will be shown in
the "Security & setup warnings" dialog for the administrator.
Fix this misconfiguration by setting "output_buffering=0" by default.
[1]: https://docs.nextcloud.com/server/stable/admin_manual/configuration_files/big_file_upload_configuration.html#configuring-php
Closes#277206
The bug mentioned above was a symptom of the issue fixed here: when
opening the `forms` app which is installed via `extraApps` (or the
app store) the site wouldn't work because `.mjs` files had the wrong
Content-Type.
The actual problem got fixed already[1], however this config was not
used for stuff from `/nix-apps` & `/store-apps` which had their own
location section with only a `root ;` statement.
In fact, this setup isn't strictly supported by Nextcloud upstream[2],
so to fix this for good, I decided to follow the upstream suggestion for
app directories outside the server root, i.e. linking them back into the
store path.
This means that the module generates a new derivation now with
* `services.nextcloud.package` linked into it via `lndir`.
* under `nix-apps` is a symlink to the link farm containing all apps
from `services.nextcloud.extraApps`.
* under `store-apps` is a symlink to `/var/lib/nextcloud/store-apps`.
Since this is only used in the NixOS module that also configures this
location for imperatively installed apps, this seems an OK thing to
do.
Successfully tested the change on a productive Nextcloud 28.0.1 with
several apps installed via `extraApps` (`forms`, `cospend`, `maps`,
`user_saml` and a few more).
[1] 292c74c7a9
[2] https://docs.nextcloud.com/server/28/admin_manual/apps_management.html#using-custom-app-directories
* Always use PHP 8.2: at the time of writing, Nextcloud also suggests to
use 8.2 rather than 8.3 in the manual for v28.
One contributing factor is probably that all plugins need new releases
to declare PHP 8.3 support.
* Fix upgradeWarning for installing v27 now that v28 is out.
* Drop upgrade warning for v24. This one is EOL for quite a while
already, so right now everybody should've switched (or carefully
studied the release notes in case they were upgrading from <23.05) and
we can clean up the module a little bit.
v25 was dropped not so long ago, so if it's still referenced (because
somebody didn't declare `services.nextcloud.package` and has
`system.stateVersion = "22.11";`) it's appropriate to still give a
specialized error.
Closes#216989
First of all, a bit of context: in PostgreSQL, newly created users don't
have the CREATE privilege on the public schema of a database even with
`ALL PRIVILEGES` granted via `ensurePermissions` which is how most of
the DB users are currently set up "declaratively"[1]. This means e.g. a
freshly deployed Nextcloud service will break early because Nextcloud
itself cannot CREATE any tables in the public schema anymore.
The other issue here is that `ensurePermissions` is a mere hack. It's
effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how
a value is substituted in a query. You'd have to parse a subset of SQL
to actually know which object are permissions granted to for a user).
After analyzing the existing modules I realized that in every case with
a single exception[2] the UNIX system user is equal to the db user is
equal to the db name and I don't see a compelling reason why people
would change that in 99% of the cases. In fact, some modules would even
break if you'd change that because the declarations of the system user &
the db user are mixed up[3].
So I decided to go with something new which restricts the ways to use
`ensure*` options rather than expanding those[4]. Effectively this means
that
* The DB user _must_ be equal to the DB name.
* Permissions are granted via `ensureDBOwnerhip` for an attribute-set in
`ensureUsers`. That way, the user is actually the owner and can
perform `CREATE`.
* For such a postgres user, a database must be declared in
`ensureDatabases`.
For anything else, a custom state management should be implemented. This
can either be `initialScript`, doing it manual, outside of the module or
by implementing proper state management for postgresql[5], but the
current state of `ensure*` isn't even declarative, but a convergent tool
which is what Nix actually claims to _not_ do.
Regarding existing setups: there are effectively two options:
* Leave everything as-is (assuming that system user == db user == db
name): then the DB user will automatically become the DB owner and
everything else stays the same.
* Drop the `createDatabase = true;` declarations: nothing will change
because a removal of `ensure*` statements is ignored, so it doesn't
matter at all whether this option is kept after the first deploy (and
later on you'd usually restore from backups anyways).
The DB user isn't the owner of the DB then, but for an existing setup
this is irrelevant because CREATE on the public schema isn't revoked
from existing users (only not granted for new users).
[1] not really declarative though because removals of these statements
are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467
[2] `services.invidious`: I removed the `ensure*` part temporarily
because it IMHO falls into the category "manage the state on your
own" (see the commit message). See also
https://github.com/NixOS/nixpkgs/pull/265857
[3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";`
[4] As opposed to other changes that are considered a potential fix, but
also add more things like collation for DBs or passwords that are
_never_ touched again when changing those.
[5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
First of all, a few cleanups were made to make it more readable:
* Reordered the sections by their priority so what you're reading in Nix
is also what you get in the final nginx.conf.
* Unified media/asset locations
Most notably, this fixes the
Your web server is not properly set up to resolve "/ocm-provider/".
warning since 27.1.2 where `ocm-provider` was moved from a static
directory in the source tarball to a dynamic HTTP route[1].
Additionally, the following things were fixed:
* The 404 checks for build/tests/etc. are now guaranteed to be before
the `.php` location match and it's not implicitly relied upon Nix's
internal attribute sorting anymore.
* `.wasm` files are supported properly and a correct `Content-Type` is
set.
* For "legacy" routes (e.g. `ocs-provider`/`cron`/etc) a `rewrite` rule
inside the location for fastcgi is used as recommended by upstream[2].
This also makes it easier to understand the purpose of the location
itself (i.e. use fastcgi for PHP code).
[1] https://github.com/nextcloud/documentation/pull/11179
[2] https://docs.nextcloud.com/server/27/admin_manual/installation/nginx.html
