I'd like to use systemd-resolved in my Debian live cd/usb, built with
live-build. This fails, as I believe will fail any other attempt to use
systemd-resolved in debootstrapped chroot environment.

Installing systemd-resolved overwrites /etc/resolv.conf with link to
../run/systemd/resolve/stub-resolve.conf.

From systemd-resolved.postinst:

        echo "Converting /etc/resolv.conf to a symlink to /run/systemd/resolve/stub-resolv.conf..."
        if [ -f "${DPKG_ROOT}/etc/resolv.conf" ]; then
            mv "${DPKG_ROOT}/etc/resolv.conf" "${DPKG_ROOT}/etc/.resolv.conf.systemd-resolved.bak" || echo "Cannot take a backup of /etc/resolv.conf."
        fi
        ln -sf ../run/systemd/resolve/stub-resolv.conf "${DPKG_ROOT}/etc/resolv.conf" || echo "Cannot install symlink from /etc/resolv.conf to ../run/systemd/resolve/stub-resolv.conf"

This is fine, as long as systemd-resolved.service it started right away.

However, when building a Debian live image or quite possibly when doing
any Debian install in debootstrapped chroot environment, the service is
not started.

Now we are in a chroot environment, but name resolution does not work.

Would it be possible to defer overwriting /etc/resolv.conf? Does it have
to happen at .postinst and not at, say, at the start of the service?

Example:

# mkdir bootstrapped
# debootstrap bookworm bootstrapped
I: Target architecture can be executed
I: Retrieving InRelease
I: Checking Release signature
I: Valid Release signature (key id A7236886F3CCCAAD148A27F80E98404D386FA1D9)
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://deb.debian.org/debian...
[ ... ]
I: Base system installed successfully.
# mount --make-private --rbind /dev bootstrapped/dev/
# mount --make-private --rbind /proc bootstrapped/proc/
# mount --make-private --rbind /sys bootstrapped/sys
# chroot bootstrapped/
# ping -c 1 deb.debian.org
PING deb.debian.org(2a04:4e42:8e::644 (2a04:4e42:8e::644)) 56 data bytes
64 bytes from 2a04:4e42:8e::644 (2a04:4e42:8e::644): icmp_seq=1 ttl=59 time=5.26 ms
--- deb.debian.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.256/5.256/5.256/0.000 ms
# apt install systemd-resolved
Reading package lists... Done
Building dependency tree... Done
[ ...]
Selecting previously unselected package systemd-resolved.
Preparing to unpack .../8-systemd-resolved_252.6-1_amd64.deb ...
Unpacking systemd-resolved (252.6-1) ...
[...]
Setting up dbus (1.14.6-1) ...
Running in chroot, ignoring request.
Setting up systemd-resolved (252.6-1) ...
Converting /etc/resolv.conf to a symlink to /run/systemd/resolve/stub-resolv.conf...
Creating group 'systemd-resolve' with GID 997.
Creating user 'systemd-resolve' (systemd Resolver) with UID 997 and GID 997.
Created symlink /etc/systemd/system/dbus-org.freedesktop.resolve1.service → /lib/systemd/system/systemd-resolved.service.
Created symlink /etc/systemd/system/sysinit.target.wants/systemd-resolved.service → /lib/systemd/system/systemd-resolved.service.
Setting up libnss-resolve:amd64 (252.6-1) ...
Processing triggers for libc-bin (2.36-8) ...
# ping -c1 deb.debian.org
ping: deb.debian.org: Name or service not known
# ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Mar 14 12:34 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
# cat /etc/resolv.conf
cat: /etc/resolv.conf: No such file or directory

work.
have

No, because the image might be read-only by that time. If you decide to
install the package, you need to ensure it can work, and if you use an
image build tool, it's up to that tool to ensure it is set up
correctly, as it obviously cannot be done from the package itself.

Let's make this RC, as it breaks updates.

The systemd-resolved package modifies a global config file
/etc/resolv.conf.  This breaks any name resolution if resolved is not
running.  Especially if it can't run at all.

| root@debian-sid:~# ls -al /etc/resolv.conf
| lrwxrwxrwx 1 root root 40 Mar 14 14:03 /etc/resolv.conf -> /../run/systemd/resolve/stub-resolv.conf
| root@debian-sid:~# getent hosts heise.de
| 2a02:2e0:3fe:1001:302:: heise.de
| root@debian-sid:~# systemctl stop systemd-resolved
| root@debian-sid:~# getent hosts heise.de
| root@debian-sid:~#

Sorry, but the only person to know if resolved can be used is the admin,
not a package.

Bastian

Control: severity -1 wishlist
Control: tags -1 wontfix
/../run/systemd/resolve/stub-resolv.conf
admin,

