This creates and opens a luks volume, puts its passphrase into a keyfile
and writes a /etc/crypttab. It then reboots the machine, and verifies
systemd parsed /etc/crypttab properly, and was able to unlock the volume
with the keyfile provided (as we try to mount it).
The memorySize of the VM had to be bumped, as luksFormat would otherwise
run out of memory.
Cookie jar can be used to accurately test if the login was successful.
Simply searching for the user name is not sufficient, since it is always
part of the returned page after login. The page should display a phrase
containing the username after login.
This was omitted in the latest update.
Only adds ~400 KB.
It required adding openssl to tests so I tacked on some cleanups.
In particular, the GI_TYPELIB_PATH was already being set in the wrapper
so we can remove it from the module (not sure why Gtk was even there).
Also switched away from using pkgconfig and docbook_xsl aliases
and reordered the expression a bit.
Not strictly an upgrade, but adds a new mongodb-4_2 target with the
current mongodb from that branch.
Use matching client and server versions in mongodb tests- tests were
using the mongo 3.4 client to connect, and this finally doesn't work
with server 4.2.
Per reviewer suggestion, adding myself as cheetah3 maintainer.
Additionally, reestore comments describing the purpose of the
build-dependencies patch
Along with the `socat` fix in the parent commit, this makes
the Flatpak’s installed tests finally pass again.
The tests seem to need slightly over 2G of disk space,
and it appears that the test suite was ported to Python 3 in 1.5.1:
2b6641575d
Flatpak’s installed tests build Flatpak runtimes, among other things.
Upstream code does this by copying some programs on `PATH`
as well as some possible dependencies from host’s /usr.
We patch the code to use `nix-store --query --requisites`
to make the dependency discovery easier.
The Flatpak’s installed tests add `socat` to `PATH` and later run
`nix-store --query --requisites` on its location but it was failing with
error: path '/nix/store/qcyf7nq5vvfw32967sv4j6z190inrbrc-socat-1.7.3.4' is not valid
The issue occurred because, while the host Nix store is bind mounted into the test VM,
the VM’s store uses its own database that only contains the packages in the VM’s closure.
Since the test commands are not actually part of the VM but only passed through PTY,
the `flatpak.installedTests` derivation was not part of the VM’s closure, so `nix-store`
in the VM could not get information about its dependency `socat`.
Let’s make the `installedTests` of the tested package part of the test VM’s closure
by passing it as a global environment variable. This will also have the added benefit
that user no longer has to type the path when running the installed tests manually in the VM;
they can just use `gnome-desktop-testing-runner -d $TESTED_PACKAGE_INSTALLED_TESTS`,
which is much more conducive to tab completion.
This modifies the `router` to not give out a range of IP addresses but
only give out a fixed address based on the MAC address using the
`services.dhcpd4.machines` option.
To get access to the MAC address the `qemuNicMac` function is defined
and exported from `qemu-flags.nix`.
Also, add some sleep statements in between, which seems to at least feel
like it causes
> WARNING: Device /dev/vda* not initialized in udev database even after waiting 10000000 microseconds.
To occur less frequently.
This eventually still succeeds after some amount of waiting, I suspect
some racyness in the way lvm's udev-triggered scripts trigger other
units.
This is required by (among others) Podman to run containers in rootless mode.
Other distributions such as Fedora and Ubuntu already set up these mappings.
The scheme with a start UID/GID offset starting at 100000 and increasing in 65536 increments is copied from Fedora.
The image tag can be specified or generated from the output hash.
Previously, a generated tag could be recovered from the evaluated
image with some string operations.
However, with the introduction of streamLayeredImage, it's not
feasible to compute the generated tag yourself.
With this change, the imageTag attribute is set unconditionally,
for the buildImage, buildLayeredImage, streamLayeredImage functions.
This permits using method_set_hostname but still denies
method_set_static_hostname. As a result DHCP clients can now always set
the transient hostname via the SetHostname method of the D-Bus interface
of systemd-hostnamed (org.freedesktop.hostname1.set-hostname).
If the NixOS option networking.hostName is set to an empty string (or
"localhost") the static hostname (kernel.hostname but NOT /etc/hostname)
will additionally be updated (this is intended).
From "man hostnamectl": The transient hostname is a fallback value
received from network configuration. If a static hostname is set, and is
valid (something other than localhost), then the transient hostname is
not used.
Fix#74847.
Note: It's possible to restrict access to the org.freedesktop.hostname1
interface using Polkit rules.
nixos/tests/initrd-openvpn: Add test for openvpn in the initramfs
The module in this commit adds new options that allows the
integration of an OpenVPN client into the initrd.
This can be used e.g. to remotely unlock LUKS devices.
This commit also adds two tests for `boot.initrd.network.openvpn`.
The first one is a basic test to validate that a failing connection
does not prevent the machine from booting.
The second test validates that this module actually creates a valid
openvpn connection.
For this, it spawns three nodes:
- The client that uses boot.initrd.network.openvpn
- An OpenVPN server that acts as gateway and forwards a port
to the client
- A node that is external to the OpenVPN network
The client connects to the OpenVPN server and spawns a netcat instance
that echos a value to every client.
Afterwards, the external node checks if it receives this value over the
forwarded port on the OpenVPN gateway.
test failed because gnutls-cli does not properly report connection
errors any more, fixed by increasing the debug level for gnutls-cli
Fixes: #84507Closes: #90718
This option exposes the prefconfigured nextcloud-occ
program. nextcloud-occ can then be used in other systemd services or
added in environment.systemPackages.
The nextcloud test shows how it can be add in
environment.systemPackages.
Done by setting `autopilot.min_quorum = 3`.
Techncially, this would have been required to keep the test correct since
Consul's "autopilot" "Dead Server Cleanup" was enabled by default (I believe
that was in Consul 0.8). Practically, the issue only occurred with our NixOS
test with releases >= `1.7.0-beta2` (see #90613). The setting itself is
available since Consul 1.6.2.
However, this setting was not documented clearly enough for anybody to notice,
and only the upstream issue https://github.com/hashicorp/consul/issues/8118
I filed brought that to light.
As explained there, the test could also have been made pass by applying the
more correct rolling reboot procedure
-m.wait_until_succeeds("[ $(consul members | grep -o alive | wc -l) == 5 ]")
+m.wait_until_succeeds(
+ "[ $(consul operator raft list-peers | grep true | wc -l) == 3 ]"
+)
but we also intend to test that Consul can regain consensus even if
the quorum gets temporarily broken.
The systemd socket unit files now more precisely track the IPFS
configuration, by including any multaddr they can make a `ListenStream`
for. (The daemon doesn't currently support anything which would use
`ListDatagram`, so we don't need to worry about that.)
The tests use some of these features.
Reads a bit more naturally, and now the changes to the
acme-${cert}.service actually reflect what would be needed were you to
do the same in production.
e.g. "for dns-01, your service that needs the cert needs to pull in the
cert"
Refactor the systemd service definition for the haproxy reverse proxy,
using the upstream systemd service definition. This allows the service
to be reloaded on changes, preserving existing server state, and adds
some hardening options.
NixOS currently has issues with setting the FQDN of a system in a way
where standard tools work. In order to help with experimentation and
avoid regressions, add a test that checks that the hostname is
reported as the user wanted it to be.
Co-authored-by: Michael Weiss <dev.primeos@gmail.com>
Favor the configuration in "configFile" over "config" to allow
"configFile" to override "config" without a system rebuild.
Add a "persistentKeys" option to generate keys and addresses that
persist across service restarts. This is useful for self-configuring
boot media.
This adds a simple test running GNU Hello cross-compiled for armv7l and
aarch64 inside a x86_64 VM with configured binfmt.
We already build the cross toolchains in other invocations, and building
hello itself is small.
This test is sometimes flaky on hydra as at the time of the `git clone`
the network isn't really configured yet[1]. That problem doesn't seem to
occur locally but if you run it on a machine with high enough load (such
as hydra build machines). Hopefully this will make the test not flaky
anymore.
[1] https://hydra.nixos.org/build/118710378/nixlog/21/raw
This seems to have worked in 15f105d41f (5
months ago) but broke somewhere in the meantime.
The current module doesn't seem to be underdocumented and might need a
serious refactor. It requires quite some hacks to get it to work (see
https://github.com/NixOS/nixpkgs/issues/86305#issuecomment-621129942),
or how the ldap.nix test used systemd.services.openldap.preStart and
made quite some assumptions on internals.
Mic92 agreed on being added as a maintainer for the module, as he uses
it a lot and can possibly fix eventual breakages. For the most basic
startup breakages, the remaining openldap.nix test might suffice.
`doas` is a lighter alternative to `sudo` that "provide[s] 95% of the
features of `sudo` with a fraction of the codebase" [1]. I prefer it to
`sudo`, so I figured I would add a NixOS module in order for it to be
easier to use. The module is based off of the existing `sudo` module.
[1] https://github.com/Duncaen/OpenDoas
This is a follow-up to the PR #82026 that contains the promised tests.
In this test I am testing if we can properly propagate prefixes received
via DHCPv6 PD with the networkd options in our module system.
The comments in the test should be sufficient to follow the idea and
what is going on.
Setting up a XMPP chat server is a pretty deep rabbit whole to jump in
when you're not familiar with this whole universe. Your experience
with this environment will greatly depends on whether or not your
server implements the right set of XEPs.
To tackle this problem, the XMPP community came with the idea of
creating a meta-XEP in charge of listing the desirable XEPs to comply
with. This meta-XMP is issued every year under an new XEP number. The
2020 one being XEP-0423[1].
This prosody nixos module refactoring makes complying with XEP-0423
easier. All the necessary extensions are enabled by default. For some
extensions (MUC and HTTP_UPLOAD), we need some input from the user and
cannot provide a sensible default nixpkgs-wide. For those, we guide
the user using a couple of assertions explaining the remaining manual
steps to perform.
We took advantage of this substential refactoring to refresh the
associated nixos test.
Changelog:
- Update the prosody package to provide the necessary community
modules in order to comply with XEP-0423. This is a tradeoff, as
depending on their configuration, the user might end up not using them
and wasting some disk space. That being said, adding those will
allow the XEP-0423 users, which I expect to be the majority of
users, to leverage a bit more the binary cache.
- Add a muc submodule populated with the prosody muc defaults.
- Add a http_upload submodule in charge of setting up a basic http
server handling the user uploads. This submodule is in is
spinning up an HTTP(s) server in charge of receiving and serving the
user's attachments.
- Advertise both the MUCs and the http_upload endpoints using mod disco.
- Use the slixmpp library in place of the now defunct sleekxmpp for
the prosody NixOS test.
- Update the nixos test to setup and test the MUC and http upload
features.
- Add a couple of assertions triggered if the setup is not xep-0423
compliant.
[1] https://xmpp.org/extensions/xep-0423.html
When testing WireGuard updates, I usually run the VM-tests with
different kernels to make sure we're not introducing accidental
regressions for e.g. older kernels.
I figured that we should automate this process to ensure continuously
that WireGuard works fine on several kernels.
For now I decided to test the latest LTS version (5.4) and
the latest kernel (currently 5.6). We can add more kernels in the
future, however this seems to significantly slow down evaluation and
time.
The list can be customized by running a command like this:
nix-build nixos/tests/wireguard --arg kernelVersionsToTest '["4.19"]'
The `kernelPackages` argument in the tests is null by default to make
sure that it's still possible to invoke the test-files directly. In that
case the default kernel of NixOS (currently 5.4) is used.
