[buildd-tools-devel] Bug#842634: Bug#851877: fails every time

[Michael Stapelberg]

On Sun, May 14, 2017 at 7:59 AM, Adam Borowski <kilobyte at angband.pl> wrote:

> On Sat, May 13, 2017 at 08:44:15PM +0200, Michael Stapelberg wrote:
> > Sorry for the late reply.
> >
> > Adam, could you run the attached example program (derived from the
> > getaddrinfo and getnameinfo manpages) please? The output should help us
> > narrow down whether the problem is with the application code of sslh or
> > something in the environment.
> >
> > Use: gcc -Wall -o gai gai.c && ./gai localhost 9002
>
> On all three machines, it looks fine:
> .----
> printing getaddrinfo(localhost, 9002) results:
>
>   ai_family = 10
>   ai_socktype = 2
>   ai_protocol = 17
>   rp->ai_addrlen = 28
>     host=::1, serv=9002
>
>   ai_family = 2
>   ai_socktype = 2
>   ai_protocol = 17
>   rp->ai_addrlen = 16
>     host=127.0.0.1, serv=9002
>
> done
> `----
>

This seems correct.


>
> Inside the chroot:
> .----
> [/srv/sbuild/stretch-armhf/tmp]# cp -p /tmp/gai .
> [/srv/sbuild/stretch-armhf/tmp]# chroot ..
> (stretch-armhf-sbuild)root at kholdan:/# tmp/gai localhost 9002
> printing getaddrinfo(localhost, 9002) results:
>
>   ai_family = 2
>   ai_socktype = 2
>   ai_protocol = 17
>   rp->ai_addrlen = 16
>     host=127.0.0.1, serv=9002
>
>   ai_family = 2
>   ai_socktype = 2
>   ai_protocol = 17
>   rp->ai_addrlen = 16
>     host=127.0.0.1, serv=9002
>
> done
> `----
>

This seems incorrect: the results are two IPv4 addresses (127.0.0.1:9002)
as opposed to one IPv6 and one IPv4 address (or just one IPv4 address).

I can actually reproduce this issue on abel.debian.org (armhf porterbox):

On abel, my gai test program returns ::1, 127.0.0.1.
On abel within an schroot, my gai test program returns 127.0.0.1, 127.0.0.1.

Looking at /etc/hosts within the schroot, I see:
127.0.0.1       localhost
127.0.0.1       localhost ip6-localhost ip6-loopback
172.28.17.11    abel.debian.org abel

Modifying /etc/hosts by replacing ::1 with 127.0.0.1 results in being able
to reproduce the issue on other machines as well.

This has already caused issues in other packages (e.g. rustc), and is
tracked as Debian bug #842634.

Now, the next question is: where does this /etc/hosts come from? The file
is present in the above form directly after unpacking the schroot tarball,
before even entering the schroot:

abel% sessionid=$(schroot -b -c sid)
abel% cat /srv/chroot/schroot-unpack/$sessionid/etc/hosts
127.0.0.1       localhost
127.0.0.1       localhost ip6-localhost ip6-loopback
172.28.17.11    abel.debian.org abel

Running debootstrap does not produce an /etc/hosts in --variant=minbase and
--variant=buildd. When run without --variant, it does produce an
/etc/hosts, but that looks correct:

midna% sudo debootstrap --variant=minbase stretch /tmp/bootstrap
http://deb.debian.org/debian
midna% cat /tmp/bootstrap/etc/hosts
cat: /tmp/bootstrap/etc/hosts: No such file or directory
midna% sudo rm -rf /tmp/bootstrap
midna% sudo debootstrap stretch /tmp/bootstrap http://deb.debian.org/debian
midna% cat /tmp/bootstrap/etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

So, where does the file get mangled? I can’t find any traces in the schroot
and sbuild sources. Does anyone know by chance?



>
>
> Meow!
> --
> Don't be racist.  White, amber or black, all beers should be judged based
> solely on their merits.  Heck, even if occasionally a cider applies for a
> beer's job, why not?
> On the other hand, corpo lager is not a race.
>



-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20170514/ac280742/attachment.html>