Ronan Pigott [Fri, 8 Mar 2024 20:40:08 +0000 (13:40 -0700)]
resolved: permit dnssec rrtype questions when we aren't validating
This check introduced in 91adc4db33f6 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: 9c47b334445a ("resolved: enable DNS proxy mode if client wants DNSSEC")
Daan De Meyer [Fri, 17 May 2024 14:20:11 +0000 (16:20 +0200)]
tpm2-setup: Don't fail if we can't access the TPM due to authorization failure
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.
Mike Yuan [Tue, 14 May 2024 10:33:32 +0000 (18:33 +0800)]
core/mount: stop generating mount units for cred mounts
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.
Ian Abbott [Thu, 30 May 2024 10:20:41 +0000 (11:20 +0100)]
udev: tag MTD devices for systemd
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.
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.
Kamil Szczęk [Mon, 3 Jun 2024 15:56:42 +0000 (17:56 +0200)]
core: populate $REMOTE_ADDR for AF_UNIX sockets
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.
Yu Watanabe [Tue, 11 Jun 2024 15:48:56 +0000 (00:48 +0900)]
sd-dhcp-server: clear buffer before receive
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.
tpm2-util: tighten rules on the nvindex handle range we allocate from
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.
man: document that separate /usr/local/ must not be used for config
Since we document /usr/local/lib/systemd/ and other paths for various things,
add notes that this is not supported if /usr/local is a separate partition. In
systemd.unit, I tried to add the footnote in the table where
/usr/local/lib/systemd/ is listed, but that get's rendered as '[sup]a[/sup]'
with a mangled footnote at the bottom of the table :( .
Also, split paragraphs in one place where the subject changes without any
transition.
From the logs in the bug:
Jun 10 22:55:37 systemd-logind[909]: The system will suspend now!
Jun 10 22:55:37 ModemManager[996]: <msg> [sleep-monitor-systemd] system is about to suspend
...
Jun 10 22:55:48 systemd-sleep[422408]: Failed to freeze unit 'user.slice': Connection timed out
Jun 10 22:55:48 systemd-sleep[422408]: Performing sleep operation 'suspend'...
The delay is ~11 s, consistent with the patch that set the timeout to 10 s.
Looks like this is not enough. It's the freeze operation that fails, but
thawing might be slow too, so just bump the timeout again.
Daan De Meyer [Thu, 6 Jun 2024 20:59:36 +0000 (22:59 +0200)]
chase: Tighten "." and "./" check
Currently the check also succeeds if the input path starts with a dot, whereas
we only want it to succeed for "." and "./". Tighten the check and add a test.
Daan De Meyer [Fri, 7 Jun 2024 15:21:48 +0000 (17:21 +0200)]
presets: Don't enable systemd-homed-firstboot.service by default
Enabling this service by default means every CI image without a
regular user now gets stuck on first boot due to the password prompt
from systemd-homed-firstboot.service. Let's not enable the service
by default but instead require users to enable it explicitly if they
want its behavior.
Daan De Meyer [Fri, 7 Jun 2024 13:10:58 +0000 (15:10 +0200)]
dev-setup: Follow /dev/console symlinks when locking /dev/console
systemd-nspawn sets up /dev/console as a symlink to a pty, so let's
make sure we follow the symlink when trying to lock /dev/console so
we don't fail with ELOOP.
The pty path returned by OpenMachinePTY() cannot be opened from outside
the machine, hence let's use the plain Standard{Input,Output,Error}=tty
in such a case. This means if --machine= is specified, #32916 would occur.
A comprehensive fix requires a new dbus method in machined, which shall
be material for v257.
See also: https://github.com/systemd/systemd/pull/33216#discussion_r1628020429
As discussed in https://github.com/systemd/systemd/issues/33104,
that patch caused problems in Debian which has a udev drop-in with
[Match]
Path=*-usb-*
[Link]
NamePolicy=mac
The rename fails:
eth0: Policy *mac* yields "enx00*".
eth0: /usr/lib/udev/rules.d/80-net-setup-link.rules:11 NAME 'enx00*'
eth0: /usr/lib/udev/rules.d/99-systemd.rules:69 RUN '/usr/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$
eth0: sd-device: Created database file '/run/udev/data/n9' for '/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:
eth0: Failed to rename network interface 9 from 'eth0' to 'enx00*': File exists
eth0: sd-device: Created database file '/run/udev/data/n9' for '/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:
eth0: Failed to process device, ignoring: File exists
Two network interfaces have the same MAC and it's not marked NET_ADDR_STOLEN.
In this case the conflict is very visible because it causes the rename to fail,
but it would also occur in other cases, for alternative names.
A patch has been submitted for r8152 to properly set NET_ADDR_STOLEN:
https://lore.kernel.org/linux-usb/20240605153340.25694-1-gmazyland@gmail.com/T/#u
Let's revert this now to avoid a regression. We can try again after the kernel
issue is resolved.
Luca Boccassi [Wed, 5 Jun 2024 23:14:37 +0000 (00:14 +0100)]
mkosi: do a sparse checkout of debian/ubuntu packaging repo
The repository on Salsa includes the full upstream sources, which means
they are duplicated, taking extra space and showing duplicated grep results.
But we only need the debian/ subfolder, so do a sparse clone and checkout.
Yu Watanabe [Mon, 3 Jun 2024 20:29:59 +0000 (05:29 +0900)]
network/ndisc: use router lifetime as one for redirect route
Previously, we did not set lifetime for redirect route, and redirect
routes were removed only when received a RA from the target address.
Thus, routes that redirect on-link addresses were never removed.
RFCs mention nothing about the lifetime of redirection. But the previous
implementation does not pass the IPv6 Core Conformance Tests.
This makes
- remember all received RAs and manage them by the sender address
(previously, remembered only one with the highest preference),
- then use the router lifetime as one for redirect route,
- remove redirect route also when the router corresponds to the sender
address is dropped (previously, considered only target address).
Note, even if we recieve a new RA, we do not update existing redirect
routes. The lifetime of the redirect route is updated only when a new
Redirect message is received.
* 5b9607385d debian/tests/storage: without scsi_debug, skip test
* 8a195a6327 debian/extra: use a dropin to configure Nice=-1 on systemd-journald.service
* 5436d49288 debian/extra: use a drop-in resolved.conf to configure Cache=no-negative
* 596a99d2d3 debian/extra: set ManagedOOMSwap=auto on -.slice
* 07ba81b14d LimitCORE: restore default hard limit to infinity
* df3a9a91e8 Restart managers on libc-upgrade dpkg trigger
Those scripts are written with the expectation that all input variables are set
and will not behave correctly if something is ommitted. In particular, the
non-chrooted scripts (mkosi.clean, mkosi.sync) might wreak havoc if called
without the full environment.
projects / thirdparty / systemd.git / log
