The `sparseCheckout` argument allows the user to specify directories or
patterns of files, which Git uses to filter files it should check-out.
Git expects a multi-line string on stdin ("newline-delimited list", see
`git-sparse-checkout(1)`), but within nixpkgs it is more consistent to
use a list of strings instead. The list elements are joined to a
multi-line string only before passing it to the builder script.
A deprecation warning is emitted if a (multi-line) string is passed to
`sparseCheckout`, but for the time being it is still accepted.
Relative paths are interpreted relative to the working directory, which
is currently unset and thus defaults to `/`. However we want to change
the working directory in a future release such that relative paths are
interpreted relative to `/var/lib/syncthing`.
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.
Allow building other than Legacy-BIOS-only Proxmox images.
Default is unchanged.
To build UEFI proxmox image use:
proxmox.qemuConf.bios = "ovmf";
(default is "seabios")
To build image bootable using both "seabios" and "ovmf" use:
partitionTableType = "hybrid";
BIOS can be switched in Proxmox between "seabios" and "ovmf" and VM still boots.
(GRUB2-only, systemd-boot does not boot under "seabios")
To build systemd-boot UEFI image:
proxmox.qemuConf.bios = "ovmf";
boot.loader.systemd-boot.enable = true;
Support will be dropped on 01 Jan 2023[1]. Normally we'd keep it around
until then, but considering that it's an LTS kernel it may be better to
do it before 22.11 to make sure there are no unpleasant surprises.
Closes#199933
[1] https://endoflife.date/linux
Percona Server for MySQL 5.6 is no more maintained due to the EOL of MySQL 5.6.
See https://www.percona.com/downloads/Percona-Server-5.6/LATEST/.
A bit hard to list all the potential security issues affecting it but CVE-2021-27928
should be one of them.
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>
- Previously PolyMC's removal was counted as a release highlight
- It probably shouldn't be, as it's more a notable change rather than a
highlight
- Thanks @Ma27 for noticing this
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.
