nixpkgs/nixos/tests/nextcloud/default.nix

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

30 lines
881 B
Nix
Raw Normal View History

2021-12-02 17:24:50 +00:00
{ system ? builtins.currentSystem
, config ? { }
, pkgs ? import ../../.. { inherit system config; }
}:
with pkgs.lib;
foldl
(matrix: ver: matrix // {
"basic${toString ver}" = import ./basic.nix { inherit system pkgs; nextcloudVersion = ver; };
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 11:05:24 +00:00
"openssl-sse${toString ver}" = import ./openssl-sse.nix {
inherit system pkgs;
nextcloudVersion = ver;
};
"with-postgresql-and-redis${toString ver}" = import ./with-postgresql-and-redis.nix {
inherit system pkgs;
nextcloudVersion = ver;
};
"with-mysql-and-memcached${toString ver}" = import ./with-mysql-and-memcached.nix {
inherit system pkgs;
nextcloudVersion = ver;
};
2022-07-05 22:08:29 +00:00
"with-declarative-redis-and-secrets${toString ver}" = import ./with-declarative-redis-and-secrets.nix {
inherit system pkgs;
nextcloudVersion = ver;
};
})
2021-12-02 17:24:50 +00:00
{ }
2023-06-14 11:59:43 +00:00
[ 25 26 27 ]