The submodule of the "docker-containers" option isn't recognized as a
proper submodule and thus neither properly type-checks nor are its
options included in the manual.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by a02bb00156.
The fix is done by disabling writableStore, because the latter will set
up an overlayfs on the Nix store within the VM, which in turn will
discard all the outputs of the resulting output path.
However in runInMachine we actually *want* the contents of the generated
path and also don't want a writable store within the VM (except of
course for $out, which is writable anyway).
I've added a small regression test to verifify the output in
nixos/tests/run-in-machine.nix to make sure this won't break again in
the future.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by 801c920e95.
Since then, the btrfsSimple subtest of the installer VM test fails with:
Btrfs did not return a path for the subvolume at /
The reason for this is that the output for "btrfs subvol show" has
changed between version 4.8.2 and 4.13.1.
For example the output of "btrfs subvol show /" in version 4.8.2 was:
/ is toplevel subvolume
In version 4.13.1, the output now is the following and thus the regular
expressions used in nixos-generate-config.pl and install-grub.pl now
match (which results in the error mentioned above):
/
Name: <FS_TREE>
UUID: -
Parent UUID: -
Received UUID: -
Creation time: -
Subvolume ID: 5
Generation: 287270
Gen at creation: 0
Parent ID: 0
Top level ID: 0
Flags: -
Snapshot(s):
In order to fix this I've changed nixos-generate-config.pl and
install-grub.pl, because both use "btrfs subvol show" in a similar vein,
so the regex for parsing the output now doesn't match anymore whenever
the volume path is "/", which should result in the same behaviour as we
had with btrfs-progs version 4.8.2.
Tested against the btrfsSimple, btrfsSubvols and btrfsSubvolDefault
subtests of the installer VM test and they all succeed now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The output of ./configure shows all modules/plugins, both enabled and
disabled. With this info we can finally build the _complete_ list of
modules. We were missing these:
mod_authn_gssapi
mod_authn_ldap
mod_geoip
(I hit this as I was building lighttpd with ldap support and the NixOS
module said ldap was unsupported, due to these missing entries in
allKnownModules.)
powertop attempt to load some kernel modules like msr by calling
modprobe. This is the counterpart to
88e43eb39b which has the powertop
executable search PATH for modprobe rather than hardcoding /sbin, and
actually adds the directory containing modprobe to its PATH for the
systemd service.
* Safer defaults for immutable znc config
I just lost all the options I configured in ZNC, because the mutable config was overwritten.
I accept any suggestions on the way to implement this, but overwriting a mutable config by default seems weird. If we want to do this, we should ensure that ZNC does not allow to edit the config via the webmin when cfg.mutable is false.
* Do not backup old config files.
There seems to be little need for backups if mutable becomes a voluntary opt-out.
* fixup
* the keyboard modules in all-hardware.nix are already defaults of
boot.initrd.availableKernelModules
* ide modules, hid_lenovo_tpkbd and scsi_wait_scan have been removed
because they're not available anymore
* i8042 was a duplicate (see few lines abowe)
All available options were just enabling
hardware.enableRedistributableFirmware. There were nix files without
modules which weren't referenced anywhere.
Container config example code mentions `postgresql` service, but the correct use of that service involves setting `system.stateVersion` option (as discovered in https://github.com/NixOS/nixpkgs/issues/30056).
The actual system state version is set randomly to 17.03 because I have no preferences here
The current `remotes` option is a string option containing nullmailer remote
definitions. However, those definitions may contain secret credentials and
should therefore not be put world-readable in the nix store.
I added a `remotesFile` option, which allows to specify a path to the remotes
definition file instead. This way, the definitions can be kept outside of the
nix store with more secure file permissions.
We now wait for dhcpcd to acquire a lease but dhcpcd is restarted on
system activation. As wpa_supplicant is stopped while dhcpcd is
restarting a significant delay is introduced on systems with wireless
network connections only. This changes the wpa_supplicant service to
also be restarted together with dhcpcd in case both services were
changed.
This reverts commit 0c81594a29.
It's no longer needed since systemd-vconsole-setup enumerates all ttys
until it finds a suitable one since systemd v234.
The current version is broken:
- there's no `openFirewall` attribute directly in the `cfg` set
- the `port` option is an attribute of the `confOptions` set
I used the proper attribute for the firewall port and moved the `openFirewall`
option directly up to the `services.znc` set, as it's rather a general option
for the whole service than a znc-specific option (which are located inside the
`confOptions` set).
This introduces dependency cycles.
A network file system to be running is not required for a network
connection to be available.
19759cfeab (commitcomment-22044519)
* Grants enough privileges to the configured user so that it can run
mysqldump.
* Adds a nixos test.
* Use systemd timers instead of a cronjob (by @fadenb).
* Creates a new user for backups by default, instead of using mysql
user.
* Ensures that backup user has write permissions on backup location.
* Write backup to a temporary file before renaming so that a failed
backup won't overwrite the previous backup, and so that the backup
location will never contain a partial backup.
Breaking changes:
* Renamed period to calendar to reflect the change in how to
configure the backup time.
* A failed backup will no longer result in cron sending an e-mail --
users' monitoring systems must be updated.
Resolves#24728
Spamassassin expects its system-wide configuration at /etc/spamassassin, and
some user tools (like sa-learn) need to read those configuration files.
Therefore, we provide a symlink from /etc/spamassassin to the appropriate Nix
store path to make sure those tools work without the user having to pass an
elaborate --siteconfig path that, potentially, changes every time the system
updates.
Fixes https://github.com/NixOS/nixpkgs/issues/29414.
Sometimes (especially in the default route case) it is required to NOT
add routes for all allowed IP ranges. One might run it's own custom
routing on-top of wireguard and only use the wireguard addresses to
exchange prefixes with the remote host.
Systemd is complaining that it can't delay the startup of device units.
We have a before dependency on the respective device unit for every
netdev service, which doesn't make any sense because we create the
actual interface in this service.
Previously, depending on the environment and the type of interface that
was created, the configured IPs of an interface wouldn't be applied on a
nixos-rebuild switch. It works after a reboot.
This patch ensures that the network-addresses service is started
either via the network-link service or if the networking target is
activated (i.e. on system activation).
Fixes#28474#16230.
* gnome3: only maintain single GNOME 3 package set
GNOME 3 was split into 3.10 and 3.12 in #2694. Unfortunately, we barely have the resources
to update a single version of GNOME. Maintaining multiple versions just does not make sense.
Additionally, it makes viewing history using most Git tools bothersome.
This commit renames `pkgs/desktops/gnome-3/3.24` to `pkgs/desktops/gnome-3`, removes
the config variable for choosing packageset (`environment.gnome3.packageSet`), updates
the hint in maintainer script, and removes the `gnome3_24` derivation from `all-packages.nix`.
Closes: #29329
* maintainers/scripts/gnome: Use fixed GNOME 3 directory
Since we now allow only a single GNOME 3 package set, specifying
the working directory is not necessary.
This commit sets the directory to `pkgs/desktops/gnome-3`.
- add flannel support
- remove deprecated authorizationRBACSuperAdmin option
- rename from deprecated poratalNet to serviceClusterIpRange
- add nodeIp option for kubelet
- kubelet, add br_netfilter to kernelModules
- enable firewall by default
- enable dns by default on node and on master
- disable iptables for docker by default on nodes
- dns, restart on failure
- update tests
and other minor changes
1. The chmod 400 with the preset cookie prevented restarts, as
on the second boot it would fail to write to the cookie. Oops.
2. As far as I can tell, sasl logs were disabled because of the
following error:
{error,{cannot_log_to_tty,sasl_report_tty_h,not_installed}}
Not because we actually wanted to disable them. This meant the
management plugin wasn't usable due to a bug set to be fixed in
3.7.0.
Add another option for debugging instead. Lots of users have been
complaining about this default behaviour.
This patch also cleans up the EFI bootloader entries in the ISO.
This has been broken nearly all the time due to the patches needed to
iproute2 not being compatible with the newer versions we have been
shipping. As long as Ubuntu does not manage to upstream these changes
so they are maintained with iproute2 and we don't have a maintainer
updating these patches to new iproute2 versions it is not feasible to
have this available.
This reverts commit 670b4e29adc16e0a29aa5b4c126703dcca56aeb6. The change
added in this commit was controversial when it was originally suggested
in https://github.com/NixOS/nixpkgs/pull/29205. Then that PR was closed
and a new one opened, https://github.com/NixOS/nixpkgs/pull/29503,
effectively circumventing the review process. I don't agree with this
modification. Adding an option 'resolveLocalQueries' to tell the locally
running name server that it should resolve local DNS queries feels
outright nuts. I agree that the current state is unsatisfactory and that
it should be improved, but this is not the right way.
(cherry picked from commit 23a021d12e8f939cd0bfddb1c7adeb125028c1e3)
Ensure that modules required by all declared fileSystems are explicitly
loaded. A little ugly but fixes the deferred mount test.
See also https://github.com/NixOS/nixpkgs/issues/29019
This includes fuse-common (fusePackages.fuse_3.common) as recommended by
upstream. But while fuse(2) and fuse3 would normally depend on
fuse-common we can't do that in nixpkgs while fuse-common is just
another output from the fuse3 multiple-output derivation (i.e. this
would result in a circular dependency). To avoid building fuse3 twice I
decided it would be best to copy the shared files (i.e. the ones
provided by fuse(2) and fuse3) from fuse-common to fuse (version 2) and
avoid collision warnings by defining priorities. Now it should be
possible to install an arbitrary combination of "fuse", "fuse3", and
"fuse-common" without getting any collision warnings. The end result
should be the same and all changes should be backwards compatible
(assuming that mount.fuse from fuse3 is backwards compatible as stated
by upstream [0] - if not this might break some /etc/fstab definitions
but that should be very unlikely).
My tests with sshfs (version 2 and 3) didn't show any problems.
See #28409 for some additional information.
[0]: https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0
The getty@.service unit already has an ExecStart so we cannot simply set a new
one in order to override it or we will get this error:
systemd[1]: getty@tty1.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing.
Instead "reset" ExecStart by setting it to empty which is the systemd way of
doing it.
Currently the `rpc-gssd.service` has a `ConditionPathExists` clause that can
never be met, because it's looking for stateful data inside `/nix/store`.
`auth-rpcgss-module.service` also only starts if this file exists.
FixesNixOS/nixpkgs#29509.
When the user specifies the networking.nameservers setting in the
configuration file, it must take precedence over automatically
derived settings.
The culprit was services.bind that made the resolver set to
127.0.0.1 and ignore the nameserver setting.
This patch adds a flag to services.bind to override the nameserver
to localhost. It defaults to true. Setting this to false prevents the
service.bind and dnsmasq.resolveLocalQueries settings from
overriding the users' settings.
Also, when the user specifies a domain to search, it must be set in
the resolver configuration, even if the user does not specify any
nameservers.
(cherry picked from commit 670b4e29adc16e0a29aa5b4c126703dcca56aeb6)
This commit was accidentally merged to 17.09 but was intended for
master. This is the cherry-pick to master.
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.
If neither database.password or database.passwordFile were provided,
it would try and fail to coerce null to a string.
This fixes the situation where there is no password for the database.
Resolves#27950
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
the systemd.unit(5) discussion of wantedBy and requiredBy is in the
[Install] section, and thus focused on stateful 'systemctl enable'.
so, clarify that in NixOS, wantedBy & requiredBy are still what most
users want, and not to be confused with enabled.
Arguably, breaking linux-latest should not block a release. Also, booting
the kernel + basic sanity checking is implicitly exercised by every other
vm test.
For various reasons, big Nix attrsets look ugly in the generated manual
page[1]. Use literalExample to fix it.
[1] Quotes around attribute names are lost, newlines inside multi-line
strings are shown as '\n' and attrs written on multiple lines are joined
into one.
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>
Boot fails when a keyfile is configured for all encrypted filesystems
and no other luks devices are configured. This is because luks support is only
enabled in the initrd, when boot.initrd.luks.devices has entries. When a
fileystem has a keyfile configured though, it is setup by a custom
command, not by boot.initrd.luks.
This commit adds an internal config flag to enable luks support in the
initrd file, even if there are no luks devices configured.
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>
10k staging builds are not yet finished on Hydra (mostly darwin),
but we now have a 20k jobs rebuilding directly on master, so we would
never get to merge this way...
It doesn't look good when the initial admin user is named
"<hash>-gitolite-admin" and the key stored as
"<hash>-gitolite-admin.pub". Instead, make it simply "gitolite-admin"
and "gitolite-admin.pub".
* prometheus-collectd-exporter service: init module
Supports JSON and binary (optional) protocol
of collectd.
* nixos/prometheus-collectd-exporter: submodule is not needed for collectdBinary
There are currently two ways to build Openstack image. This just picks
best of both, to keep only one!
- Image is resizable
- Cloudinit is enable
- Password authentication is disable by default
- Use the same layer than other image builders (ec2, gce...)
- sysctl is new and never succeeded on i686-linux
> cannot stat /proc/sys/net/core/bpf_jit_enable: No such file or directory
- testing plasma5 on i686 would defeat part of the reason why we ended
supporting i686 (lots of stuff built on Hydra)
Update physlock to a more current version which supports PAM and
systemd-logind. Amongst others, this should work now with the slim
login manager without any additional configuration, because it does
not rely on the utmp mechanism anymore.
The section was strange to read, as the initial example already used
`listOf' which is mentioned in the very first paragraph. Then you read
in a subsection about `listOf' and the exact same example is given
once again.
This file was removed in 6f0b538044, but sufficient care was not taken
to remove all references to it. Without this change, trying to
rebuild nixos fails.
I realize that advanced users like to configure services with Nix
attrsets, but I don't think we should remove the option to use the
(configuration) language provided by upstream.
When keys get refreshed a folder with the permissions of the root user
get created in the home directory of the user dnscrypt-wrapper. This
prevents the service from restarting.
In addition to that the parameters of dnscrypt-wrapper have
changed in upstream and in the newly packaged software.
Grub configs include the NixOS version and date they were built, now
systemd can have fun too:
version Generation 99 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-08-30
version Generation 100 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-08-30
version Generation 101 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-08-31
version Generation 102 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-09-01
version Generation 103 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-09-02
version Generation 104 NixOS 17.09beta41.1b8c7786ee, Linux Kernel 4.9.46, Built on 2017-09-02
version Generation 105 NixOS 17.09.git.1b8c778, Linux Kernel 4.9.46, Built on 2017-09-02
I missed this in 799435b7ca.
This time I used "git grep -F pythonPackages.deluge" just to be sure :-)
Thanks a lot to @roconnor for spotting this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: @roconnor