Exactly, so the admin shouldn't install a package that in the
description says:

"Installing this package automatically overwrites /etc/resolv.conf and
switches it to be managed by systemd-resolved."

if that's not what they want to achieve. I agree that the
/etc/resolv.conf interface is garbage, but there's nothing we can do
about it, that's just how it works.
This is the only way read-only images can be supported sanely.

Why exactly is it necessary to overwrite /etc/resolv.conf at postinst, even if
the service will not and can not be started?

Wouldn’t it make more sense to make the symlink at a later stage? For
Instance when the service is actually started?

There’s no point in having resolv.conf symlink to
/run/systemd/resolve/stub-resolv.conf when systemd-resolved is not running.

Samuli

On Tue, 14 Mar 2023 18:03:53 +0200 =?utf-8?Q?Samuli_Suonp=C3=A4=C3=A4?= <suonpaa@diurnalis.fi> wrote:
and
do
postinst, even if

No, because at that point /etc might be part of a read-only filesystem
and thus it's too late.
running.

Don't install it if you don't want it to run.

I might accept a patch that switches to using tmpfiles.d, as long as
the default is still to enable on install, and that taking a copy of
the existing resolv.conf is also done, and that it is proven to work on
a read-only image. That way it's easier to override it with a drop-in.
I am not going to write and test such patch though, someone else needs
to do it and send a MR on Salsa.

Am 14.03.23 um 17:31 schrieb Luca Boccassi:
/etc/resolv.conf to /run/systemd/resolve/stub-resolv.conf in postinst.

If systemd-resolved is started, it will be overwritten properly, if not,
the original resolv.conf should continue to work.

This is how resolvconf does it and how the systemd-resolved package in
Ubuntu does it:
https://salsa.debian.org/debian/resolvconf/-/blob/unstable/debian/postinst#L101
https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/systemd-resolved.postinst#n31

Would be a simple, 2-line patch

mkdir -p "${DPKG_ROOT}/run/systemd/resolve"
cp "${DPKG_ROOT}/etc/resolv.conf"
"${DPKG_ROOT}/run/systemd/resolve/stub-resolv.conf"

Regards,
Michael

Hi

I intend to NMU this today.  It changes global config without any
knowledge if it might work.

diff -Nru systemd-253/debian/changelog systemd-253/debian/changelog
--- systemd-253/debian/changelog	2023-02-15 21:36:32.000000000 +0100
+++ systemd-253/debian/changelog	2023-03-19 11:54:54.000000000 +0100
@@ -1,3 +1,10 @@
+systemd (253-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove broken resolv.conf setup.  (closes: #1032937)
+
+ -- Bastian Blank <waldi@debian.org>  Sun, 19 Mar 2023 11:54:54 +0100
+
 systemd (253-1) experimental; urgency=medium

   * New upstream version 253. For a full list of changes, see:
diff -Nru systemd-253/debian/systemd-resolved.postinst systemd-253/debian/systemd-resolved.postinst
--- systemd-253/debian/systemd-resolved.postinst	2023-02-09 15:56:44.000000000 +0100
+++ systemd-253/debian/systemd-resolved.postinst	2023-03-19 11:54:50.000000000 +0100
@@ -23,14 +23,4 @@
     _adopt_conffile "${DPKG_ROOT}/etc/systemd/resolved.conf" systemd-resolved
 fi

This modification of global configuration breaks the building of cloud
images.  We need a way to install the package, but no services will run
in the environment, nor is there a systemd-resolved in the same network
namespace.

The build does not exhibit that failure right now, because by chance
systemd-resolved is the last thing that needs a working resolver before
the build is finished.  But this is not guaranteed.

Regards,
Bastian

NACK, this is wrong as already explained.

Hi Bastian,

That sounds fine to me.

On irc, you explained the concrete expectation an I'm giving it here for
reference.

You expect that you can install systemd-resolved without running any
services or init processes (in a chroot or service-less container) and
then continue using DNS resolution inside that environment.

I content that such an environment is very unusual since you would not
want to install systemd-resolved in a setting where you do not run
services and if you are in bootstrap setting, you can use an external
apt (with access to an external resolv.conf) to download packages.

Even then when assuming that your expectation is well-founded (which I
do not fully agree with), it remains unclear why Michael's proposal
would not solve your problem.

Given the lack of answers on these questions, I think that rc-severity
is not reasonable though I do not have authority on this question.

Helmut

Ubuntu had this in their systemd.postinst since 5 years:

and moved the relevant copy operation into systemd-resolved.postinst in September.
Any reason not to apply the same, @Luca?

Workaround for live-build can be a /usr/share/live/build/hooks/normal/0001-systemd-resolved-unbreak.hook.chroot