This fixes using coderepos in /home, by allowing the coderepo paths to
be bind mounted into an otherwise empty /home tmpfs. Since this was
the usecase for making ProtectHome= overrideable, we don't need the
mkDefault any more.
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.
The output from `systemd-analyze security davmail`:
Before: `Overall exposure level for davmail.service: 8.2 EXPOSED 🙁`
After: `Overall exposure level for davmail.service: 1.3 OK 🙂`
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.
- `wait_until_fails` was not passing through its `timeout` argument to
the internal `retry` function, hence was always using 900 seconds (the
default timeout for `retry`) rather than the user-specified value.
epub manuals are holding back the transition away from docbook, and
cursory research does not suggest that they are used very much. it's
still very early in the 23.11 release cycle, so if we're going to find
out just how many people do use the epub manuals it should be now.
this need not be the end of epub manuals. nixos-render-docs could be
extended to also export epubs, but that has not been done yet since it's
going to be some effort with unknown real-world usefulness.
Test for presence of all specified options in the generated .nspawn
config file.
Additionally test for absence of misspelled and fixed option MachineID.
The nixos/caddy module is somewhat old by now
and has undergone quite some refactors.
This specific module option (originally named
`ca`) used to make a bit more sense when
Caddy did not have multiple ACME CAs as
fallback (LE & ZeroSSL) by configured by
default yet (ZeroSSL came with v2.3.0).
I also rephrased the description slightly,
to mention Caddy's automatic issuer fallback
and a note which this option maps to in the
Caddyfile, to provide a bit more context and
a more up-to-date recommendation.
Specifically that "fine-grained configuration"
section comes from a time when this module did
some custom tls/issuer config json merging
with the templated Caddyfile using `jq`.
The "The URL to the ACME CA's directory"
section is a word-for-word copy from the
official Caddy docs, which also include a link
to LE's docs to the referenced staging
endpoint. So I added that as well.
Since ddclient@24ba945 (v3.10.0), the type and meaning of the "ipv6"
option has changed. This resulted in the following warning when
starting the service:
WARNING: file /run/ddclient/ddclient.conf, line 13:
Invalid Value for keyword 'ipv6' = 'no'
This therefore removes the matching boolean option.
More advanced configurations can use the "extraConfig" option instead.
As with many things, we have scenarios where we don't want to boot on a
disk / bootloader and also we don't want to boot directly.
Sometimes, we want to boot through an OptionROM of our NIC, e.g. netboot
scenarios or let the firmware decide something, e.g. UEFI PXE (or even
UEFI OptionROM!).
This is composed of:
- `directBoot.enable`: whether to direct boot or not
- `directBoot.initrd`: enable overriding the
`config.system.build.initialRamdisk` defaults, useful for
netbootRamdisk for example.
This makes it possible.
This is necessary because this test relies on switching the root fs to an empty one which
does not have a Nix store available in stage 1, therefore, we have to make this test
host-store only.
A better fix in the long term is to evaluate whether this is worth to enable a proper
Nix store image for it with EROFS?
This essentially backports
https://github.com/systemd/systemd/pull/27791. `systemd-networkd.service`
is sent the `SIGTERM` signal, but it is not required to be stopped
before `initrd-switch-root.target` is reached, despite the use of
`systemctl isolate initrd-switch-root.target`. This is because when
there is no ordering at all between two units, and a transaction stops
one and starts the other, the two operations can happen
simultaneously. This means the service could still be running when
`switch-root` actually occurs. Then, stage 2 systemd will see the
service still running and decide it doesn't need to add a start
operation for it to its initial transaction. Finally, the service
exits, but only after it's already too late. If, however, there is any
ordering at all between a stopping unit and a starting unit, then the
stop operation will be done first. This way, we ensure that the
service is properly exited before doing `switch-root`.
This is something to keep in mind going forward. There may be other
services that need this treatment. These `before` and `conflicts`
definitions are the correct way to ensure a unit is actually stopped
before you reach initrd-switch-root
