>>>>> "Lucas" == Lucas Nussbaum <lu...@debian.org> writes:

    Lucas> On 26/10/23 at 07:45 -0600, Sam Hartman wrote:
    >> >>>>> "Lucas" == Lucas Nussbaum <lu...@debian.org> writes:
    Lucas> Hi,
    >> 
    Lucas> As an additional data point, I can still reproduce this
    Lucas> failure.
    >> 
    >> So, my understanding is that so far for you it always fails, and
    >> the evidence so far suggests that it generally (or always, but I
    >> am not sure we have long enough evidence for that) succeeds on
    >> the builds.
    >> 
    >> What is your environment like?  Chroot? Container?  If any
    >> namespaces are involved, how do you build the namespaces, and
    >> what non-default capability settings do you have on top of the
    >> defaults of containerization software you use.

    Lucas> It's a standard sbuild setup, on an AWS EC2 VM.

Yep, it's some sort of DNS issue.  A kind developer gave me access to a
similarly configured machine on which I can reproduce the problem.

Outside the chroot:

PING ip-10-84-234-64(ip-10-84-234-64 (fe80::816:edff:fe35:ded1%ens5)) 56
data bytes
64 bytes from ip-10-84-234-64 (fe80::816:edff:fe35:ded1%ens5):
icmp_seq=1 ttl=64 time=0.022 ms
64 bytes from ip-10-84-234-64 (fe80::816:edff:fe35:ded1%ens5):
icmp_seq=2 ttl=64 time=0.035 ms
^C
--- ip-10-84-234-64 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1010ms
rtt min/avg/max/mdev = 0.022/0.028/0.035/0.006 ms


(bookworm)hartmans@ip-10-84-234-64:~$ ping ip-10-84-234-64
ping: ip-10-84-234-64: Name or service not known

The test framework uses gethostname() to find the name to use to contact
the KDC.
kinit is trying to look up ip-10-84-234-64 and contact a KDC on that
address.
But because that name is not resolvable within the chroot, the test
fails.

The configuration difference between inside the chroot and outside the
chroot appears to be the use of systemd-resolved.
In particular libnss-resolve  is installed on the host.
Resolved can resolve ip-10-84-234-64,
but the EC2 nameserver referenced by resolv.conf in the chroot cannot
resolve that name without qualification.

I'm not entirely sure what the right fix is.  Krb5 tests really do want
a name that they can use to refer to the local machine (and it would be
significant work to get that name from a source other than
gethostname()).

Possibilities include:

* Use 127.0.0.53 inside the chroot and let systemd-resolved resolve the
  name.

* Find some way to detect this situation and bypass the tests.

* include the appropriate search domain in the chroot's resolv.conf so
  that EC2 can resolve the machine's name.
  

Reply via email to