mirrormanager2 icon indicating copy to clipboard operation
mirrormanager2 copied to clipboard

metalink vs website differences

Open fenris02 opened this issue 9 years ago • 9 comments

$ curl -sk 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f20&arch=x86_64' |grep -c http 7

One of these results is a header line. That means https://admin.fedoraproject.org/mirrormanager/mirrors/Fedora/20/x86_64 should show 6 entries.

Instead, it shows 151 active mirrors. Selecting one randomly, http://mirror.pnl.gov/fedora/linux/updates/20/ shows that this mirror does not contain f20 updates.

These two lists should have the same content.

Other, active mirrors, like http://mirror.cc.vt.edu/pub/fedora-archive/fedora/linux/updates/20/x86_64/ do not show up at all.

fenris02 avatar Oct 12 '15 18:10 fenris02

I wonder if this wouldn't actually be related to the bug fixed in https://github.com/fedora-infra/mirrormanager2/pull/138

pypingou avatar Oct 13 '15 07:10 pypingou

Might be. The website url above currently reports " We have currently 149 active mirrors "

The curl command used by package management, reports 6 active mirrors.

What is the website url mentioned in #138 to compare with ?

fenris02 avatar Oct 14 '15 03:10 fenris02

For better readability I am not using the metalink, but the mirrorlist mode:

https://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f20&arch=x86_64&country=global

also with the additional &country=global to get all mirrors worldwide.

The results from https://admin.fedoraproject.org/mirrormanager/mirrors seems more or less correct for F19 but totally wrong for F20.

Looking directly at the database all architectures for F20 list the correct number of hosts (between 10 and 20) except for x86_64. So somehow the architecture selection in the web interface does not work correctly and the database has the wrong information for x86_64. I am continuing to investigate where this error comes from.

adrianreber avatar Oct 14 '15 11:10 adrianreber

I tried the fix from #138 in staging and did not help. Maybe we need to run umdl once more with the delete option. I will try it in staging to see if it helps.

adrianreber avatar Oct 16 '15 12:10 adrianreber

Running umdl with --delete-directories on the category "Fedora Linux" did not help. Still a lot of mirrors reported for Fedora 20.

adrianreber avatar Oct 17 '15 09:10 adrianreber

Seems still not fixed for EPEL 7 and 8.

I'm a user in China. curl -sk 'https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=x86_64' I can get 37 results from CN, JP, TW, TH etc. curl -sk 'https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64' I can only get 7 results, and no CN mirrors. same for epel-8.

https://admin.fedoraproject.org/mirrormanager/mirrors/EPEL/7/x86_64 said there are hundreds of mirrors active, including mirrors in CN.

aflyhorse avatar Sep 18 '20 06:09 aflyhorse

Yes, this is known and will probably not be fixed any time soon. The only important information is the metalink for end-users.

The problem is that the metalink knows exactly which file you want and can give you the mirror which has that file, the website only knows that a mirror exists and that it was configured to serve the content. The code displaying the website is just much simpler.

adrianreber avatar Sep 18 '20 06:09 adrianreber

I see. By comparing the modification date of epel/7/x86_64/repodata/, I found that all of the CN mirrors are only dated 9/16 while a JP mirror stated 9/18. Maybe they share a same upstream. I'll inform the maintainers. And thanks for your explanation. Keep the good job!

aflyhorse avatar Sep 18 '20 06:09 aflyhorse

Thanks a lot for informing the out of date mirrors.

adrianreber avatar Sep 18 '20 06:09 adrianreber