This reverts commit 1010271c63f503113c0e8337977610ea783880ec.
This reverts commit e85e51d41f0f3be40490b0de9a76f20f3685659c.
The first commit causes multiple regressions. The second commit tries to
fix the regressions, but does not catch all of them. There are multiple
failing tests, one of which is blocking a package update. That is not
acceptable for a cosmetic patch.
* influxdb module: add postStart
* cadvisor module: increase TimeoutStartSec
Under high load, the cadvisor module can take longer than the default 90
seconds to start. This change should hopefully fix the test on Hydra.
Regression introduced by bccd75094fd5108b3d834ad3a86e056eed3b0337.
The mentioned commit removed the pkgs.gtk attribute, but forgot to
change this within the xfce module.
Tested using the xfce NixOS test and it has passed on my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by 1010271c63f503113c0e8337977610ea783880ec.
This caused the line after using the loginuid module to be concatenated
with the next line without a newline.
In turn this has caused a lot of the NixOS VM tests to either run very
slowly (because of constantly hitting PAM errors) or simply fail.
I have tested this only with one of the failing NixOS tests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
While entering the chroot should provide the same amount of isolation,
the preStart script will run with full root privileges and so would
benefit from some isolation as well (in particular due to
unbound-anchor, which can perform network I/O).
1. The preStart script ensures consistent ownership, even if the unbound
user's uid has changed
2. The unbound daemon does not generate data that needs to be private to
it, so it would not matter that a different service would end up
owning its data (as long as unbound remains enabled, it should reclaim
ownership soon enough anyway).
Thus, there's no clear benefit to allocate a dedicated uid for the
unbound service. This releases uid/gid 48.
Also, because the preStart script creates the data directory, there's no
need to specify a homedir or ask for its creation.
/dev/random is an exhaustible resource. Presumably, unbound will not be
used to generate long-term encryption keys and so allowing it to use
/dev/random only increases the risk of entropy exhaustion for no
benefit.
The generated files in /etc/pam.d/ typically have a lot of empty lines
in them, due to how the generated Nix strings are joined together;
optional elements that are excluded still produce a newline. This patch
changes how the files are generated to create more compact,
human-friendly output files.
The change is basically this, repeated:
- ''
- ${optionalString use_ldap
- "account sufficient ${pam_ldap}/lib/security/pam_ldap.so"}
- ''
+ optionalString use_ldap ''
+ account sufficient ${pam_ldap}/lib/security/pam_ldap.so
+ ''
This introduces VirtualBox version 5.1.6 along with a few refactored
stuff, notably:
* Kernel modules and user space applications are now separate
derivations.
* If config.pulseaudio doesn't exist in nixpkgs config, the default is
now to build with PulseAudio modules.
* A new updater to keep VirtualBox up to date.
All subtests in nixos/tests/virtualbox.nix succeed on my machine and
VirtualBox was reported to be working by @DamienCassou (although with
unrelated audio problems for another fix/branch) and @calbrecht.
One reason why it took me so long for debugging the test failure with
systemd-detect-virt was that simple-cli has succeeded while the former
has not.
This now makes sure we have consistency accross all the subtests and if
problems like the one in the previos commit ever show up again, we will
have just the headless test succeeding and it's more obvious where the
actual problem resides.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We don't have (simulated) sound hardware within the qemu VM, neither do
we have it available within VirtualBox that's running within the qemu
VMs.
With sound hardware the VirtualBox UI displays an error dialog, which in
turn causes the VM process to hang on unregister. This in turn has
caused the tests to fail because of the following error:
Cannot unregister the machine '...' while it is locked
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using waitUntilSucceeds for testing whether the shutdown signalling
files have vanished is quite noisy because it prints two lines for every
try. This is now fixed with a while loop on the guest VM which does the
same check but with only one output for the command that's executed and
another one when the conditions are met.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
- logDriver option, use journald for logging by default
- keep storage driver intact by default, as docker has sane defaults
- do not choose storage driver in tests, docker will choose by itself
- use dockerd binary as "docker daemon" command is deprecated and will be
removed
- add overlay2 to list of storage drivers
modify tests to not fail if the event handlers are
registered too slowly or if the wrong window is in focus
(cherry picked from commit e087b0d12f97604ee1fdd09ef3d78b772c12468e)
Signed-off-by: Domen Kožar <domen@dev.si>
