The helper tool had a very early check whether the automatically created
CA key/cert are available and thus it would abort if the key was
unavailable even though we don't need or even want to have the CA key.
Unfortunately our NixOS test didn't catch this, because it was just
switching from a configuration with an automatically created CA to a
manual configuration without deleting the generated keys and certs.
This is done now in the tests and it's also fixed in the helper tool.
Reported-by: @jpotier
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
1. Needs to call makeTest or else nothing happens when you run
`nix-build nixos/tests/postgresql.nix`.
2. Tests run as root, so there needs to be a corresponding user in
PostgreSQL.
Tesseract seems to have a hard time detecting the "ALICE FOOBAR" text,
so let's match on "Select your user and enter password" instead.
Ran the test on x86_64-linux and it now succeeds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* Add kibana5 and logstash5
* Upgrade the elastic beats to 5.4
* Make sure all elastic products use the same version
(see elk5Version)
* Add a test for the ELK stack
Restructure the nixos-artwork to make it easy to selectively
incorporate other components from upstream without needing to download
the full package.
Until now only the Gnome_Dark wallpaper was included. Add other
wallpapers available in the package repository.
An iso containing metadatas is created and attached as a cdrom to the
qemu VM used for this test.
The cloudinit service is enabled. The test case ensures the root
authorized_keys file is populated and the cloudinit write_file module is
working well.
OVMF{,CODE,VARS}.fd are now available in a dedicated fd output, greatly
reducing the closure in the common case where only those files are used (a
few MBs versus several hundred MBs for the full OVMF).
Note: it's unclear why `dontPatchELF` is now necessary for the build to
pass (on my end, at any rate) but it doesn't make much sense to run this
fixup anyway,
Note: my reading of xen's INSTALL suggests that --with-system-ovmf should
point directly to the OVMF binary. As such, the previous invocation was
incorrect (it pointed to the root of the OVMF tree). In any case, I have
only built xen with `--with-system-ovmf`, I have not tested it.
Fixes https://github.com/NixOS/nixpkgs/issues/25854
Closes https://github.com/NixOS/nixpkgs/pull/25855
This test exercises the linux_hardened kernel along with the various
hardening features (enabled via the hardened profile).
Move hidepid test from misc, so that misc can go back to testing a vanilla
configuration.
This is currently our default display manager, so I'm adding this to the
"tested" job as well to ensure we don't ship broken revisions where X is
most likely not working.
The test uses a custom SLiM theme that's specifically tailored for good
OCR results (mainly white background and black fonts without anything
else), because our default NixOS theme has a very small contrast between
background and fonts in some places.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
- adds distro dependency
- buildbot nodaemon in service module
- fakerepo for module tests
- service module parameter fixup
- tested on nixos
- tested on darwin
The key distinction I'm drawing is that there's a component that deals
with the store of the machine being built, and another component for
the store building it. The inner part of it assumes nothing from the
builder (doesn't need chroot or root powers) so it can run comfortably
inside a Nix build, as well as nixos-rebuild. I have some upcoming work
that will use that to significantly speed up and streamline image builds
for NixOS, especially on virtualized hosts like EC2, but it's also a
reasonable speedup on native hosts.
This reverts commit 0a6a06346a.
The commit replaced the text to search for from ALICE to BOB, because
our OCR detection only caught "BOB FOOBAR" but missed "ALICE FOOBAR"
completely.
With the improvements to our OCR system this no longer is the case and
the test passes successfully with this reverted.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @shlevy
For whatever reason, the OCR code is not detecting ALICE but is BOB.
OCR output from login screen (blank lines omitted):
> Session none + icewm
> 08:41 <
> Thursday, April 6, 2017
> BOB FOOBAR
> Select your user and enter password
There was one confusing recent failure of this:
http://cache.nixos.org/log/myla8bc17j8spmifdxmrz9jswxwsf5w6-vm-test-run-hibernate.drv
I don't have any real ideas on what could cause the problem but there is
at least one theoretical one: the system starts hibernating before the
listener process manages to open the TCP port for listening, and it can't
open it after resuming because not enough pages from the netcat binary
have been paged in (and as the 9p filesystem holding it is now toast,
they can't be loaded anymore).
This has surfaced since f803270b7e.
The commit bumped bash to version 4.4, which caused to change the order
of --subst-var flags in substituteAll, which this test was relying on,
because it added a @shell@ to boot.initrd.postMountCommands.
Our substituter is currently working a bit like this:
original.replace('@var1@', 'val1').replace('@var2@', 'val2')...
Unfortunately, this means that if @var2@ occurs within @var1@ it is
replaced by the new value, so the order of the substvars actually
matter. I highly doubt that we want a behaviour like this and I'm
wondering why it didn't occur to me as a problem while writing the
initial implementation of the VirtualBox tests.
Whether to get rid of this and disallowing substitution of substvars
within substvars is another topic which I think needs discussion in a
different place.
As for now, I'm using stdenv.shell, because the closure size of this
should fit within the initrd, so it's fine especially because it's just
a test.
Tested with the net-hostonlyif and systemd-detect-virt tests and they
both succeed with this change.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: @globin on IRC
And adopt the tests to add an interface and remove it again.
It should work when deactivating rstp, it will not work when activating
rstp for the first bridge as then the userspace daemon is not yet
available. But once one bridge is active with stp, it should work with
the reload for any further bridge.
Fixes#21745. Also see #22547.
