For plugins to work properly, their assets need to be precompiled
along with the rest of Discourse's assets. This means we need to build
new packages when the list of plugins change.
Since 3edde6562e, we can no longer use
aliases inside the test framework. This has the implication that we can
no longer use aliases in any NixOS modules used by the test framework as
well (which is good), but does mean we need to clean up any instances
where this is the case.
* Most significant is probably the patching necessary to run plausible
with postgres without superuser privilege. This change includes:
* updating ecto_sql to 3.6 where `CREATE DATABASE` is only executed if
it doesn't exist[1].
* patching a migration to only modify the `users.email` column (to use
`citext` rather than creating the extension. `plausible-postgres`
takes care of that).
* Correctly declare dependencies in systemd.
* A few minor fixes.
[1] 051baf669e
A secret key generated by the nixos module was misspelled, which could
possibly impact the security of session cookies.
To recover from this situation we will wipe all security keys that were
previously generated by the NixOS module, when the misspelled one is
found. This will result in all session cookies being invalidated. This
is confirmed by the wordpress documentation:
> You can change these at any point in time to invalidate all existing
> cookies. This does mean that all users will have to login again.
https://wordpress.org/support/article/editing-wp-config-php/#security-keys
Meanwhile this issue shouldn't be too grave, since the salting function
of wordpress will rely on the concatenation of both the user-provided
and automatically generated values, that are stored in the database.
> Secret keys are located in two places: in the database and in the
> wp-config.php file. The secret key in the database is randomly
> generated and will be appended to the secret keys in wp-config.php.
https://developer.wordpress.org/reference/functions/wp_salt/
Fixes: 2adb03fdae ("nixos/wordpress:
generate secrets locally")
Reported-by: Moritz Hedtke <Moritz.Hedtke@t-online.de>
Assert that the PostgreSQL version being deployed is the one used
upstream. Allow the user to override this assertion, since it's not
always possible or preferable to use the recommended one.
Instead of requiring the user to bundle the certificate and private
key into a single file, provide separate options for them. This is
more in line with most other modules.
`install` copies the files before setting their mode, so there could
be a breif window where the secrets are readable by other users
without a strict umask.
Feeding `psql` the password on the command line leaks it through the
`psql` process' `/proc/<pid>/cmdline` file. Using `echo` to put the
command in a file and then feeding `psql` the file should work around
this, since `echo` is a bash builtin and thus shouldn't spawn a new
process.
Using `replace-literal` to insert secrets leaks the secrets through
the `replace-literal` process' `/proc/<pid>/cmdline`
file. `replace-secret` solves this by reading the secret straight from
the file instead, which also simplifies the code a bit.
Using `replace-literal` to insert secrets leaks the secrets through
the `replace-literal` process' `/proc/<pid>/cmdline`
file. `replace-secret` solves this by reading the secret straight from
the file instead, which also simplifies the code a bit.
This reverts commit d9e18f4e7f.
This change is broken, since it doesn't configure the proper database
username in keycloak when provisioning a local database with a custom
username. Its intended behavior is also potentially confusing and
dangerous, so rather than fixing it, let's revert to the old one.
Bash doesn't handle subshell errors properly if the result is used as
input to a command. To cause the services to fail when the files can't
be read, we need to assign the value to a variable, then export it
separately.
As the only consequence of isSystemUser is that if the uid is null then
it's allocated below 500, if a user has uid = something below 500 then
we don't require isSystemUser to be set.
Motivation: https://github.com/NixOS/nixpkgs/issues/112647
This allows for shared hledger installations, where the web interface is
available via network and multiple user share a SSH access to the
hledger user.
Also added `--serve` to the CLI options, as hledger-web tries to open a
webbrowser otherwise:
hledger-web: xdg-open: rawSystem: runInteractiveProcess: exec: does not
exist (No such file or directory)
Co-authored-by: Aaron Andersen <aaron@fosslib.net>
ChangeLog: https://nextcloud.com/changelog/#latest21
* Packaged 21.0.0, test-deployed it to my personal instance and tested
the most basic functionality (`davfs2`-mount, {card,cal}dav sync, file
management).
* Bumped the default version for unstable/21.05 to `nextcloud21`. Since
`nextcloud20` was added after the release of 20.09 (and thus the
default on 20.09 is still `nextcloud19`), it's now needed to upgrade
across two majors.
This is not a problem though since it's possible to upgrade to v20 on
20.09 already and if not, the module will guard the administrator
through the upgrade with eval warnings as it's the case since 20.03.
* Dropped `nextcloud17` attribute and marked `nextcloud18` as EOL.
4255954d97 set the StateDirectory to 0750,
but nginx wasn't in the Mastodon group. This commit also deletes a line,
that probably was intended to serve this purpose, but makes no sense.
Why should the Mastodon user be added as an extraGroup to the nginx
user?
The NixOS 21.03 release has been delayed to 21.05. See NixOS/rfcs#80.
There are two instances of 21.03 which have been left as is, since they
are in stateVersion comparisons. This will ensure that existing user
configurations which refer to 21.03 will continue to work.
* It should be made explicit in the eval-error that the CVE only affects
a component which is turned off by default.
* For more clarity, the default version used by the module is noted in
the manual.
Closes#108419
The service was failing with:
gunicorn[2192104]: [2020-12-31 13:35:28 +0000] [2192104] [ERROR] Exception in worker process
gunicorn[2192104]: Traceback (most recent call last):
gunicorn[2192104]: File "/nix/store/jmc14qf1sfnlhw27xyyj862ghkmdkj5a-python2.7-gunicorn-19.10.0/lib/python2.7/site-packages/gunicorn/arbiter.py", line 586, in spawn_worker
gunicorn[2192104]: worker.init_process()
gunicorn[2192104]: File "/nix/store/jmc14qf1sfnlhw27xyyj862ghkmdkj5a-python2.7-gunicorn-19.10.0/lib/python2.7/site-packages/gunicorn/workers/ggevent.py", line 196, in init_process
gunicorn[2192104]: self.patch()
gunicorn[2192104]: File "/nix/store/jmc14qf1sfnlhw27xyyj862ghkmdkj5a-python2.7-gunicorn-19.10.0/lib/python2.7/site-packages/gunicorn/workers/ggevent.py", line 65, in patch
gunicorn[2192104]: monkey.patch_all(subprocess=True)
gunicorn[2192104]: File "/nix/store/fysf67w3i8iv1hfvp536nl8jbzqyk1s7-python-2.7.18-env/lib/python2.7/site-packages/gevent/monkey.py", line 1160, in patch_all
gunicorn[2192104]: from gevent import events
gunicorn[2192104]: File "/nix/store/fysf67w3i8iv1hfvp536nl8jbzqyk1s7-python-2.7.18-env/lib/python2.7/site-packages/gevent/events.py", line 67, in <module>
gunicorn[2192104]: from zope.interface import Interface
gunicorn[2192104]: ImportError: No module named zope.interface
`file_exists` also returns `FALSE` if the file is in a directory that
can't be read by the user. This e.g. happens if permissions for
`nixops(1)`-deployment keys aren't configured correctly.
This patch improves the error message for invalid files to avoid
confusion[1].
[1] https://discourse.nixos.org/t/nixops-deploy-secrets-to-nextcloud/10414/4
This adds a `package` option to allow for easier overriding of the used
CodiMD version and `runCommandLocal` with `nativeBuildInputs` is now
used to pretty print the configuration.
These were broken since 2016:
f0367da7d1
since StartLimitIntervalSec got moved into [Unit] from [Service].
StartLimitBurst has also been moved accordingly, so let's fix that one
too.
NixOS systems have been producing logs such as:
/nix/store/wf98r55aszi1bkmln1lvdbp7znsfr70i-unit-caddy.service/caddy.service:31:
Unknown key name 'StartLimitIntervalSec' in section 'Service', ignoring.
I have also removed some unnecessary duplication in units disabling
rate limiting since setting either interval or burst to zero disables it
(ad16158c10/src/basic/ratelimit.c (L16))
Please note that this is only for 21.03 since `nextcloud19` is intended
to be the default for the already feature-frozen 20.09 (the bump itself
is supposed to get backported however).
Both packages will get EOLed within the lifetime of 20.09. `nextcloud17`
can be removed entirely (the attribute-path is kept however to provide
meaningful errors), however `nextcloud18` must be kept as `insecure` to
make sure that users from `nextcloud17` can properly upgrade to
`nextcloud19` on NixOS 20.09.
Secrets are injected from the environment into the rendered
configuration before each startup using envsubst.
The test now makes use of this feature for the db password.
This patch ensures that latest Nextcloud works flawlessly again on our
`nginx`. The new config is mostly based on upstream recommendations
(again)[1]:
* Trying to access internals now results in a 404.
* All `.php`-routes get properly resolved now.
* Removed 404/403 handling from `nginx` as the app itself takes care of
this. Also, this breaks the `/ocs`-API.
* `.woff2?`-files expire later than other assets like images.
Closes#95293
[1] https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html
Since systemd 243, docs were already steering users towards using
`journal`:
eedaf7f322
systemd 246 will go one step further, it shows warnings for these units
during bootup, and will [automatically convert these occurences to
`journal`](f3dc6af20f):
> [ 6.955976] systemd[1]: /nix/store/hwyfgbwg804vmr92fxc1vkmqfq2k9s17-unit-display-manager.service/display-manager.service:27: Standard output type syslog is obsolete, automatically updating to journal. Please update│······················
your unit file, and consider removing the setting altogether.
So there's no point of keeping `syslog` here, and it's probably a better
idea to just not set it, due to:
> This setting defaults to the value set with DefaultStandardOutput= in
> systemd-system.conf(5), which defaults to journal.
This breaks the Nextcloud vhost declaration when adding e.g. another
vhost as the `services.nginx.virtualHosts` option has `{ nextcloud =
...; }` as *default* value which will be replaced by another
`virtualHosts`-declaration with a higher (e.g. the default) priority.
The following cases are now supported & covered by the module:
* `nginx` is enabled with `nextcloud` enabled and other vhosts can be
added / other options can be declared without having to care
about the declaration's priority.
* Settings in the `nextcloud`-vhost in `nginx` have to be altered using
`mkForce` as this is the only way how we officially support `nginx`
for `nextcloud` and customizations have to be done explicitly using
`mkForce`.
* `nginx` will be completely omitted if a user enables nextcloud
and disables nginx using `services.nginx.enable = false;`. (because
nginx will be enabled by this module using `mkDefault`).
This reverts commit 128dbb31cc.
Closes#95259
In fd9eb16b24, the option
"services.nextcloud.nginx.enable" has been removed since the module now
exclusively supports nginx only.
Unfortunately, with the option gone from the manual, the link in the
Nextcloud-specific documentation referencing the NixOS option also
became a dead link and thus the manual will no longer build.
I also removed a second reference to this option in the Nextcloud-
specific documentation, which while it doesn't lead to a build error in
the manual is nevertheless a good idea to remove as well to ensure we
don't present outdated information to readers of the manual.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @DavHau, @Ma27
- remove optons cfg.user, cfg.groups
- add option `serverUser` which is required when not using nginx
- add `serverUser` to nextcloud group
- set user/group to "nextcloud" for nextcloud services
- make setup-service non-root
Enhance the heuristics to make sure that a user doesn't accidentally
upgrade across two major versions of Nextcloud (e.g. from v17 to v19).
The original idea/discussion has been documented in the nixpkgs manual[1].
This includes the following changes:
* `nextcloud19` will be selected automatically when having a stateVersion
greater or equal than 20.09. For existing setups, the package has to
be selected manually to avoid accidental upgrades.
* When using `nextcloud18` or older, a warning will be thrown which recommends
upgrading to `nextcloud19`.
* Added a brief paragraph about `nextcloud19` in the NixOS 19.09 release
notes.
* Restart `phpfpm` if the Nextcloud-package (`cfg.package`) changes[2].
[1] https://nixos.org/nixos/manual/index.html#module-services-nextcloud-maintainer-info
[2] https://github.com/NixOS/nixpkgs/pull/89427#issuecomment-638885727
This option exposes the prefconfigured nextcloud-occ
program. nextcloud-occ can then be used in other systemd services or
added in environment.systemPackages.
The nextcloud test shows how it can be add in
environment.systemPackages.
The OC_PASS environment variable can be used to create a user with
`occ user:add --password-from-env`. It is currently not possible to
use the `nextcloud-occ` to "non-interactively" create a user since
this variable is ignored by sudo.
Rework withExtensions / buildEnv to handle currently enabled
extensions better and make them compatible with override. They now
accept a function with the named arguments enabled and all, where
enabled is a list of currently enabled extensions and all is the set
of all extensions. This gives us several nice properties:
- You always get the right version of the list of currently enabled
extensions
- Invocations chain
- It works well with overridden PHP packages - you always get the
correct versions of extensions
As a contrived example of what's possible, you can add ImageMagick,
then override the version and disable fpm, then disable cgi, and
lastly remove the zip extension like this:
{ pkgs ? (import <nixpkgs>) {} }:
with pkgs;
let
phpWithImagick = php74.withExtensions ({ all, enabled }: enabled ++ [ all.imagick ]);
phpWithImagickWithoutFpm743 = phpWithImagick.override {
version = "7.4.3";
sha256 = "wVF7pJV4+y3MZMc6Ptx21PxQfEp6xjmYFYTMfTtMbRQ=";
fpmSupport = false;
};
phpWithImagickWithoutFpmZip743 = phpWithImagickWithoutFpm743.withExtensions (
{ enabled, all }:
lib.filter (e: e != all.zip) enabled);
phpWithImagickWithoutFpmZipCgi743 = phpWithImagickWithoutFpmZip743.override {
cgiSupport = false;
};
in
phpWithImagickWithoutFpmZipCgi743
Use types.str instead of types.path to exclude private information from
the derivation.
Add a warinig about the contents of acl beeing included in the nix
store.
Enables multi-site configurations.
This break compatibility with prior configurations that expect options
for a single dokuwiki instance in `services.dokuwiki`.
The new wording does not assume the user is upgrading.
This is because a user could be setting up a new installation on 20.03
on a server that has a 19.09 or before stateVersion!!
The new wording ensures that confusion is reduced by stating that they
do not have to care about the assumed 16→17 transition.
Then, the wording explains that they should, and how to upgrade to
version 18.
It also reviews the confusing wording about "multiple" upgrades.
* * *
The only thing we cannot really do is stop a fresh install of 17 if
there was no previous install, as it cannot be detected. That makes a
useless upgrade forced for new users with old state versions.
It is also important to state that they must set their package to
Nextcloud 18, as future upgrades to Nextcloud will not allow an uprade
from 17!
I assume future warning messages will exist specifically stating what to
do to go from 18 to 19, then 19 to 20, etc...
So now we have only packages for human interaction in php.packages and
only extensions in php.extensions. With this php.packages.exts have
been merged into the same attribute set as all the other extensions to
make it flat and nice.
The nextcloud module have been updated to reflect this change as well
as the documentation.
Many options define their example to be a Nix value without using
literalExample. This sometimes gets rendered incorrectly in the manual,
causing confusion like in https://github.com/NixOS/nixpkgs/issues/25516
This fixes it by using literalExample for such options. The list of
option to fix was determined with this expression:
let
nixos = import ./nixos { configuration = {}; };
lib = import ./lib;
valid = d: {
# escapeNixIdentifier from https://github.com/NixOS/nixpkgs/pull/82461
set = lib.all (n: lib.strings.escapeNixIdentifier n == n) (lib.attrNames d) && lib.all (v: valid v) (lib.attrValues d);
list = lib.all (v: valid v) d;
}.${builtins.typeOf d} or true;
optionList = lib.optionAttrSetToDocList nixos.options;
in map (opt: {
file = lib.elemAt opt.declarations 0;
loc = lib.options.showOption opt.loc;
}) (lib.filter (opt: if opt ? example then ! valid opt.example else false) optionList)
which when evaluated will output all options that use a Nix identifier
that would need escaping as an attribute name.
It's impossible to move two major-versions forward when upgrading
Nextcloud. This is an issue when comming from 19.09 (using Nextcloud 16)
and trying to upgrade to 20.03 (using Nextcloud 18 by default).
This patch implements the measurements discussed in #82056 and #82353 to
improve the update process and to circumvent similar issues in the
future:
* `pkgs.nextcloud` has been removed in favor of versioned attributes
(currently `pkgs.nextcloud17` and `pkgs.nextcloud18`). With that
approach we can safely backport major-releases in the future to
simplify those upgrade-paths and we can select one of the
major-releases as default depending on the configuration (helpful to
decide whether e.g. `pkgs.nextcloud17` or `pkgs.nextcloud18` should be
used on 20.03 and `master` atm).
* If `system.stateVersion` is older than `20.03`, `nextcloud17` will be
used (which is one major-release behind v16 from 19.09). When using a
package older than the latest major-release available (currently v18),
the evaluation will cause a warning which describes the issue and
suggests next steps.
To make those package-selections easier, a new option to define the
package to be used for the service (namely
`services.nextcloud.package`) was introduced.
* If `pkgs.nextcloud` exists (e.g. due to an overlay which was used to
provide more recent Nextcloud versions on older NixOS-releases), an
evaluation error will be thrown by default: this is to make sure that
`services.nextcloud.package` doesn't use an older version by accident
after checking the state-version. If `pkgs.nextcloud` is added
manually, it needs to be declared explicitly in
`services.nextcloud.package`.
* The `nixos/nextcloud`-documentation contains a
"Maintainer information"-chapter which describes how to roll out new
Nextcloud releases and how to deal with old (and probably unsafe)
versions.
Closes#82056
