In case of a power loss shortly after first boot,
the host keys gernerated by ssh-keygen could exist
in the file system but have zero size, preventing
sshd from starting up.
This commit changes the behaviour to generate host
keys if the file either does not exist or has zero
size, fixing the problem on the next boot.
Thanks to @SuperSandro2000 for figuring this out.
On some systems bootctl cannot write the `LoaderSystemToken` EFI variable
during installation, which results in a failure to install the boot
loader. Upstream provides a flag (--graceful) to ignore such write failures -
this change exposes it as a configuration option.
As the exact semantics of this option appear to be somewhat volatile it
should be used only if systemd-boot otherwise fails to install.
A few minor changes to get #119638 - nextcloud: add option to set
datadir and extensions - ready:
* `cfg.datadir` now gets `cfg.home` as default to make the type
non-nullable.
* Enhanced the `basic` test to check the behavior with a custom datadir
that's not `/var/lib/nextcloud`.
* Fix hashes for apps in option example.
* Simplify if/else for `appstoreenable` in override config.
* Simplify a few `mapAttrsToList`-expressions in
`nextcloud-setup.service`.
Note the appstoreEnable which will prevent nextcloud form updating
nix-managed apps. This is needed because nextcloud will store an other
version of the app in /var/lib/nextcloud/store-apps and it will
no longer be manageable.
The multipath-tools package had existed in Nixpkgs for some time but
without a nixos module to configure/drive it. This module provides
attributes to drive the majority of multipath configuration options
and is being successfully used in stage-1 and stage-2 boot to mount
/nix from a multipath-serviced iSCSI volume.
Credit goes to @grahamc for early contributions to the module and
authoring the NixOS module test.
Don't worry, it's is true by default. But I think this is important to
have because NixOS indeed shouldn't need Nix at run time when the
installation is not being modified, and now we can verify that.
NixOS images that cannot "self-modify" are a legitamate
use-case that this supports more minimally. One should be able to e.g. do a
sshfs mount and use `nixos-install` to modify them remotely, or just
discard them and build fresh ones if they are run VMs or something.
The next step would be to make generations optional, allowing just
baking `/etc` and friends rather than using activation scripts. But
that's more involved so I'm leaving it out.
I realized quite recently that running a test VM - as documented in the
manual - like
QEMU_NET_OPTS='hostfwd=tcp::8080-:80' ./result/bin/nixos-run-vms
doesn't work anymore on `master`. After bisecting I realized that the
introduction of a forward-port option[1] is the problem since it adds a
trailing comma even if no forwarding options are specified via
`virtualisation.forwardPorts`. In that case, the networking options
would look like `-netdev user,id=user.0,,hostfwd=tcp::8080-:80' which
confused QEMU and thus the VM refused to start.
Now, the trailing comma is only added if additional port forwards are
specified declaratively.
[1] b8bfc81d5b
