Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#930735: WireGuard: Add resolvconf as optional dependency
932 views
Skip to first unread message
Willem van den Akker
Jun 19, 2019, 9:10:03 AM6/19/19
to
Package: WireGuard
Version: WireGuard
Severity: normal
Dear Maintainer,
Add resolvconf as an optional dependency.
If the DNS option is used in the config file and resolvconf is not installed
wg-quick will return an
error and the interface is not created.
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 192.168.3.21/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
/usr/bin/wg-quick: line 31: resolvconf: command not found
[#] ip link delete dev wg0
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Version: WireGuard
Severity: normal
Dear Maintainer,
Add resolvconf as an optional dependency.
If the DNS option is used in the config file and resolvconf is not installed
wg-quick will return an
error and the interface is not created.
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 192.168.3.21/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
/usr/bin/wg-quick: line 31: resolvconf: command not found
[#] ip link delete dev wg0
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Daniel Kahn Gillmor
Jun 19, 2019, 6:30:02 PM6/19/19
to
Control: tags 930735 + moreinfo
Hi Willem--
On Wed 2019-06-19 15:01:53 +0200, Willem van den Akker wrote:
> Add resolvconf as an optional dependency.
> If the DNS option is used in the config file and resolvconf is not installed
> wg-quick will return an
> error and the interface is not created.
>
> [#] ip link add wg0 type wireguard
> [#] wg setconf wg0 /dev/fd/63
> [#] ip -4 address add 192.168.3.21/32 dev wg0
> [#] ip link set mtu 1420 up dev wg0
> [#] resolvconf -a wg0 -m 0 -x
> /usr/bin/wg-quick: line 31: resolvconf: command not found
> [#] ip link delete dev wg0
Thanks for this suggestion! I'm willing to update the Suggests: of the
wireguard package if i understand more about what actually works in this
case.
Are you certain that debian's resolvconf will work for this? Upstream
has complained in the past about debian's implementation of resolvconf
being broken (iirc, about the -x flag, but i'm not sure). Would
openresolv's resolvconf be better?
What about when resolvectl(1) from systemd is symlinked as resolvconf
(see the resolvectl man page for more details) -- would that be
preferable? according to its documentation, it has partial support for
-x, plausible support for -a, and silently ignores -m. is that
sufficient? If that's ok, maybe there are other adjustments we can make
so that it integrates nicely with systemd-resolved.
More details about what configurations you've tested and how well they
work to do what you expect from wg-quick would help me understand how to
make this system integration work better for you.
all the best,
--dkg
Hi Willem--
On Wed 2019-06-19 15:01:53 +0200, Willem van den Akker wrote:
> Add resolvconf as an optional dependency.
> If the DNS option is used in the config file and resolvconf is not installed
> wg-quick will return an
> error and the interface is not created.
>
> [#] ip link add wg0 type wireguard
> [#] wg setconf wg0 /dev/fd/63
> [#] ip -4 address add 192.168.3.21/32 dev wg0
> [#] ip link set mtu 1420 up dev wg0
> [#] resolvconf -a wg0 -m 0 -x
> /usr/bin/wg-quick: line 31: resolvconf: command not found
> [#] ip link delete dev wg0
wireguard package if i understand more about what actually works in this
case.
Are you certain that debian's resolvconf will work for this? Upstream
has complained in the past about debian's implementation of resolvconf
being broken (iirc, about the -x flag, but i'm not sure). Would
openresolv's resolvconf be better?
What about when resolvectl(1) from systemd is symlinked as resolvconf
(see the resolvectl man page for more details) -- would that be
preferable? according to its documentation, it has partial support for
-x, plausible support for -a, and silently ignores -m. is that
sufficient? If that's ok, maybe there are other adjustments we can make
so that it integrates nicely with systemd-resolved.
More details about what configurations you've tested and how well they
work to do what you expect from wg-quick would help me understand how to
make this system integration work better for you.
all the best,
--dkg
Willem van den Akker
Sep 7, 2019, 3:20:03 AM9/7/19
to
Hi dkg,
Sorry for the long delay.
Case:
Clients that I have (laptops, routers) which connects with the main
site needs a DNS.
To resolv centra servers the clients must access the central DNS (there
is no distributed DNS).
To accomplish this I add the "DNS = 192.168.4.1" option to the wg0.conf
file. Running wq-quick results in 'resolvconf: command not found'. Installing resolvconf make things work.
But ..... if wireguard is not started (laptops), resolvconf will bite
me. DNS options received from DHCP-servers will not work in some cases.
How did I resolv this?
On laptops I imported the wg0.conf (with DNS) into Network-manager and
start the VPN with 'nmcli'. This works ok.
Agree that resolvconf is not working optimal in some cases.
For now wq-quick cannot handle the DNS option (not tested is the last
versions), but I have a workaround.
If resolvectl is symlinked to resolvconf this also should work. But the
symlinked is not on my system. Even with resolvectl available.
Greetings,
Willem
> Hi Willem--On Wed 2019-06-19 15:01:53 +0200, Willem van den Akker
Sorry for the long delay.
Case:
Clients that I have (laptops, routers) which connects with the main
site needs a DNS.
To resolv centra servers the clients must access the central DNS (there
is no distributed DNS).
To accomplish this I add the "DNS = 192.168.4.1" option to the wg0.conf
file. Running wq-quick results in 'resolvconf: command not found'. Installing resolvconf make things work.
But ..... if wireguard is not started (laptops), resolvconf will bite
me. DNS options received from DHCP-servers will not work in some cases.
How did I resolv this?
On laptops I imported the wg0.conf (with DNS) into Network-manager and
start the VPN with 'nmcli'. This works ok.
Agree that resolvconf is not working optimal in some cases.
For now wq-quick cannot handle the DNS option (not tested is the last
versions), but I have a workaround.
If resolvectl is symlinked to resolvconf this also should work. But the
symlinked is not on my system. Even with resolvectl available.
Greetings,
Willem
> Hi Willem--On Wed 2019-06-19 15:01:53 +0200, Willem van den Akker
> wrote:
> > Add resolvconf as an optional dependency.
> > If the DNS option is used in the config file and resolvconf is not
> installed
> > wg-quick will return an
> > error and the interface is not created.
> >
> > [#] ip link add wg0 type wireguard
> > [#] wg setconf wg0 /dev/fd/63
> > [#] ip -4 address add 192.168.3.21/32 dev wg0
> > [#] ip link set mtu 1420 up dev wg0
> > [#] resolvconf -a wg0 -m 0 -x
> > /usr/bin/wg-quick: line 31: resolvconf: command not found
> > [#] ip link delete dev wg0
> > Add resolvconf as an optional dependency.
> > If the DNS option is used in the config file and resolvconf is not
> installed
> > wg-quick will return an
> > error and the interface is not created.
> >
> > [#] ip link add wg0 type wireguard
> > [#] wg setconf wg0 /dev/fd/63
> > [#] ip -4 address add 192.168.3.21/32 dev wg0
> > [#] ip link set mtu 1420 up dev wg0
> > [#] resolvconf -a wg0 -m 0 -x
> > /usr/bin/wg-quick: line 31: resolvconf: command not found
> > [#] ip link delete dev wg0
> Thanks for this suggestion! I'm willing to update the Suggests: of
> the
> wireguard package if i understand more about what actually works in
> this
> case.
> Are you certain that debian's resolvconf will work for
> this? Upstream
> has complained in the past about debian's implementation of
> resolvconf
> being broken (iirc, about the -x flag, but i'm not sure). Would
> openresolv's resolvconf be better?
> What about when resolvectl(1) from systemd is symlinked as resolvconf
> (see the resolvectl man page for more details) -- would that be
> preferable? according to its documentation, it has partial support
> for
> -x, plausible support for -a, and silently ignores -m. is that
> sufficient?
> If that's ok, maybe there are other adjustments we can make
> so that it integrates nicely with systemd-resolved.More details about
> the
> wireguard package if i understand more about what actually works in
> this
> case.
> Are you certain that debian's resolvconf will work for
> this? Upstream
> has complained in the past about debian's implementation of
> resolvconf
> being broken (iirc, about the -x flag, but i'm not sure). Would
> openresolv's resolvconf be better?
> What about when resolvectl(1) from systemd is symlinked as resolvconf
> (see the resolvectl man page for more details) -- would that be
> preferable? according to its documentation, it has partial support
> for
> -x, plausible support for -a, and silently ignores -m. is that
> sufficient?
> If that's ok, maybe there are other adjustments we can make
Daniel Kahn Gillmor
Sep 9, 2019, 7:30:03 PM9/9/19
to
Control: clone 930735 -1
Control: reassign -1 src:systemd
Control: severity -1 wishlist
Control: blocks 930735 with -1
Control: retitle -1 systemd should ship resolvconf symlink in some package
Control: affects -1 + wireguard-tools
Hi Willem--
Thanks for the followup.
It sounds to me like there is still no great suggestion on how to make
this work smoothly, or a clear consensus on what we should do to ensure
that the DNS = directive works for wg-quick :(
On Sat 2019-09-07 08:55:17 +0200, Willem van den Akker wrote:
> If resolvectl is symlinked to resolvconf this also should work. But the
> symlinked is not on my system. Even with resolvectl available.
For most modern debian systems, this seems like the simplest approach,
but i don't think it's safe to assume it will work automatically yet.
Perhaps the systemd source package could ship a systemd-resolvconf
binary package that (a) enables and runs the systemd-resolved service
automatically, and (b) ships the symlink from /sbin/resolvconf to
resolvectl, and (c) Provides: and Conflicts: with resolvconf itself
(similar to how openresolv does).
I note that the systemd binary package already ships a resolvconf
manpage as a symlink to the resolvectl manpage, but it puts it in
section 1 of the manual, instead of section 8, so it doesn't manage to
conflict with resolvconf or openresolv. that's a little bit weird too :/
I'm cloning this wireguard bug report to the systemd source package to
see whether this suggestion is something they'd be willing to consider.
Debian systemd maintainers -- feel free to suggest an alternate
resolution if you have one you'd prefer.
If systemd would do that, then i'd be willing to add a new control line
for wireguard-tools as something like this:
Recommends: systemd-resolvconf | resolvconf
Does this seem like a plausible suggestion? This sort of system
integration across multiple potentially conflicting packages is a bit of
a pain point in Debian, and it's not clear how to make it work sensibly
and easily for everyone.
--dkg
Control: reassign -1 src:systemd
Control: severity -1 wishlist
Control: blocks 930735 with -1
Control: retitle -1 systemd should ship resolvconf symlink in some package
Control: affects -1 + wireguard-tools
Hi Willem--
Thanks for the followup.
It sounds to me like there is still no great suggestion on how to make
this work smoothly, or a clear consensus on what we should do to ensure
that the DNS = directive works for wg-quick :(
On Sat 2019-09-07 08:55:17 +0200, Willem van den Akker wrote:
> If resolvectl is symlinked to resolvconf this also should work. But the
> symlinked is not on my system. Even with resolvectl available.
but i don't think it's safe to assume it will work automatically yet.
Perhaps the systemd source package could ship a systemd-resolvconf
binary package that (a) enables and runs the systemd-resolved service
automatically, and (b) ships the symlink from /sbin/resolvconf to
resolvectl, and (c) Provides: and Conflicts: with resolvconf itself
(similar to how openresolv does).
I note that the systemd binary package already ships a resolvconf
manpage as a symlink to the resolvectl manpage, but it puts it in
section 1 of the manual, instead of section 8, so it doesn't manage to
conflict with resolvconf or openresolv. that's a little bit weird too :/
I'm cloning this wireguard bug report to the systemd source package to
see whether this suggestion is something they'd be willing to consider.
Debian systemd maintainers -- feel free to suggest an alternate
resolution if you have one you'd prefer.
If systemd would do that, then i'd be willing to add a new control line
for wireguard-tools as something like this:
Recommends: systemd-resolvconf | resolvconf
Does this seem like a plausible suggestion? This sort of system
integration across multiple potentially conflicting packages is a bit of
a pain point in Debian, and it's not clear how to make it work sensibly
and easily for everyone.
--dkg
Michael Biebl
Sep 10, 2019, 3:00:02 AM9/10/19
to
wouldn't it be better if wireguard calls resolvctl directly?
Then it knows exactly what kind of behaviour it'll get.
You're right about the resolvconf.1 man page. We should not ship that in
the systemd man page since we don't ship the resolvconf symlink either
(for obvious reasons).
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Then it knows exactly what kind of behaviour it'll get.
You're right about the resolvconf.1 man page. We should not ship that in
the systemd man page since we don't ship the resolvconf symlink either
(for obvious reasons).
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Willem van den Akker
Sep 10, 2019, 3:10:02 AM9/10/19
to
Hi dkg,
> It sounds to me like there is still no great suggestion on how to make
> this work smoothly, or a clear consensus on what we should do to ensure
> that the DNS = directive works for wg-quick :(
Correct.
>
> On Sat 2019-09-07 08:55:17 +0200, Willem van den Akker wrote:
> > If resolvectl is symlinked to resolvconf this also should work. But the
> > symlinked is not on my system. Even with resolvectl available.
>
> For most modern debian systems, this seems like the simplest approach,
> but i don't think it's safe to assume it will work automatically yet.
I have the standard bullseye installation and a simple symlink to
resolv gives an error when starting wg-quick up wg0.
'[#] ip link add wg0 type wireguard
org.freedesktop.resolve1.service not found.
[#] ip link delete dev wg0'
> Perhaps the systemd source package could ship a systemd-resolvconf
> binary package that (a) enables and runs the systemd-resolved service
> automatically, and (b) ships the symlink from /sbin/resolvconf to
> resolvectl, and (c) Provides: and Conflicts: with resolvconf itself
> (similar to how openresolv does).
Sound as a good solution and would explain the error above.
> If systemd would do that, then i'd be willing to add a new control line
> for wireguard-tools as something like this:
>
> Recommends: systemd-resolvconf | resolvconf
>
> Does this seem like a plausible suggestion?
Sure. Perhals the even the recommend of resolvconf can be left behind
if the systemd integration works.
/Willem
> It sounds to me like there is still no great suggestion on how to make
> this work smoothly, or a clear consensus on what we should do to ensure
> that the DNS = directive works for wg-quick :(
>
> On Sat 2019-09-07 08:55:17 +0200, Willem van den Akker wrote:
> > If resolvectl is symlinked to resolvconf this also should work. But the
> > symlinked is not on my system. Even with resolvectl available.
>
> For most modern debian systems, this seems like the simplest approach,
> but i don't think it's safe to assume it will work automatically yet.
resolv gives an error when starting wg-quick up wg0.
'[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 192.168.3.21/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
Failed to set DNS configuration: Unit dbus-
[#] ip -4 address add 192.168.3.21/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
org.freedesktop.resolve1.service not found.
[#] ip link delete dev wg0'
> Perhaps the systemd source package could ship a systemd-resolvconf
> binary package that (a) enables and runs the systemd-resolved service
> automatically, and (b) ships the symlink from /sbin/resolvconf to
> resolvectl, and (c) Provides: and Conflicts: with resolvconf itself
> (similar to how openresolv does).
> If systemd would do that, then i'd be willing to add a new control line
> for wireguard-tools as something like this:
>
> Recommends: systemd-resolvconf | resolvconf
>
> Does this seem like a plausible suggestion?
if the systemd integration works.
/Willem
Daniel Kahn Gillmor
Sep 10, 2019, 5:00:03 PM9/10/19
to
On Tue 2019-09-10 08:54:35 +0200, Michael Biebl wrote:
> wouldn't it be better if wireguard calls resolvctl directly?
> Then it knows exactly what kind of behaviour it'll get.
>
> You're right about the resolvconf.1 man page. We should not ship that in
> the systemd man page since we don't ship the resolvconf symlink either
> (for obvious reasons).
Hm, Jason (wireguard upstream, cc'ed here) seems to believe strongly in
> wouldn't it be better if wireguard calls resolvctl directly?
> Then it knows exactly what kind of behaviour it'll get.
>
> You're right about the resolvconf.1 man page. We should not ship that in
> the systemd man page since we don't ship the resolvconf symlink either
> (for obvious reasons).
the resolvconf interface. he writes [0]:
>> The standard interface for modifying DNS on Linux is resolvconf. It is for
>> this reason that systemd added the compatibility layer. Debian should
>> install the proper symlink. WireGuard upstream will support the standard
>> mechanism of resolvconf.
fwiw, I don't understand the vehemence of his allegiance to this
interface, especially given the amount of trouble its different
implementations have caused him (and others) in the past, but *shrug*
i'd also prefer not to diverge from the version of wg-quick that he's
shipping upstream, unless someone from the systemd team wants to supply
a patch that they think is a reliable fix for the linux bash
implementation [1].
Is the resolvectl interface stable as documented?
So for wireguard's purposes, it would be good to figure out how to get
some debian package that ships the symlink in question (i understand why
you can't ship the symlink by default in the systemd package -- it would
conflict with the other implementations of resolvconf).
Is there a chance that the systemd source would generate such a package
(one that enables systemd-resolved, and supplies the symlinks to the
binary and the manpage)?
If not, feel free to close this bug with an explanation of why that's
not acceptable.
Thanks for your work in maintaining systemd.
--dkg
[0] https://lists.zx2c4.com/pipermail/wireguard/2019-September/004521.html
[1] https://salsa.debian.org/debian/wireguard/blob/debian/master/src/tools/wg-quick/linux.bash
Tim Mohlmann
Apr 22, 2020, 5:10:04 PM4/22/20
to
Good day,
I would like to pitch in. I've created a symlink: ln -s /usr/bin/resolvectl /usr/local/bin/resolvconf and wg-quick works fine with it. I did not need to install any other package.
Br, Tim
Tim Mohlmann
Apr 22, 2020, 5:10:04 PM4/22/20
to
Hi,
> So for wireguard's purposes, it would be good to figure out how to get
> some debian package that ships the symlink in question (i understand why
> you can't ship the symlink by default in the systemd package -- it would
> conflict with the other implementations of resolvconf).
> some debian package that ships the symlink in question (i understand why
> you can't ship the symlink by default in the systemd package -- it would
> conflict with the other implementations of resolvconf).
I've stumbled across this after I replied to 930735. Arch linux seems to solve it by a separate package. It blocks openresolv, to prevent the conflict on the symlink.
Br, Tim
Jason A. Donenfeld
Aug 25, 2020, 6:20:03 PM8/25/20
to
On Thu, Apr 23, 2020 at 12:02:59AM +0300, Tim Mohlmann wrote:
> Hi,
>
> > So for wireguard's purposes, it would be good to figure out how to get
> > some debian package that ships the symlink in question (i understand why
> > you can't ship the symlink by default in the systemd package -- it would
> > conflict with the other implementations of resolvconf).
>
> I've stumbled across this after I replied to 930735. Arch linux seems to
> solve it by a separate package. It blocks openresolv, to prevent the
> conflict on the symlink.
>
> https://www.archlinux.org/packages/core/x86_64/systemd-resolvconf/
This seems like an exceedingly reasonable way of handling this. Can
> Hi,
>
> > So for wireguard's purposes, it would be good to figure out how to get
> > some debian package that ships the symlink in question (i understand why
> > you can't ship the symlink by default in the systemd package -- it would
> > conflict with the other implementations of resolvconf).
>
> I've stumbled across this after I replied to 930735. Arch linux seems to
> solve it by a separate package. It blocks openresolv, to prevent the
> conflict on the symlink.
>
> https://www.archlinux.org/packages/core/x86_64/systemd-resolvconf/
Debian move forward with something similar?
Jason
Luca Boccassi
Aug 5, 2022, 2:10:04 PM8/5/22
to
systemd-resolved is now in experimental as a new package, and if there
are no huge breakages (it has provides/conflicts/replaces: resolvconf
and installs the symlinks) it will make it to unstable too at some
point soon. So the plan to add the Recommends you mentioned sounds good
to me.
--
Kind regards,
Luca Boccassi
Raphaël Halimi
Aug 13, 2022, 10:40:04 PM8/13/22
to
Dear developers,
I just upgraded a sid system and I noticed that the network was broken
on this machine.
I suppose the reason is that I had systemd-resolved enabled and
/etc/resolv.conf was symlinked to the stub resolver
(/run/systemd/resolve/stub-resolv.conf), and since the systemd-resolved
service had disappeared and didn't respond anymore on 127.0.0.53, the
system was left with a broken DNS resolution.
On a side note, the changelog says that an entry was added in
NEWS.Debian to warn user of the change, but it wasn't displayed during
the upgrade (this is weird, I know). I had to read the changelog to
understand what was going on.
And finally, my opinion:
After reading the mail thread in this bug report, I thought the plan was
to separate systemd-resolvconf (as Arch did, IIUC), not the entire
systemd-resolved service.
IMHO this is a **very** bad idea, and not only because of the broken DNS
resolution broken after the upgrade in some cases... The whole point of
systemd-resolved is that it's included in systemd (so basically in every
Linux system nowadays) and, alongside systemd-networkd, provides an
entire network configuration/management stack, without the need to
install optional packages, but most importantly, standard across all
distributions (no need to learn and/or master ifupdown, sysconfig,
netplan, whatever, etc).
If it's not too late, I strongly suggest to reintegrate systemd-resolved
in the main systemd package (as it was before), and split only
systemd-resolvconf.
Best regards,
--
Raphaël Halimi
I just upgraded a sid system and I noticed that the network was broken
on this machine.
I suppose the reason is that I had systemd-resolved enabled and
/etc/resolv.conf was symlinked to the stub resolver
(/run/systemd/resolve/stub-resolv.conf), and since the systemd-resolved
service had disappeared and didn't respond anymore on 127.0.0.53, the
system was left with a broken DNS resolution.
On a side note, the changelog says that an entry was added in
NEWS.Debian to warn user of the change, but it wasn't displayed during
the upgrade (this is weird, I know). I had to read the changelog to
understand what was going on.
And finally, my opinion:
After reading the mail thread in this bug report, I thought the plan was
to separate systemd-resolvconf (as Arch did, IIUC), not the entire
systemd-resolved service.
IMHO this is a **very** bad idea, and not only because of the broken DNS
resolution broken after the upgrade in some cases... The whole point of
systemd-resolved is that it's included in systemd (so basically in every
Linux system nowadays) and, alongside systemd-networkd, provides an
entire network configuration/management stack, without the need to
install optional packages, but most importantly, standard across all
distributions (no need to learn and/or master ifupdown, sysconfig,
netplan, whatever, etc).
If it's not too late, I strongly suggest to reintegrate systemd-resolved
in the main systemd package (as it was before), and split only
systemd-resolvconf.
Best regards,
--
Raphaël Halimi
Andrej Shadura
Aug 14, 2022, 1:00:03 PM8/14/22
to
Hi,
On Sun, 14 Aug 2022 04:29:52 +0200 Raphaël Halimi
<raphael...@gmail.com> wrote:
> And finally, my opinion:
>
> After reading the mail thread in this bug report, I thought the plan was
> to separate systemd-resolvconf (as Arch did, IIUC), not the entire
> systemd-resolved service.
>
> IMHO this is a **very** bad idea, and not only because of the broken DNS
> resolution broken after the upgrade in some cases... The whole point of
> systemd-resolved is that it's included in systemd (so basically in every
> Linux system nowadays) and, alongside systemd-networkd, provides an
> entire network configuration/management stack, without the need to
> install optional packages, but most importantly, standard across all
> distributions (no need to learn and/or master ifupdown, sysconfig,
> netplan, whatever, etc).
>
> If it's not too late, I strongly suggest to reintegrate systemd-resolved
> in the main systemd package (as it was before), and split only
> systemd-resolvconf.
I agree that the decision should be revisited, but for a different
reason. I see no reason why resolvconf cannot be used with resolved;
OTOH the current split prevents that, which I find very undesirable.
I was very surprised when I learnt today systemd-resolved has a
Conflicts against resolvconf, that was contrary to my expectations, and
I suspect I’m not the only person concerned about this.
--
Cheers,
Andrej
On Sun, 14 Aug 2022 04:29:52 +0200 Raphaël Halimi
<raphael...@gmail.com> wrote:
> And finally, my opinion:
>
> After reading the mail thread in this bug report, I thought the plan was
> to separate systemd-resolvconf (as Arch did, IIUC), not the entire
> systemd-resolved service.
>
> IMHO this is a **very** bad idea, and not only because of the broken DNS
> resolution broken after the upgrade in some cases... The whole point of
> systemd-resolved is that it's included in systemd (so basically in every
> Linux system nowadays) and, alongside systemd-networkd, provides an
> entire network configuration/management stack, without the need to
> install optional packages, but most importantly, standard across all
> distributions (no need to learn and/or master ifupdown, sysconfig,
> netplan, whatever, etc).
>
> If it's not too late, I strongly suggest to reintegrate systemd-resolved
> in the main systemd package (as it was before), and split only
> systemd-resolvconf.
reason. I see no reason why resolvconf cannot be used with resolved;
OTOH the current split prevents that, which I find very undesirable.
I was very surprised when I learnt today systemd-resolved has a
Conflicts against resolvconf, that was contrary to my expectations, and
I suspect I’m not the only person concerned about this.
--
Cheers,
Andrej
Michael Biebl
Aug 14, 2022, 1:10:04 PM8/14/22
to
Am 14.08.22 um 18:43 schrieb Andrej Shadura:
Given that the package takes over management of /etc/resolv.conf, I
don't think it makes sense to have resolvconf interfering here.
tbh, I don't see the benefit/use case of installing resolvconf along
side systemd-resolved.
don't think it makes sense to have resolvconf interfering here.
tbh, I don't see the benefit/use case of installing resolvconf along
side systemd-resolved.
Andrej Shadura
Aug 14, 2022, 1:40:04 PM8/14/22
to
Hi,
On Sun, 14 Aug 2022, at 19:04, Michael Biebl wrote:
>> I agree that the decision should be revisited, but for a different
>> reason. I see no reason why resolvconf cannot be used with resolved;
>> OTOH the current split prevents that, which I find very undesirable.
>>
>> I was very surprised when I learnt today systemd-resolved has a
>> Conflicts against resolvconf, that was contrary to my expectations, and
>> I suspect I’m not the only person concerned about this.
>>
>
> Given that the package takes over management of /etc/resolv.conf, I
> don't think it makes sense to have resolvconf interfering here.
>
> tbh, I don't see the benefit/use case of installing resolvconf along
> side systemd-resolved.
But that's the point of the complaint, I'm afraid. Resolved doesn't have to take it over, it's just one of its operation modes.
--
Cheers,
Andrej
On Sun, 14 Aug 2022, at 19:04, Michael Biebl wrote:
>> I agree that the decision should be revisited, but for a different
>> reason. I see no reason why resolvconf cannot be used with resolved;
>> OTOH the current split prevents that, which I find very undesirable.
>>
>> I was very surprised when I learnt today systemd-resolved has a
>> Conflicts against resolvconf, that was contrary to my expectations, and
>> I suspect I’m not the only person concerned about this.
>>
>
> Given that the package takes over management of /etc/resolv.conf, I
> don't think it makes sense to have resolvconf interfering here.
>
> tbh, I don't see the benefit/use case of installing resolvconf along
> side systemd-resolved.
--
Cheers,
Andrej
Luca Boccassi
Aug 16, 2022, 5:10:04 PM8/16/22
to
remove unused binaries and config from the main package, while keeping
the new one as simple and straightforward as possible - no faffing
around with maintainer scripts managing persistent filesystem changes,
or weird optional toggles to figure out.
You want resolved? Install the resolved package. Don't want resolved?
Don't install the package.
We do no want to support combining resolved with resolvconf - and in
fact, the setup with conflicts+provides is exactly like other packages
like openresolv are set up.
Raphaël Halimi
Aug 16, 2022, 5:30:04 PM8/16/22
to
Le 16/08/2022 à 22:59, Luca Boccassi a écrit :
> You want resolved? Install the resolved package. Don't want resolved?
> Don't install the package.
Personally I see this as a regression, since resolved used to be part of
> You want resolved? Install the resolved package. Don't want resolved?
> Don't install the package.
systemd and thus readily available without installing additional packages.
> We do no want to support combining resolved with resolvconf - and in
> fact, the setup with conflicts+provides is exactly like other packages
> like openresolv are set up.
systemd package, and splitting only systemd-resolvconf in its own package.
Regards,
--
Raphaël Halimi
Luca Boccassi
Aug 16, 2022, 6:40:04 PM8/16/22
to
On Tue, 2022-08-16 at 23:17 +0200, Raphaël Halimi wrote:
> Le 16/08/2022 à 22:59, Luca Boccassi a écrit :
> > You want resolved? Install the resolved package. Don't want resolved?
> > Don't install the package.
>
> Personally I see this as a regression, since resolved used to be part of
> systemd and thus readily available without installing additional packages.
No support was provided before for resolved, it was completely inhert,
> Le 16/08/2022 à 22:59, Luca Boccassi a écrit :
> > You want resolved? Install the resolved package. Don't want resolved?
> > Don't install the package.
>
> Personally I see this as a regression, since resolved used to be part of
> systemd and thus readily available without installing additional packages.
hence it is not a regression. It is a change in behaviour, and thus
noted in the NEWS file as expected.
> > We do no want to support combining resolved with resolvconf - and in
> > fact, the setup with conflicts+provides is exactly like other packages
> > like openresolv are set up.
>
> Yes, but this goal could be achieved by letting resolved in the main
> systemd package, and splitting only systemd-resolvconf in its own package.
>
not something we want to do, unless there are extremely compelling
reasons for it. Supporting resolvconf is not one.
Raphaël Halimi
Aug 18, 2022, 10:10:03 AM8/18/22
to
Le 17/08/2022 à 00:36, Luca Boccassi a écrit :
>> Personally I see this as a regression, since resolved used to be part of
>> systemd and thus readily available without installing additional packages.
>
> No support was provided before for resolved, it was completely inhert,
> hence it is not a regression. It is a change in behaviour, and thus
> noted in the NEWS file as expected.
>
>> Personally I see this as a regression, since resolved used to be part of
>> systemd and thus readily available without installing additional packages.
>
> No support was provided before for resolved, it was completely inhert,
> hence it is not a regression. It is a change in behaviour, and thus
> noted in the NEWS file as expected.
>
>> Yes, but this goal could be achieved by letting resolved in the main
>> systemd package, and splitting only systemd-resolvconf in its own package.
>>
>
> Having a single-file-package that is confusing and harder to find is
> not something we want to do, unless there are extremely compelling
> reasons for it. Supporting resolvconf is not one.
Could you at least address the temporary break in DNS resolution ? This
>> systemd package, and splitting only systemd-resolvconf in its own package.
>>
>
> Having a single-file-package that is confusing and harder to find is
> not something we want to do, unless there are extremely compelling
> reasons for it. Supporting resolvconf is not one.
is still a serious bug, which would deserve its own bug with priority
grave (if not critical). Since systemd-resolved is mainly used on
servers, it could result in a very bad surprise for sysadmins when
bookworm is released.
Perhaps it could be fixed by promoting systemd-resolved to a recommends
(instead of suggests) in systemd, so that it's installed during the
upgrade ? Or don't stop the service if /etc/resolv.conf is symlinked to
/run/systemd/resolve/stub-resolv.conf, so that the admin has the time to
read the NEWS entry (which, again, didn't work on my system, whereas it
was supposed to be sent in an e-mail by apt-listchanges), and install
systemd-resolved before rebooting ?
Also, I understand that you don't wish to revert your changes, but is
there a reason why resolvconf, openresolv and thus systemd-resolved
could coexist thanks to the alternatives system ? I know it would be
more work for maintainers of those three packages, but IMHO it would be
worth the effort.
And, last but not the least, I see that /etc/resolv.conf is now part of
systemd-resolved files, which means that it would be deleted when the
systemd-resolved package is removed from the system. I think it would
also deserve its own bug with some high priority.
Regards,
--
Raphaël Halimi
Luca Boccassi
Aug 18, 2022, 10:30:03 AM8/18/22
to
On Thu, 2022-08-18 at 16:07 +0200, Raphaël Halimi wrote:
> Le 17/08/2022 à 00:36, Luca Boccassi a écrit :
> > > Personally I see this as a regression, since resolved used to be part of
> > > systemd and thus readily available without installing additional packages.
> >
> > No support was provided before for resolved, it was completely inhert,
> > hence it is not a regression. It is a change in behaviour, and thus
> > noted in the NEWS file as expected.
> >
> > > Yes, but this goal could be achieved by letting resolved in the main
> > > systemd package, and splitting only systemd-resolvconf in its own package.
> > >
> >
> > Having a single-file-package that is confusing and harder to find is
> > not something we want to do, unless there are extremely compelling
> > reasons for it. Supporting resolvconf is not one.
>
> Could you at least address the temporary break in DNS resolution ? This
> is still a serious bug, which would deserve its own bug with priority
> grave (if not critical). Since systemd-resolved is mainly used on
> servers, it could result in a very bad surprise for sysadmins when
> bookworm is released.
No, it is not, because no integration nor support was provided before.
> Le 17/08/2022 à 00:36, Luca Boccassi a écrit :
> > > Personally I see this as a regression, since resolved used to be part of
> > > systemd and thus readily available without installing additional packages.
> >
> > No support was provided before for resolved, it was completely inhert,
> > hence it is not a regression. It is a change in behaviour, and thus
> > noted in the NEWS file as expected.
> >
> > > Yes, but this goal could be achieved by letting resolved in the main
> > > systemd package, and splitting only systemd-resolvconf in its own package.
> > >
> >
> > Having a single-file-package that is confusing and harder to find is
> > not something we want to do, unless there are extremely compelling
> > reasons for it. Supporting resolvconf is not one.
>
> Could you at least address the temporary break in DNS resolution ? This
> is still a serious bug, which would deserve its own bug with priority
> grave (if not critical). Since systemd-resolved is mainly used on
> servers, it could result in a very bad surprise for sysadmins when
> bookworm is released.
It was an inhert and disabled service and binary.
The NEWS file covers the change adequately for custom setups. Custom
setups are always at risk of breakage.
> Perhaps it could be fixed by promoting systemd-resolved to a recommends
> (instead of suggests) in systemd, so that it's installed during the
> upgrade ? Or don't stop the service if /etc/resolv.conf is symlinked to
> /run/systemd/resolve/stub-resolv.conf, so that the admin has the time to
> read the NEWS entry (which, again, didn't work on my system, whereas it
> was supposed to be sent in an e-mail by apt-listchanges), and install
> systemd-resolved before rebooting ?
really don't want that at this stage. There appears to be some bug in
apt-listchanges when showing changelogs is enabled making it skip NEWS
files if a changelog for the same version was already displayed, and
there's not much we can do about it, it's a problem to be solved by
apt-listchanges.
> Also, I understand that you don't wish to revert your changes, but is
> there a reason why resolvconf, openresolv and thus systemd-resolved
> could coexist thanks to the alternatives system ? I know it would be
> more work for maintainers of those three packages, but IMHO it would be
> worth the effort.
have never existed in the first place. If you want to use openresolv,
install openresolv and remove resolved.
> And, last but not the least, I see that /etc/resolv.conf is now part of
> systemd-resolved files, which means that it would be deleted when the
> systemd-resolved package is removed from the system. I think it would
> also deserve its own bug with some high priority
install another one that provides it.
Luca Boccassi
Aug 18, 2022, 11:10:04 AM8/18/22
to
On Thu, 2022-08-18 at 16:46 +0200, Raphaël Halimi wrote:
> systemd, with a stable interface, and as such, it was available for the
> admin to use it if he/she wished. Breaking DNS resolution after an
> upgrade is not a serious bug in your opinion ?
No, custom and unsupported setups are unsupported. Compatibility is
provided for default environments, anything outside of it can and will
break at any given time, and it's not really feasible to do otherwise
given the uncountable amount of possible permutations. This time
there's a clear and unambiguos NEWS entry with a notification, which
doesn't even always happen.
> > That would make it de-facto the default resolver on Debian, and we
> > really don't want that at this stage. There appears to be some bug in
> > apt-listchanges when showing changelogs is enabled making it skip NEWS
> > files if a changelog for the same version was already displayed, and
> > there's not much we can do about it, it's a problem to be solved by
> > apt-listchanges.
>
> Wrong, I always receive e-mails with news as well as changelogs during
> upgrades, with the more recent examples being on July 13, 22 and 25. I
> don't know why it didn't work this time, but I can hardly believe that
> it's apt-listchanges' fault.
And yet it is, and it's been a known issue for quite some time:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977422
> > Absolutely not, the alternatives system is a gigantic mess that should
> > have never existed in the first place. If you want to use openresolv,
> > install openresolv and remove resolved.
>
> I think you don't understand my position: I don't care about resolvconf
> or openresolv, I just want to use systemd-resolved (not the systemd
> resolvconf interface, but the systemd-resolved service itself!) and
> avoid breakage during upgrades for all users.
>
> Look, I'm just trying to help here. You made a change, it has serious
> consequences for systemd-resolved users, and I hinted them to you,
> that's all. I think this is a bad change, but that's another matter.
> Being obtuse and condescending won't help.
Name-calling won't help either.
> Le 18/08/2022 à 16:20, Luca Boccassi a écrit :
> > No, it is not, because no integration nor support was provided before.
> > It was an inhert and disabled service and binary.
> > The NEWS file covers the change adequately for custom setups. Custom
> > setups are always at risk of breakage.
>
> I agree that it was not enabled by default, but it was shipped by
> > No, it is not, because no integration nor support was provided before.
> > It was an inhert and disabled service and binary.
> > The NEWS file covers the change adequately for custom setups. Custom
> > setups are always at risk of breakage.
>
> systemd, with a stable interface, and as such, it was available for the
> admin to use it if he/she wished. Breaking DNS resolution after an
> upgrade is not a serious bug in your opinion ?
No, custom and unsupported setups are unsupported. Compatibility is
provided for default environments, anything outside of it can and will
break at any given time, and it's not really feasible to do otherwise
given the uncountable amount of possible permutations. This time
there's a clear and unambiguos NEWS entry with a notification, which
doesn't even always happen.
> > That would make it de-facto the default resolver on Debian, and we
> > really don't want that at this stage. There appears to be some bug in
> > apt-listchanges when showing changelogs is enabled making it skip NEWS
> > files if a changelog for the same version was already displayed, and
> > there's not much we can do about it, it's a problem to be solved by
> > apt-listchanges.
>
> upgrades, with the more recent examples being on July 13, 22 and 25. I
> don't know why it didn't work this time, but I can hardly believe that
> it's apt-listchanges' fault.
And yet it is, and it's been a known issue for quite some time:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977422
> > Absolutely not, the alternatives system is a gigantic mess that should
> > have never existed in the first place. If you want to use openresolv,
> > install openresolv and remove resolved.
>
> or openresolv, I just want to use systemd-resolved (not the systemd
> resolvconf interface, but the systemd-resolved service itself!) and
> avoid breakage during upgrades for all users.
>
> Look, I'm just trying to help here. You made a change, it has serious
> consequences for systemd-resolved users, and I hinted them to you,
> that's all. I think this is a bad change, but that's another matter.
> Being obtuse and condescending won't help.
Name-calling won't help either.
Luca Boccassi
Aug 18, 2022, 3:40:04 PM8/18/22
to
On Thu, 2022-08-18 at 18:07 +0200, Raphaël Halimi wrote:
> systemd-resolved) was considered supported since it was shipped with
> systemd and thus installed by default (unlike, for example, netplan),
> albeit not enabled.
>
> Should I understand that the only supported way to configure the network
> in Debian is ifupdown with a plain /etc/resolv.conf file, and everything
> outside of this scope is considered custom and thus, unsupported ? I'm
> not being ironical here, it's a legitimate question.
The default supported network configuration managers on Debian are
NetworkManager for desktop environments (default brought in by Gnome,
the default desktop env), and ifupdown (which is priority: important)
for headless environments.
> > > Wrong, I always receive e-mails with news as well as changelogs during
> > > upgrades, with the more recent examples being on July 13, 22 and 25. I
> > > don't know why it didn't work this time, but I can hardly believe that
> > > it's apt-listchanges' fault.
> >
> > And yet it is, and it's been a known issue for quite some time:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977422
>
> OK, you're right on this point, I didn't know that. Apologies. But it
> also means that other sysadmins will be in the same case too when the
> upgrade will take place (when bookworm is released, or when systemd
> 251.3-2 will be backported to bullseye) and will have their DNS
> resolution temporarily broken after the upgrade.
>
> But I guess you'll probably argue that it's their fault for using
> systemd-resolved.
NEWS files' main purpose is to communicate breaking changes, so I hope
the issue in apt-listchanges is fixed before the release. Feel free to
go bump the severity if you wish. I cannot do much about it.
> > > I think you don't understand my position: I don't care about resolvconf
> > > or openresolv, I just want to use systemd-resolved (not the systemd
> > > resolvconf interface, but the systemd-resolved service itself!) and
> > > avoid breakage during upgrades for all users.
> > >
> > > Look, I'm just trying to help here. You made a change, it has serious
> > > consequences for systemd-resolved users, and I hinted them to you,
> > > that's all. I think this is a bad change, but that's another matter.
> > > Being obtuse and condescending won't help.
> >
> > Name-calling won't help either.
>
> Right, but at least admit that you're being a bit harsh to me since the
> beginning of this thread, rejecting all my arguments and refusing to see
> the problem here, basically saying that the resulting breakage is not
> your fault and systemd-resolved users brought it on themselves by using
> it because it's "unsupported".
>
> Again, I don't care about resolvconf or openresolv, I care about
> sysadmins who use systemd-networkd/resolved on their servers or
> containers, and I'm just trying to avoid problems for them as well as
> for myself in the future.
>
> systemd brought a lot of controversy when it was adopted in Debian, and
> I myself was amongst the people who were quite unhappy when it happened
> (I still think that Jessie was too soon, it was not mature enough, but
> that's another story).
>
> Now that we started to familiarize with its different parts and all in
> all find it very convenient that they're installed by default, you
> slowly remove them one by one (systemd-machined, systemd-timesyncd,
> systemd-boot, and now systemd-resolved... Which will be the next ?),
> forcing us sysadmins to constantly update our automated installation
> procedures (debian-installer hooks, ansible/puppet recipes, container
> images, etc etc), and defeating the very purpose of systemd to be "a
> suite of basic building blocks for a Linux system" that we finally embraced.
>
> It's almost as if you want to discourage us to use the non-init-related
> parts of systemd.
Staying with a distro's default means there's almost always a seamless
upgrade path when breaking changes happen, though not always.
Going for a custom setup means sometimes there is, sometimes there's
not. It's always a tradeoff. This breaking change means there's now a
supported way to run resolved, and it's the easiest possible way for
all those that weren't using it before, which is the majority given
there was no support and no integration before.
> Le 18/08/2022 à 16:59, Luca Boccassi a écrit :
> > No, custom and unsupported setups are unsupported. Compatibility is
> > provided for default environments, anything outside of it can and will
> > break at any given time, and it's not really feasible to do otherwise
> > given the uncountable amount of possible permutations. This time
> > there's a clear and unambiguos NEWS entry with a notification, which
> > doesn't even always happen.
>
> What I meant is that I thought systemd-networkd (which partly relies on
> > No, custom and unsupported setups are unsupported. Compatibility is
> > provided for default environments, anything outside of it can and will
> > break at any given time, and it's not really feasible to do otherwise
> > given the uncountable amount of possible permutations. This time
> > there's a clear and unambiguos NEWS entry with a notification, which
> > doesn't even always happen.
>
> systemd-resolved) was considered supported since it was shipped with
> systemd and thus installed by default (unlike, for example, netplan),
> albeit not enabled.
>
> Should I understand that the only supported way to configure the network
> in Debian is ifupdown with a plain /etc/resolv.conf file, and everything
> outside of this scope is considered custom and thus, unsupported ? I'm
> not being ironical here, it's a legitimate question.
The default supported network configuration managers on Debian are
NetworkManager for desktop environments (default brought in by Gnome,
the default desktop env), and ifupdown (which is priority: important)
for headless environments.
> > > Wrong, I always receive e-mails with news as well as changelogs during
> > > upgrades, with the more recent examples being on July 13, 22 and 25. I
> > > don't know why it didn't work this time, but I can hardly believe that
> > > it's apt-listchanges' fault.
> >
> > And yet it is, and it's been a known issue for quite some time:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977422
>
> also means that other sysadmins will be in the same case too when the
> upgrade will take place (when bookworm is released, or when systemd
> 251.3-2 will be backported to bullseye) and will have their DNS
> resolution temporarily broken after the upgrade.
>
> But I guess you'll probably argue that it's their fault for using
> systemd-resolved.
NEWS files' main purpose is to communicate breaking changes, so I hope
the issue in apt-listchanges is fixed before the release. Feel free to
go bump the severity if you wish. I cannot do much about it.
> > > I think you don't understand my position: I don't care about resolvconf
> > > or openresolv, I just want to use systemd-resolved (not the systemd
> > > resolvconf interface, but the systemd-resolved service itself!) and
> > > avoid breakage during upgrades for all users.
> > >
> > > Look, I'm just trying to help here. You made a change, it has serious
> > > consequences for systemd-resolved users, and I hinted them to you,
> > > that's all. I think this is a bad change, but that's another matter.
> > > Being obtuse and condescending won't help.
> >
> > Name-calling won't help either.
>
> beginning of this thread, rejecting all my arguments and refusing to see
> the problem here, basically saying that the resulting breakage is not
> your fault and systemd-resolved users brought it on themselves by using
> it because it's "unsupported".
>
> Again, I don't care about resolvconf or openresolv, I care about
> sysadmins who use systemd-networkd/resolved on their servers or
> containers, and I'm just trying to avoid problems for them as well as
> for myself in the future.
>
> systemd brought a lot of controversy when it was adopted in Debian, and
> I myself was amongst the people who were quite unhappy when it happened
> (I still think that Jessie was too soon, it was not mature enough, but
> that's another story).
>
> Now that we started to familiarize with its different parts and all in
> all find it very convenient that they're installed by default, you
> slowly remove them one by one (systemd-machined, systemd-timesyncd,
> systemd-boot, and now systemd-resolved... Which will be the next ?),
> forcing us sysadmins to constantly update our automated installation
> procedures (debian-installer hooks, ansible/puppet recipes, container
> images, etc etc), and defeating the very purpose of systemd to be "a
> suite of basic building blocks for a Linux system" that we finally embraced.
>
> It's almost as if you want to discourage us to use the non-init-related
> parts of systemd.
Staying with a distro's default means there's almost always a seamless
upgrade path when breaking changes happen, though not always.
Going for a custom setup means sometimes there is, sometimes there's
not. It's always a tradeoff. This breaking change means there's now a
supported way to run resolved, and it's the easiest possible way for
all those that weren't using it before, which is the majority given
there was no support and no integration before.
Michael Prokop
Aug 19, 2022, 3:10:03 AM8/19/22
to
Hi,
* Luca Boccassi [Thu Aug 18, 2022 at 03:20:22PM +0100]:
I just tested a few things, JFYI:
* When systemd-resolved is installed and gets removed, the
file/symlink /etc/resolv.conf gets removed as well. Is that really
expected? (This is something e.g. the resolvconf doesn't do, you
still end up with a /etc/resolv.conf being in-place then)
* Installation of the systemd-resolved package inside docker/podman
fails hard for me (running on a Debian/bullseye host):
| Unpacking systemd-resolved (251.4-1) ...
| dpkg: error processing archive /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb (--unpack):
| unable to make backup link of './etc/resolv.conf' before installing new version: Invalid cross-device link
| Selecting previously unselected package libnss-resolve:amd64.
| Preparing to unpack .../libnss-resolve_251.4-1_amd64.deb ...
| Unpacking libnss-resolve:amd64 (251.4-1) ...
| Errors were encountered while processing:
| /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb
| E: Sub-process /usr/bin/dpkg returned an error code (1)
(Didn't investigate further on this yet, seems to be related to the
way dpkg handles symlinks (as set up by dh_link in the systemd
packaging) and containers with overlay doesn't like that, though
installing systemd inside docker/podman containers used to work fine
so far for me)
HTH && regards
-mika-
* Luca Boccassi [Thu Aug 18, 2022 at 03:20:22PM +0100]:
* When systemd-resolved is installed and gets removed, the
file/symlink /etc/resolv.conf gets removed as well. Is that really
expected? (This is something e.g. the resolvconf doesn't do, you
still end up with a /etc/resolv.conf being in-place then)
* Installation of the systemd-resolved package inside docker/podman
fails hard for me (running on a Debian/bullseye host):
| Unpacking systemd-resolved (251.4-1) ...
| dpkg: error processing archive /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb (--unpack):
| unable to make backup link of './etc/resolv.conf' before installing new version: Invalid cross-device link
| Selecting previously unselected package libnss-resolve:amd64.
| Preparing to unpack .../libnss-resolve_251.4-1_amd64.deb ...
| Unpacking libnss-resolve:amd64 (251.4-1) ...
| Errors were encountered while processing:
| /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb
| E: Sub-process /usr/bin/dpkg returned an error code (1)
(Didn't investigate further on this yet, seems to be related to the
way dpkg handles symlinks (as set up by dh_link in the systemd
packaging) and containers with overlay doesn't like that, though
installing systemd inside docker/podman containers used to work fine
so far for me)
HTH && regards
-mika-
Luca Boccassi
Aug 20, 2022, 3:40:04 PM8/20/22
to
On Fri, 19 Aug 2022 08:58:03 +0200 Michael Prokop <mi...@debian.org>
wrote:
Yes I noticed the same thing when building images, this cross-device
check is a true annoyance and can't seem to find a workaround :-/
wrote:
check is a true annoyance and can't seem to find a workaround :-/
Luca Boccassi
Aug 20, 2022, 6:50:03 PM8/20/22
to
On Sat, 20 Aug 2022 20:30:43 +0100 Luca Boccassi <bl...@debian.org>
wrote:
I can't find a solution, so unfortunately it looks like we have to
resort to maintainer scripts, which is awful but I can't think of
anything else:
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/164
wrote:
resort to maintainer scripts, which is awful but I can't think of
anything else:
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/164
0 new messages