El 27/10/23 a las 19:36, Sam Hartman escribió:
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
Hi. The /etc/hosts file for the host machine was like this:
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
and I always wondered what's the minimal file which
is ok to build packages.
In my own test rebuilds, the machines have a minimalistic
/etc/hosts file which at least assigns an IP to
the hostname:
127.0.0.1 localhost
192.168.122.101 thehostname
which I guess it helps to avoid problems like this.
So, I wonder if it would feasible to do something similar
in the mass-rebuilds done by Lucas.
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.
Simple question: Would "localhost" work in this context?
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.
Interesting note: I've checked and installing systemd-resolved
inside the chroot makes the non-FQDN ping to work again.
Certainly, not because any service is started at all, as
they are disabled inside the chroot, as usual:
All runlevel operations denied by policy
but maybe because of additional support files that allow
the chroot to communicate with the DNS in the host machine.
Would it make sense to add systemd-resolved as a build-dependency?
In either case, I don't quite understand the need to resolve the hostname
to obtain the IP to which the connection should take place in the
test suite, as connecting to the outside world inside a package build
is forbidden by policy. In the context of a test suite, should
127.0.0.1 not be enough, or it has to be done with a different IP?
Thanks.
