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
A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
Only use sudo if we are currently not running as the nextcloud user.
This is problematic when occ is called from a systemd service with
NoNewPrivileges=true
This commit adds a Strict-Transport-Security header to
the nginx config file generated by the nextcloud module.
The Strict-Transport-Security header is recommended in
official guide for hardening Nextcloud installations:
https://docs.nextcloud.com/server/16/admin_manual/installation/harden_server.html
Further, if it is not set, we see a warning in the security scan results
in the Nextcloud admin panel:
```
The "Strict-Transport-Security" HTTP header is not set to at least "15552000" seconds. For enhanced security, it is recommended to enable HSTS as described in the security tips
```
IE6 is long gone and this directive is not useful anymore. We can
spare a few CPU cycles (and maybe skip some bugs) by not trying to
disable gzip for MSIE6.
Regression I caused with 3944aa051c, sorry
for this! The Nextcloud installer broke back then because
`trusted_domains` was an empty value by default (a.k.a an empty array)
which seemed to break the config merger of Nextcloud as Nextcloud
doesn't do recursive merging and now no domain was trusted because of
that, hence Nextcloud was unreachable for the `curl` call.
One of the main problems of the Nextcloud module is that it's currently
not possible to alter e.g. database configuration after the initial
setup as it's written by their imperative installer to a file.
After some research[1] it turned out that it's possible to override all values
with an additional config file. The documentation has been
slightly updated to remain up-to-date, but the warnings should
remain there as the imperative configuration is still used and may cause
unwanted side-effects.
Also simplified the postgresql test which uses `ensure{Databases,Users}` to
configure the database.
Fixes#49783
[1] https://github.com/NixOS/nixpkgs/issues/49783#issuecomment-483063922
nixos/nextcloud: Add documentation for nextcloud app installation and updates
nixos/nextcloud: Enable autoUpdateApps in nextcloud test
nixos/nextcloud: Fix typo in nixos/modules/services/web-apps/nextcloud.xml
Co-Authored-By: Florian Klink <flokli@flokli.de>
nixos/nextcloud: Escape html in option description
nixos/nextcloud: Fix autoUpdateApps URL in documentation.
Co-Authored-By: Florian Klink <flokli@flokli.de>
Documize is an open-source alternative for wiki software like Confluence
based on Go and EmberJS. This patch adds the sources for the community
edition[1], for commercial their paid-plan[2] needs to be used.
For commercial use a derivation that bundles the commercial package and
contains a `$out/bin/documize` can be passed to
`services.documize.enable`.
The package compiles the Go sources, the build process also bundles the
pre-built frontend from `gui/public` into the binary.
The NixOS module generates a simple `systemd` unit which starts the
service as a dynamic user, database and a reverse proxy won't be
configured.
[1] https://www.documize.com/get-started/
[2] https://www.documize.com/pricing/
`phpPackage` is 7.3 by default, but `pkgs.php` is 7.2,
so this saves the need for an extra copy of php
for the purpose of running nextcloud's cron;
more importantly this fixes problems with extensions
not loading since they are built against a different php.
The default, which is /tmp, has a few issues associated with it:
One being that it makes it easy for users on the system to spoof a
PostgreSQL server if it's not running, causing applications to connect
to their provided sockets instead of just failing to connect.
Another one is that it makes sandboxing of PostgreSQL and other services
unnecessarily difficult. This is already the case if only PrivateTmp is
used in a systemd service, so in order for such a service to be able to
connect to PostgreSQL, a bind mount needs to be done from /tmp to some
other path, so the service can access it. This pretty much defeats the
whole purpose of PrivateTmp.
We regularily run into issues with this in the past already (one example
would be https://github.com/NixOS/nixpkgs/pull/24317) and with the new
systemd-confinement mode upcoming in
https://github.com/NixOS/nixpkgs/pull/57519, it makes it even more
tedious to sandbox services.
I've tested this change against all the postgresql NixOS VM tests and
they still succeed and I also grepped through the source tree to replace
other occasions where we might have /tmp hardcoded. Luckily there were
very few occasions.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @ocharles, @thoughtpolice, @danbst
The overwriteprotocol option can be used to force Nextcloud to generate
URLs with the given protocol. This is useful for instances behind
reverse proxies that serve Nextcloud with HTTPS.
In this case Nextcloud can't determine the proper protocol and it needs
to be configured manually.
