If one of the certificates of the chain gets substituted from a binary
cache and the rest is generated locally it might turn out that we get
invalid certificates, which in turn cause tests using this module to
fail.
So let's set allowSubstitutes to false for all derivations that are
involved with certificate/key generation.
Signed-off-by: aszlig <aszlig@nix.build>
For now check that the default client config boots.
Ideas for the future:
- Expand on control via netcat
- Configure a circuit of nodes exercise various configs (e.g., check
that a client node can access a hidden www service). Needs setting up
authoritative directory servers &c.
A script is used to create a project, and configure a jobset. This
jobset fetches a local file containing a trivial Nix expression. The
test script makes sure this derivation has been successfully built by
Hydra.
While building the container there are a few occasions where stdenvNoCC
is used underneath. During the last staging merge, some change now tries
to build texinfo during the test while building stdenvNoCC.
With this change, I'm adding stdenvNoCC to the closure to make sure that
even when we have future stdenv changes, it doesn't break (well, except
if we do have another variation like stdenvNoCC that overrides stdenv).
I haven't bisected the exact change, but I'd suspect that it could be
one of the commits in #39457.
This fixes the test and it no longer fails with the following error:
error: unable to download 'http://ftpmirror.gnu.org/texinfo/texinfo-6.5.tar.xz': Couldn't resolve host name (6)
builder for '/nix/store/r7sf1wjbnimwgnv276jh59nfnzw40x30-texinfo-6.5.tar.xz.drv' failed with exit code 1
cannot build derivation '/nix/store/5w1pv788ayi1wahyy76i90yqv96ai4h5-texinfo-6.5.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/cnsfkf0j5xmm14zzm5a3a66pz66gbc82-stdenv-linux.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/11kkhk57ic8kfd7g197sqwgd0pzqfjhl-nixos-system-foo-0-18.09pre-git.drv': 1 dependencies couldn't be built
error: build of '/nix/store/11kkhk57ic8kfd7g197sqwgd0pzqfjhl-nixos-system-foo-0-18.09pre-git.drv' failed
/run/current-system/sw/bin/nixos-container: failed to build initial container configuration
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @aristidb, @edolstra, @chaoflow, @kampfschlaefer
BIND doesn't allow the options section (or any section I'd guess) to be
defined more than once, so whenever you want to set an additional option
you're stuck using weird hacks like this:
services.bind.forwarders = lib.mkForce [ "}; empty-zones-enable no; #" ];
This basically exploits the fact that values coming from the module
options aren't escaped and thus works in a similar vain to how SQL
injection works.
Another option would be to just set configFile to a file that includes
all the options, including zones. That obviously makes the configuration
way less extensible and more awkward to use with the module system.
To make sure this change does work correctly I added a small test just
for that. The test could use some improvements, but better to have a
test rather than none at all. For a future improvement the test could be
merged with the NSD test, because both use the same zone file format.
This change has been reviewed in #40053 and after not getting any
opposition, I'm hereby adding this to master.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @peti, @edolstra
Closes: #40053
VMs were starving, many of the daemons were unable to complete their
tasks resulting in tests failures.
Turned off verbose output from k8s components as it consumes even more resources, and useful error messages actually drown in debug-clutter
1) Change start-type to ```notify``` when running MariaDB so that we don't have to busy-wait for the
socket to appear.
2) Do not manually create the directory under /run as we can get systemd to do
that for us. This opens up the possibility later for not having to launch as root.
`xsslock` (which was originally packaged in 6cb1d1aaaf)
is a simple screensaver which connects a given screen locker (e.g.
`i3lock`) with `logind`. Whenever `loginctl lock-sessions` is invoked
the locker will be used to lock the screen. This works with its power
management features (e.g. `lid switch`) as well, so the PC can be locked
automatically when the lid is closed.
The module can be used like this:
```
{
services.xserver.enable = true;
programs.xss-lock.enable = true;
programs.xss-lock.lockerCommand = "i3lock";
}
```
