Bug#1064133: systemd-resolved: Using systemd-resolved as drop-in replacements breaks in conjunction with ifupdown
Control: tags -1 -upstream Control: tags -1 wontfix Control: close -1 On Sun, 3 Mar 2024 01:14:03 +0100 Felix Jacobi wrote: > In my opinion, it should be possible to use systemd-resolved along with > the original resolvconf again. This could re-allow using > systemd-resolved in cases, where the protocol specific identifiers are > relevant (in conjunction with a custom resolvconf hook). > > Maybe /usr/sbin/resolvconf could be managed with update-alternatives or > the symlink from /usr/sbin/resolvconf to resolvectl could be shipped in > a separate package? Sorry, but the current setup is very much intentional. There is not going to be yet-another-package, and there is not going to be update- alternatives, which is an unholy mess. If you want to use sd-resolved, just don't bother with ifupdown - there is no reason to use that in 2024, for headless systems use networkd and for GUI systems use network-manager. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064133: systemd-resolved: Using systemd-resolved as drop-in replacements breaks in conjunction with ifupdown
Hi Michael, Thank you for your research. I've checked out the history of implementation of the resolvconf compatibility mode in systemd. It seems, that dropping protocol-specific identifiers was a conscious design decision of the systemd developers since systemd-resolved internals does not know anything about protocol identifiers. So, I think reporting a bug upstream won't change anything as it works as intended from their perspective. It seems that the resolvconf compatibility mode never intended to fully support all resolvconf features. In my opinion, it is not optimal, that using the systemd-resolved package now enforces also using the resolvconf compatibility mode of systemd. In the past, I used systemd-resolved alongside with the resolvconf package and a custom hook, which configures systemd-resolved with the data from resolvconf (see https://github.com/stsbl/iserv-server-systemd-resolved/blob/master/iconf/etc/resolvconf/update.d/systemd-resolved/20server-systemd-resolved_hook). With the newly introduced Breaks/Replaces, such a scenario does no longer work, although systemd-resolved also intended to support it: (from `man systemd-resolved.service`) /ETC/RESOLV.CONF Four modes of handling /etc/resolv.conf (see resolv.conf(5)) are supported: [...] • Alternatively, /etc/resolv.conf may be managed by other packages, in which case systemd-resolved will read it for DNS configuration data. In this mode of operation systemd-resolved is consumer rather than provider of this configuration file. Note that the selected mode of operation for this file is detected fully automatically, depending on whether /etc/resolv.conf is a symlink to /run/systemd/resolve/resolv.conf or lists 127.0.0.53 as DNS server. [...] In my opinion, it should be possible to use systemd-resolved along with the original resolvconf again. This could re-allow using systemd-resolved in cases, where the protocol specific identifiers are relevant (in conjunction with a custom resolvconf hook). Maybe /usr/sbin/resolvconf could be managed with update-alternatives or the symlink from /usr/sbin/resolvconf to resolvectl could be shipped in a separate package? Am 28.02.24 um 16:02 schrieb Michael Biebl: On Sat, 17 Feb 2024 16:00:08 +0100 Felix Jacobi wrote: In background, this executes `resolvconf -a IFACE.PROTOCOL` and supplies the nameservers to resolvconf, e.g. echo 'nameserver 192.0.0.1' | resolvconf -a ens3.inet However, the systemd-resolved resolvconf implementation removes the protocol indentifier: echo "nameserver 192.0.0.1" | resolvconf -a ens3.inet Dropped protocol specifier '.inet' from 'ens3.inet'. Using 'ens3' (ifindex=2). This leads to the fact, that only ens3 is used internally. For the configuration above, this means the previous configured IPv4 nameserver is completely overriddden with the latter one in the IPv6 stanza. This also causes several other problems for tools relying on resolvconf not dropping the protocol identifier and I would consider this a breaking change compared to the original resolvconf implementation. The Debian package does not ship any patches in that regard. It would thus be best if you raise this upstream at https://github.com/systemd/systemd/issues I did not immediately find, why resolvectl/resolved does strip away the protocol identifier. At the very least, this incompatibility could be documented in the resolvctl man page. Regards, Michael -- Mit freundlichen Grüßen Felix Jacobi Kind regards Felix Jacobi OpenPGP_0x2351A3C9FD44B05F.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064133: systemd-resolved: Using systemd-resolved as drop-in replacements breaks in conjunction with ifupdown
On Sat, 17 Feb 2024 16:00:08 +0100 Felix Jacobi wrote: In background, this executes `resolvconf -a IFACE.PROTOCOL` and supplies the nameservers to resolvconf, e.g. echo 'nameserver 192.0.0.1' | resolvconf -a ens3.inet However, the systemd-resolved resolvconf implementation removes the protocol indentifier: echo "nameserver 192.0.0.1" | resolvconf -a ens3.inet Dropped protocol specifier '.inet' from 'ens3.inet'. Using 'ens3' (ifindex=2). This leads to the fact, that only ens3 is used internally. For the configuration above, this means the previous configured IPv4 nameserver is completely overriddden with the latter one in the IPv6 stanza. This also causes several other problems for tools relying on resolvconf not dropping the protocol identifier and I would consider this a breaking change compared to the original resolvconf implementation. The Debian package does not ship any patches in that regard. It would thus be best if you raise this upstream at https://github.com/systemd/systemd/issues I did not immediately find, why resolvectl/resolved does strip away the protocol identifier. At the very least, this incompatibility could be documented in the resolvctl man page. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064133: systemd-resolved: Using systemd-resolved as drop-in replacements breaks in conjunction with ifupdown
Control: severity -1 wishlist On Sat, 17 Feb 2024 16:00:08 +0100 Felix Jacobi wrote: > Package: systemd-resolved > Version: 252.22-1~deb12u1 > Severity: important > Tags: upstream > X-Debbugs-Cc: fe...@jacobi-bs.de > > > Since Debian Bookworm, systemd-resolved cannot be installed along with > resolvconf anymore and provides its own stub implementation of this > command. > > However, when using it in conjunction with ifupdown, this overrides either > IPv4 or IPv6 nameservers. > > Considers the following /etc/network/interfaces: > > auto lo > iface lo inet loopback > iface lo inet6 loopback > > auto ens3 > iface ens3 inet static > address 192.0.0.2/24 > gateway 192.0.0.1 > dns-nameservers 192.0.0.1 > > iface ens3 inet6 static > address 2001:db8::2/64 > netmask 64 > gateway fe80::1 > dns-nameservers 2001:db8::1 > > In background, this executes `resolvconf -a IFACE.PROTOCOL` and supplies > the nameservers to resolvconf, e.g. > > echo 'nameserver 192.0.0.1' | resolvconf -a ens3.inet > > However, the systemd-resolved resolvconf implementation removes the > protocol indentifier: > > echo "nameserver 192.0.0.1" | resolvconf -a ens3.inet > Dropped protocol specifier '.inet' from 'ens3.inet'. Using 'ens3' (ifindex=2). > > This leads to the fact, that only ens3 is used internally. For the > configuration above, this means the previous configured IPv4 nameserver > is completely overriddden with the latter one in the IPv6 stanza. > > This also causes several other problems for tools relying on resolvconf > not dropping the protocol identifier and I would consider this a > breaking change compared to the original resolvconf implementation. ifupdown is ancient stuff, consider switching to something from this side of the millennium. -- Kind regards, Luca Boccassi
Bug#1064133: systemd-resolved: Using systemd-resolved as drop-in replacements breaks in conjunction with ifupdown
Package: systemd-resolved Version: 252.22-1~deb12u1 Severity: important Tags: upstream X-Debbugs-Cc: fe...@jacobi-bs.de Since Debian Bookworm, systemd-resolved cannot be installed along with resolvconf anymore and provides its own stub implementation of this command. However, when using it in conjunction with ifupdown, this overrides either IPv4 or IPv6 nameservers. Considers the following /etc/network/interfaces: auto lo iface lo inet loopback iface lo inet6 loopback auto ens3 iface ens3 inet static address 192.0.0.2/24 gateway 192.0.0.1 dns-nameservers 192.0.0.1 iface ens3 inet6 static address 2001:db8::2/64 netmask 64 gateway fe80::1 dns-nameservers 2001:db8::1 In background, this executes `resolvconf -a IFACE.PROTOCOL` and supplies the nameservers to resolvconf, e.g. echo 'nameserver 192.0.0.1' | resolvconf -a ens3.inet However, the systemd-resolved resolvconf implementation removes the protocol indentifier: echo "nameserver 192.0.0.1" | resolvconf -a ens3.inet Dropped protocol specifier '.inet' from 'ens3.inet'. Using 'ens3' (ifindex=2). This leads to the fact, that only ens3 is used internally. For the configuration above, this means the previous configured IPv4 nameserver is completely overriddden with the latter one in the IPv6 stanza. This also causes several other problems for tools relying on resolvconf not dropping the protocol identifier and I would consider this a breaking change compared to the original resolvconf implementation. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-resolved depends on: ii dbus [default-dbus-system-bus] 1.14.10-1~deb12u1 ii libc6 2.36-9+deb12u4 ii libssl3 3.0.11-1~deb12u2 ii libsystemd-shared 252.22-1~deb12u1 ii systemd 252.22-1~deb12u1 Versions of packages systemd-resolved recommends: ii libnss-myhostname 252.22-1~deb12u1 pn libnss-resolve Versions of packages systemd-resolved suggests: ii polkitd 122-3 -- no debconf information --- Kind regards Felix Jacobi
