in read-only way. If the cache directory is empty and you use the
very same service for system's DNS, kresd is unable to bootstrap root
trust anchors, as it would need a DNS lookup.
Also, if we don't rely on bootstrap, the extra lua deps of kresd could
be dropped by default, but let's not do that now, as the difference in
closure size is only ~4 MB, and there may be other use cases than
running the package as nixos service this way.
The unnecessary dependency of sockets.target on kresd.service causes a
dependency cycle preventing kresd.service from starting at boot:
sockets.target -> kresd.service -> basic.target -> sockets.target
In commit ec9dc73 restarting NetworkManager after resume from
suspend/hibernate was introduced.
When I initially switch to NixOS I started noticing a high delay between
wakeup and re-connecting to WiFi & wired networks. The delay increased
from a few seconds (on my previous distro, same software stack) to
almost half a minute with NixOS.
I (locally) applied the change in this commit a few weeks ago and tested
since then. The notebook/mobile device experience has improved a lot.
Reconnects are as before switching to NixOS.
Issue #24401 could be related to this. Since I am not using KDE/plasma5
I can only guess…
Tunnel configuration has no member named "host" - i2pd does but it's called "address" in the options. As a result, no tunnel configuration is generated.
* Fix attribute check in inTunnels
* Fix integer to string coercion in inTunnels
* Add destinationPort option for outTunnels
Added the boolean option:
networking.networkmanager.enableStrongSwan
which enables the networkmanager_strongswan plugin and adds
strongswanNM to the dbus packages.
This was contributed by @wucke13, @eqyiel and @globin.
Fixes: #29873
* nghttpx: Add a new NixOS module for the nghttpx proxy server
This change also adds a global `uid` and `gid` for a `nghttpx` user
and group as well as an integration test.
* nixos/nghttpx: fix building manual
In the previous version multiple default values would generate an
invalid babeld config file since all options would be concatenated
without any separator.
* 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
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.
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).
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.
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 670b4e29ad. 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 23a021d12e)
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 670b4e29ad)
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.
