I went through all categories that were already present in the grafana
module and added most options from the official docs at
https://grafana.com/docs/grafana/v9.5/setup-grafana/configure-grafana/
I also modified the descriptions of some existing options to match the
official docs more closely.
* Ensure that the redis cache is actually used in the "trivial" case
(`with-postgresql-and-redis`)
* Test against all Nextcloud versions we've packaged
* Actually set a secret to make sure that the provided secret is
properly read by Nextcloud.
* Add myself as maintainer to the secret-test to make sure that I don't
miss any more changes like this that could break the functionality of
that feature.
By some miracle, before, it was possible to reconnect to the `node1` without
doing any relevant dance.
But now we are direct booting (¿), it seems like we need to do the right things.
This introduces a `check_output` flag for `execute` because we do not want to steal the
messages from the backdoor service as we might execute the kexec too fast compared
to when we will reconnect.
Therefore, we will let the message in the pipe if needed.
There's no reason to use a bootloader when testing kexec, this is a feature
that reboots *directly* in the kernel, if anything, we should just direct boot the
kernel and reboots in the kernel.
A bootloader test really makes sense to test "default" systemctl kexec behavior which is already broken
because systemctl kexec will read the ESP to determine what to kexec by default.
This change removes the bespoke logic around identifying block devices.
Instead of trying to find the right device by iterating over
`qemu.drives` and guessing the right partition number (e.g.
/dev/vda{1,2}), devices are now identified by persistent names provided
by udev in /dev/disk/by-*.
Before this change, the root device was formatted on demand in the
initrd. However, this makes it impossible to use filesystem identifiers
to identify devices. Now, the formatting step is performed before the VM
is started. Because some tests, however, rely on this behaviour, a
utility function to replace this behaviour in added in
/nixos/tests/common/auto-format-root-device.nix.
Devices that contain neither a partition table nor a filesystem are
identified by their hardware serial number which is injecetd via QEMU
(and is thus persistent and predictable). PCI paths are not a reliably
way to identify devices because their availability and numbering depends
on the QEMU machine type.
This change makes the module more robust against changes in QEMU and the
kernel (non-persistent device naming) and by decoupling abstractions
(i.e. rootDevice, bootPartition, and bootLoaderDevice) enables further
improvement down the line.
It's supposed to be `memcache.distributed`, not an associative PHP array
named `memcache` with a key `distributed`.
This was probably never caught because the initial `grep -q` check in
the test was invalid: `redis-cli` prints nothing if no keys can be found
when not writing to a tty apparently.
a zfs fileSystems entry with an absolute (e.g. device) path rather than
a zfs dataser is parsed as an empty pool name, causing a doomed-to-fail
import job to be created as a boot dependency. Catch this as an assertion
Lemmy checks the environment variable before the configuration file;
i.e. if the file is used to configure the database but the environment
variable is set to anything, the connection will fail because it'll
ignore the file. This was the previous behavior.
Now, the environment variable will be unset unless the user explicitly
chooses to set it, which makes the file-based configuration function
correctly. It's also possible to manually set the environment variable,
which has the major advantage of working around [this issue][0], which
prevents certain setups from working.
[0]: https://github.com/LemmyNet/lemmy/issues/2945
This option conditionally adds the `CAP_NET_RAW` capability to the service,
which is mandatory for enabling the integrated DHCP server.
It also adds another test case to validate that the DHCP server successfully
provides IP addresses to clients.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
keter 2.1 now can log to stderr instead of file rotation.
Which is faster and more reliable.
These changes support that.
Announcement:
https://discourse.haskell.org/t/keter-2-1-0-released/6134
fix test by disabling log rotation
run nixpkgs fmt
move comment right before L37
run nixpkgs format on test
Add overridable default configuration
depracate keterRoot and use root, same for package
split doc lines
use lib.getExe to get keter binary
put mkRenamedOptionModule on one line
they're no longer necessary for us and will almost definitely start to
rot now (like commonmark and asciidoc outputs did previously). most
existing users seem to take the docbook output and run it through pandoc
to generate html, those can easily migrate to use commonmark instead.
other users will hopefully pipe up when they notice that things they rely
on are going away.
optionsUsedDocbook has only been around for one release and only exposed
to allow other places to generate warnings, so that does not deserve
such precautions.
with everything being rendered from markdown now we no longer need to
postprocess any options.xml that may be requested from elsewhere. we'll
don't need to keep the module path check either since that's done by
optionsJSON now.
docbook is now gone and we can flip the defaults. we won't keep the
command line args around (unlike the make-options-docs argument) because
nixos-render-docs should not be considered an exposed API.
with docbook no longer supported we can default to markdown option docs.
we'll keep the parameter around for a bit to not break external users
who set it to true. we don't know of any users that do, so the
deprecation period may be rather short for this one.
it's been long in the making, and with 23.05 out we can finally disable
docbook option docs and default to markdown instead. this brings a
massive speed boost in manual and manpage builds, so much so that we may
consider enabling user module documentation by default.
we don't remove the docbook support code entirely yet because it's a lot
all over, and probably better removed in multiple separate changes.
