Package: cloud.debian.org
Severity: important
X-Debbugs-Cc: flaviovs@magnux.com

Hello,

Bookworm's release notes clearly states that "systemd-resolved was
not, and still is not, the default DNS resolver in Debian" (https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#systemd-resolved)

However apparently it is the default on the Debian provided AWS AMIs
-- at least that's what I got out-of-box on a few instances I
installed recently from the images in https://wiki.debian.org/Cloud/AmazonEC2Image/Bookworm for the
us-east-2 and ca-west-1 regions.

Goals here is not to discuss systemd idiosyncrasies, but I've only got headaches with systemd-resolved/-networkd to the point it's being
easier to install Bullseye and upgrade (no extra systemd-nonsensed
then, everything works).

So I just want to clarify what's the current status quo regarding systemd-resolved/-networkd in cloud images so I can file bug reports
properly.

p.s.: same for polkitd -- not sure if we need a daemon "intended to be
used by privileged programs offering service to unprivileged programs
often through some form of inter-process communication mechanism"
installed NOT TO SAY RUNNING on a purposedly minimal network server
that virtually can only be acessed via ssh. I'm happy to file a bug report/wishlist item if necessary.

Thank you,
FVS

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Apr 03, 2024 at 09:39:40PM -0700, Flavio Veloso Soares wrote:

Hi Noah - I guess I'll be doing bullseye->bookworm installs in the meantime, until 12.6 so I can fill bug reports (if any).

It should be plenty to start with the bookworm images and simply remove
the libnss-resolve package. It's quite a lot simpler.

noah

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Noah,

First of all many thanks for the new images and for the help with this
bug report.

Regarding removing libnss-resolve, that's good to know. I figured doing bullseye->bookworm was not a good strategy long-term anyways, so I
decided to look further for a solution, which I found by removing the
resolve entries in /etc/nsswitch.conf.

But I'll definitely will try by removing libnss-resolve on next installs.

For instance, the other issue I was facing turned out not to be related
to s-resolved, but to s-networkd not honoring DHCP search domains (for
which I'm currently testing a solution and plan to file a bug reports
soon, hopefully with a proposed workaround).

Regards,

On 2024-04-11 20:33, Noah Meyerhans wrote:

On Wed, Apr 03, 2024 at 09:39:40PM -0700, Flavio Veloso Soares wrote:

Hi Noah - I guess I'll be doing bullseye->bookworm installs in the meantime, >> until 12.6 so I can fill bug reports (if any).

It should be plenty to start with the bookworm images and simply remove
the libnss-resolve package. It's quite a lot simpler.

noah

--
FVS

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

A small heads up on this issue, we have some minor impacts :

* sudo commands show a warning

sudo: unable to resolve host example: Name or service not known


On a more problematic side (but not breaking) we have filebeat that
generates a lot of logs with warnings related to the change :

* Failed looking up CNAME: lookup ip-10-31-51-7 on 10.31.48.2:53: no such
host: failed looking up IP: lookup ip-10-31-51-7 on 10.31.48.2:53: no such host, using hostname = ip-10-31-51-7 as FQDN

Our workaround so far is to install `libnss-resolve` in our packer build of
the AMI that is based on the debian bookworm AMI.

Arthur

<div dir="ltr"><div>Hi, <br></div><div><br></div><div>A small heads up on this issue, we have some minor impacts : <br></div><div><br></div><div>* sudo commands show a warning <br></div><div><br></div><div><pre class="gmail-hljs-copy-wrapper"><code class=
"gmail-language-shell gmail-hljs">sudo: unable to resolve host example: Name or service not known</code></pre></div><div><br></div><div>On a more problematic side (but not breaking) we have filebeat that generates a lot of logs with warnings  related to
the change : <br></div><div><br></div><div>* Failed looking up CNAME: lookup ip-10-31-51-7 on <a href="http://10.31.48.2:53" target="_blank">10.31.48.2:53</a>: no such host: failed looking up IP: lookup ip-10-31-51-7 on <a href="http://10.31.48.2:53"
target="_blank">10.31.48.2:53</a>: no such host, using hostname = ip-10-31-51-7 as FQDN</div><div><br></div><div>Our workaround so far is to install `<code>libnss-resolve` in our packer build of the AMI that is based on the debian bookworm AMI. <br></
code></div><div><code><br></code></div><div><code>Arthur<br></code></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Apr 18, 2024 at 10:17:27AM +0200, Arthur LUTZ wrote:

Hi,
A small heads up on this issue, we have some minor impacts :
* sudo commands show a warning

sudo: unable to resolve host example: Name or service not known

On a more problematic side (but not breaking) we have filebeat that
generates a lot of logs with warnings  related to the change :
* Failed looking up CNAME: lookup ip-10-31-51-7 on [1]10.31.48.2:53: no
such host: failed looking up IP: lookup ip-10-31-51-7 on [2]10.31.48.2:53:
no such host, using hostname = ip-10-31-51-7 as FQDN
Our workaround so far is to install `libnss-resolve` in our packer build
of the AMI that is based on the debian bookworm AMI.

Indeed, we needed to install libnss-myhostname in addition to removing libnss-resolve. This will be fixed in a future release, but in the
meantime you can work around it by installing libnss-myhostname
yourself.

noah

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Apr 18, 2024 at 10:17:27AM +0200, Arthur LUTZ wrote:

A small heads up on this issue, we have some minor impacts :
* sudo commands show a warning

sudo: unable to resolve host example: Name or service not known

Thanks for the report. This is resolved with the 20240429 images.

noah

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)