Massively reduce the time it takes running the test by building a
proper root disk image and increasing the virtualized core count to
4. This should make it much easier for the tests to pass even on
weaker systems.
With my laptop (AMD Ryzen 7 PRO 2700U, 32GB RAM) as the reference
system, I see the following test run times:
- No change:
25 mins, 49 secs
- Building a root image:
4 mins, 44 secs
- Building a root image and bumping the core count:
3 mins, 6 secs
The times include the time it takes to build the image (~40 secs).
Make sure the all derivations referenced by the test script are
available on the nodes. Accessing these derivations works just fine
without this change when using 9p to mount the host's store, but when
an image is built (virtualisation.buildRootImage), the dependencies
need to be copied to the image. We don't want to copy the script
itself, though, since that would trigger unnecessary image rebuilds.
pathsInNixDB isn't a very accurate name when a Nix store image is
built (virtualisation.useNixStoreImage); rename it to additionalPaths,
which should be general enough to cover both cases.
Add the `useNixStoreImage` option, allowing a disk image with the
necessary contents from the Nix store to be built using
make-disk-image.nix. The image will be mounted at `/nix/store` and
acts as a drop-in replacement for the usual 9p mounting of the host's
Nix store.
This removes the performance penalty of 9p, drastically improving
execution speed of applications which do lots of reads from the Nix
store. The caveats are increased disk space usage and image build
time.
Add a copyChannel argument which controls whether the current source
tree will be made available as a nix channel in the image or
not. Previously, it always was. Making it available is useful for
interactive use of nix utils, but changes the hash of the image when
the sources are updated.
nixos-rebuild test causes pam_mount to prompt for a password when running with
an encrypted home:
building '/nix/store/p6bflh7n5zy2dql8l45mix9qnzq65hbk-nixos-system-mildred-18.09.git.98592c5da79M.drv'...
activating the configuration...
setting up /etc...
reenter password for pam_mount:
(mount.c:68): Messages from underlying mount program:
(mount.c:72): crypt_activate_by_passphrase: File exists
(pam_mount.c:522): mount of /dev/mapper/vg0-lv_home_peter failed
kbuildsycoca5 running...
This change makes pam_mount not prompt. It still tries to remount (and fails in
the process) but that message can be ignored.
Fixes: #44586
This is done as the s3CredentialsFile specifies the environmentFile
for the systemd service, which can be used for more than just s3.
Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com>
This module was written by @puckipedia for nixcon-video-infra 2020.
Minor changes made by @cleeyv for compat with existing jibri package.
Co-authored-by: Puck Meerburg <puck@puck.moe>
This option enables a jibri service on the same host that is running
jitsi-meet. It was written, along with the jibri module, by @puckipedia
for nixcon-video-infra 2020.
Co-authored-by: Puck Meerburg <puck@puck.moe>
The existing tests for HDFS and YARN only check if the services come up and expose their web interfaces.
The new combined hadoop test will also test whether the services and roles work together as intended.
It spin up an HDFS+YARN cluster and submit a demo YARN application that uses the hadoop cluster for
storageand yarn cluster for compute.
The version 20 of Nextcloud will be EOLed by the end of this month[1].
Since the recommended default (that didn't raise an eval-warning) on
21.05 was Nextcloud 21, this shouldn't affect too many people.
In order to ensure that nobody does a (not working) upgrade across
several major-versions of Nextcloud, I replaced the derivation of
`nextcloud20` with a `throw` that provides instructions how to proceed.
The only case that I consider "risky" is a setup upgraded from 21.05 (or
older) with a `system.stateVersion` <21.11 and with
`services.nextcloud.package` not explicitly declared in its config. To
avoid that, I also left the `else-if` for `stateVersion < 21.03` which
now sets `services.nextcloud.package` to `pkgs.nextcloud20` and thus
leads to an eval-error. This condition can be removed
as soon as 21.05 is EOL because then it's safe to assume that only
21.11. is used as stable release where no Nextcloud <=20 exists that can
lead to such an issue.
It can't be removed earlier because then every `system.stateVersion <
21.11` would lead to `nextcloud21` which is a problem if `nextcloud19`
is still used.
[1] https://docs.nextcloud.com/server/20/admin_manual/release_schedule.html
borg is able to process stdin during backups when backing up the special path -,
which can be very useful for backing up things that can be streamed (eg database
dumps, zfs snapshots).
mosquitto needs a lot of attention concerning its config because it doesn't
parse it very well, often ignoring trailing parts of lines, duplicated config
keys, or just looking back way further in the file to associated config keys
with previously defined items than might be expected.
this replaces the mosquitto module completely. we now have a hierarchical config
that flattens out to the mosquitto format (hopefully) without introducing spooky
action at a distance.
/etc/crypttab can contain the _netdev option, which adds crypto devices
to the remote-cryptsetup.target.
remote-cryptsetup.target has a dependency on cryptsetup-pre.target. So
let's add both of them.
Currently, one needs to manually ssh in and invoke `systemctl start
systemd-cryptsetup@<name>.service` to unlock volumes.
After this change, systemd will properly add it to the target, and
assuming remote-cryptsetup.target is pulled in somewhere, you can simply
pass the passphrase by invoking `systemd-tty-ask-password-agent` after
ssh-ing in, without having to manually start these services.
Whether remote-cryptsetup.target should be added to multi-user.target
(as it is on other distros) is part of another discussion - right now
the following snippet will do:
```
systemd.targets.multi-user.wants = [ "remote-cryptsetup.target" ];
```
Makes service more customizeable and makes debuggingin easier through
the use of flags like `--log-debug` or `--dump-settings`.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
The current implementation just forks off a thread to read
QEMU's stdout and lets it exist forever. This, however,
makes the interpreter shutdown racy, as the thread could
still be running and writing out buffered stdout when the
main thread exits (and since it's using the low level API,
the worker thread does not get cleaned up by the atexit hooks
installed by `threading`, either). So, instead of doing that,
let's create a real `threading.Thread` object, and also
explicitly `join` it along with the other stuff when cleaning up.
Move all `virtualisation.libvirtd.qemu*` options to a
`virtualisation.libvirtd.qemu` submodule.
Also for consistency, add `virtualisation.libvirtd.qemu.swtpm.package`
(only new option during this refactor.)
we need the file itself as a dependency for the docbook build, but we don't need
it to be properly sorted at the nix level. push the sort out to a python script
instead to save eval time. on the machine used to write this `nix-instantiate
<nixos/nixos> -A system` went down from 7.1s to 5.4s and GC heap size decreased
by 50MB (or 70MB max RSS).
The latest version of Subsonic (6.1.6) does not suport Java SE 9 or later
because it depends on the JAXB APIs. Those are considered to be Java EE
APIs are no longer contained on the default classpath in Java SE 9 and
are completely removed in Java SE 11..
This makes the order of operations the same in dry-activate and a "true"
activate. Also fixes the indentation I messed up and drop a useless
unlink() call (we are already unlinking that file earlier).
The previous logic failed to detect that units were socket-activated
when the socket was stopped before switch-to-configuration was run. This
commit fixes that and also starts the socket in question.
