It is no longer required to change the config your ipfs repo manually if you change
localDiscovery option in nixos configuration after ipfs repository initialization.
Ideally I'd like the whole `nixos`/`nixpkgs` channel distinction to disappear, but this is a step along that path. After a while being in this state, we can stop creating the magic `nixpkgs -> .` symlink inside our `nixos` channel tarballs and simplify that whole mess a bit.
Wireguard is now split into two pretty much independent packages:
`wireguard` (Linux-specific kernel module) and `wireguard-tools`,
which is cross-platform.
`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";
}
```
My c6f7d43678 made the mistake of not
having enough defaults. Now both variables are default as the *explicit*
value of the other, or a fallback. The fallback of `system` is the
default of `localSystem.system`. The fallback of `localSystem` is not
the other default (projected), as that would cause a cycle, but `{
system = builtins.currentTime; }` just as nixpkgs itself does it.
`statsd` is a daemon written in `node` to gather statistics over UDP.
The current test ensures that a port is open, but the basic
functionality isn't sufficiently tested.
This patch contains the following changes:
* Simplified port scanning (`waitForOpenPort` rather than `netcat` magic).
* Issue a TCP command to check the health of the `statsd` server.
* Simple script to check if `statsd` receives data over UDP and confirms
the basic functionality of the TCP interface on `8126` for admin
purposes.
* networking/stubby.nix: implementing systemd service module for stubby
This change implements stubby, the DNS-over-TLS stub resolver daemon.
The motivation for this change was the desire to use stubby's
DNS-over-TLS funcitonality in tandem with unbound, which requires
passing certain configuration parameters. This module implements those
config parameters by exposing them for use in configuration.nix.
* networking/stubby.nix: merging back module list
re-merging the module list to remove unecessary changes.
* networking/stubby.nix: removing unecessary capabilities flag
This change removes the unecessary flag for toggling the capabilities
which allows the daemon to bind to low ports.
* networking/stubby.nix: adding debug level logging bool
Adding the option to turn on debug logging.
* networking/stubby.nix: clarifying idleTimeout and adding systemd target
Improving docs to note that idleTimeout is expressed in ms. Adding the
nss-lookup `before' target to the systemd service definition.
* networking/stubby.nix: Restrict options with types.enum
This change restricts fallbackProtocol and authenticationMode to accept
only valid options instead of any list or str types (respectively). This
change also fixes typo in the CapabilityBoundingSet systemd setting.
* networking/stubby.nix: cleaning up documentation
Cleaning up docs, adding literal tags to settings, and removing
whitespace.
* networking/stubby.nix: fixing missing linebreak in comments
* networking/stubby.nix: cleaning errant comments
* improve nix installation instructions
in the command
$ bash <(curl https://nixos.org/nix/install)
<(..) is a bashism. The documentation now show a command that does
not require to be executed by bash.
In commit 17dd7bcd89 the systemd unit
generator now uses lndir instead of "ln -s", so we need to have lndir
available in the Nix store for the installer tests to be able to build
the units and thus the whole system.
This should fix the installer tests, although I have only tested it with
the "simple" subtest.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @jtojnar, @xeji, @edolstra
When doing source routing/multihoming, it's practical to give names to routing
tables. The absence of the rt_table file in /etc make this impossible.
This patch recreates these files on rebuild so that they can be modified
by the user see NixOS#38638.
iproute2 is modified to look into config.networking.iproute2.confDir instead of
/etc/iproute2.
The manual still had a reference to an option that was already renamed
ages ago and a7ed44ccad made it 'visible'.
With the visible attribute set to false for extraKernelModules, the
option no longer appears in the manual and thus breaks the link from the
manual to the options.
This is easily fixed by referring to boot.initrd.kernelModules instead
of the obsolete option boot.initrd.extraKernelModules.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @rycee, @matthewbauer
The original `nexus` derivation required `/run/sonatype-work/nexus3`
which explicitly depended on the NixOS path structure.
This would break `nexus` for everyone using `nixpkgs` on a non-NixOS
system, additionally the module never created `/run/sonatype-work`, so
the systemd unit created in `services.nexus` fails as well. The issue
wasn't actively known as the `nixos/nexus` test wasn't registered in
Hydra (see #40257).
This patch contains the following changes:
* Adds `tests.nexus` to `release.nix` to run the test on Hydra.
* Makes JVM parameters configurable: by default all JVM options were located
in `result/bin/nexus.vmoptions` which made it quite hard to patch
these parameters. Now it's possible to override all parameters by
running `VM_OPTS_FILE=custom-nexus.vmoptions ./result/bin/nexus run`
(after patching the `nexus` shell script), additionally it's possible
to override these parameters with `services.nexus.vmoptions`.
* Bumped Nexus from 3.5.1 to 3.11.0
* Run the `nexus` test on Hydra with `callTest` in `nixos/release.nix`,
furthermore the test checks if the UI is available on the specified
port.
* Added myself as maintainer for the NixOS test and the package to have
some more people in case of further breakage.
* Added sufficient disk space to the `nexus` test, otherwise the service
fails with the following errors:
```
com.orientechnologies.orient.core.exception.ODatabaseException: Cannot create database 'accesslog'
com.orientechnologies.orient.core.exception.OLowDiskSpaceException: Error occurred while executing
a write operation to database 'accesslog' due to limited free space on the disk (242 MB). The database
is now working in read-only mode. Please close the database (or stop OrientDB), make room on your hard
drive and then reopen the database. The minimal required space is 256 MB. Required space is now set to
256MB (you can change it by setting parameter storage.diskCache.diskFreeSpaceLimit) .
```
/cc @ironpinguin @xeji
When a package contains a directory in one of the systemd directories
(like flatpak does), it is symlinked into the *-units derivation.
Then later, the derivation will try to create the directory, which
will fail:
mkdir: cannot create directory '/nix/store/…-user-units/dbus.service.d': File exists
builder for '/nix/store/…-user-units.drv' failed with exit code 1
Closes: #33233
GRUB 2.0 supports png, jpeg and tga. This will use the image's suffix to
load the right module.
As jpeg module is named jpeg, jpg is renamed jpeg.
If the user uses wrong image suffix for an image, it wouldn't work anyway.
This will leave up to two additional left-over files in /boot/ if user switches
through all the supported file formats. The module already left the png
image if the user disabled the splash image.
If docker is enabled, start mesos-slave.service after docker.service
to avoid a race condition that could result in mesos-slave to fail
with "Failed to create docker: Timed out getting docker version"
The pull request that added dhparams (#39507) was made at the time where
the dhparams module overhaul (#39526) wasn't done yet, so it's still
using the old mechanics of the module.
As stated in the release notes:
Module implementers should not set a specific bit size in order to let
users configure it by themselves if they want to have a different bit
size than the default (2048).
An example usage of this would be:
{ config, ... }:
{
security.dhparams.params.myservice = {};
environment.etc."myservice.conf".text = ''
dhparams = ${config.security.dhparams.params.myservice.path}
'';
}
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @qknight, @abbradar, @hrdinka, @leenaars
Regression introduced by d4468bedb5.
No systemd messages are shown anymore during VM test runs, which is not
very helpful if you want to find out about failures.
There is a bit of a conflict between testing and the change that
introduced the regression. While the mentioned commit makes sure that
the primary console is tty0 for virtualisation.graphics = false, our VM
tests need to have the serial console as primary console.
So in order to support both, I added a new virtualisation.qemu.consoles
option, which allows to specify those options using the module system.
The default of this option is to use the changes that were introduced
and in test-instrumentation.nix we use only the serial console the same
way as before.
For test-instrumentation.nix I didn't add a baudrate to the serial
console because I can't find a reason on top of my head why it should
need it. There also wasn't a reason stated when that was introduced in
7499e4a5b9.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @flokli, @dezgeg, @edolstra
after seeing
`adjtime failed: Invalid argument` in my syslog, I tried using
`ntpd -s` but it would trigger
`/etc/ntpd.conf: No such file or directory`
see https://github.com/NixOS/nixpkgs/issues/31885
Instead of running the daemon with a specific config file, use the
standard file so that user are able to use the ntp executable without
having to look for the current config file.
Tracking scripts in particular, cannot be included in extraOpts, because script declaration has to be above script usage in keepalived.conf.
Changes are fully backward compatible.
This introduces an option that allows us to turn off stateful generation
of Diffie-Hellman parameters, which in some way is still "stateful" as
the generated DH params file is non-deterministic.
However what we can avoid with this is to have an increased surface for
failures during system startup, because generation of the parameters is
done during build-time.
Aside from adding a NixOS VM test it also restructures the type of the
security.dhparams.params option, so that it's a submodule.
A new defaultBitSize option is also there to allow users to set a
system-wide default.
I added a release notes entry that described what has changed and also
included a few notes for module developers using this module, as the
first usage already popped up in NixOS/nixpkgs#39507.
Thanks to @Ekleog and @abbradar for reviewing.
Always enable both tty and serial console, but set preferred console
depending on cfg.graphical.
Even in qemu graphical mode, you can switch to the serial console via
Ctrl+Alt+3.
With that being done, you also don't need to specify
`systemd.services."serial-getty@ttyS0".enable = true;` either as described in
https://nixos.wiki/wiki/Cheatsheet#Building_a_service_as_a_VM_.28for_testing.29,
as systemd automatically spawns a getty on consoles passwd via cmdline.
This also means, vms built by 'nixos-rebuild build-vm' can simply be run
properly in nographic mode by appending `-nographic` to `result/bin/run-*-vm`,
without the need to explicitly add platform-specific QEMU_KERNEL_PARAMS.
This is not only to make users aware of the changes but also to give a
heads up to developers which are using the module. Specifically if they
rely on security.dhparams.path only.
Signed-off-by: aszlig <aszlig@nix.build>
This allows to set the default bit size for all the Diffie-Hellman
parameters defined in security.dhparams.params and it's particularly
useful so that we can set it to a very low value in tests (so it doesn't
take ages to generate).
Regardless for the use in testing, this also has an impact in production
systems if the owner wants to set all of them to a different size than
2048, they don't need to set it individually for every params that are
set.
I've added a subtest to the "dhparams" NixOS test to ensure this is
working properly.
Signed-off-by: aszlig <aszlig@nix.build>
When trying to run NSD to serve the root zone, one gets the following
error message:
error: illegal name: '.'
This is because the name of the zone is used as the derivation name for
building the zone file. However, Nix doesn't allow derivation names
starting with a period.
So whenever the zone is "." now, the file name generated is "root"
instead of ".".
I also added an assertion that makes sure the user sets
services.nsd.rootServer, otherwise NSD will fail at runtime because it
prevents serving the root zone without an explicit compile-time option.
Tested this by adding a root zone to the "nsd" NixOS VM test.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @hrdinka, @qknight
Without fcrontab being setuid, every attempt by an user in the fcron
group to edit their own crontab (via `fcrontab -e`) results in the
following error:
```
2018-05-06 11:29:07 ERROR could not change euid to 273: Operation not permitted
2018-05-06 11:29:07 ERROR fcron child aborted: this does not affect the main fcron daemon, but this may prevent a job from being run or an email from being sent.
```
Adding setuid by hand has resolved this issue and aligns with the way
fcrontab is installed on other distributions.
I ended up with a corrupted image with the debugfs contraption once, and
given I couldn't reproduce the problem I suppose that happens if the
filesystem of the builder runs out of space.
At least in this instance fsck could detect it, so let's add it as a
sanity check.
lib.optional returns a singleton or an empty list. Therefore the
argument does not need to be wrapped in a list.
An alternative patch could have used lib.optionals but seems like no
more elements are going to be added to the optional list.
This is apparent from the service file directory in plymouth:
├── multi-user.target.wants
│ ├── plymouth-quit.service -> ../plymouth-quit.service
│ └── plymouth-quit-wait.service -> ../plymouth-quit-wait.service
Leaving it unspecified caused gdm-wayland to crash on boot, see #39615.
The change made other display managers not quit plymouth properly however. By
removing "multi-user.target" from `plymouth-quit.after` this is resolved.
The following changes have been applied:
- the property `http.headers.X-Content-Type-Options` must a list of
strings rather than a serialized list
- instead of `/etc/docker/registry/config.yml` the configuration will be
written with `pkgs.writeText` and the store path will be used to run
the registry. This reduces the risk of possible impurities by relying
on the Nix store only.
- cleaned up the property paths to easy readability and reduce the
verbosity.
- enhanced the testcase to ensure that digests can be deleted as well
- the `services.docker-registry.extraConfig` object will be merged with
`registryConfig`
/cc @ironpinguin
Some time ago I fixed the broken package `osquery` (see #39336).
I had to test the package manually by starting the daemon locally,
however this doesn't ensure that the module is still functional.
In order to cover the package *and* the integration with the NixOS
module I thought that adding a testcase might be the best idea.
The current testcase does the following things:
* Starts an `osqueryd` service in a test machine with customized logger
path and PID file
* Ensures that the `osqueryd.service` unit is running
* Checks if the customized flags (`pidfile`, `logger_path`) are applied
to `osquery`.
* Performs a simple test query against the `etc_hosts` database to check
if the basic funcitonality of `osquery` (storing system information into
a database) works fine.
@Ekleog writes in https://github.com/NixOS/nixpkgs/pull/39526:
> I think a default of 4096 is maybe too much? See certbot/certbot#4973;
> Let's Encrypt supposedly know what they are doing and use a
> pre-generated 2048-bit DH params (and using the same DH params as
> others is quite bad, even compared to lower bit size, if I correctly
> remember the attacks available -- because it increases by as much the
> value of breaking the group).
> Basically I don't have anything personal against 4096, but fear it may
> re-start the arms race: people like having "more security" than their
> distributions, and having NixOS already having more security than is
> actually useful (I personally don't know whether a real-size quantum
> computer will come before or after our being able to break 2048-bit
> keys, let alone 3072-bit ones -- see wikipedia for some numbers).
> So basically, I'd have set it to 3072 in order to both decrease build
> time and avoid having people setting it to 8192 and complaining about
> how slow things are, but that's just my opinion. :)
While he suggests is 3072 I'm using 2048 now, because it's the default
of "openssl dhparam". If users want to have a higher value, they can
still change it.
Signed-off-by: aszlig <aszlig@nix.build>
The ability to specify "-drive if=scsi" has been removed in QEMU version
2.12 (introduced in 3e3b39f173).
Quote from https://wiki.qemu.org/ChangeLog/2.12#Incompatible_changes:
> The deprecated way of configuring SCSI devices with "-drive if=scsi"
> on x86 has been removed. Use an appropriate SCSI controller together
> "-device scsi-hd" or "-device scsi-cd" and a corresponding "-blockdev"
> parameter instead.
So whenever the diskInterface is "scsi" we use the new way to specify
the drive and fall back to the deprecated way for the time being. The
reason why I'm not using the new way for "virtio" and "ide" as well is
because there is no simple generic way anymore to specify these.
This also turns the type of the virtualisation.qemu.diskInterface option
to be an enum, so the user knows which values are allowed but we can
also make sure the right value is provided to prevent typos.
I've tested this against a few non-disk-related NixOS VM tests but also
the installer.grub1 test (because it uses "ide" as its drive interface),
the installer.simple test (just to be sure it still works with
"virtio") and all the tests in nixos/tests/boot.nix.
In order to be able to run the grub1 test I had to go back to
8b1cf100cd (which is a known commit where
that test still works) and apply the QEMU update and this very commit,
because right now the test is broken.
Apart from the tests here in nixpkgs, I also ran another[1] test in
another repository which uses the "scsi" disk interface as well (in
comparison to most of the installer tests, this one actually failed
prior to this commit).
All of them now succeed.
[1]: 9b5a119972/tests/system/kernel/bfq.nix
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edostra, @grahamc, @dezgeg, @abbradar, @ts468
The usb_add and usb_del monitor commands have been removed in QEMU
version 2.12 (introduced in 3e3b39f173).
Quote from https://wiki.qemu.org/ChangeLog/2.12#Incompatible_changes:
> The deprecated HMP commands "usb_add" and "usb_del" have been removed.
> Use "device_add" and "device_del" as replacement instead.
So we're doing exactly that and the udisks2 test now works again.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra
I'm not sure why 024b501907 used -q 0
because even netcat-openbsd has the -N flag which IMO is the better way
to shutdown the socket on EOF.
Our default netcat implementation has changed once again[1] in
3c3b82234a and we're now using LibreSSL's
implementation, which doesn't have a -q flag.
See https://github.com/NixOS/nixpkgs/pull/39634 for the pull request
introducing the switch.
[1]: https://github.com/NixOS/nixpkgs/pull/19982
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @matthewbauer, @dtzWill, @Mic92
Previously the script would contain an empty `if` block (which is invalid
syntax) if both `data.activationDelay == null` and `data.postRun == ""`. Fix
this by adding a no-op `true`.
The Nix expression here is really hard to read with multiple (and
unnecessarily) nested lets and it also generates attribute names based
on the derivation generated by makeTest, which will result in these
attribute names:
* vm-test-run-predictableInterfaceNames
* vm-test-run-predictableInterfaceNames-with-networkd
* vm-test-run-unpredictableInterfaceNames
* vm-test-run-unpredictableInterfaceNames-with-networkd
With the refactor the attribute names are now:
* predictable
* predictableNetworkd
* unpredictable
* unpredictableNetworkd
So now the code is even shorter and IMHO slightly more readable.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @symphorien, @fpletz, @adisbladis
This is a very very very ugly workaround and it's because Chromium seems
to eat keystroke for a few seconds after a new window is created.
I haven't found a better solution yet, so let's at least unbreak the
test until we come up with a better way.
Thanks to @vcunat for bringing this to my attention and also doing the
initial bisect.
The change that brought up this problem was 2b29e40153,
which updated Chromium from version 65.0.3325.181 to version
66.0.3359.117. Unfortunately the upstream changelog[1] is way too large
to actually guess what the breaking change is.
[1]: https://chromium.googlesource.com/chromium/src/+log/65.0.3325.181..66.0.3359.117?pretty=fuller&n=10000
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @bendlas, @vcunat
As suggested in https://github.com/NixOS/nixpkgs/pull/39416#discussion_r183845745
the versioning attributes in `lib` should be consistent to
`nixos/version` which implicates the following changes:
* `lib.trivial.version` -> `lib.trivial.release`
* `lib.trivial.suffix` -> `lib.trivial.versionSuffix`
* `lib.nixpkgsVersion` -> `lib.version`
As `lib.nixpkgsVersion` is referenced several times in `NixOS/nixpkgs`,
`NixOS/nix` and probably several user's setups. As the rename will cause
a notable impact it's better to keep `lib.nixpkgsVersion` as alias with
a warning yielded by `builtins.trace`.
mke2fs has this annoying property that it uses getrandom() to get random
numbers (for whatever purposes) which blocks until the kernel's secure
RNG has sufficient entropy, which it usually doesn't in the early boot
(except if your CPU supports RDRAND) where we may need to create the
root disk.
So let's give the VM a virtio RNG to avoid the boot getting stuck at
mke2fs.
Ubiquiti has both a LTS and current version of their Unifi controller software.
The latter adds new features, but may drop support for some devices.
This adds the capability to use either for the unifi module but defaults
to the LTS version, which was the previous behavior.
Previously we indirectly suggested that the user use
services.printing.extraConf to set this, but this doesn't work with the
default merge ordering. Fix this by making it an independent option.
Fixes#39611.
