Mirrormanager provides IPv4 only mirrors to clients that connect via IPv6 #247
Comments
|
Mirror servers may or may not have IPv4 or IPv6 records. MirrorManager only has their URLs, and knows very little about their connectivity (nor should it). The client, given a list of mirror server URLs, can look up each of them for A or AAAA records, and depending on its connectivity, discard addresses which it cannot reach. yum/dnf do not have a way to determine this though (e.g. automatically detect, or via configuration option). Your best approach is going to be to add such into yum/dnf somehow. |
|
is that still true ? that would be a blocker for CentOS Stream 9 on mirrormanager instance hosted by Fedora Infra |
MirrorManager still just returns URLs and does not look if it resolves as IPv4 or IPv6. So far non of our EPEL or Fedora users complained about this (besides this report). So it does not really seem to be blocker. |
|
The challenge is, a server-side application can't know what a client's full
network capabilities are based on one request that doesn't convey that
information. The server can't know that the client is IPv6-only just
because an IPv6 connection was made.
How do other client-side applications handle being on an IPv6-only system?
How is that communicated to the client application (in this case dnf) so it
knows it shouldn't try to make an IPv4 connection? Or do IPv4 connections
simply fail Network Unreachable, and it's left to the client application to
try fallbacks to other protocols and/or other addresses? I believe dnf
does exactly this already.
Thanks,
Matt
…On Wed, Aug 25, 2021 at 9:43 AM Adrian Reber ***@***.***> wrote:
is that still true ? that would be a blocker for CentOS Stream 9 on
mirrormanager instance hosted by Fedora Infra
@adrianreber <https://github.com/adrianreber> : can you confirm/deny ?
MirrorManager still just returns URLs and does not look if it resolves as
IPv4 or IPv6. So far non of our EPEL or Fedora users complained about this
(besides this report). So it does not really seem to be blocker.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#247 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFIHKVBBE3P6OPWEE2FS5LT6T6QZANCNFSM4E5U4RQA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
can this be added as a RFE ? as that's the reason why for centos mirrorlists, our crawler was creating also ipv6 lists, (dual-stack) to answer only validated mirrors with AAAA records and so we were sure that from a yum/dnf PoV, it was always possible to reach target mirror, and not be in the situation described by initial requestor. |
If this becomes necessary we can of course add it. It would make the crawler a bit more complicated but sounds doable if required. Currently the crawler has no IPv6 connectivity so that would also need to change but it all sounds doable. |
I have a server that only has IPv6 connectivity. When I retrieve a list of mirrors, some mirrors that are IPv4 only are included in the list. This makes yum throw some errors as it tries to connect to them:
https://gist.githubusercontent.com/devicenull/13533879ee0f646770e9b603f99096f8/raw/3df13b71997e3f35dab2717a670039b45659e5f2/gistfile1.txt
This is part of the mirror list I get:
https://gist.githubusercontent.com/devicenull/1f84d71d8482848313e72decf0dbad26/raw/e6d62c14b98e1b25fe48e70d9bf79395fd82447d/gistfile1.txt
mirror.cogentco.com and mirror.grid.uchicago.edu do not actually have IPv6 connectivity.
If I clear my local timedhosts.txt, it somewhat works around this issue, as it detects the hosts aren't actually available:
So I'm not sure if a proper mitigation here would be clientside or serverside.
The text was updated successfully, but these errors were encountered: