IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In the past bridge devices used to be created with a generated MAC address
thwarting the inheritance of the first slave's MAC address. This has been
changed by commit [1] some time ago. Reflect that behavioral change in the
documentation.
[1] deb2cfa4c6 ("networkd: do not generate MAC for bridge device.")
This allows to limit units to machines that run on a certain firmware
type. For device tree defined machines checking against the machine's
compatible is also possible.
`AllowedIPs=` only affects "routing inside the network interface
itself", as in, which wireguard peer packets with a specific destination
address are sent to, and what source addresses are accepted from which
peer.
To cause packets to be sent via wireguard in first place, a route via
that interface needs to be added - either in the `[Routes]` section on
the `.network` matching the wireguard interface, or outside of networkd.
This is a common cause of misunderstanding, because tools like wg-quick
also add routes to the interface. However, those tools are meant as a
"extremely simple script for easily bringing up a WireGuard interface,
suitable for a few common use cases (from their manpage).
Networkd also should support other usecases - like setting AllowedIPs to
0.0.0.0/0 and ::/0 and having a dynamic routing protocol setting more
specific routes (or the user manually setting them).
Reported-In: https://github.com/systemd/systemd/issues/14176
In NEWS, the new option was described twice, most likely because the first
description was tucked away in a paragraph about some other subject.
While at it, improve the descriptions in the man page to make it easier to grok
what that option really does.
Let's use the new flag wherever we read key material/passphrases/hashes
off disk, so that people can plug in their own IPC service as backend if
they like, easily.
(My main goal was actually to support this for crypttab key files — i.e.
that you can specify AF_UNIX sockets as third column in crypttab — but
that's harder to implement, since the keys are read via libcryptsetup's
API, not ours.)
