With these changes, a container can have more then one veth-pair. This allows for example to have LAN and DMZ as bridges on the host and add dedicated containers for proxies, ipv4-firewall and ipv6-firewall. Or to have a bridge for normal WAN, one bridge for administration and one bridge for customer-internal communication. So that web-server containers can be reached from outside per http, from the management via ssh and can talk to their database via the customer network.
The scripts to set up the containers are now rendered several times instead of just one template. The scripts now contain per-container code to configure the extra veth interfaces. The default template without support for extra-veths is still rendered for the imperative containers.
Also a test is there to see if extra veths can be placed into host-bridges or can be reached via routing.
GoCD is an open source continuous delivery server specializing in advanced workflow
modeling and visualization. Update maintainers list to include swarren83. Update
module list to include gocd agent and server module. Update packages list to include
gocd agent and server package. Update version, revision and checksum for GoCD
release 16.5.0.
The LUKS passphrase prompt has changed from "Enter passphrase" to "Enter
LUKS Passphrase" in c69c76ca7e, so the OCR
detection of the test fails indefinitely.
Unfortunately, this doesn't fix the test because we have a real problem
here:
Enter LUKS Passphrase:
killall: cryptsetup: no process killed
Enter LUKS Passphrase:
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @abbradar
I've failed to figure out what why `paxtest blackhat` hangs the vm, and
have resigned to running individual `paxtest` programs. This provides
limited coverage, but at least verifies that some important features are
in fact working.
Ideas for future work includes a subtest for basic desktop
functionality.
IceWM is not part of KDE 5 and is now no longer part of the test. KDE 5
applications: Dolphin, System Monitor, and System Settings are started
in this test.
VBoxService needs dbus in order to work properly, which failed to start
up so far, because it was searching in /run/current-system/sw for its
configuration files.
We now no longer run with the --system flag but specify the
configuration file directly instead.
This fixes at least the "simple-gui" test and probably the others as
well, which I haven't tested yet.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We can't use waitForWindow here because it runs xwininfo as user root,
who in turn is not authorized to connect to the X server running as
alice.
So instead, we use xprop from user alice which should fix waiting for
the VirtualBox manager window.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The VirtualBox tests so far ran the X server as root instead of user
"alice" and it did work, because we had access control turned off by
default.
Fortunately, it was changed in 1541fa351b.
As a side effect, it caused all the VirtualBox tests to fail because
they now can't connect to the X server, which is a good thing because
it's a bug of the VirtualBox tests.
So to fix it, let's just start the X server as user alice.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This allows setting options for the same LUKS device in different
modules. For example, the auto-generated hardware-configuration.nix
can contain
boot.initrd.luks.devices.crypted.device = "/dev/disk/...";
while configuration.nix can add
boot.initrd.luks.devices.crypted.allowDiscards = true;
Also updated the examples/docs to use /disk/disk/by-uuid instead of
/dev/sda, since we shouldn't promote the use of the latter.
As @edolstra pointed out that the kernel module might be painful to
maintain. I strongly disagree because it's only a small module and it's
good to have such a canary in the tests no matter how the bootup process
looks like, so I'm going the masochistic route and try to maintain it.
If it *really* becomes too much maintenance burden, we can still drop or
disable kcanary.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We already have a small regression test for #15226 within the swraid
installer test. Unfortunately, we only check there whether the md
kthread got signalled but not whether other rampaging processes are
still alive that *should* have been killed.
So in order to do this we provide multiple canary processes which are
checked after the system has booted up:
* canary1: It's a simple forking daemon which just sleeps until it's
going to be killed. Of course we expect this process to not
be alive anymore after boot up.
* canary2: Similar to canary1, but tries to mimick a kthread to make
sure that it's going to be properly killed at the end of
stage 1.
* canary3: Like canary2, but this time using a @ in front of its
command name to actually prevent it from being killed.
* kcanary: This one is a real kthread and it runs until killed, which
shouldn't be the case.
Tested with and without 67223ee and everything works as expected, at
least on my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is a regression test for #15226, so that the test will fail once we
accidentally kill one or more of the md kthreads (aka: if safe mode is
enabled).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Just removing the system argument because it doesn't exist (it's
actually config.nixpkgs.system, which we're already using). We won't get
an error anyway if we're not actually using it, so this is just an
aesthetics fix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Make sure that we always have everything available within the store of
the VM, so let's evaluate/build the test container fully on the host
system and propagate all dependencies to the VM.
This way, even if there are additional default dependencies that come
with containers in the future we should be on the safe side as these
dependencies should now be included for the test as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @kampfschlaefer, @edolstra
This partially reverts f2d24b9840.
Instead of disabling the channels via removing the channel mapping from
the tests themselves, let's just explicitly reference the stable test in
release.nix. That way it's still possible to run the beta and dev tests
via something like "nix-build nixos/tests/chromium.nix -A beta" and
achieve the same effect of not building beta and dev versions on Hydra.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It's not the job of Nixpkgs to distribute beta versions of upstream
packages. More importantly, building these delays channel updates by
several hours, which is bad for our security fix turnaround time.
Regression introduced by dfe608c8a2.
The commit turns the two arguments into one attrset argument so we need
to adapt that to use the new calling convention.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The Nix store squashfs is stored inside the initrd instead of separately
(cherry picked from commit 976fd407796877b538c470d3a5253ad3e1f7bc68)
Signed-off-by: Domen Kožar <domen@dev.si>
Two fixes:
Not really sure why removing `--fail` from the curl calls is necessary,
but with that option, curl erronously reports 404 (which it shouldn't
per my interactive vm testing).
Fix paths to example files used for the printing test
Toghether, these changes allow the test to run to completion on my machine.
This adds a Taskserver module along with documentation and a small
helper tool which eases managing a custom CA along with Taskserver
organisations, users and groups.
Taskserver is the server component of Taskwarrior, a TODO list
application for the command line.
The work has been started by @matthiasbeyer back in mid 2015 and I have
continued to work on it recently, so this merge contains commits from
both of us.
Thanks particularly to @nbp and @matthiasbeyer for reviewing and
suggesting improvements.
I've tested this with the new test (nixos/tests/taskserver.nix) this
branch adds and it fails because of the changes introduced by the
closure-size branch, so we need to do additional work on base of this.
Coreutils is multi-output and the `info` output doesn't seem to be
included on the install disk, failing like this (because now nix-env
wants to build coreutils):
````
machine# these derivations will be built:
machine# /nix/store/0jk4wzg11sa6cqyw8g7w5lb35axji969-bison-3.0.4.tar.gz.drv
...
machine# /nix/store/ybjgqwxx63l8cj1s7b8axx09wz06kxbv-coreutils-8.25.drv
machine# building path(s) ‘/nix/store/4xvdi5740vq8vlsi48lik3saz0v5jsx0-coreutils-8.25.tar.xz’
machine# downloading ‘http://ftpmirror.gnu.org/coreutils/coreutils-8.25.tar.xz’...
machine# error: unable to download ‘http://ftpmirror.gnu.org/coreutils/coreutils-8.25.tar.xz’: Couldn't resolve host name (6)
machine# builder for ‘/nix/store/5j3bc5sjr6271fnjh9gk9hrid8kgbpx3-coreutils-8.25.tar.xz.drv’ failed with exit code 1
machine# cannot build derivation ‘/nix/store/ybjgqwxx63l8cj1s7b8axx09wz06kxbv-coreutils-8.25.drv’: 1 dependencies couldn't be built
machine# error: build of ‘/nix/store/ybjgqwxx63l8cj1s7b8axx09wz06kxbv-coreutils-8.25.drv’ failed
````
Try to match the subcommands to act more like the subcommands from the
taskd binary and also add a subcommand to list groups.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As suggested by @matthiasbeyer:
"We might add a short note that this port has to be opened in the
firewall, or is this done by the service automatically?"
This commit now adds the listenPort to
networking.firewall.allowedTCPPorts as soon as the listenHost is not
"localhost".
In addition to that, this is now also documented in the listenHost
option declaration and I have removed disabling of the firewall from the
VM test.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Whenever the nixos-taskserver tool was invoked manually for creating an
organisation/group/user we now add an empty file called .imperative to
the data directory.
During the preStart of the Taskserver service, we use process-json which
in turn now checks whether those .imperative files exist and if so, it
doesn't do anything with it.
This should now ensure that whenever there is a manually created user,
it doesn't get killed off by the declarative configuration in case it
shouldn't exist within that configuration.
In addition, we also add a small subtest to check whether this is
happening or not and fail if the imperatively created user got deleted
by process-json.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We were putting the whole output of "nixos-taskserver export-user" from
the server to the respective client and on every such operation the
whole output was shown again in the test log.
Now we're *only* showing these details whenever a user import fails on
the client.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Now we finally can delete organisations, groups and users along with
certificate revocation. The new subtests now make sure that the client
certificate is also revoked (both when removing the whole organisation
and just a single user).
If we use the imperative way to add and delete users, we have to restart
the Taskserver in order for the CRL to be effective.
However, by using the declarative configuration we now get this for
free, because removing a user will also restart the service and thus its
client certificate will end up in the CRL.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It's not necessarily related to the PKI options, because this is also
used for setting the server address on the Taskwarrior client.
So if someone doesn't have his/her own certificates from another CA, all
options that need to be adjusted are in .pki. And if someone doesn't
want to bother with getting certificates from another CA, (s)he just
doesn't set anything in .pki.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
After moving out the PKI-unrelated options, let's name this a bit more
appropriate, so we can finally get rid of the taskserver.server thing.
This also moves taskserver.caCert to taskserver.pki.caCert, because that
clearly belongs to the PKI options.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Having an option called services.taskserver.server.host is quite
confusing because we already have "server" in the service name, so let's
first get rid of the listening options before we rename the rest of the
options in that .server attribute.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As the nixos-taskserver command can also be used to imperatively manage
users, we need to test this as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This module adds an option `security.hideProcessInformation` that, when
enabled, restricts access to process information such as command-line
arguments to the process owner. The module adds a static group "proc"
whose members are exempt from process information hiding.
Ideally, this feature would be implemented by simply adding the
appropriate mount options to `fileSystems."/proc".fsOptions`, but this
was found to not work in vmtests. To ensure that process information
hiding is enforced, we use a systemd service unit that remounts `/proc`
after `systemd-remount-fs.service` has completed.
To verify the correctness of the feature, simple tests were added to
nixos/tests/misc: the test ensures that unprivileged users cannot see
process information owned by another user, while members of "proc" CAN.
Thanks to @abbradar for feedback and suggestions.
Using nixos-taskserver is more verbose but less cryptic and I think it
fits the purpose better because it can't be confused to be a wrapper
around the taskdctl command from the upstream project as
nixos-taskserver shares no commonalities with it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
A small test which checks whether tasks can be synced using the
Taskserver.
It doesn't test group functionality because I suspect that they're not
yet implemented upstream. I haven't done an in-depth check on that but I
couldn't find a method of linking groups to users yet so I guess this
will get in with one of the text releases of Taskwarrior/Taskserver.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
A testcase each for
- declarative ipv6-only container
Seems odd to define the container IPs with their prefix length attached.
There should be a better way…
- declarative bridged container
Also fix the ping test by waiting for the container to start
When the ping was executed, the container might not have finished starting. Or
the host-side of the container wasn't finished with config. Waiting for
2 seconds in between fixes this.
I had the basic version of this laying around for some while but didn't
continue on it. Originally it was for testing support for the Neo layout
introduced back then (8cd6d53).
We only test the first three Neo layers, because the last three layers
are largely comprised of special characters and in addition to that the
support for the VT keymap seems to be limited compared to the Xorg
keymap.
Yesterday @NicolasPetton on IRC had troubles with the Colemak layout
(IRC logs: http://nixos.org/irc/logs/log.20160330, starting at 16:08)
and I found that test again, so I went for improving and adding to
<nixpkgs>.
While the original problem seemed to be related to GDM, we can still add
another subtest that checks whether GDM correctly applies the keyboard
layout. However I don't have a clue how to properly configure the
keyboard layout on GDM, at least not within the NixOS configuration.
The main goal of this test is not to test a complete set of all key
mappings but to check whether the keymap is loaded and working at all.
It also serves as an example for NixOS keyboard configurations.
The list of keyboard layouts is by no means complete, so everybody is
free to add their own to the test or improve the existing ones.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We now generate a qcow2 image to prevent hitting Hydra's output size
limit. Also updated /root/user-data -> /etc/ec2-metadata/user-data.
http://hydra.nixos.org/build/33843133
These two steps seem to fail intermittently with exit code 1. It isn't clear to me why, or what the issue is. Adding the `--verbose` option, hoping to capture some debugging information which might aid stabilization. Also: I was unable to replicate the failure locally.
Assigning the channelMap by the function attrset argument at the
top-level of the test expression file may reference a different
architecture than we need for the tests.
So if we get the pkgs attribute by auto-calling, this will lead to test
failure because we have a different architecture for the test than for
the browser.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This has been the case before e45c211, but it turns out that it's very
useful to override the channel packages so we can run tests with
different Chromium build options.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The docker service is socket activated by default; thus,
`waitForUnit("docker.service")` before any docker command causes the
unit test to time out.
Instead, do `waitForUnit("sockets.target")` to ensure that sockets are
setup before running docker commands.
As @bobvanderlinden suggests in #13585:
"Looks like that cleans things up quite a bit! Just one aesthetics note,
the boot tests could now be renamed from boot.bootBiosCdrom to
boot.biosCdrom in nixos/tests/boot.nix:L33.
That makes them more consistent with the other tests."
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This makes it easier to test just a specific channel rather than to
force testing all builds down the users/testers throat. Especially this
makes it easier to test NixOS channel upgrades only against the Chromium
stable channel instead of just removing the beta/dev channels from the
tests entirely (as done in 69ec09f38a).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So far the networking test expression only generated a single test
depending on the passed "test" attribute. This makes it difficult to
autodiscover the subtests with our shiny new callSubTests function.
This change essentially doesn't change the behaviour of the subtests but
rather exposes them as an attribute set instead of relying on a
particular input argument.
The useNetworkd argument still exists however.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @wkennington
Now subtests are separate derivations, because the individual tests do
not depend on state from previous test runs.
This has the advantage that it's easier to run individiual tests and
it's also easier to pinpoint individual tests that randomly fail.
I ran all of these tests locally and they still succeed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It looks like now queue is not immediately cleared from cancelled jobs.
Instead, files like "c00001" are left alongside "d00001-001", and
cleanup happens at some later point of time. Also, all new jobs are
assigned consecutive numbers now (00002, 00003 etc.). So when
original d00001 file is finally cleaned, it breaks the test. Fixed
by checking for any "d*" file inside the queue and cleaning it by
ourselves to ensure that each job works correctly.
Allow usage of list of strings instead of a comma-separated string
for filesystem options. Deprecate the comma-separated string style
with a warning message; convert this to a hard error after 16.09.
15.09 was just released, so this provides a deprecation period during
the 16.03 release.
closes#10518
Signed-off-by: Robin Gloster <mail@glob.in>
Generally we shouldn't ship pre-release versions anyway, and we
certainly don't want them to be release blockers. Also, chromium
builds are just too slow to have them blocking the channel (see
https://github.com/NixOS/nixpkgs/issues/12794).
With the new upstream Git version of ioquake3 introduced in 7fc7502, the
arguments to the quake3(server) binaries/wrappers may no longer be
passed as full single arguments (like "+set foo bar") but rather as
separate arguments (like "+set" "foo" "bar"), otherwise they will be
completely ignored.
Ran the x86_64-linux test on my machine and it now succeeds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by 6b447a3c9b.
In this commit the Quake 3 demo data now have a meta attribute which
specifies the license as unfreeRedistributable.
While I haven't found anything official about that on the web, let's
just allow it to be used in the test because first of all, we have been
using it for a long time (since 2009, introduced in 497760b) and second,
because it will be quite some effort to rewrite the test with something
like OpenArena (particularily because we need coverage data and need to
use the ioquake3 version plus OpenArena-specific patches).
Tested evaluation on my local system, but the VM test still fails.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It serves as a regression test, because right now if you enable
networking.useNetworkd the default loopback interface doesn't get
assigned any IP addresses.
To be sure, I have bisected this and it has been introduced with the
update to systemd 228 in 1da87d4.
Only the "scripted" networking tests have to succeed in order to trigger
a channel update of nixos-unstable, so I'm leaving this test as broken
and we have to figure out next what's the *exact* reason for the
breakage.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
systemd-udev-settle is not started by default anymore.
Because checking for psmouse like that is considered legacy,
we start systemd-udev-settle manually in the test.
cc @edolstra
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
Commit 9bfe92ecee ("docker: Minor improvements, fix failing test") added
the services.docker.storageDriver option, made it mandatory but didn't
give it a default value. This results in an ugly traceback when users
enable docker, if they don't pay enough attention to also set the
storageDriver option. (An attempt was made to add an assertion, but it
didn't work, possibly because of how "mkMerge" works.)
The arguments against a default value were that the optimal value
depends on the filesystem on the host. This is, AFAICT, only in part
true. (It seems some backends are filesystem agnostic.) Also, docker
itself uses a default storage driver, "devicemapper", when no
--storage-driver=x options are given. Hence, we use the same value as
default.
Add a FIXME comment that 'devicemapper' breaks NixOS VM tests (for yet
unknown reasons), so we still run those with the 'overlay' driver.
Closes#10100 and #10217.
I'm not quite sure why the official Hydra gets a kernel panic in one of
two VMs using the exact same kernels:
https://hydra.nixos.org/build/26339384
Because the kernel panic happens before stage 1, let's wait for the
first VM to boot up and after the bootup is done, start the second one
in hope that it won't trigger the panic.
Oddly enough, whenever I run the test on my own Hydra and on my local
machines, I don't get anything like that.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I forgot to do this in da0e642. It shouldn't be a big problem but it's
more clean to destroy the VM once we're done testing.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We previously had 1024 MB of memory to fit a VirtualBox VM with 512 MB
plus the memory needed of the VirtualBox host VM. That obviously won't
work for two VirtualBox VMs, which are used for testing networking
between two VirtualBox guests.
Now, we have 2048 MB on the qemu guest (the VirtualBox host) and 768 MB
for each VirtualBox guest. That should be enough to fit in two
VirtualBox guests (I hope).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Unfortunately, we can't test whether USB is really working, but we can
make sure that VirtualBox has access to the USB devices.
This is essentially testing #9736, which I haven't yet been able to
reproduce though, but it makes sense to test it so it won't happen in
future releases.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Addresses #9876 in the way that we want to make sure that VirtualBox 5.x
is going to be properly detected. Right now the result is "kvm", so the
subtest fails as expected with:
error: systemd-detect-virt returned "kvm" instead of "oracle" at (eval
14) line 414, <__ANONIO__> line 92.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Makes it easier to debug and find out for which machine a certain log
socket has been started or stopped.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We're simply using antiquotation, since it's been a while since these
got introduced (in Nix 1.7). So we can use them because it makes the
code much more readable.
As usual, I made sure that I didn't accidentally change something in
functionality:
$ nix-instantiate nixos/tests/virtualbox.nix
...
/nix/store/cldxyrxqvwpqm02cd3lvknnmj4qmblyn-vm-test-run-virtualbox.drv
$ git stash pop
...
$ nix-instantiate nixos/tests/virtualbox.nix
...
/nix/store/cldxyrxqvwpqm02cd3lvknnmj4qmblyn-vm-test-run-virtualbox.drv
$
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is essentially not only "wrapping" the line but refactoring into a
shorter name which is used in two places.
And yes, I know I'm very pedantic if it comes to whitespaces and line
lengths, but I made sure this doesn't change any functionality:
$ nix-instantiate nixos/tests/virtualbox.nix
...
/nix/store/cldxyrxqvwpqm02cd3lvknnmj4qmblyn-vm-test-run-virtualbox.drv
$ git stash pop
...
$ nix-instantiate nixos/tests/virtualbox.nix
...
/nix/store/cldxyrxqvwpqm02cd3lvknnmj4qmblyn-vm-test-run-virtualbox.drv
$
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Instead of manually setting debug to true or false, this should make it
possible to now run the test like this:
nix-build nixos/tests/virtualbox.nix --arg debug true
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Sometimes there are random kernel panics do to the lack of memory in the
qemu guests, but as we're setting the VirtualBox memory size relatively
low, 1024 MB should be enough for the qemu guests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We want to check whether DBus functionality is working, so let's make
sure it is running in our mini-initrd.
DBus unfortunately requires to have users properly set up and another
configuration file other than in ${dbus.daemon}/etc/dbus-1/system.conf,
so we do provide that as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
