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.
* s/NextCloud/Nextcloud/g
* `enableBrokenCiphersForSSE` should be enabled by default for any NixOS
installation from before 22.11 to make sure existing installations
don't run into the issue. Not the other way round.
* Update release notes to reflect on that.
* Improve wording of the warning a bit: explain which option to change
to get rid of it.
* Ensure that basic tests w/o `enableBrokenCiphersForSSE` run with
OpenSSL 3.
in some circumstances, the setup service would fail with:
ERROR 1062 (23000) at line 5: Duplicate entry '1' for key 'PRIMARY'
so let's use an upsert instead of insert. This also simplifies the
script.
Besides, also fix that when the setup script changes, the corresponding
script is not restarted as it is usually not active, so we trigger a
restart of the main systemd service.
In ee0b8a7eaa we made the user service wait on network-online, but
forgot about the system service. We need them _both_ to wait when the
wifi source is enabled.
See the discussion below the original PR[1] and #197443 for more
context.
I guess I missed that upon review because the branch was too old and I
cherry-picked the commit onto my deployment branch which is based on
22.05. Sorry for that!
[1] https://github.com/NixOS/nixpkgs/pull/162784#issuecomment-1306848036
i based this on the neighboring lightdm-greeters/mini.nix module.
lightdm-mobile-greeter doesn't have a lot of configuration options.
it grabs the default user to login as from lightdm, along with which DE
it should launch. so no further configuration should be needed aside
from enabling `services.xserver.displayManager.lightdm.enable` and
either setting `services.xserver.displayManager.defaultSession` to the
appropriate session or explicitly defining a seat like:
```nix
services.xserver.displayManager.lightdm.extraSeatDefaults = ''
user-session = phosh
'';
```
Not a big deal in most of the cases because wordpress ensures that this
directory exists on its own, but with our twentig customizations that's
actually causing issues.
(cherry picked from commit 3285342bfe5f401dda84c13c834e73154928a61c)
It's a very useful backend (that probably should be enabled by default,
like on Ubuntu), let's start by making it easier to discover.
Ref https://github.com/NixOS/nixpkgs/issues/28406.
when a new peer is added, it does not modify any active units, because
the interface unit remains the same. therefore the new peer is not added
until next reboot or manual action.
Previously, dhcpcd and bitcoind starting up in parallel could lead to
the following error in bitcoind:
```
bitcoind: libevent: getaddrinfo: address family for nodename not supported
bitcoind: Binding RPC on address 127.0.0.1 port 8332 failed.
bitcoind: Unable to bind any endpoint for
```
After the initial failure, the bitcoind service would always restart successfully.
This race condition, where both applications were simultaneously
manipulating network resources, was only triggered under specific
hardware conditions.
Fix it by running bitcoind after dhcp has started (by running after
`network-online.target`).
This bug and the fix only affect the default NixOS scripted
networking backend.
