I noticed this minor grammar mistake when running update.nix, and then
while grepping to find the source I noticed we had it a few times in
Nixpkgs. Just as easy to fix treewide as it was to fix the one
occurrence I noticed.
Dash `echo` interprets backslash escapes. This causes two consecutive backslashes in JSON to turn into a single one before the string is passed to jq, resulting in a parsing error.
This is useful for situations in which you might want to reset certain
things using `--reset-database` or `--reset-deltas` or debug certain
things using any of the debug options like `--debug-perf-stats`.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This sets up a different systemd service for each interface. This way
each wpa_supplicant instance waits for his inteface to become ready
using the respective device unit, and that only. The configuration file
is still shared between all instances, though.
This closes a longstanding "fixme" from cbfba81.
- Add an option to automatically launch a scan when the
signal of the current network is low
- Enable 802.11r (fast access point transition) by default for all
protected networks
I may have finally found a clean solution to the issues[1][2][3] with
the automatic discovery of wireless network interfaces.
[1]: https://github.com/NixOS/nixpkgs/issues/101963
[2]: https://github.com/NixOS/nixpkgs/issues/23196
[3]: https://github.com/NixOS/nixpkgs/pull/125917#issuecomment-856000426
Currently the start script fails right away if no interface is available
by the time it's running, possibly leaving the system without network.
This happens when running a little early in the boot. A solution is to
instead wait for at least one interface to appear before scanning the
/sys/class/net/ directory. This is done here by listening for the right
udev events (from the net/wlan subsystem) using the `udevadm monitor`
command and grep to match its output.
This methods guarantees the availability of at least one interface to
wpa_supplicant, but won't add additional interfaces once it has started.
However, if the current interface is lost, say unplugged, the service is
automatically stopped and will be restarted as soon as a one (not
necessarily the same) is detected. It would be possible make this fully
dynamic by running another service that continously listen for udev
events and manages the main wpa_supplicant daemon, but this is probably
overkill.
I tested the following cases:
- one interface, starting at boot, w/o predictable naming scheme
- two interfaces, starting at boot (intel wireless and a usb adapter),
w/o predictable naming scheme
- one interface after the system booted, w/o predictable naming scheme
- two interfaces after the system booted, w/o predictable naming scheme
- unplugging and plugging back the current interface
The pppd daemon starting with version 2.4.9 uses rtnetlink to configure
the ipv6 peer address on the ppp interface. It therefore requires
allowing AF_NETLINK sockets.
The kernel before version 5.7 required CAP_SYS_ADMIN to conduct BPF
operations. After that a separate capability CAP_BPF was created, which
should be sufficient in this scenario and will further tighten the
sandbox around our pppd service.
Tested on my personal DSL line.
- The order of NSS (host) modules has been brought in line with upstream
recommendations:
- The `myhostname` module is placed before the `resolve` (optional) and `dns`
entries, but after `file` (to allow overriding via `/etc/hosts` /
`networking.extraHosts`, and prevent ISPs with catchall-DNS resolvers from
hijacking `.localhost` domains)
- The `mymachines` module, which provides hostname resolution for local
containers (registered with `systemd-machined`) is placed to the front, to
make sure its mappings are preferred over other resolvers.
- If systemd-networkd is enabled, the `resolve` module is placed before
`files` and `myhostname`, as it provides the same logic internally, with
caching.
- The `mdns(_minimal)` module has been updated to the new priorities.
If you use your own NSS host modules, make sure to update your priorities
according to these rules:
- NSS modules which should be queried before `resolved` DNS resolution should
use mkBefore.
- NSS modules which should be queried after `resolved`, `files` and
`myhostname`, but before `dns` should use the default priority
- NSS modules which should come after `dns` should use mkAfter.
This allows users of the bind module to specify an alternate BIND
package. For example, by overriding the source attribute to use a
different version of BIND.
Since the default value for `services.bind.package` is `pkgs.bind`,
this change is completely backwards compatible with the current
module.
The previous justification for using "VERBOSE" is incorrect,
because OpenSSH does use level INFO to log "which key was used
to log in" for sccessful logins, see:
6247812c76/auth.c (L323-L328)
Also update description to the wording of the sshd_config man page.
`fail2ban` needs, sshd to be "VERBOSE" to work well, thus
the `fail2ban` module sets it to "VERBOSE" if enabled.
The docs are updated accordingly.
Reload only works with a static configuration path as there is no way to
pass the dynamically generated config path to a running solanum
instance, therefore we symlink the configuration to
/etc/solanum/ircd.conf.
But that will prevent reloads of the ircd, because the systemd unit
wouldn't change when the configuration changes. That is why we add the
actual location of the config file to restartTriggers and enable
reloadIfChanged, so changes will not restart, but reload on changes.
tailscale allows to specify the interface name.
The upstream systemd unit does not expose it directly however, only
via the `FLAGS` environment variable.
I can’t be 100% sure that the escaping is correct, but this is as good
as we can do for now, unless upstream changes their unit file.
Adds the `networking.networkmanager.connectionConfig` option which allows setting arbitrary settings inside the `[connection]` section.
This also reworked the underlying representation significantly to be less string-pasting and more semantic. In a future step it probably makes sense to provide raw access to other sections to users rather than replying on `extraConfig`. However I decided to defer this primarily because ordering of sections can matter. (Although IIUC this is only true for different `[connection]` sections). I think in the future we could expose an object where users can define/edit all sections and map the current configuration onto those. For now however only `[connection]` is exposed and the rest are just used internally.
Currently tailscaled expects `sysctl` (from package procps) to be present
in the path when running on Linux. It can function without the `sysctl`
command present but it prints an error about it. This fixes that error.
Warning: couldn't check net.ipv4.ip_forward (exec: "sysctl":
executable file not found in $PATH).
Signed-off-by: Christine Dodrill <me@christine.website>
As per `man systemd.path`:
> When a service unit triggered by a path unit terminates
> (regardless whether it exited successfully or failed),
> monitored paths are checked immediately again,
> **and the service accordingly restarted instantly**.
Thus the existence of the path unit made it impossible to stop the
wireguard service using e.g.
systemctl stop wireguard-wg0.service
Systemd path units are not intended for program inputs such
as private key files.
This commit simply removes this usage; the private key is still
generated by the `generateKeyServiceUnit`.
use it when networkmanager or wpa_supplicant is enabled.
fixes#57053
fixes "Direct firmware load for regulatory.db failed with error -2"
in dmesg
Note that all kernels on unstable are newer that 4.15, which is required
for this to work.
Also document that `ProtectClock` blocks access to serial line.
I couldn't found out why this is the case,
but faxgetty complains about the device file
not being accessible with `ProtectClock=true`.
According to
https://github.com/NixOS/nixpkgs/pull/84556
this effort helps with cross-compilation.
This commit also renames a substituted variable `hylafax`
to `hylafaxplus` to permit substitution with `inherit`.
The radicale version is no longer chosen automatically based on
system.stateVersion because that gave the impression that old versions
are still supported.
Follow RFC 42 by having a settings option that is
then converted into an unbound configuration file
instead of having an extraConfig option.
Existing options have been renamed or kept if
possible.
An enableRemoteAccess has been added. It sets remote-control setting to
true in unbound.conf which in turn enables the new wrapping of
unbound-control to access the server locally. Also includes options
'remoteAccessInterfaces' and 'remoteAccessPort' for remote access.
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
Fixes these two deprecation warnings, by moving away from these options
towards a simple listener configuration.
> The 'bind_address' option is now deprecated and will be removed in a future version. The behaviour will default to true.
> The 'port' option is now deprecated and will be removed in a future version. Please use 'listener' instead.
Fixes: #120860
It can still network, it can only access the ssl related files if ssl is
enabled.
✗ PrivateNetwork= Service has access to the host's network 0.5
✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets 0.3
✗ DeviceAllow= Service has a device ACL with some special devices 0.1
✗ IPAddressDeny= Service does not define an IP address allow list 0.2
✗ RootDirectory=/RootImage= Service runs within the host's root directory 0.1
✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets 0.1
→ Overall exposure level for mosquitto.service: 1.1 OK 🙂
Standard best-practice shell quoting, which can prevent the most
horrible production accidents.
Note that we cannot use `+ optionalString someBool '' someString''`
because Nix's multi-line ''double-quoted'' strings remove leading
whitespace.
Until now, the `touch + chmod 600 + write` approach made it possible for
an unprivileged local user read the private key file, by opening
the file after the touch, before the read permissions are restricted.
This was only the case if `generatePrivateKeyFile = true` and the parent
directory of `privateKeyFile` already existed and was readable.
This commit fixes it by using `umask`, which ensures kernel-side that
the `touch` creates the file with the correct permissions atomically.
This commit also:
* Removes `mkdir --mode 0644 -p "${dirOf values.privateKeyFile}"`
because setting permissions `drw-r--r--` ("nobody can enter that dir")
is awkward. `drwx------` would perhaps make sense, like for `.ssh`.
However, setting the permissions on the private key file is enough,
and likely better, because `privateKeyFile` is about that file
specifically and no docs suggest that there's something special
about its parent dir.
* Removes the `chmod 0400 "${values.privateKeyFile}"`
because there isn't really a point in removing write access from
the owner of the private key.
The last bits to prevent babeld from running unprivileged was its
kernel_setup_interface routine, that wants to set per interface
rp_filter. This behaviour has been disabled in a patch that has been
submitted upstream at https://github.com/jech/babeld/pull/68 and reuses
the skip-kernel-setup config option.
→ Overall exposure level for babeld.service: 1.7 OK 🙂
Upstream repositories do no longer exists. There has been no release in
a while. - Not a good combination for a network daemon running as root
in C that parses network packets...
For a while now it's possible to specify an additional config file in
`wpa_supplicant`[1]. In contrast to the file specified via `-c` this was
supposed to be used for immutable settings and not e.g. additional
networks.
However I'm a little bit unhappy about the fact that one has to choose
between a fully imperative setup and a fully declarative one where the
one would have to write credentials for e.g. WPA2-enterprise networks
into the store.
The primary problem with the current state of `wpa_supplicant` is that
if the `SAVE_CONFIG` command is invoked (e.g. via `wpa_cli`), all known
networks will be written to `/etc/wpa_supplicant.conf` and thus all
declarative networks would get out of sync with the declarative
settings.
To work around this, I had to change the following things:
* The `networking.wireless`-module now uses `-I` for declarative config,
so the user-controlled mode can be used along with the
`networks`-option.
* I added an `ro`-field to the `ssid`-struct in the
`wpa_supplicant`-sources. This will be set to `1` for each network
specified in the config passed via `-I`.
Whenever config is written to the disk, those networks will be
skipped, so changes to declarative networks are only temporary.
[1] https://w1.fi/cgit/hostap/commit/wpa_supplicant?id=e6304cad47251e88d073553042f1ea7805a858d1
As the only consequence of isSystemUser is that if the uid is null then
it's allocated below 500, if a user has uid = something below 500 then
we don't require isSystemUser to be set.
Motivation: https://github.com/NixOS/nixpkgs/issues/112647
The haskellPackages.spacecookie derivation also includes a library and
thus a lot of propagated haskell dependencies. The top-level attribute
uses haskell.lib.justStaticExecutables and therefore only the
executable. This should reduce the runtime closure users have to
download considerably if they only want the server.
* Move `hostname` and `root` into a settings submodule with a freeform
type, allowing users to also use options not known to the NixOS
service. Compatibility with a warning for the renamed options is also
trivial to achieve.
* `port` stays where it is as we don't actually use the `port` option of
spacecookie to set up the socket, but only to inform spacecookie about
the port we have set in the `systemd.socket` file, this makes more
sense. Additionally the configuration of the listening port and
address change in the next spacecookie release — we can dodge this
issue altogether by doing our own thing, but I'm interested to hear
opinions on this.
To ensure that this is not misconfigured, we add an assertion for
the port option.
* Add an assertion for `user` in settings which has no effect the way
we are starting spacecookie as it wouldn't be able to call setuid.
The message also explains how a specific user can be used with
spacecookie if desired.
This configuration option reflects a new feature from the unreleased
spacecookie version allowing to customize the address spacecookie will
listen on (e. g. "::1" to bind on link-local addresses only). We will
not use this feature in the future, since the configuration option of
spacecookie naturally only has an effect if we don't use socket
activation (and spacecookie sets up its own socket), but having the same
functionality in the service seems like a good idea.
We can luckily emulate this behavior with socket activation as well.
This allows to change the derivation to use for the spacecookie server
binary. We probably should also use justStaticExecutables by default to
reduce the runtime closure of the service.
Maximum password length per cjdns code is somehwhere less than that, see
ecd01e7681/client/AdminClient.c (L80)
Currently we generate 96 char long passwords that don't work
This changes it so password length is just 32 chars long
