Without this option all changes done with Caddy API are lost after reboot.
Current service is not supporting Caddy --resume parameter. There is reference to original unit https://github.com/caddyserver/dist/blob/master/init/caddy.service which also mentions --resume and that it should be used if new Caddy API will be used.
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.
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.
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)
- 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
