In version 2.0.15 `gotify` switched to `packr` at 2.x which is why the
UI can't be served properly via HTTP and causes an empty 500 response and
the following errors in `journald`:
```
2020/09/12 19:18:33 [Recovery] 2020/09/12 - 19:18:33 panic recovered:
GET / HTTP/1.1
Host: localhost:8080
Accept: */*
User-Agent: curl/7.72.0
stat /home/ma27/Projects/ui/build/index.html: no such file or directory
```
This wasn't caught by the VM-test as it only tested the REST and push
APIs. Using their internal `packr.go` script in our build as it's the
case in the upstream build-system[1] fixes the issue.
[1] https://github.com/gotify/server/pull/277/files#diff-b67911656ef5d18c4ae36cb6741b7965R48
This commit fixes the ejabberd tests for hydra:
mod_http_upload and mod_disco need to be explicitly enabled, and a
handler needs to be setup to make it work. Also, the client needs to be
able to contact the server.
The commit also fixes the situation where http upload failed: in that
case the client would wait forever because nothing catched the error.
Finally, there remains a non-reproducible error where ejabberd server
fails to start with an error like:
format: "Failed to create cookie file '/var/lib/ejabberd/.erlang.cookie': eacces"
(happens ~15%) I tried to check existence of /var/lib/ejabberd/ in
pre-start script and saw nothing that would explain this error, so I
gave up about this error in particular.
We apparently didn't fit anymore. I don't think this test is meant
to (also) check closure size.
Note: as of this commit, the test is blocked by a fontconfig problem,
so I tested with that merge temporarily reverted.
Attempting to reuse keys on a basis different to the cert (AKA,
storing the key in a directory with a hashed name different to
the cert it is associated with) was ineffective since when
"lego run" is used it will ALWAYS generate a new key. This causes
issues when you revert changes since your "reused" key will not
be the one associated with the old cert. As such, I tore out the
whole keyDir implementation.
As for the race condition, checking the mtime of the cert file
was not sufficient to detect changes. In testing, selfsigned
and full certs could be generated/installed within 1 second of
each other. cmp is now used instead.
Also, I removed the nginx/httpd reload waiters in favour of
simple retry logic for the curl-based tests
The cyclic dependency of systemd → cryptsetup → lvm2 → udev=systemd
needs to be broken somewhere. The previous strategy of building
cryptsetup with an lvm2 built without udev (#66856) caused the
installer.luksroot test to fail. Instead, build lvm2 with a udev built
without cryptsetup.
Fixes#96479.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Testing of certs failed randomly when the web server was still
returning old certs even after the reload was "complete". This was
because the reload commands send process signals and do not wait
for the worker processes to restart. This commit adds log watchers
which wait for the worker processes to be restarted.
- Use an acme user and group, allow group override only
- Use hashes to determine when certs actually need to regenerate
- Avoid running lego more than necessary
- Harden permissions
- Support "systemctl clean" for cert regeneration
- Support reuse of keys between some configuration changes
- Permissions fix services solves for previously root owned certs
- Add a note about multiple account creation and emails
- Migrate extraDomains to a list
- Deprecate user option
- Use minica for self-signed certs
- Rewrite all tests
I thought of a few more cases where things may go wrong,
and added tests to cover them. In particular, the web server
reload services were depending on the target - which stays alive,
meaning that the renewal timer wouldn't be triggering a reload
and old certs would stay on the web servers.
I encountered some problems ensuring that the reload took place
without accidently triggering it as part of the test. The sync
commands I added ended up being essential and I'm not sure why,
it seems like either node.succeed ends too early or there's an
oddity of the vm's filesystem I'm not aware of.
- Fix duplicate systemd rules on reload services
Since useACMEHost is not unique to every vhost, if one cert
was reused many times it would create duplicate entries in
${server}-config-reload.service for wants, before and
ConditionPathExists
The original idea for this test was, on top of providing a networkd
test, to provide newcomers with a sample configuration they could use
to get started with networkd.
That's precisely why we were doing this systemd tmpfile dance in the
first place. It was a convenient way to create a runtime file with a
specific mode and owner.
Sadly, this tmpfile rule made the test flaky. There's a race condition
between the wireguard interface configured by systemd-networkd and
systemd-tmpfiles-setup.
Sometimes, networkd is going to try loading the wireguard private key
file *before* the said file gets created by systemd-tmpfiles.
A perfect solution here would be to create a "After" dependency
between wg0.netdev and systemd-tmpfiles-setup.service. Sadly, it is
currently impossible to create such a dependency between a
networkd-specific unit and a service.
We're removing this tmp file in favor of pointing networkd directly to
the Nix store. This is clearly something that shouldn't be done in the
real world for a private file: the store is world-readable. However,
this is the only way I found to fix this test flakiness for now.
In `systemd-243` the option `FwMark` in the `[WireGuard]` section of
a `.netdev`-unit has been renamed to `FirewallMark`[1]. Due to the
removal of deprecated options in our `networkd` module[2] the evaluation
of this test doesn't work.
Renaming the option to its new name fixes the issue.
[1] 1c30b174ed
[2] e9d13d3751
... and remove some weirdnesses.
- Port to Python
- Drop the extra pkgs, config, system args
- Drop all `with`
- Don't override the standard PostgreSQL directory
- Use pkgs and lib from the test runner
Tested with:
- postgresql_12
- postgresql_11
- postgresql_10
- postgresql_9_6
- postgresql_9_5
Closes#96347
cc @flokli
According to RFC4291[1], 2001:db8:: is the anycast address for the
prefix and will be answered by all routers responsible for this prefix.
This means that before the iputils bump, the ping from client to isp was
answered by the router and not by the ISP machine. Switching away from
the anycast address fixes this issue.
Credits for finding this go to @primeos.
[1]: https://tools.ietf.org/html/rfc4291#section-2.6.1Fixes#96188
This test wants to download things from the internet while building the
system. It can probably be fixed by ensuring these paths are present in
the initial nix-store.
This appears to avoid requiring KVM when it’s not available. This is
what I originally though -cpu host did. Unfortunately not much
documentation available from the QEMU side on this, but this appears
to square with help:
$ qemu-system-x86 -cpu help
...
x86 host KVM processor with all supported host features
x86 max Enables all features supported by the accelerator in the current host
...
Whether we actually want to support this not clear, since this only
happens when your CPU doesn’t have full KVM support. Some Nix builders
are lying about kvm support though. Things aren’t too slow without it
though.
Fixes https://github.com/NixOS/nixpkgs/issues/85394
Alternative to https://github.com/NixOS/nixpkgs/pull/83920
Related to #72828
Replaces and closes#76708
Looks like `nix ping-store` does not output anything anymore but still
fails when the connection does not work.
Since systemd 243, docs were already steering users towards using
`journal`:
eedaf7f322
systemd 246 will go one step further, it shows warnings for these units
during bootup, and will [automatically convert these occurences to
`journal`](f3dc6af20f):
> [ 6.955976] systemd[1]: /nix/store/hwyfgbwg804vmr92fxc1vkmqfq2k9s17-unit-display-manager.service/display-manager.service:27: Standard output type syslog is obsolete, automatically updating to journal. Please update│······················
your unit file, and consider removing the setting altogether.
So there's no point of keeping `syslog` here, and it's probably a better
idea to just not set it, due to:
> This setting defaults to the value set with DefaultStandardOutput= in
> systemd-system.conf(5), which defaults to journal.
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.
The elasticsearch-curator was not deleting indices because the indices
had ILM policies associated with them. This is now fixed by
configuring the elasticsearch-curator with `allow_ilm_indices: true`.
Also see: https://github.com/elastic/curator/issues/1490
Enables multi-site configurations.
This break compatibility with prior configurations that expect options
for a single dokuwiki instance in `services.dokuwiki`.
Shimming out the Let's Encrypt domain name to reuse client configuration
doesn't work properly (Pebble uses different endpoint URL formats), is
recommended against by upstream,[1] and is unnecessary now that the ACME
module supports specifying an ACME server. This commit changes the tests
to use the domain name acme.test instead, and renames the letsencrypt
node to acme to reflect that it has nothing to do with the ACME server
that Let's Encrypt runs. The imports are renamed for clarity:
* nixos/tests/common/{letsencrypt => acme}/{common.nix => client}
* nixos/tests/common/{letsencrypt => acme}/{default.nix => server}
The test's other domain names are also adjusted to use *.test for
consistency (and to avoid misuse of non-reserved domain names such
as standalone.com).
[1] https://github.com/letsencrypt/pebble/issues/283#issuecomment-545123242
Co-authored-by: Yegor Timoshenko <yegortimoshenko@riseup.net>
This was added in aade4e577b, but the
implementation of the ACME module has been entirely rewritten since
then, and the test seems to run fine on AArch64.
linux-hardened sets kernel.unprivileged_userns_clone=0 by default; see
anthraxx/linux-hardened@104f44058f.
This allows the Nix sandbox to function while reducing the attack
surface posed by user namespaces, which allow unprivileged code to
exercise lots of root-only code paths and have lead to privilege
escalation vulnerabilities in the past.
We can safely leave user namespaces on for privileged users, as root
already has root privileges, but if you're not running builds on your
machine and really want to minimize the kernel attack surface then you
can set security.allowUserNamespaces to false.
Note that Chrome's sandbox requires either unprivileged CLONE_NEWUSER or
setuid, and Firefox's silently reduces the security level if it isn't
allowed (see about:support), so desktop users may want to set:
boot.kernel.sysctl."kernel.unprivileged_userns_clone" = true;
* nixos/k3s: simplify config expression
* nixos/k3s: add config assertions and trim unneeded bits
* nixos/k3s: add a test that k3s works; minor module improvements
This is a single-node test. Eventually we should also have a multi-node
test to verify the agent bit works, but that one's more involved.
* nixos/k3s: add option description
* nixos/k3s: add defaults for token/serveraddr
Now that the assertion enforces their presence, we dont' need to use the typesystem for it.
* nixos/k3s: remove unneeded sudo in test
* nixos/k3s: add to test list
For reasons yet unknown, the vxlan backend doesn't work (at least inside
the qemu networking), so this is moved to the udp backend.
Note changing the backend apparently also changes the interface name,
it's now `flannel0`, not `flannel.1`
fixes#74941
This was whitespace-sensitive, kept fighting with my editor and broke
the tests easily. To fix this, let python convert the output to
individual lines, and strip whitespace from them before comparing.
Also removed `pkgs.hydra-flakes` since flake-support has been merged
into master[1]. Because of that, `pkgs.hydra-unstable` is now compiled
against `pkgs.nixFlakes` and currently requires a patch since Hydra's
master doesn't compile[2] atm.
[1] https://github.com/NixOS/hydra/pull/730
[2] https://github.com/NixOS/hydra/pull/732
Upgrades Hydra to the latest master/flake branch. To perform this
upgrade, it's needed to do a non-trivial db-migration which provides a
massive performance-improvement[1].
The basic ideas behind multi-step upgrades of services between NixOS versions
have been gathered already[2]. For further context it's recommended to
read this first.
Basically, the following steps are needed:
* Upgrade to a non-breaking version of Hydra with the db-changes
(columns are still nullable here). If `system.stateVersion` is set to
something older than 20.03, the package will be selected
automatically, otherwise `pkgs.hydra-migration` needs to be used.
* Run `hydra-backfill-ids` on the server.
* Deploy either `pkgs.hydra-unstable` (for Hydra master) or
`pkgs.hydra-flakes` (for flakes-support) to activate the optimization.
The steps are also documented in the release-notes and in the module
using `warnings`.
`pkgs.hydra` has been removed as latest Hydra doesn't compile with
`pkgs.nixStable` and to ensure a graceful migration using the newly
introduced packages.
To verify the approach, a simple vm-test has been added which verifies
the migration steps.
[1] https://github.com/NixOS/hydra/pull/711
[2] https://github.com/NixOS/nixpkgs/pull/82353#issuecomment-598269471
While our ETag patch works pretty fine if it comes to serving data off
store paths, it unfortunately broke something that might be a bit more
common, namely when using regexes to extract path components of
location directives for example.
Recently, @devhell has reported a bug with a nginx location directive
like this:
location ~^/\~([a-z0-9_]+)(/.*)?$" {
alias /home/$1/public_html$2;
}
While this might look harmless at first glance, it does however cause
issues with our ETag patch. The alias directive gets broken up by nginx
like this:
*2 http script copy: "/home/"
*2 http script capture: "foo"
*2 http script copy: "/public_html/"
*2 http script capture: "bar.txt"
In our patch however, we use realpath(3) to get the canonicalised path
from ngx_http_core_loc_conf_s.root, which returns the *configured* value
from the root or alias directive. So in the example above, realpath(3)
boils down to the following syscalls:
lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home/$1", 0x7ffd08da6f60) = -1 ENOENT (No such file or directory)
During my review[1] of the initial patch, I didn't actually notice that
what we're doing here is returning NGX_ERROR if the realpath(3) call
fails, which in turn causes an HTTP 500 error.
Since our patch actually made the canonicalisation (and thus additional
syscalls) necessary, we really shouldn't introduce an additional error
so let's - at least for now - silently skip return value if realpath(3)
has failed.
However since we're using the unaltered root from the config we have
another issue, consider this root:
/nix/store/...-abcde/$1
Calling realpath(3) on this path will fail (except if there's a file
called "$1" of course), so even this fix is not enough because it
results in the ETag not being set to the store path hash.
While this is very ugly and we should fix this very soon, it's not as
serious as getting HTTP 500 errors for serving static files.
I added a small NixOS VM test, which uses the example above as a
regression test.
It seems that my memory is failing these days, since apparently I *knew*
about this issue since digging for existing issues in nixpkgs, I found
this similar pull request which I even reviewed:
https://github.com/NixOS/nixpkgs/pull/66532
However, since the comments weren't addressed and the author hasn't
responded to the pull request, I decided to keep this very commit and do
a follow-up pull request.
[1]: https://github.com/NixOS/nixpkgs/pull/48337
Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @devhell
Acked-by: @7c6f434c
Acked-by: @yorickvP
Merges: https://github.com/NixOS/nixpkgs/pull/80671
Fixes: https://github.com/NixOS/nixpkgs/pull/66532
Dropbear lags behind OpenSSH significantly in both support for modern
key formats like `ssh-ed25519`, let alone the recently-introduced
U2F/FIDO2-based `sk-ssh-ed25519@openssh.com` (as I found when I switched
my `authorizedKeys` over to it and promptly locked myself out of my
server's initrd SSH, breaking reboots), as well as security features
like multiprocess isolation. Using the same SSH daemon for stage-1 and
the main system ensures key formats will always remain compatible, as
well as more conveniently allowing the sharing of configuration and
host keys.
The main reason to use Dropbear over OpenSSH would be initrd space
concerns, but NixOS initrds are already large (17 MiB currently on my
server), and the size difference between the two isn't huge (the test's
initrd goes from 9.7 MiB to 12 MiB with this change). If the size is
still a problem, then it would be easy to shrink sshd down to a few
hundred kilobytes by using an initrd-specific build that uses musl and
disables things like Kerberos support.
This passes the test and works on my server, but more rigorous testing
and review from people who use initrd SSH would be appreciated!
This mirrors the behaviour of systemd - It's udev that parses `.link`
files, not `systemd-networkd`.
This was originally applied in 36ef112a47,
but was reverted due to 1115959a8d causing
evaluation errors on hydra.
...even when networkd is disabled
This reverts commit ce78f3ac70, reversing
changes made to dc34da0755.
I'm sorry; Hydra has been unable to evaluate, always returning
> error: unexpected EOF reading a line
and I've been unable to reproduce the problem locally. Bisecting
pointed to this merge, but I still can't see what exactly was wrong.
