Am 5. Oktober 2018 12:51:44 MESZ schrieb KatolaZ <katolaz@???>:
>On Fri, Oct 05, 2018 at 12:26:31PM +0200, Evilham wrote:
>
>[cut]
>
>> $ curl -I -H 'Host: deb.devuan.org'
>>
>http://195.85.215.180/merged/pool/DEBIAN/main/n/ncdu/ncdu_1.12-1+b1_amd64.deb
>> HTTP/1.1 302 Moved Temporarily
>> Server: nginx/1.6.2
>> Date: Fri, 05 Oct 2018 10:15:18 GMT
>> Content-Type: text/html
>> Content-Length: 160
>> Connection: keep-alive
>> Location:
>>
>http://debian.ipacct.com/debian/pool/main/n/ncdu/ncdu_1.12-1+b1_amd64.deb
>>
>> * OS/apt follows 302, therefore resolving debian.ipacct.com
>> $ host debian.ipacct.com
>> debian.ipacct.com has address 195.85.215.251
>> debian.ipacct.com has IPv6 address 2a01:9e40::251
>>
>> * OS contacts the listed IPv6 on port 80, which refuses the
>connection.
>> $ curl -I -6
>>
>http://debian.ipacct.com/merged/pool/DEBIAN/main/n/ncdu/ncdu_1.12-1+b1_amd64.deb
>> curl: (7) Failed to connect to debian.ipacct.com port 80: Connection
>refused
>>
>
>Now I understand (even if the latter URL is not what the previous
>Location: header pointed you to, but that makes no difference). The
>main problem is in the same request being channelled half via IPv4 and
>half via IPv6. There is no alternative to 302 redirects, atm, since
>this is how the Devuan repositories work (and has nothing to do with
>amprolla, which runs off-line).

Happens when you quickly copy paste :-).
Amprolla kinda relies on this, otherwise it couldn't work offline.

The problem has 0 to do with the IP version, it just happened to be more evident in this case.

Say I host a devuan pkg mirror that 302s to deb.debian.example.org which is a RR of 8 IPs and 1 of those hosts is misconfigured,,you can expect requests that get redirected there to fail 1/8th of the time which a naïve check won't see 7/8ths of the time and users would not see 7/8 * (N-1)/N where N=$(count of IPs in deb.devuan.org) of the time, so pretty much never and would appear to be purely random.


>Yes. we should check all the IPs connected with a certain mirror, and
>we should also include IPv6 support. It's in the TODO list :)

I suggest the mentioned IP is removed until that is fixed, I can help implement the checks you need, there is nothing speciaç meeded for IPv6 support besides this check which is valid for IPv4 too adding AAAA entries with the IPs that support that.

If the machine you use to perform the checks, doesn't have IPv6 connectivity, I can probably setup something.

If you can point me to the repo with the checking scripts, I can see that the checks are implemented by Wednesday 10th/17th.