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
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.
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.
Nullmailer expects that this directory exists (see
073f4e9c5d/doc/nullmailer-send.8 (L185)).
When it doesn't and an email cannot be sent due to a permanent failure
or has been in the queue longer than queuelifetime (7 days), message
"Can't rename file: No such file or directory" starts appearing in the
log and nullmailer never sends "Could not send message" notification.
This means that the user may never learn that his email was not
delivered.
