nixpkgs/nixos/modules/services/web-apps/nextcloud.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1258 lines
46 KiB
Nix
Raw Normal View History

{ config, lib, pkgs, ... }:
with lib;
let
cfg = config.services.nextcloud;
fpm = config.services.phpfpm.pools.nextcloud;
jsonFormat = pkgs.formats.json {};
defaultPHPSettings = {
output_buffering = "0";
short_open_tag = "Off";
expose_php = "Off";
error_reporting = "E_ALL & ~E_DEPRECATED & ~E_STRICT";
display_errors = "stderr";
"opcache.interned_strings_buffer" = "8";
"opcache.max_accelerated_files" = "10000";
"opcache.memory_consumption" = "128";
"opcache.revalidate_freq" = "1";
"opcache.fast_shutdown" = "1";
"openssl.cafile" = "/etc/ssl/certs/ca-certificates.crt";
catch_workers_output = "yes";
};
appStores = {
# default apps bundled with pkgs.nextcloudXX, e.g. files, contacts
apps = {
enabled = true;
writable = false;
};
# apps installed via cfg.extraApps
nix-apps = {
enabled = cfg.extraApps != { };
linkTarget = pkgs.linkFarm "nix-apps"
(mapAttrsToList (name: path: { inherit name path; }) cfg.extraApps);
writable = false;
};
# apps installed via the app store.
store-apps = {
enabled = cfg.appstoreEnable == null || cfg.appstoreEnable;
linkTarget = "${cfg.home}/store-apps";
writable = true;
};
};
2024-03-02 17:00:56 +00:00
webroot = pkgs.runCommandLocal
"${cfg.package.name or "nextcloud"}-with-apps"
{ }
''
mkdir $out
ln -sfv "${cfg.package}"/* "$out"
${concatStrings
(mapAttrsToList (name: store: optionalString (store.enabled && store?linkTarget) ''
if [ -e "$out"/${name} ]; then
echo "Didn't expect ${name} already in $out!"
exit 1
fi
ln -sfTv ${store.linkTarget} "$out"/${name}
'') appStores)}
'';
inherit (cfg) datadir;
phpPackage = cfg.phpPackage.buildEnv {
extensions = { enabled, all }:
(with all; enabled
2023-12-13 00:07:10 +00:00
++ [ bz2 intl sodium ] # recommended
++ optional cfg.enableImagemagick imagick
# Optionally enabled depending on caching settings
++ optional cfg.caching.apcu apcu
++ optional cfg.caching.redis redis
++ optional cfg.caching.memcached memcached
)
++ cfg.phpExtraExtensions all; # Enabled by user
extraConfig = toKeyValue cfg.phpOptions;
};
toKeyValue = generators.toKeyValue {
mkKeyValue = generators.mkKeyValueDefault {} " = ";
};
phpCli = concatStringsSep " " ([
"${getExe phpPackage}"
] ++ optionals (cfg.cli.memoryLimit != null) [
"-dmemory_limit=${cfg.cli.memoryLimit}"
]);
occ = pkgs.writeScriptBin "nextcloud-occ" ''
#! ${pkgs.runtimeShell}
cd ${webroot}
sudo=exec
if [[ "$USER" != nextcloud ]]; then
sudo='exec /run/wrappers/bin/sudo -u nextcloud'
fi
$sudo ${pkgs.coreutils}/bin/env \
NEXTCLOUD_CONFIG_DIR="${datadir}/config" \
${phpCli} \
occ "$@"
'';
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
inherit (config.system) stateVersion;
mysqlLocal = cfg.database.createLocally && cfg.config.dbtype == "mysql";
pgsqlLocal = cfg.database.createLocally && cfg.config.dbtype == "pgsql";
nixos/nextcloud: set up base directories & override.config.php with tmpfiles 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] fd9eb16b249aad1d5e231b8329035abfab5fc0eb [2] ca916e8cb3220ba43a43d10f72ccb4b88077a461
2024-01-12 19:27:58 +00:00
nextcloudGreaterOrEqualThan = versionAtLeast cfg.package.version;
nextcloudOlderThan = versionOlder cfg.package.version;
# https://github.com/nextcloud/documentation/pull/11179
nixos/nextcloud: set up base directories & override.config.php with tmpfiles 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] fd9eb16b249aad1d5e231b8329035abfab5fc0eb [2] ca916e8cb3220ba43a43d10f72ccb4b88077a461
2024-01-12 19:27:58 +00:00
ocmProviderIsNotAStaticDirAnymore = nextcloudGreaterOrEqualThan "27.1.2"
|| (nextcloudOlderThan "27.0.0" && nextcloudGreaterOrEqualThan "26.0.8");
overrideConfig = let
c = cfg.config;
requiresReadSecretFunction = c.dbpassFile != null || c.objectstore.s3.enable;
objectstoreConfig = let s3 = c.objectstore.s3; in optionalString s3.enable ''
'objectstore' => [
'class' => '\\OC\\Files\\ObjectStore\\S3',
'arguments' => [
'bucket' => '${s3.bucket}',
'autocreate' => ${boolToString s3.autocreate},
'key' => '${s3.key}',
'secret' => nix_read_secret('${s3.secretFile}'),
${optionalString (s3.hostname != null) "'hostname' => '${s3.hostname}',"}
${optionalString (s3.port != null) "'port' => ${toString s3.port},"}
'use_ssl' => ${boolToString s3.useSsl},
${optionalString (s3.region != null) "'region' => '${s3.region}',"}
'use_path_style' => ${boolToString s3.usePathStyle},
${optionalString (s3.sseCKeyFile != null) "'sse_c_key' => nix_read_secret('${s3.sseCKeyFile}'),"}
],
]
'';
showAppStoreSetting = cfg.appstoreEnable != null || cfg.extraApps != {};
renderedAppStoreSetting =
let
x = cfg.appstoreEnable;
in
if x == null then "false"
else boolToString x;
mkAppStoreConfig = name: { enabled, writable, ... }: optionalString enabled ''
[ 'path' => '${webroot}/${name}', 'url' => '/${name}', 'writable' => ${boolToString writable} ],
'';
in pkgs.writeText "nextcloud-config.php" ''
<?php
${optionalString requiresReadSecretFunction ''
function nix_read_secret($file) {
if (!file_exists($file)) {
throw new \RuntimeException(sprintf(
"Cannot start Nextcloud, secret file %s set by NixOS doesn't seem to "
. "exist! Please make sure that the file exists and has appropriate "
. "permissions for user & group 'nextcloud'!",
$file
));
}
return trim(file_get_contents($file));
}''}
function nix_decode_json_file($file, $error) {
if (!file_exists($file)) {
throw new \RuntimeException(sprintf($error, $file));
}
$decoded = json_decode(file_get_contents($file), true);
nixos/nextcloud: set up base directories & override.config.php with tmpfiles 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] fd9eb16b249aad1d5e231b8329035abfab5fc0eb [2] ca916e8cb3220ba43a43d10f72ccb4b88077a461
2024-01-12 19:27:58 +00:00
if (json_last_error() !== JSON_ERROR_NONE) {
throw new \RuntimeException(sprintf("Cannot decode %s, because: %s", $file, json_last_error_msg()));
}
return $decoded;
}
$CONFIG = [
'apps_paths' => [
${concatStrings (mapAttrsToList mkAppStoreConfig appStores)}
],
${optionalString (showAppStoreSetting) "'appstoreenabled' => ${renderedAppStoreSetting},"}
${optionalString cfg.caching.apcu "'memcache.local' => '\\OC\\Memcache\\APCu',"}
${optionalString (c.dbname != null) "'dbname' => '${c.dbname}',"}
${optionalString (c.dbhost != null) "'dbhost' => '${c.dbhost}',"}
${optionalString (c.dbuser != null) "'dbuser' => '${c.dbuser}',"}
${optionalString (c.dbtableprefix != null) "'dbtableprefix' => '${toString c.dbtableprefix}',"}
${optionalString (c.dbpassFile != null) ''
'dbpassword' => nix_read_secret(
"${c.dbpassFile}"
),
''
}
'dbtype' => '${c.dbtype}',
${objectstoreConfig}
];
$CONFIG = array_replace_recursive($CONFIG, nix_decode_json_file(
"${jsonFormat.generate "nextcloud-settings.json" cfg.settings}",
"impossible: this should never happen (decoding generated settings file %s failed)"
nixos/nextcloud: set up base directories & override.config.php with tmpfiles 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] fd9eb16b249aad1d5e231b8329035abfab5fc0eb [2] ca916e8cb3220ba43a43d10f72ccb4b88077a461
2024-01-12 19:27:58 +00:00
));
${optionalString (cfg.secretFile != null) ''
$CONFIG = array_replace_recursive($CONFIG, nix_decode_json_file(
"${cfg.secretFile}",
"Cannot start Nextcloud, secrets file %s set by NixOS doesn't exist!"
));
''}
'';
in {
imports = [
(mkRenamedOptionModule
[ "services" "nextcloud" "cron" "memoryLimit" ]
[ "services" "nextcloud" "cli" "memoryLimit" ])
(mkRemovedOptionModule [ "services" "nextcloud" "enableBrokenCiphersForSSE" ] ''
This option has no effect since there's no supported Nextcloud version packaged here
using OpenSSL for RC4 SSE.
'')
(mkRemovedOptionModule [ "services" "nextcloud" "config" "dbport" ] ''
Add port to services.nextcloud.config.dbhost instead.
'')
(mkRenamedOptionModule
[ "services" "nextcloud" "logLevel" ] [ "services" "nextcloud" "settings" "loglevel" ])
(mkRenamedOptionModule
[ "services" "nextcloud" "logType" ] [ "services" "nextcloud" "settings" "log_type" ])
(mkRenamedOptionModule
[ "services" "nextcloud" "config" "defaultPhoneRegion" ] [ "services" "nextcloud" "settings" "default_phone_region" ])
(mkRenamedOptionModule
[ "services" "nextcloud" "config" "overwriteProtocol" ] [ "services" "nextcloud" "settings" "overwriteprotocol" ])
(mkRenamedOptionModule
[ "services" "nextcloud" "skeletonDirectory" ] [ "services" "nextcloud" "settings" "skeletondirectory" ])
(mkRenamedOptionModule
[ "services" "nextcloud" "globalProfiles" ] [ "services" "nextcloud" "settings" "profile.enabled" ])
(mkRenamedOptionModule
[ "services" "nextcloud" "config" "extraTrustedDomains" ] [ "services" "nextcloud" "settings" "trusted_domains" ])
(mkRenamedOptionModule
[ "services" "nextcloud" "config" "trustedProxies" ] [ "services" "nextcloud" "settings" "trusted_proxies" ])
(mkRenamedOptionModule ["services" "nextcloud" "extraOptions" ] [ "services" "nextcloud" "settings" ])
];
options.services.nextcloud = {
enable = mkEnableOption "nextcloud";
hostName = mkOption {
type = types.str;
description = "FQDN for the nextcloud instance.";
};
home = mkOption {
type = types.str;
default = "/var/lib/nextcloud";
description = "Storage path of nextcloud.";
};
datadir = mkOption {
type = types.str;
default = config.services.nextcloud.home;
defaultText = literalExpression "config.services.nextcloud.home";
description = ''
2023-08-04 03:51:12 +00:00
Nextcloud's data storage path. Will be [](#opt-services.nextcloud.home) by default.
This folder will be populated with a config.php file and a data folder which contains the state of the instance (excluding the database).";
'';
example = "/mnt/nextcloud-file";
};
extraApps = mkOption {
type = types.attrsOf types.package;
default = { };
description = ''
Extra apps to install. Should be an attrSet of appid to packages generated by fetchNextcloudApp.
The appid must be identical to the "id" value in the apps appinfo/info.xml.
Using this will disable the appstore to prevent Nextcloud from updating these apps (see [](#opt-services.nextcloud.appstoreEnable)).
'';
example = literalExpression ''
{
2023-11-13 19:26:08 +00:00
inherit (pkgs.nextcloud25Packages.apps) mail calendar contact;
phonetrack = pkgs.fetchNextcloudApp {
name = "phonetrack";
sha256 = "0qf366vbahyl27p9mshfma1as4nvql6w75zy2zk5xwwbp343vsbc";
url = "https://gitlab.com/eneiluj/phonetrack-oc/-/wikis/uploads/931aaaf8dca24bf31a7e169a83c17235/phonetrack-0.6.9.tar.gz";
version = "0.6.9";
};
}
'';
};
extraAppsEnable = mkOption {
type = types.bool;
default = true;
description = ''
2023-08-04 03:51:12 +00:00
Automatically enable the apps in [](#opt-services.nextcloud.extraApps) every time Nextcloud starts.
If set to false, apps need to be enabled in the Nextcloud web user interface or with `nextcloud-occ app:enable`.
'';
};
appstoreEnable = mkOption {
type = types.nullOr types.bool;
default = null;
example = true;
description = ''
2023-08-04 03:51:12 +00:00
Allow the installation and updating of apps from the Nextcloud appstore.
Enabled by default unless there are packages in [](#opt-services.nextcloud.extraApps).
2023-08-04 03:51:12 +00:00
Set this to true to force enable the store even if [](#opt-services.nextcloud.extraApps) is used.
Set this to false to disable the installation of apps from the global appstore. App management is always enabled regardless of this setting.
'';
};
https = mkOption {
type = types.bool;
default = false;
2023-08-04 03:51:12 +00:00
description = "Use HTTPS for generated links.";
};
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
package = mkOption {
type = types.package;
description = "Which package to use for the Nextcloud instance.";
relatedPackages = [ "nextcloud28" "nextcloud29" ];
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
};
phpPackage = mkPackageOption pkgs "php" {
example = "php82";
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
};
maxUploadSize = mkOption {
default = "512M";
type = types.str;
description = ''
2023-08-04 03:51:12 +00:00
The upload limit for files. This changes the relevant options
in php.ini and nginx if enabled.
'';
};
webfinger = mkOption {
type = types.bool;
default = false;
description = ''
Enable this option if you plan on using the webfinger plugin.
The appropriate nginx rewrite rules will be added to your configuration.
'';
};
phpExtraExtensions = mkOption {
type = with types; functionTo (listOf package);
default = all: [];
defaultText = literalExpression "all: []";
description = ''
2023-08-04 03:51:12 +00:00
Additional PHP extensions to use for Nextcloud.
By default, only extensions necessary for a vanilla Nextcloud installation are enabled,
but you may choose from the list of available extensions and add further ones.
2023-08-04 03:51:12 +00:00
This is sometimes necessary to be able to install a certain Nextcloud app that has additional requirements.
'';
example = literalExpression ''
all: [ all.pdlib all.bz2 ]
'';
};
phpOptions = mkOption {
type = with types; attrsOf (oneOf [ str int ]);
defaultText = literalExpression (generators.toPretty { } defaultPHPSettings);
description = ''
Options for PHP's php.ini file for nextcloud.
Please note that this option is _additive_ on purpose while the
attribute values inside the default are option defaults: that means that
```nix
{
services.nextcloud.phpOptions."opcache.interned_strings_buffer" = "23";
}
```
will override the `php.ini` option `opcache.interned_strings_buffer` without
discarding the rest of the defaults.
Overriding all of `phpOptions` (including `upload_max_filesize`, `post_max_size`
and `memory_limit` which all point to [](#opt-services.nextcloud.maxUploadSize)
by default) can be done like this:
```nix
{
services.nextcloud.phpOptions = lib.mkForce {
/* ... */
};
}
```
'';
};
2019-09-10 17:33:00 +00:00
poolSettings = mkOption {
type = with types; attrsOf (oneOf [ str int bool ]);
default = {
"pm" = "dynamic";
"pm.max_children" = "32";
"pm.start_servers" = "2";
"pm.min_spare_servers" = "2";
"pm.max_spare_servers" = "4";
"pm.max_requests" = "500";
};
description = ''
Options for nextcloud's PHP pool. See the documentation on `php-fpm.conf` for details on configuration directives.
'';
2019-09-10 17:33:00 +00:00
};
poolConfig = mkOption {
type = types.nullOr types.lines;
default = null;
description = ''
2023-08-04 03:51:12 +00:00
Options for Nextcloud's PHP pool. See the documentation on `php-fpm.conf` for details on configuration directives.
'';
};
fastcgiTimeout = mkOption {
type = types.int;
default = 120;
description = ''
FastCGI timeout for database connection in seconds.
'';
};
database = {
createLocally = mkOption {
type = types.bool;
default = false;
description = ''
2023-08-04 03:51:12 +00:00
Whether to create the database and database user locally.
'';
};
};
config = {
dbtype = mkOption {
type = types.enum [ "sqlite" "pgsql" "mysql" ];
default = "sqlite";
description = "Database type.";
};
dbname = mkOption {
type = types.nullOr types.str;
default = "nextcloud";
description = "Database name.";
};
dbuser = mkOption {
type = types.nullOr types.str;
default = "nextcloud";
description = "Database user.";
};
dbpassFile = mkOption {
type = types.nullOr types.str;
default = null;
description = ''
The full path to a file that contains the database password.
'';
};
dbhost = mkOption {
type = types.nullOr types.str;
default =
if pgsqlLocal then "/run/postgresql"
else if mysqlLocal then "localhost:/run/mysqld/mysqld.sock"
else "localhost";
defaultText = "localhost";
example = "localhost:5000";
description = ''
Database host (+port) or socket path.
2023-08-04 03:51:12 +00:00
If [](#opt-services.nextcloud.database.createLocally) is true and
[](#opt-services.nextcloud.config.dbtype) is either `pgsql` or `mysql`,
defaults to the correct Unix socket instead.
'';
};
dbtableprefix = mkOption {
type = types.nullOr types.str;
default = null;
description = ''
Table prefix in Nextcloud's database.
__Note:__ since Nextcloud 20 it's not an option anymore to create a database
schema with a custom table prefix. This option only exists for backwards compatibility
with installations that were originally provisioned with Nextcloud <20.
'';
};
adminuser = mkOption {
type = types.str;
default = "root";
description = ''
Username for the admin account. The username is only set during the
initial setup of Nextcloud! Since the username also acts as unique
ID internally, it cannot be changed later!
'';
};
adminpassFile = mkOption {
type = types.str;
description = ''
The full path to a file that contains the admin's password. Must be
readable by user `nextcloud`. The password is set only in the initial
2023-08-04 03:51:12 +00:00
setup of Nextcloud by the systemd service `nextcloud-setup.service`.
'';
};
objectstore = {
s3 = {
enable = mkEnableOption ''
S3 object storage as primary storage.
This mounts a bucket on an Amazon S3 object storage or compatible
implementation into the virtual filesystem.
Further details about this feature can be found in the
2024-06-03 16:59:45 +00:00
[upstream documentation](https://docs.nextcloud.com/server/22/admin_manual/configuration_files/primary_storage.html)
'';
bucket = mkOption {
type = types.str;
example = "nextcloud";
description = ''
The name of the S3 bucket.
'';
};
autocreate = mkOption {
type = types.bool;
description = ''
Create the objectstore if it does not exist.
'';
};
key = mkOption {
type = types.str;
example = "EJ39ITYZEUH5BGWDRUFY";
description = ''
The access key for the S3 bucket.
'';
};
secretFile = mkOption {
type = types.str;
example = "/var/nextcloud-objectstore-s3-secret";
description = ''
The full path to a file that contains the access secret. Must be
readable by user `nextcloud`.
'';
};
hostname = mkOption {
type = types.nullOr types.str;
default = null;
example = "example.com";
description = ''
Required for some non-Amazon implementations.
'';
};
port = mkOption {
type = types.nullOr types.port;
default = null;
description = ''
Required for some non-Amazon implementations.
'';
};
useSsl = mkOption {
type = types.bool;
default = true;
description = ''
Use SSL for objectstore access.
'';
};
region = mkOption {
type = types.nullOr types.str;
default = null;
example = "REGION";
description = ''
Required for some non-Amazon implementations.
'';
};
usePathStyle = mkOption {
type = types.bool;
default = false;
description = ''
Required for some non-Amazon S3 implementations.
Ordinarily, requests will be made with
`http://bucket.hostname.domain/`, but with path style
enabled requests are made with
`http://hostname.domain/bucket` instead.
'';
};
sseCKeyFile = mkOption {
type = types.nullOr types.path;
default = null;
example = "/var/nextcloud-objectstore-s3-sse-c-key";
description = ''
If provided this is the full path to a file that contains the key
to enable [server-side encryption with customer-provided keys][1]
(SSE-C).
The file must contain a random 32-byte key encoded as a base64
string, e.g. generated with the command
```
openssl rand 32 | base64
```
Must be readable by user `nextcloud`.
[1]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html
'';
};
};
};
};
enableImagemagick = mkEnableOption ''
the ImageMagick module for PHP.
This is used by the theming app and for generating previews of certain images (e.g. SVG and HEIF).
You may want to disable it for increased security. In that case, previews will still be available
for some images (e.g. JPEG and PNG).
2024-06-03 16:59:45 +00:00
See <https://github.com/nextcloud/server/issues/13099>
'' // {
default = true;
};
configureRedis = lib.mkOption {
type = lib.types.bool;
default = config.services.nextcloud.notify_push.enable;
defaultText = literalExpression "config.services.nextcloud.notify_push.enable";
description = ''
2023-08-04 03:51:12 +00:00
Whether to configure Nextcloud to use the recommended Redis settings for small instances.
::: {.note}
2023-08-04 03:51:12 +00:00
The `notify_push` app requires Redis to be configured. If this option is turned off, this must be configured manually.
:::
'';
};
caching = {
apcu = mkOption {
type = types.bool;
default = true;
description = ''
Whether to load the APCu module into PHP.
'';
};
redis = mkOption {
type = types.bool;
default = false;
description = ''
Whether to load the Redis module into PHP.
You still need to enable Redis in your config.php.
See https://docs.nextcloud.com/server/14/admin_manual/configuration_server/caching_configuration.html
'';
};
memcached = mkOption {
type = types.bool;
default = false;
description = ''
Whether to load the Memcached module into PHP.
You still need to enable Memcached in your config.php.
See https://docs.nextcloud.com/server/14/admin_manual/configuration_server/caching_configuration.html
'';
};
};
autoUpdateApps = {
enable = mkOption {
type = types.bool;
default = false;
description = ''
2023-08-04 03:51:12 +00:00
Run a regular auto-update of all apps installed from the Nextcloud app store.
'';
};
startAt = mkOption {
type = with types; either str (listOf str);
default = "05:00:00";
example = "Sun 14:00:00";
description = ''
When to run the update. See `systemd.services.<name>.startAt`.
'';
};
};
occ = mkOption {
type = types.package;
default = occ;
defaultText = literalMD "generated script";
description = ''
The nextcloud-occ program preconfigured to target this Nextcloud instance.
'';
};
settings = mkOption {
type = types.submodule {
freeformType = jsonFormat.type;
options = {
loglevel = mkOption {
type = types.ints.between 0 4;
default = 2;
description = ''
Log level value between 0 (DEBUG) and 4 (FATAL).
- 0 (debug): Log all activity.
- 1 (info): Log activity such as user logins and file activities, plus warnings, errors, and fatal errors.
- 2 (warn): Log successful operations, as well as warnings of potential problems, errors and fatal errors.
- 3 (error): Log failed operations and fatal errors.
- 4 (fatal): Log only fatal errors that cause the server to stop.
'';
};
log_type = mkOption {
type = types.enum [ "errorlog" "file" "syslog" "systemd" ];
default = "syslog";
description = ''
Logging backend to use.
systemd requires the php-systemd package to be added to services.nextcloud.phpExtraExtensions.
See the [nextcloud documentation](https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/logging_configuration.html) for details.
'';
};
skeletondirectory = mkOption {
default = "";
type = types.str;
description = ''
The directory where the skeleton files are located. These files will be
copied to the data directory of new users. Leave empty to not copy any
skeleton files.
'';
};
trusted_domains = mkOption {
type = types.listOf types.str;
default = [];
description = ''
Trusted domains, from which the nextcloud installation will be
accessible. You don't need to add
`services.nextcloud.hostname` here.
'';
};
trusted_proxies = mkOption {
type = types.listOf types.str;
default = [];
description = ''
Trusted proxies, to provide if the nextcloud installation is being
proxied to secure against e.g. spoofing.
'';
};
overwriteprotocol = mkOption {
type = types.enum [ "" "http" "https" ];
default = "";
example = "https";
description = ''
Force Nextcloud to always use HTTP or HTTPS i.e. for link generation.
Nextcloud uses the currently used protocol by default, but when
behind a reverse-proxy, it may use `http` for everything although
Nextcloud may be served via HTTPS.
'';
};
default_phone_region = mkOption {
default = "";
type = types.str;
example = "DE";
description = ''
An [ISO 3166-1](https://www.iso.org/iso-3166-country-codes.html)
country code which replaces automatic phone-number detection
without a country code.
As an example, with `DE` set as the default phone region,
the `+49` prefix can be omitted for phone numbers.
'';
};
"profile.enabled" = mkEnableOption "global profiles" // {
description = ''
Makes user-profiles globally available under `nextcloud.tld/u/user.name`.
Even though it's enabled by default in Nextcloud, it must be explicitly enabled
here because it has the side-effect that personal information is even accessible to
unauthenticated users by default.
By default, the following properties are set to Show to everyone
if this flag is enabled:
- About
- Full name
- Headline
- Organisation
- Profile picture
- Role
- Twitter
- Website
Only has an effect in Nextcloud 23 and later.
'';
};
};
};
default = {};
description = ''
2023-08-04 03:51:12 +00:00
Extra options which should be appended to Nextcloud's config.php file.
'';
2022-07-05 22:08:29 +00:00
example = literalExpression '' {
redis = {
host = "/run/redis/redis.sock";
port = 0;
dbindex = 0;
password = "secret";
timeout = 1.5;
};
} '';
};
secretFile = mkOption {
type = types.nullOr types.str;
default = null;
description = ''
2023-08-04 03:51:12 +00:00
Secret options which will be appended to Nextcloud's config.php file (written as JSON, in the same
form as the [](#opt-services.nextcloud.settings) option), for example
`{"redis":{"password":"secret"}}`.
'';
};
2022-07-05 22:08:29 +00:00
nginx = {
recommendedHttpHeaders = mkOption {
type = types.bool;
default = true;
description = "Enable additional recommended HTTP response headers";
};
hstsMaxAge = mkOption {
type = types.ints.positive;
default = 15552000;
description = ''
Value for the `max-age` directive of the HTTP
`Strict-Transport-Security` header.
See section 6.1.1 of IETF RFC 6797 for detailed information on this
directive and header.
'';
};
};
cli.memoryLimit = mkOption {
type = types.nullOr types.str;
default = null;
example = "1G";
description = ''
The `memory_limit` of PHP is equal to [](#opt-services.nextcloud.maxUploadSize).
The value can be customized for `nextcloud-cron.service` using this option.
'';
};
};
config = mkIf cfg.enable (mkMerge [
{ warnings = let
latest = 29;
upgradeWarning = major: nixos:
''
A legacy Nextcloud install (from before NixOS ${nixos}) may be installed.
After nextcloud${toString major} is installed successfully, you can safely upgrade
2023-08-04 03:51:12 +00:00
to ${toString (major + 1)}. The latest version available is Nextcloud${toString latest}.
Please note that Nextcloud doesn't support upgrades across multiple major versions
(i.e. an upgrade from 16 is possible to 17, but not 16 to 18).
The package can be upgraded by explicitly declaring the service-option
`services.nextcloud.package`.
'';
in (optional (cfg.poolConfig != null) ''
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
Using config.services.nextcloud.poolConfig is deprecated and will become unsupported in a future release.
Please migrate your configuration to config.services.nextcloud.poolSettings.
'')
++ (optional (cfg.config.dbtableprefix != null) ''
Using `services.nextcloud.config.dbtableprefix` is deprecated. Fresh installations with this
option set are not allowed anymore since v20.
If you have an existing installation with a custom table prefix, make sure it is
set correctly in `config.php` and remove the option from your NixOS config.
'')
2022-10-23 14:31:22 +00:00
++ (optional (versionOlder cfg.package.version "25") (upgradeWarning 24 "22.11"))
++ (optional (versionOlder cfg.package.version "26") (upgradeWarning 25 "23.05"))
2023-12-13 00:07:10 +00:00
++ (optional (versionOlder cfg.package.version "27") (upgradeWarning 26 "23.11"))
++ (optional (versionOlder cfg.package.version "28") (upgradeWarning 27 "24.05"))
++ (optional (versionOlder cfg.package.version "29") (upgradeWarning 28 "24.11"));
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
services.nextcloud.package = with pkgs;
mkDefault (
if pkgs ? nextcloud
then throw ''
The `pkgs.nextcloud`-attribute has been removed. If it's supposed to be the default
nextcloud defined in an overlay, please set `services.nextcloud.package` to
`pkgs.nextcloud`.
''
2023-12-13 00:07:10 +00:00
else if versionOlder stateVersion "24.05" then nextcloud27
else nextcloud29
nixos/nextcloud: implement a safe upgrade-path between 19.09 and 20.03 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
2020-03-14 03:07:30 +00:00
);
services.nextcloud.phpPackage =
if versionOlder cfg.package.version "29" then pkgs.php82
else pkgs.php83;
services.nextcloud.phpOptions = mkMerge [
(mapAttrs (const mkOptionDefault) defaultPHPSettings)
{
upload_max_filesize = cfg.maxUploadSize;
post_max_size = cfg.maxUploadSize;
memory_limit = cfg.maxUploadSize;
}
(mkIf cfg.caching.apcu {
"apc.enable_cli" = "1";
})
];
}
{ assertions = [
{ assertion = cfg.database.createLocally -> cfg.config.dbpassFile == null;
message = ''
Using `services.nextcloud.database.createLocally` with database
password authentication is no longer supported.
If you use an external database (or want to use password auth for any
other reason), set `services.nextcloud.database.createLocally` to
`false`. The database won't be managed for you (use `services.mysql`
if you want to set it up).
If you want this module to manage your nextcloud database for you,
unset `services.nextcloud.config.dbpassFile` and
`services.nextcloud.config.dbhost` to use socket authentication
instead of password.
'';
}
]; }
2019-08-13 21:52:01 +00:00
{ systemd.timers.nextcloud-cron = {
wantedBy = [ "timers.target" ];
after = [ "nextcloud-setup.service" ];
2024-02-04 22:51:16 +00:00
timerConfig = {
OnBootSec = "5m";
OnUnitActiveSec = "5m";
Unit = "nextcloud-cron.service";
};
};
nixos/nextcloud: set up base directories & override.config.php with tmpfiles 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] fd9eb16b249aad1d5e231b8329035abfab5fc0eb [2] ca916e8cb3220ba43a43d10f72ccb4b88077a461
2024-01-12 19:27:58 +00:00
systemd.tmpfiles.rules = map (dir: "d ${dir} 0750 nextcloud nextcloud - -") [
"${cfg.home}"
"${datadir}/config"
"${datadir}/data"
"${cfg.home}/store-apps"
] ++ [
"L+ ${datadir}/config/override.config.php - - - - ${overrideConfig}"
];
systemd.services = {
# When upgrading the Nextcloud package, Nextcloud can report errors such as
# "The files of the app [all apps in /var/lib/nextcloud/apps] were not replaced correctly"
# Restarting phpfpm on Nextcloud package update fixes these issues (but this is a workaround).
nixos/nextcloud: set up base directories & override.config.php with tmpfiles 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] fd9eb16b249aad1d5e231b8329035abfab5fc0eb [2] ca916e8cb3220ba43a43d10f72ccb4b88077a461
2024-01-12 19:27:58 +00:00
phpfpm-nextcloud.restartTriggers = [ webroot overrideConfig ];
2019-08-13 21:52:01 +00:00
nextcloud-setup = let
c = cfg.config;
occInstallCmd = let
mkExport = { arg, value }: "export ${arg}=${value}";
dbpass = {
arg = "DBPASS";
value = if c.dbpassFile != null
then ''"$(<"${toString c.dbpassFile}")"''
else ''""'';
};
adminpass = {
arg = "ADMINPASS";
value = ''"$(<"${toString c.adminpassFile}")"'';
};
installFlags = concatStringsSep " \\\n "
(mapAttrsToList (k: v: "${k} ${toString v}") {
"--database" = ''"${c.dbtype}"'';
# The following attributes are optional depending on the type of
# database. Those that evaluate to null on the left hand side
# will be omitted.
${if c.dbname != null then "--database-name" else null} = ''"${c.dbname}"'';
${if c.dbhost != null then "--database-host" else null} = ''"${c.dbhost}"'';
${if c.dbuser != null then "--database-user" else null} = ''"${c.dbuser}"'';
"--database-pass" = "\"\$${dbpass.arg}\"";
"--admin-user" = ''"${c.adminuser}"'';
"--admin-pass" = "\"\$${adminpass.arg}\"";
"--data-dir" = ''"${datadir}/data"'';
});
in ''
${mkExport dbpass}
${mkExport adminpass}
${occ}/bin/nextcloud-occ maintenance:install \
${installFlags}
'';
occSetTrustedDomainsCmd = concatStringsSep "\n" (imap0
(i: v: ''
${occ}/bin/nextcloud-occ config:system:set trusted_domains \
${toString i} --value="${toString v}"
'') ([ cfg.hostName ] ++ cfg.settings.trusted_domains));
in {
wantedBy = [ "multi-user.target" ];
wants = [ "nextcloud-update-db.service" ];
before = [ "phpfpm-nextcloud.service" ];
after = optional mysqlLocal "mysql.service" ++ optional pgsqlLocal "postgresql.service";
requires = optional mysqlLocal "mysql.service" ++ optional pgsqlLocal "postgresql.service";
path = [ occ ];
nixos/nextcloud: set up base directories & override.config.php with tmpfiles 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] fd9eb16b249aad1d5e231b8329035abfab5fc0eb [2] ca916e8cb3220ba43a43d10f72ccb4b88077a461
2024-01-12 19:27:58 +00:00
restartTriggers = [ overrideConfig ];
script = ''
${optionalString (c.dbpassFile != null) ''
if [ ! -r "${c.dbpassFile}" ]; then
echo "dbpassFile ${c.dbpassFile} is not readable by nextcloud:nextcloud! Aborting..."
exit 1
fi
if [ -z "$(<${c.dbpassFile})" ]; then
echo "dbpassFile ${c.dbpassFile} is empty!"
exit 1
fi
''}
if [ ! -r "${c.adminpassFile}" ]; then
echo "adminpassFile ${c.adminpassFile} is not readable by nextcloud:nextcloud! Aborting..."
exit 1
fi
if [ -z "$(<${c.adminpassFile})" ]; then
echo "adminpassFile ${c.adminpassFile} is empty!"
exit 1
fi
${concatMapStrings (name: ''
if [ -d "${cfg.home}"/${name} ]; then
echo "Cleaning up ${name}; these are now bundled in the webroot store-path!"
rm -r "${cfg.home}"/${name}
fi
'') [ "nix-apps" "apps" ]}
# Do not install if already installed
if [[ ! -e ${datadir}/config/config.php ]]; then
${occInstallCmd}
fi
${occ}/bin/nextcloud-occ upgrade
${occ}/bin/nextcloud-occ config:system:delete trusted_domains
${optionalString (cfg.extraAppsEnable && cfg.extraApps != { }) ''
# Try to enable apps
${occ}/bin/nextcloud-occ app:enable ${concatStringsSep " " (attrNames cfg.extraApps)}
''}
${occSetTrustedDomainsCmd}
'';
serviceConfig.Type = "oneshot";
serviceConfig.User = "nextcloud";
# On Nextcloud ≥ 26, it is not necessary to patch the database files to prevent
# an automatic creation of the database user.
environment.NC_setup_create_db_user = lib.mkIf (nextcloudGreaterOrEqualThan "26") "false";
};
2019-08-13 21:52:01 +00:00
nextcloud-cron = {
after = [ "nextcloud-setup.service" ];
environment.NEXTCLOUD_CONFIG_DIR = "${datadir}/config";
2024-02-04 22:51:16 +00:00
serviceConfig = {
Type = "exec";
2024-02-04 22:51:16 +00:00
User = "nextcloud";
ExecCondition = "${phpCli} -f ${webroot}/occ status -e";
ExecStart = "${phpCli} -f ${webroot}/cron.php";
KillMode = "process";
2024-02-04 22:51:16 +00:00
};
};
2019-08-13 21:52:01 +00:00
nextcloud-update-plugins = mkIf cfg.autoUpdateApps.enable {
after = [ "nextcloud-setup.service" ];
2024-02-04 22:51:16 +00:00
serviceConfig = {
Type = "oneshot";
ExecStart = "${occ}/bin/nextcloud-occ app:update --all";
User = "nextcloud";
};
startAt = cfg.autoUpdateApps.startAt;
};
nextcloud-update-db = {
after = [ "nextcloud-setup.service" ];
environment.NEXTCLOUD_CONFIG_DIR = "${datadir}/config";
script = ''
${occ}/bin/nextcloud-occ db:add-missing-columns
${occ}/bin/nextcloud-occ db:add-missing-indices
${occ}/bin/nextcloud-occ db:add-missing-primary-keys
'';
serviceConfig = {
Type = "exec";
User = "nextcloud";
ExecCondition = "${phpCli} -f ${webroot}/occ status -e";
};
};
};
services.phpfpm = {
pools.nextcloud = {
user = "nextcloud";
group = "nextcloud";
phpPackage = phpPackage;
phpEnv = {
NEXTCLOUD_CONFIG_DIR = "${datadir}/config";
PATH = "/run/wrappers/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin:/usr/bin:/bin";
};
settings = mapAttrs (name: mkDefault) {
"listen.owner" = config.services.nginx.user;
"listen.group" = config.services.nginx.group;
2019-09-10 17:33:00 +00:00
} // cfg.poolSettings;
extraConfig = cfg.poolConfig;
};
};
users.users.nextcloud = {
home = "${cfg.home}";
group = "nextcloud";
isSystemUser = true;
};
users.groups.nextcloud.members = [ "nextcloud" config.services.nginx.user ];
environment.systemPackages = [ occ ];
services.mysql = lib.mkIf mysqlLocal {
enable = true;
package = lib.mkDefault pkgs.mariadb;
ensureDatabases = [ cfg.config.dbname ];
ensureUsers = [{
name = cfg.config.dbuser;
ensurePermissions = { "${cfg.config.dbname}.*" = "ALL PRIVILEGES"; };
}];
};
services.postgresql = mkIf pgsqlLocal {
enable = true;
ensureDatabases = [ cfg.config.dbname ];
ensureUsers = [{
name = cfg.config.dbuser;
nixos/postgresql: drop ensurePermissions, fix ensureUsers for postgresql15 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
2023-11-08 11:50:09 +00:00
ensureDBOwnership = true;
}];
};
services.redis.servers.nextcloud = lib.mkIf cfg.configureRedis {
enable = true;
user = "nextcloud";
};
services.nextcloud = {
caching.redis = lib.mkIf cfg.configureRedis true;
settings = mkMerge [({
datadirectory = lib.mkDefault "${datadir}/data";
trusted_domains = [ cfg.hostName ];
}) (lib.mkIf cfg.configureRedis {
"memcache.distributed" = ''\OC\Memcache\Redis'';
"memcache.locking" = ''\OC\Memcache\Redis'';
redis = {
host = config.services.redis.servers.nextcloud.unixSocket;
port = 0;
};
})];
};
services.nginx.enable = mkDefault true;
2021-07-08 14:43:27 +00:00
services.nginx.virtualHosts.${cfg.hostName} = {
root = webroot;
locations = {
"= /robots.txt" = {
priority = 100;
extraConfig = ''
allow all;
access_log off;
'';
};
"= /" = {
priority = 100;
extraConfig = ''
if ( $http_user_agent ~ ^DavClnt ) {
return 302 /remote.php/webdav/$is_args$args;
}
'';
};
"^~ /.well-known" = {
priority = 210;
extraConfig = ''
2021-02-16 16:58:38 +00:00
absolute_redirect off;
location = /.well-known/carddav {
return 301 /remote.php/dav/;
}
location = /.well-known/caldav {
return 301 /remote.php/dav/;
}
location ~ ^/\.well-known/(?!acme-challenge|pki-validation) {
return 301 /index.php$request_uri;
}
try_files $uri $uri/ =404;
'';
};
"~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)" = {
priority = 450;
extraConfig = ''
return 404;
'';
};
"~ ^/(?:\\.|autotest|occ|issue|indie|db_|console)" = {
priority = 450;
extraConfig = ''
return 404;
'';
};
"~ \\.php(?:$|/)" = {
priority = 500;
extraConfig = ''
# legacy support (i.e. static files and directories in cfg.package)
rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[s${optionalString (!ocmProviderIsNotAStaticDirAnymore) "m"}]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;
include ${config.services.nginx.package}/conf/fastcgi.conf;
fastcgi_split_path_info ^(.+?\.php)(\\/.*)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
fastcgi_param PATH_INFO $path_info;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param HTTPS ${if cfg.https then "on" else "off"};
fastcgi_param modHeadersAvailable true;
fastcgi_param front_controller_active true;
fastcgi_pass unix:${fpm.socket};
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
fastcgi_read_timeout ${builtins.toString cfg.fastcgiTimeout}s;
'';
};
"~ \\.(?:css|js|mjs|svg|gif|png|jpg|jpeg|ico|wasm|tflite|map|html|ttf|bcmap|mp4|webm|ogg|flac)$".extraConfig = ''
try_files $uri /index.php$request_uri;
expires 6M;
access_log off;
location ~ \.mjs$ {
default_type text/javascript;
}
location ~ \.wasm$ {
default_type application/wasm;
}
'';
"~ ^\\/(?:updater|ocs-provider${optionalString (!ocmProviderIsNotAStaticDirAnymore) "|ocm-provider"})(?:$|\\/)".extraConfig = ''
try_files $uri/ =404;
index index.php;
'';
"/remote" = {
priority = 1500;
extraConfig = ''
return 301 /remote.php$request_uri;
'';
};
"/" = {
priority = 1600;
extraConfig = ''
try_files $uri $uri/ /index.php$request_uri;
'';
};
};
extraConfig = ''
index index.php index.html /index.php$request_uri;
${optionalString (cfg.nginx.recommendedHttpHeaders) ''
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag "noindex, nofollow";
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header X-Frame-Options sameorigin;
add_header Referrer-Policy no-referrer;
''}
${optionalString (cfg.https) ''
add_header Strict-Transport-Security "max-age=${toString cfg.nginx.hstsMaxAge}; includeSubDomains" always;
''}
client_max_body_size ${cfg.maxUploadSize};
fastcgi_buffers 64 4K;
fastcgi_hide_header X-Powered-By;
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
${optionalString cfg.webfinger ''
rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
''}
'';
};
}
]);
meta.doc = ./nextcloud.md;
}