I find myself wanting to check this data with a quick command, and
browsing through /sys/ manually getting binary data sucks. Hence let's
do add a nice little analysis tool.
This check introduced in 91adc4db33 is intended to spare us from
encountering broken resolver behavior we don't want to deal with.
However if we aren't validating we more than likely don't know the state
of the upstream resolver's support for dnssec. Let's let clients try
these queries if they want.
This brings the behavior of sd-resolved in-line with previouly stated
change in the meaning of DNSSEC=no, which now means "don't validate"
rather than "don't validate, because the upstream resolver is declared to
be dnssec-unaware".
Fixes: 9c47b33444 ("resolved: enable DNS proxy mode if client wants DNSSEC")
The TPM might be password/pin protected for various reasons even if
there is no SRK yet. Let's handle those cases gracefully instead of
failing the unit as it is enabled by default.
This reverts commit 1e1225614c.
This was an incomplete workaround of the race. Now that
we stop generating mount units for credential mounts,
the logic could be dropped.
While @poettering wants to keep mount units for credential
mounts, this has brought nothing but pain in real life.
By generating mount units for each cred mount, we had trouble
with default dependencies on them, which causes their stop jobs
to race with unmounting through exec_context_destroy_credentials().
There were several attempts to workaround the problem, but
none seems very graceful: #26959, #28787, #28957, #31360, #32011.
Also, we want to carry over credentials for services that
survive soft-reboot to the new mount tree, and during the practice
the stop of mount units are irritating.
The mentioned problems are ultimately resolved by disabling
default deps: #32799. But after doing that, maybe the next question
should be "why do we generate these mount units at all?"
Let's revisit the whole concept here. First of all, the credential
dirs are supposed to be opaque to users, and hence nobody should
really reference to these mounts directly. Secondly, the lifetime
of credentials is strictly bound to the service units, but nothing
else. Moreover, as more and more users of credentials pop up,
we could end up with hundreds of such mount units, which is
something we handle poorly. And we emit useless UnitRemoved signals,
etc...
As discussed, it seems that eliminating these mount units
is the correct way to go. No real use cases are impacted,
and the lifetime management becomes sane again.
Replaces #32011
Allow systemd units to require/bind to MTD devices. One use case is for
using a systemd service to attach an MTD device to an UBI controller,
which cannot be done until the MTD device has been probed.
Fixes#33096
Multipath TCP (MPTCP), standardized in RFC8684 [1], is a TCP extension
that enables a TCP connection to use different paths. It allows a device
to make use of multiple interfaces at once to send and receive TCP
packets over a single MPTCP connection. MPTCP can aggregate the
bandwidth of multiple interfaces or prefer the one with the lowest
latency, it also allows a fail-over if one path is down, and the traffic
is seamlessly re-injected on other paths.
To benefit from MPTCP, both the client and the server have to support
it. Multipath TCP is a backward-compatible TCP extension that is enabled
by default on recent Linux distributions (Debian, Ubuntu, Redhat, ...).
Multipath TCP is included in the Linux kernel since version 5.6 [2]. To
use it on Linux, an application must explicitly enable it when creating
the socket:
int sd = socket(AF_INET(6), SOCK_STREAM, IPPROTO_MPTCP);
No need to change anything else in the application.
This patch allows MPTCP protocol in the Socket unit configuration. So
now, a <unit>.socket can contain this to use MPTCP instead of TCP:
[Socket]
SocketProtocol=mptcp
MPTCP support has been allowed similarly to what has been already done
to allow SCTP: just one line in core/socket.c, a very simple addition
thanks to the flexible architecture already in place.
On top of that, IPPROTO_MPTCP has also been added in the list of allowed
protocols in two other places, and in the doc. It has also been added to
the missing_network.h file, for systems with an old libc -- note that it
was also required to include <netinet/in.h> in this file to avoid
redefinition errors.
Link: https://www.rfc-editor.org/rfc/rfc8684.html [1]
Link: https://www.mptcp.dev [2]
Set the $REMOTE_ADDR environment variable for AF_UNIX socket connections
when using per-connection socket activation (Accept=yes). $REMOTE_ADDR
will now contain the remote socket's file system path (starting with a
slash "/") or its address in the abstract namespace (starting with an
at symbol "@").
This information is essential for identifying the remote peer in AF_UNIX
socket connections, but it's not easy to obtain in a shell script for
example without pulling in a ton of additional tools. By setting
$REMOTE_ADDR, we make this information readily available to the
activated service.
I do not think this is necessary, but all other places in
libsystemd-network we clear buffer before receive. Without this,
Coverity warns about use-of-uninitialized-values.
Let's silence Coverity.
Closes CID#1469721.
Let's follow the conventions set by "Registry of Reserved TPM 2.0 Handles
and Localities" and only allocate nvindex currently not assigned to any
vendor.
For details see:
https://trustedcomputinggroup.org/resource/registry/
Section 2.2
