Previously services depending on network-online.target would wait until
dhcpcd times out if it was enabled and a static network address
configuration was used. Setting the default gateway statically is enough
for the networking to be considered online.
This also adjusts the relevant networking tests to wait for
network-online.target instead of just network.target.
This option got introduced in 7904499542
and it didn't check whether mailUser and mailGroup are null, which they
are by default.
Now we're only creating the user if createMailUser is set in conjunction
with mailUser and the group if mailGroup is set as well.
I've added a NixOS VM test so that we can verify whether dovecot works
without any additional options set, so it serves as a regression test
for issue #29466 and other issues that might come up with future changes
to the Dovecot service.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #29466
Cc: @qknight, @abbradar, @ixmatus, @siddharthist
Quoting from @FRidh:
Note overridePythonAttrs exists since 17.09. It overrides the call to
buildPythonPackage.
While it's not strictly necessary to do this, because postPatch ends up
in drvAttrs anyway, it's probably better to use overridePythonAttrs so
we don't run into problems when the underlying implementation of
buildPythonPackage changes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Since 67651d80bc the requests package now
depends on certifi, which in turn provides the CA root certificates that
we need to replace.
It might also be a good idea to actually patch certifi with our version
of cacert by default so that if we want to override and/or add something
we only need to do it once.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @fpletz, @k0ral, @FRidh
The enableSSL option has been deprecated in
a912a6a291, so we switch to using onlySSL.
I've also explicitly disabled enableACME, because this is the default
and we don't actually want to have ACME enabled for a host which runs an
actual ACME server.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The test here is pretty basic and only tests nginx, but it should get us
started to write tests for different webservers and different ACME
implementations.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
These modules implement a way to test ACME based on a test instance of
Letsencrypt's Boulder service. The service implementation is in
letsencrypt.nix and the second module (resolver.nix) is a support-module
for the former, but can also be used for tests not involving ACME.
The second module provides a DNS server which hosts a root zone
containing all the zones and /etc/hosts entries (except loopback) in the
entire test network, so this can be very useful for other modules that
need DNS resolution.
Originally, I wrote these modules for the Headcounter deployment, but
I've refactored them a bit to be generally useful to NixOS users. The
original implementation can be found here:
https://github.com/headcounter/deployment/tree/89e7feafb/modules/testing
Quoting parts from the commit message of the initial implementation of
the Letsencrypt module in headcounter/deployment@95dfb31110:
This module is going to be used for tests where we need to
impersonate an ACME service such as the one from Letsencrypt within
VM tests, which is the reason why this module is a bit ugly (I only
care if it's working not if it's beautiful).
While the module isn't used anywhere, it will serve as a pluggable
module for testing whether ACME works properly to fetch certificates
and also as a replacement for our snakeoil certificate generator.
Also quoting parts of the commit where I have refactored the same module
in headcounter/deployment@85fa481b34:
Now we have a fully pluggable module which automatically discovers
in which network it's used via the nodes attribute.
The test environment of Boulder used "dns-test-srv", which is a fake
DNS server that's resolving almost everything to 127.0.0.1. On our
setup this is not useful, so instead we're now running a local BIND
name server which has a fake root zone and uses the mentioned node
attribute to automatically discover other zones in the network of
machines and generate delegations from the root zone to the
respective zones with the primaryIPAddress of the node.
...
We want to use real letsencrypt.org FQDNs here, so we can't get away
with the snakeoil test certificates from the upstream project but
now roll our own.
This not only has the benefit that we can easily pass the snakeoil
certificate to other nodes, but we can (and do) also use it for an
nginx proxy that's now serving HTTPS for the Boulder web front end.
The Headcounter deployment tests are simulating a production scenario
with real IPs and nameservers so it won't need to rely on
networking.extraHost. However in this implementation we don't
necessarily want to do that, so I've added auto-discovery of
networking.extraHosts in the resolver module.
Another change here is that the letsencrypt module now falls back to
using a local resolver, the Headcounter implementation on the other hand
always required to add an extra test node which serves as a resolver.
I could have squashed both modules into the final ACME test, but that
would make it not very reusable, so that's the main reason why I put
these modules in tests/common.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The installer tests are failing after 505e94256e
due to `nixos-rebuild switch` in the installed system trying to build
stdenvNoCC.
Seems that previously, stdenvNoCC wasn't in the installed
system either, but all the direct dependencies for the build were
(I don't really understand why, for that matter), so the building
actually went fine and everything worked.
But now gcc is also a direct build dependency due to allowedRequisites
containing gcc (even though it doesn't become a runtime dependency)
which doesn't get to the installed system.
All in all, let's ensure stdenvNoCC actually gets to the installed
system. It's after all necessary in almost any NixOS config build.
This commit readds and updates the 1.x package from 1.1.4 to 1.1.6 which
also includes the needed command for migrating to 2.x
The module is adjusted to the version change, defaulting to radicale2 if
stateVersion >= 17.09 and radicale1 otherwise. It also now uses
ExecStart instead of the script service attribute. Some missing dots at
the end of sentences were also added.
I added a paragraph in the release notes on how to update to a newer
version.
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.
