The wpa_supplicant service in the NixOS installer is unusable because
the control socket is disabled and /etc/wpa_supplicant.conf ignored.
The manual currently recommends manually starting the daemon and using
wpa_passphrase, but this requires figuring out the interface name,
driver and only works for WPA2 personal networks.
By enabling the control socket, instead, a user can configure the
network via wpa_cli (or wpa_gui in the graphical installer), which
support more advanced network configurations.
The paperless project has moved on to paperless-ng and the original
paperless package in Nixpkgs has stopped working recently (due to
version incompatibility with the providede Django package).
Instead of investing more time into the old module we should migrate all
users to the new module instead.
This is the case when the test-script is empty. `nixos-build-vms(8)` is
primarily supposed to be used as tool to test changes or to reproduce
bugs (IMHO) where "just spinning up a few VMs" is the primary use-case.
In the ongoing discussion about these changes[1] it was suggested to
only expose it when needed (i.e. in the case I described above) to keep
the API surface as slim as possible.
[1] https://github.com/NixOS/nixpkgs/pull/133675#discussion_r688112485
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.
This is relevant for `nixos-build-vms(8)` which doesn't have a
test-script. In that case it's more intuitive to directly go into the
interactive mode which is IMHO more intuitive.
The generated json configuration returns this warning:
the 'issuer' field is deprecated and will be removed in the future; use 'issuers' instead
Updated the config to use "issuers" instead of "issuer"
Also, now it's possible to set the ca option null to not inject
automatically any ca. This is useful if you don't want to generate any
certificates or if you want to define a more fine-graned ca config
manually (e.g.: use different ca per domain)
Previously, for processes launched by doas the unwrapped doas binary preceded the
setuid-wrapped doas binary in PATH.
This caused error `doas: not installed setuid` when running doas from
processes launched by doas.
doas seems to short-circuit the PATH lookup when called like
`doas -u myuser doas -u myuser ...` so the error doesn't appear in this case.
- 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
I expect it suffices that the channel only blocks on one firefox ESR
test - the one for the default ESR. I didn't want to have the
information about the default in two places, so either of the tests will
be evaluated twice (but to the same *.drv I hope).
Analogous to 6325d15e90.
The test certificate expiration date was set to the default 30 days.
This certificate is generated through its own derivation. As with
every derivation, it gets cached by cache.nixos.org once we build it.
In practice, we rebuild this derivation only if one of its input
changes. The only inputs here being openssl and stdenv.
While it's not an issue on the unstable branches, it can be
problematic on a stable release: the test will fail after 30 days.
Extending the certificate lifespan from 1 month to 100 years to prevent
it from getting expired while being cached.
There is no generic services.kea.enable option. Instead kea consists of
four daemons (dhcp4, dhcp6, ddns, ctrlagent) that can be enabled
individually. In this test we're just looking at dhcp6.
Some ACME providers (like Buypass) are using a different certificate
to sign OCSP responses than for server certificates. Therefore,
sslTrustedCertificate should be provided by the user and we need to
allow that.
* Previously, both the xorg and wayland backend were built into the yambar
package. The refactor breaks up each backends to its separate, with xorg
being the default. Thus yambar users on wayland should switch to the
yambar-wayland package.
For security reasons, and generally, it is best to create a more fine
grained group than plugdev. This way users that wish to tweak razer
devices don't have access to the entire plugdev group's permissions.
This is of course a breaking change.
