Nextcloud
Nextcloud is an open-source,
self-hostable cloud platform. The server setup can be automated using
services.nextcloud. A
desktop client is packaged at pkgs.nextcloud-client.
Basic usage
Nextcloud is a PHP-based application which requires an HTTP server
(services.nextcloud
optionally supports
services.nginx)
and a database (it's recommended to use
services.postgresql).
A very basic configuration may look like this:
{ pkgs, ... }:
{
services.nextcloud = {
enable = true;
hostName = "nextcloud.tld";
config = {
dbtype = "pgsql";
dbuser = "nextcloud";
dbhost = "/run/postgresql"; # nextcloud will add /.s.PGSQL.5432 by itself
dbname = "nextcloud";
adminpassFile = "/path/to/admin-pass-file";
adminuser = "root";
};
};
services.postgresql = {
enable = true;
ensureDatabases = [ "nextcloud" ];
ensureUsers = [
{ name = "nextcloud";
ensurePermissions."DATABASE nextcloud" = "ALL PRIVILEGES";
}
];
};
# ensure that postgres is running *before* running the setup
systemd.services."nextcloud-setup" = {
requires = ["postgresql.service"];
after = ["postgresql.service"];
};
networking.firewall.allowedTCPPorts = [ 80 443 ];
}
The hostName option is used internally to configure an HTTP
server using PHP-FPM
and nginx. The config attribute set is
used by the imperative installer and all values are written to an additional file
to ensure that changes can be applied by changing the module's options.
In case the application serves multiple domains (those are checked with
$_SERVER['HTTP_HOST'])
it's needed to add them to
services.nextcloud.config.extraTrustedDomains.
Auto updates for Nextcloud apps can be enabled using
services.nextcloud.autoUpdateApps.
Pitfalls
Unfortunately Nextcloud appears to be very stateful when it comes to
managing its own configuration. The config file lives in the home directory
of the nextcloud user (by default
/var/lib/nextcloud/config/config.php) and is also used to
track several states of the application (e.g. whether installed or not).
All configuration parameters are also stored in
/var/lib/nextcloud/config/override.config.php which is generated by
the module and linked from the store to ensure that all values from config.php
can be modified by the module.
However config.php manages the application's state and shouldn't be touched
manually because of that.
Don't delete config.php! This file
tracks the application's state and a deletion can cause unwanted
side-effects!Don't rerun nextcloud-occ
maintenance:install! This command tries to install the application
and can cause unwanted side-effects!
Nextcloud doesn't allow to move more than one major-version forward. If you're e.g. on
v16, you cannot upgrade to v18, you need to upgrade to
v17 first. This is ensured automatically as long as the
stateVersion is declared properly. In that case
the oldest version available (one major behind the one from the previous NixOS
release) will be selected by default and the module will generate a warning that reminds
the user to upgrade to latest Nextcloud after that deploy.
Using an alternative webserver as reverse-proxy (e.g. <literal>httpd</literal>)
By default, nginx is used as reverse-proxy for nextcloud.
However, it's possible to use e.g. httpd by explicitly disabling
nginx using and fixing the
settings listen.owner & listen.group in the
corresponding phpfpm pool.
An exemplary configuration may look like this:
{ config, lib, pkgs, ... }: {
services.nginx.enable = false;
services.nextcloud = {
enable = true;
hostName = "localhost";
/* further, required options */
};
services.phpfpm.pools.nextcloud.settings = {
"listen.owner" = config.services.httpd.user;
"listen.group" = config.services.httpd.group;
};
services.httpd = {
enable = true;
adminAddr = "webmaster@localhost";
extraModules = [ "proxy_fcgi" ];
virtualHosts."localhost" = {
documentRoot = config.services.nextcloud.package;
extraConfig = ''
<Directory "${config.services.nextcloud.package}">
<FilesMatch "\.php$">
<If "-f %{REQUEST_FILENAME}">
SetHandler "proxy:unix:${config.services.phpfpm.pools.nextcloud.socket}|fcgi://localhost/"
</If>
</FilesMatch>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
DirectoryIndex index.php
Require all granted
Options +FollowSymLinks
</Directory>
'';
};
};
}Maintainer information
As stated in the previous paragraph, we must provide a clean upgrade-path for Nextcloud
since it cannot move more than one major version forward on a single upgrade. This chapter
adds some notes how Nextcloud updates should be rolled out in the future.
While minor and patch-level updates are no problem and can be done directly in the
package-expression (and should be backported to supported stable branches after that),
major-releases should be added in a new attribute (e.g. Nextcloud v19.0.0
should be available in nixpkgs as pkgs.nextcloud19).
To provide simple upgrade paths it's generally useful to backport those as well to stable
branches. As long as the package-default isn't altered, this won't break existing setups.
After that, the versioning-warning in the nextcloud-module should be
updated to make sure that the
package-option selects the latest version
on fresh setups.
If major-releases will be abandoned by upstream, we should check first if those are needed
in NixOS for a safe upgrade-path before removing those. In that case we shold keep those
packages, but mark them as insecure in an expression like this (in
<nixpkgs/pkgs/servers/nextcloud/default.nix>):
/* ... */
{
nextcloud17 = generic {
version = "17.0.x";
sha256 = "0000000000000000000000000000000000000000000000000000";
insecure = true;
};
}
Ideally we should make sure that it's possible to jump two NixOS versions forward:
i.e. the warnings and the logic in the module should guard a user to upgrade from a
Nextcloud on e.g. 19.09 to a Nextcloud on 20.09.