[Qa-jenkins-dev] Bug#897662: Bug#897662: reproducible: is localhost unresolvable in the build chroot?

Simon McVittie smcv at debian.org
Thu May 10 14:48:45 BST 2018


On Thu, 10 May 2018 at 12:41:25 +0000, Holger Levsen wrote:
> we build with pbuilder and disabling network access during build is the
> default for some time.
> 
> see #748967 and #806386

One day I should teach sbuild/schroot to unshare the network :-(

I see there were some comments on #806386 about the need to populate
a minimal hosts file inside the container while in the state where the
network is unshared, so that localhost and $(hostname) remain resolvable,
but that doesn't seem to have been implemented yet.

If we could rely on having libnss-myhostname (from src:systemd), we could
guarantee a reasonable resolver without needing to edit the hosts file;
but neither default installations nor minimal chroots have that plugin
installed, so playing with the hosts file is probably the easiest way.

> On Fri, May 04, 2018 at 12:03:03AM +0100, Simon McVittie wrote:
> > If so, I don't think that's a good idea. Resolving arbitrary DNS names
> > and contacting remote machines is not something that a build should be
> > doing; but if we want to run build-time tests for anything that does
> > networking, then I don't think these actions should be counted as network
> > access:
> 
> I disagree: if the tests are part of the build process, there should be no
> external network access be involved in the tests neither, else tests might
> or not fail depending on the network, or produce otherwise different results…

No *external* network access, sure, but the loopback interface isn't
external.

> that said, localhost is probably a special host on the network…

Yes, that was the point of the list of actions that I said shouldn't count
as network access, which you edited out from your reply: the loopback
interface is special. I see the ability to contact lo, 127.0.0.0/8 and
::1 as being less like networking and more like an OS API, and pbuilder
seems to agree (it has a hook to bring up lo). Being able to resolve
localhost is a bit more arguable; I think the reserved name "localhost"
is API too, but I could be convinced otherwise.

If I change the test-case in question so it listens on "127.0.0.1" instead
of "localhost", can I rely on that working? At the moment it seems that
127.0.0.1 does work, otherwise more tests would have failed.

    smcv



More information about the Qa-jenkins-dev mailing list