[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: