The pufferpanel module (#225274) was merged shortly after the tree-wide
rename f63a12f296 (#225748), so the use of
deperecated buildFHSUserEnv in the docs slipped through review 😅
There is apparently a bug in the parser of iproute2 where the command
`ip link show <devname>` will not show the device but list all
interfaces (equivalent to `ip link show`) if devname is equal to one of
the flags of `ip-address(8)`. For example, `home`, or `optimistic`.
This bug causes a false positive in the clean up command of the
<devname>-netdev.service, the service fails and the interface is never
configured.
To avoid the bug we can simply use `ip link show dev <devname>`.
PROXY protocol is a convenient way to carry information about the
originating address/port of a TCP connection across multiple layers of
proxies/NAT, etc.
Currently, it is possible to make use of it in NGINX's NixOS module, but
is painful when we want to enable it "globally".
Technically, this is achieved by reworking the defaultListen options and
the objective is to have a coherent way to specify default listeners in
the current API design.
See `mkDefaultListenVhost` and `defaultListen` for the details.
It adds a safeguard against running a NGINX with no HTTP listeners (e.g.
only PROXY listeners) while asking for ACME certificates over HTTP-01.
An interesting usecase of PROXY protocol is to enable seamless IPv4 to
IPv6 proxy with origin IPv4 address for IPv6-only NGINX servers, it is
demonstrated how to achieve this in the tests, using sniproxy.
Finally, the tests covers:
- NGINX `defaultListen` mechanisms are not broken by these changes;
- NGINX PROXY protocol listeners are working in a final usecase
(sniproxy);
- uses snakeoil TLS certs from ACME setup with wildcard certificates;
In the future, it is desirable to spoof-attack NGINX in this scenario to
ascertain that `set_real_ip_from` and all the layers are working as
intended and preventing any user from setting their origin IP address to
any arbitrary, opening up the NixOS module to bad™ vulnerabilities.
For now, it is quite hard to achieve while being minimalistic about the
tests dependencies.
It appears that newer mautrix-facebook versions default to the appservice name `facebook`. This was breaking our registration and causing mautrix-facebook to fail to start. This changes the name back and makes the registration generated match whatever the setting in the app is.
Adds a new option to the virtualisation modules that enables specifying explicitly named network interfaces in QEMU VMs.
The existing `virtualisation.vlans` option is still supported for cases where the name of the network interface is irrelevant.
