Re: Assurances that autopkgtests can resolve 'localhost' to test network services
On Tue, 24 Jun 2025 at 16:45:58 +0000, John Scott wrote:
it doesn't seem like there's any guarantee, not even with a careful choice of restrictions such as 'isolation-container', that a loopback interface exists when a test is run, or that the name 'localhost' resolves to the testbed
I think the loopback (lo) interface and 127.0.0.1 should be considered
to be "part of the API". Our default init system (systemd), as typically
used on real hardware, VMs, and system containers like lxc/lxd/incus,
brings up the loopback interface as a hard-coded early-boot thing rather
than something that is configurable; and it's straightforward for
container managers like podman, docker, unshare and even the
unprivileged bubblewrap to do likewise.
Non-default init systems like sysvinit don't necessarily guarantee to
bring up the loopback interface (because sysvinit outsources almost all
of its functionality to init scripts, rather than implementing the
basics in C code like systemd does), but I think it would be OK to say
that autopkgtests are only required to pass on reasonable systems, and
at this point a fully-bootable system that doesn't bring up loopback
(for example it might boot with sysvinit, but lack ifupdown or similar)
is no longer a reasonable thing to test on.
I don't think usability of ::1 is *necessarily* guaranteed, because
/proc/sys/net/ipv6/conf/all/disable_ipv6 is something that is offered,
so tests that specifically connect to ::1 should probably be guarded by
a general check that IPv6 works and skipped if not. The skippable
restriction, combined with a Perl or Python script that listens on an
interface to prove that it can, would be a good way to check that.
Ability to resolve "localhost" is more subtle. To guarantee to be able
to resolve that, in principle you either need netbase (for /etc/hosts)
or libnss-myhostname. It also doesn't *necessarily* resolve
successfully with AF_INET or AF_INET6 and the AI_ADDRCONFIG flag,
because of <https://bugs.debian.org/952740>.
Ability to resolve the result of gethostname() (sometimes desired by
e.g. mailservers) is also not guaranteed; libnss-myhostname guarantees
to provide it (because that's the point), and in practice netbase
generally provides it too but I'm not sure that's technically a
guarantee.
Is this something I should write off as "just plain common sense" that doesn't need to be prescribed
I think mostly yes, with some caveats as above. dbus, glib2.0 and the
libsoup* family are among the many examples of packages that assume that
they can make a server listen on 127.0.0.1 and run a client against it.
Realistically I think isolation-container and isolation-machine should promise that an Internet Protocol-compatible loopback interface always exists such that listening and connecting to ports on the localhost including the loopback address works.
I think this is such a common test scenario that we should consider it
to be a guarantee even with no particular restrictions declared:
technically tests that rely on it would fail if run on a system where
loopback communication is broken, but I think it would be valid for us
to say that such a system is unreasonable and therefore those failures
aren't bugs.
(Analogous: if you run tests on a system where PATH has been
misconfigured to not include /usr/bin, lots of tests would fail, but we
wouldn't say that was a bug either.)
This mainly matters so I can write a test with a server and have a client attempt a connection to it.
This is a common test scenario and in practice a lot of packages do it,
with no particular Restrictions. I think this is fine.
If we say that now, even if in future we somehow find a use-case for
testbeds with no loopback interface, there is a possible exit strategy:
we could declare that in such a testbed, only tests with new Features
(Features: works-without-loopback?) should be run, and all others should
be skipped.
smcv
Reply to: