mirrormanager2
mirrormanager2 copied to clipboard
fedora-infra
Mirrormanager provides IPv4 only mirrors to clients that connect via IPv6
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:
# cat /var/cache/yum/x86_64/7/timedhosts.txt | grep cogent
mirror.cogentco.com 99999999999
So I'm not sure if a proper mitigation here would be clientside or serverside.
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 @adrianreber : can you confirm/deny ?
is that still true ? that would be a blocker for CentOS Stream 9 on mirrormanager instance hosted by Fedora Infra @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.
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 https://github.com/fedora-infra/mirrormanager2/issues/247#issuecomment-905563787, 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.
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.