This commit fixes broken non-declarative configs by
making the assertions more relaxed.
It also allows to remove the forced configuration merge by making
`settings` `null`able (now the default).
Both cases (trivial non-declarative config and `null`able config) are
verified with additional tests.
Fixes#198665
fscrypt can automatically unlock directories with the user's login
password. To do this it ships a PAM module which reads the user's
password and loads the respective keys into the user's kernel keyring.
Significant inspiration was taken from the ecryptfs implementation.
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.
Previously we did socket-activation but this breaks the autostart
feature since upstream expects libvirtd to be started unconditionally on
boot.
Fixes#171623.
* 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.
I need to fix copying the chrome://gpu content to the clipboard (Ctrl+a doesn't
work anymore so we have to click the button) but we can at least test the font
rendering for now.
This is a small smoke test of each piece (setuid, setgid, caps) of
wrappers' functionality. It doesn't try to check for combinations of
functionalities or anything more complicated.
The new defaults allows jenkins-job-builder to reload the configuration
out-of-the-box, whereas the previous defaults required users to manually
reload/restart jenkins, or configure accessUser/accessTokenFile
themselves.
(If `extraJavaOptions = [ "-Djenkins.install.runSetupWizard=false" ]`
then the initial admin user is *not* created and you have to use JCasC
or something else to bootstrap.)
This corrects the multi-node test after a couple recent changes which
resulted in it being broken.
The `lib.toString` change was an incorrect tree-wide refactor, and the
aarch64 change also introduced an error in python indentation/formatting
I believe.
- Fix hostname configuration on proxmox, which uses "hostname" in user-data
instead of "local-hostname" in meta-data.
- Allow setting resolv.conf through cloud-init
- Add tests for new changes
- Add timeouts to make tests fail faster
This will add `passthru.schema_version` to be used as default value for
the adguardhome module.
It will also update the `update.sh` to keep the `schema_version` in sync
with the version by inspecting the sourcecode.
This might break existing configs, if they use deprecated values that don't
appear in newer schema_versions and schema_version wasn't set explicitly.
Explicit declarations of schema_version always have higher priority.
This also removes the `host` and `config` settings in favour of using the
appropriate `settings`.
Fixes#173938
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
I haven't had time to look into this yet but it looks like opening chrome://gpu
doesn't work anymore without proper GPU rendering (we use software rendering
due to the virtualisation).
According to the console output the new window never opens (at least with
Google Chrome - I couldn't test it with Chromium yet due to the failing builds
for M107 and M108):
```
(finished: sending keys ‘chrome://gpu
‘, in 0.14 seconds)
machine: waiting for a window to appear
machine: must succeed: xwininfo -root -tree | sed 's/.*0x[0-9a-f]* \"\([^\"]*\)\".*/\1/; t; d'
(finished: must succeed: xwininfo -root -tree | sed 's/.*0x[0-9a-f]* \"\([^\"]*\)\".*/\1/; t; d', in 0.05 seconds)
machine # Error: eglChooseConfig returned zero configs
machine # at Create (../../third_party/dawn/src/dawn/native/opengl/ContextEGL.cpp:53)
machine #
machine: must succeed: xwininfo -root -tree | sed 's/.*0x[0-9a-f]* \"\([^\"]*\)\".*/\1/; t; d'
machine # WARNING: lavapipe is not a conformant vulkan implementation, testing use only.
(finished: must succeed: xwininfo -root -tree | sed 's/.*0x[0-9a-f]* \"\([^\"]*\)\".*/\1/; t; d', in 0.06 seconds)
machine: must succeed: xwininfo -root -tree | sed 's/.*0x[0-9a-f]* \"\([^\"]*\)\".*/\1/; t; d'
(finished: must succeed: xwininfo -root -tree | sed 's/.*0x[0-9a-f]* \"\([^\"]*\)\".*/\1/; t; d', in 0.09 seconds)
[...]
```
The meta attribute "timeout" is only set for Chromium (might still be required
due to the long build duration). The Google Chrome tests were failing with:
error: attribute 'timeout' missing
According to nixos/lib/testing/meta.nix "null values are filtered out by
`meta`" so `timeout = chromiumPkg.meta.timeout or null` might be fine as
well.
This commit refactors `services.grafana.provision.datasources` towards
the RFC42 style. To preserve backwards compatibility, we have to jump
through a ton of hoops, introducing esoteric type signatures and bizarre
structs. The Grafana module definition should hopefully become a lot
cleaner after a release cycle or two once the old configuration style is
completely deprecated.
This commit refactors `services.grafana.provision.dashboards` towards
the RFC42 style. To preserve backwards compatibility, we have to jump
through a ton of hoops, introducing esoteric type signatures and bizarre
structs. The Grafana module definition should hopefully become a lot
cleaner after a release cycle or two once the old configuration style is
completely deprecated.
This will remove all state directories related to CUPS on startup, which
is particularly useful for guaranteeing that printer discovery works
more reliably on some networks, since CUPS will no longer be able to
store state that effects the next run of the service, such as old
printer names and mDNS information.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
