If setting the received timezone or transient hostname fails because D-Bus is
not (yet) up, store the data in the Manager object and try again after
connecting to D-Bus.
systemd-networkd runs as user "systemd-network" and thus is not privileged to
set the timezone acquired from DHCP:
systemd-networkd[4167]: test_eth42: Could not set timezone: Interactive authentication required.
Similarly to commit e8c0de912, add a polkit rule to grant
org.freedesktop.timedate1.set-timezone to the "systemd-network" system user.
Move the polkit rules from src/hostname/ to src/network/ to avoid too many
small distributed policy snippets (there might be more in the future), as it's
easier to specify the privileges for a particular subject in this case.
Add NetworkdClientTest.test_dhcp_timezone() test case to verify this (for
all people except those in Pacific/Honolulu, there the test doesn't prove
anything -- sorry ☺ ).
Never propagate DNS/NTP servers on the local link via the DHCP server. The
DNS/NTP servers 0.0.0.0 and 127.0.0.1 only make sense in the local context,
hence never propagate them automatically to other hosts.
Fixes: #4524
DNS servers must be specified as IP addresses, hence let's store them as that
internally, so that they are guaranteed to be fully normalized always, and
invalid data cannot be stored.
Let's reorder them a bit, so that stuff that belongs together semantically is
placed together (in particular, move the various DHCP "use" booleans together).
When systemd-networkd is run on the same IPv6 enabled interface where
radvd is announcing prefixes, a route is being set up pointing to the
interface address. As this will fail with an invalid argument error,
the link is marked as failed and the following message like the
following will appear in in the logs:
systemd-networkd[21459]: eth1: Could not set NDisc route or address: Invalid argument
systemd-networkd[21459]: eth1: Failed
Should the interface be required by systemd-networkd-wait-online,
network-online.target will wait until its timeout hits thereby
significantly delaying system startup.
The fix is to check whether the gateway address obtained from NDisc
messages is equal to any of the interface addresses on the same link
and not set the NDisc route in that case.
This adds a new invocation ID concept to the service manager. The invocation ID
identifies each runtime cycle of a unit uniquely. A new randomized 128bit ID is
generated each time a unit moves from and inactive to an activating or active
state.
The primary usecase for this concept is to connect the runtime data PID 1
maintains about a service with the offline data the journal stores about it.
Previously we'd use the unit name plus start/stop times, which however is
highly racy since the journal will generally process log data after the service
already ended.
The "invocation ID" kinda matches the "boot ID" concept of the Linux kernel,
except that it applies to an individual unit instead of the whole system.
The invocation ID is passed to the activated processes as environment variable.
It is additionally stored as extended attribute on the cgroup of the unit. The
latter is used by journald to automatically retrieve it for each log logged
message and attach it to the log entry. The environment variable is very easily
accessible, even for unprivileged services. OTOH the extended attribute is only
accessible to privileged processes (this is because cgroupfs only supports the
"trusted." xattr namespace, not "user."). The environment variable may be
altered by services, the extended attribute may not be, hence is the better
choice for the journal.
Note that reading the invocation ID off the extended attribute from journald is
racy, similar to the way reading the unit name for a logging process is.
This patch adds APIs to read the invocation ID to sd-id128:
sd_id128_get_invocation() may be used in a similar fashion to
sd_id128_get_boot().
PID1's own logging is updated to always include the invocation ID when it logs
information about a unit.
A new bus call GetUnitByInvocationID() is added that allows retrieving a bus
path to a unit by its invocation ID. The bus path is built using the invocation
ID, thus providing a path for referring to a unit that is valid only for the
current runtime cycleof it.
Outlook for the future: should the kernel eventually allow passing of cgroup
information along AF_UNIX/SOCK_DGRAM messages via a unique cgroup id, then we
can alter the invocation ID to be generated as hash from that rather than
entirely randomly. This way we can derive the invocation race-freely from the
messages.
This patch adds support to remote checksum checksum offload to VXLAN.
This patch adds RemoteCheckSumTx and RemoteCheckSumRx vxlan configuration
to enable remote checksum offload for transmit and receive on the VXLAN tunnel.
[BridgeFDB] did not apply to bridge ports so far. This patch adds the proper
handling. In case of a bridge interface the correct flag NTF_MASTER is now set
in the netlink call. FDB MAC addresses are now applied in
link_enter_set_addresses to make sure the link is setup.
While an interface is still being processed by udev, it is in state "pending",
instead of "unmanaged". We must not flush device configuration then.
Further fixes commit 3104883ddc after commit c436d55397.
Fixes#4186
If Kind is not specied, the message about "Invalid Kind" was misleading.
If Kind was specified in an invalid way, we get a message in the parsing
phase anyway. Reword the message to cover both cases better.
Lennart Poettering
Susant Sahani
Martin Pitt
Tom Gundersen
Zbigniew Jędrzejewski-Szmek
Benjamin Richter
Patrik Flykt
Andrew Jeddeloh
Tobias Jungel
Elias Probst
Jason Kölker
Jean-Sébastien Bour
Susant Sahani