nixpkgs/nixos/tests/nextcloud/basic.nix

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

119 lines
4.4 KiB
Nix
Raw Normal View History

args@{ pkgs, nextcloudVersion ? 22, ... }:
(import ../make-test-python.nix ({ pkgs, ...}: let
adminpass = "notproduction";
adminuser = "root";
in {
name = "nextcloud-basic";
meta = with pkgs.lib.maintainers; {
maintainers = [ globin eqyiel ];
};
nodes = rec {
# The only thing the client needs to do is download a file.
client = { ... }: {
services.davfs2.enable = true;
system.activationScripts.davfs2-secrets = ''
echo "http://nextcloud/remote.php/dav/files/${adminuser} ${adminuser} ${adminpass}" > /tmp/davfs2-secrets
chmod 600 /tmp/davfs2-secrets
'';
virtualisation.fileSystems = {
"/mnt/dav" = {
device = "http://nextcloud/remote.php/dav/files/${adminuser}";
fsType = "davfs";
options = let
davfs2Conf = (pkgs.writeText "davfs2.conf" "secrets /tmp/davfs2-secrets");
in [ "conf=${davfs2Conf}" "x-systemd.automount" "noauto"];
};
};
};
nextcloud = { config, pkgs, ... }: let
cfg = config;
in {
networking.firewall.allowedTCPPorts = [ 80 ];
systemd.tmpfiles.rules = [
"d /var/lib/nextcloud-data 0750 nextcloud nginx - -"
];
services.nextcloud = {
enable = true;
datadir = "/var/lib/nextcloud-data";
hostName = "nextcloud";
database.createLocally = true;
config = {
# Don't inherit adminuser since "root" is supposed to be the default
adminpassFile = "${pkgs.writeText "adminpass" adminpass}"; # Don't try this at home!
dbtableprefix = "nixos_";
};
package = pkgs.${"nextcloud" + (toString nextcloudVersion)};
autoUpdateApps = {
enable = true;
startAt = "20:00";
};
phpExtraExtensions = all: [ all.bz2 ];
};
environment.systemPackages = [ cfg.services.nextcloud.occ ];
};
nextcloudWithoutMagick = args@{ config, pkgs, lib, ... }:
lib.mkMerge
[ (nextcloud args)
{ services.nextcloud.enableImagemagick = false; } ];
};
testScript = { nodes, ... }: let
withRcloneEnv = pkgs.writeScript "with-rclone-env" ''
#!${pkgs.runtimeShell}
export RCLONE_CONFIG_NEXTCLOUD_TYPE=webdav
export RCLONE_CONFIG_NEXTCLOUD_URL="http://nextcloud/remote.php/dav/files/${adminuser}"
export RCLONE_CONFIG_NEXTCLOUD_VENDOR="nextcloud"
export RCLONE_CONFIG_NEXTCLOUD_USER="${adminuser}"
export RCLONE_CONFIG_NEXTCLOUD_PASS="$(${pkgs.rclone}/bin/rclone obscure ${adminpass})"
"''${@}"
'';
copySharedFile = pkgs.writeScript "copy-shared-file" ''
#!${pkgs.runtimeShell}
echo 'hi' | ${withRcloneEnv} ${pkgs.rclone}/bin/rclone rcat nextcloud:test-shared-file
'';
diffSharedFile = pkgs.writeScript "diff-shared-file" ''
#!${pkgs.runtimeShell}
diff <(echo 'hi') <(${pkgs.rclone}/bin/rclone cat nextcloud:test-shared-file)
'';
findInClosure = what: drv: pkgs.runCommand "find-in-closure" { exportReferencesGraph = [ "graph" drv ]; inherit what; } ''
test -e graph
grep "$what" graph >$out || true
'';
nextcloudUsesImagick = findInClosure "imagick" nodes.nextcloud.system.build.vm;
nextcloudWithoutDoesntUseIt = findInClosure "imagick" nodes.nextcloudWithoutMagick.system.build.vm;
in ''
assert open("${nextcloudUsesImagick}").read() != ""
assert open("${nextcloudWithoutDoesntUseIt}").read() == ""
nextcloud.start()
client.start()
nextcloud.wait_for_unit("multi-user.target")
# This is just to ensure the nextcloud-occ program is working
nextcloud.succeed("nextcloud-occ status")
nextcloud.succeed("curl -sSf http://nextcloud/login")
nixos/nextcloud: fixup openssl compat change Upon testing the change itself I realized that it doesn't build properly because * the `pname` of a php extension is `php-<name>`, not `<name>`. * calling the extension `openssl-legacy` resulted in PHP trying to compile `ext/openssl-legacy` which broke since it doesn't exist: source root is php-8.1.12 setting SOURCE_DATE_EPOCH to timestamp 1666719000 of file php-8.1.12/win32/wsyslog.c patching sources cdToExtensionRootPhase /nix/store/48mnkga4kh84xyiqwzx8v7iv090i7z66-stdenv-linux/setup: line 1399: cd: ext/openssl-legacy: No such file or directory I didn't encounter that one before because I was mostly interested in having a sane behavior for everyone not using this "feature" and the documentation around this. My findings about the behavior with turning openssl1.1 on/off are still valid because I tested this on `master` with manually replacing `openssl` by `openssl_1_1` in `php-packages.nix`. To work around the issue I had to slightly modify the extension build-system for PHP: * The attribute `extensionName` is now relevant to determine the output paths (e.g. `lib/openssl.so`). This is not a behavioral change for existing extensions because then `extensionName==name`. However when specifying `extName` in `php-packages.nix` this value is overridden and it is made sure that the extension called `extName` NOT `name` (i.e. `openssl` vs `openssl-legacy`) is built and installed. The `name` still has to be kept to keep the legacy openssl available as `php.extensions.openssl-legacy`. Additionally I implemented a small VM test to check the behavior with server-side encryption: * For `stateVersion` below 22.11, OpenSSL 1.1 is used (in `basic.nix` it's checked that OpenSSL 3 is used). With that the "default" behavior of the module is checked. * It is ensured that the PHP interpreter for Nextcloud's php-fpm actually loads the correct openssl extension. * It is tested that (encrypted) files remain usable when (temporarily) installing OpenSSL3 (of course then they're not decryptable, but on a rollback that should still be possible). Finally, a few more documentation changes: * I also mentioned the issue in `nextcloud.xml` to make sure the issue is at least mentioned in the manual section about Nextcloud. Not too much detail here, but the relevant option `enableBrokenCiphersForSSE` is referenced. * I fixed a few minor wording issues to also give the full context (we're talking about Nextcloud; we're talking about the PHP extension **only**; please check if you really need this even though it's enabled by default). This is because I felt that sometimes it might be hard to understand what's going on when e.g. an eval-warning appears without telling where exactly it comes from.
2022-11-10 12:05:24 +01:00
# Ensure that no OpenSSL 1.1 is used.
nextcloud.succeed(
"${nodes.nextcloud.services.phpfpm.pools.nextcloud.phpPackage}/bin/php -i | grep 'OpenSSL Library Version' | awk -F'=>' '{ print $2 }' | awk '{ print $2 }' | grep -v 1.1"
)
nextcloud.succeed(
"${withRcloneEnv} ${copySharedFile}"
)
client.wait_for_unit("multi-user.target")
nextcloud.succeed("test -f /var/lib/nextcloud-data/data/root/files/test-shared-file")
client.succeed(
"${withRcloneEnv} ${diffSharedFile}"
)
assert "hi" in client.succeed("cat /mnt/dav/test-shared-file")
nixos/nextcloud: fixup openssl compat change Upon testing the change itself I realized that it doesn't build properly because * the `pname` of a php extension is `php-<name>`, not `<name>`. * calling the extension `openssl-legacy` resulted in PHP trying to compile `ext/openssl-legacy` which broke since it doesn't exist: source root is php-8.1.12 setting SOURCE_DATE_EPOCH to timestamp 1666719000 of file php-8.1.12/win32/wsyslog.c patching sources cdToExtensionRootPhase /nix/store/48mnkga4kh84xyiqwzx8v7iv090i7z66-stdenv-linux/setup: line 1399: cd: ext/openssl-legacy: No such file or directory I didn't encounter that one before because I was mostly interested in having a sane behavior for everyone not using this "feature" and the documentation around this. My findings about the behavior with turning openssl1.1 on/off are still valid because I tested this on `master` with manually replacing `openssl` by `openssl_1_1` in `php-packages.nix`. To work around the issue I had to slightly modify the extension build-system for PHP: * The attribute `extensionName` is now relevant to determine the output paths (e.g. `lib/openssl.so`). This is not a behavioral change for existing extensions because then `extensionName==name`. However when specifying `extName` in `php-packages.nix` this value is overridden and it is made sure that the extension called `extName` NOT `name` (i.e. `openssl` vs `openssl-legacy`) is built and installed. The `name` still has to be kept to keep the legacy openssl available as `php.extensions.openssl-legacy`. Additionally I implemented a small VM test to check the behavior with server-side encryption: * For `stateVersion` below 22.11, OpenSSL 1.1 is used (in `basic.nix` it's checked that OpenSSL 3 is used). With that the "default" behavior of the module is checked. * It is ensured that the PHP interpreter for Nextcloud's php-fpm actually loads the correct openssl extension. * It is tested that (encrypted) files remain usable when (temporarily) installing OpenSSL3 (of course then they're not decryptable, but on a rollback that should still be possible). Finally, a few more documentation changes: * I also mentioned the issue in `nextcloud.xml` to make sure the issue is at least mentioned in the manual section about Nextcloud. Not too much detail here, but the relevant option `enableBrokenCiphersForSSE` is referenced. * I fixed a few minor wording issues to also give the full context (we're talking about Nextcloud; we're talking about the PHP extension **only**; please check if you really need this even though it's enabled by default). This is because I felt that sometimes it might be hard to understand what's going on when e.g. an eval-warning appears without telling where exactly it comes from.
2022-11-10 12:05:24 +01:00
nextcloud.succeed("grep -vE '^HBEGIN:oc_encryption_module' /var/lib/nextcloud-data/data/root/files/test-shared-file")
'';
})) args