nixpkgs/nixos/tests/nextcloud
Maximilian Bosch 35b146ca31
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-11 14:45:46 +01:00
..
basic.nix nixos/nextcloud: fixup openssl compat change 2022-11-11 14:45:46 +01:00
default.nix nixos/nextcloud: fixup openssl compat change 2022-11-11 14:45:46 +01:00
openssl-sse.nix nixos/nextcloud: fixup openssl compat change 2022-11-11 14:45:46 +01:00
with-declarative-redis-and-secrets.nix
with-mysql-and-memcached.nix
with-postgresql-and-redis.nix