Fedora 40 mirrors : errors leading from Western Europe to mirrors based in UA & RU?

Hi to the Fedora community,

Following my update from Fedora 39 to Fedora 40 (I made a post about that a few days ago), I have noticed that Fedora has been reaching out to mirrors based further and further, until reaching out to Ukraine or Russia.

Being based in France, I understand that my OS should be accessing mirrors based in Western Europe, and that it may also depend on the VPN connection (I can use eg. FR, BE or NL).

Two days ago, I noticed though that Fedora update reached out to Poland and Ukraine, which was already unexpected. But today, it went as far as to two mirrors based in Russia, ie. Novotelecom(dot)ru and Sibirskie Seti Ltd - sdd3(dot)ru.

Looking at the network activity, it appears there were a number of errors with the http initial query to the mirrors, which seems to have led from BE to NL, then DE, CH, SE and later PL, UA and finally RU.

Here is for instance the error message received for the Belgian mirror Cu.be which should be working - and actually some activity took place with that mirror anyway.

GET /linux/updates/40/Everything/x86_64/repodata/8ecd4684ef1ee28b2bc4a6efa07f91a17589c41cd7974b1572f78e6d0992aa69-updateinfo.xml.zck HTTP/1.1
Host: fedora.cu.be
Range: bytes=0-6170
User-Agent: libdnf (Fedora Linux 40; workstation; Linux.x86_64)
Accept: */*

HTTP/1.1 301 Moved Permanently
Server: nginx/1.26.0
Date: Thu, 16 May 2024 11:20:05 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive
Location: https://fedora.cu.be/linux/updates/40/Everything/x86_64/repodata/8ecd4684ef1ee28b2bc4a6efa07f91a17589c41cd7974b1572f78e6d0992aa69-updateinfo.xml.zck
Permissions-Policy: interest-cohort=()

<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.26.0</center>
</body>
</html>

Similar or other types of error messages impacted other http queries, eg for Nluug.nl as well as several Western/Central European mirrors.

Oddly enough, the communication with that very remote RU mirror seems eventually mingled with communications to a French mirror.

Except from the fact that it is certainly not very efficient to reach out to a mirror based several thousands kilometers away, I am not comfortable to see Fedora update contacting servers based in a war zone. Cybersecurity/defense pros reading this forum could probably confirm that such kind of network activity may have consequences.

Has anyone else experienced such issues with Fedora 40 mirrors ? How can you avoid to be brought into that again ?

Many thanks.

Keep in mind that DNF should verify downloads with checksums and GPG signatures, so all of this is likely irrelevant.

Anyway, you can limit the metalink result to specific countries:

COUNTRY="BE,CH,DE,FR,NL,SE"
URL="$(grep -o -m 1 -e "^metalink=.*basearch" /etc/yum.repos.d/fedora.repo)"
sudo dnf config-manager --save --setopt "fedora.${URL}&country=${COUNTRY}"
URL="$(grep -o -m 1 -e "^metalink=.*basearch" /etc/yum.repos.d/fedora-updates.repo)"
sudo dnf config-manager --save --setopt "updates.${URL}&country=${COUNTRY}"

HTTP 301 is not an error, but a redirection status code.
Download managers normally follow redirects.

2 Likes

Hi, and thanks a lot for your message, much appreciated.

Many thanks also for the config file, I am going to add this today.

About the issue, I pasted in my post the first report which is a redirection indeed, and it was actually followed by more than 15 occurrences of “404 Not Found” for subsequent mirrors.

Could you please advise or explain what may have happened ?

Best regards

The metalink server returns the hash for the latest metadata, but mirrors asynchronously download metadata and packages from the main server, and some of them might not have finished synchronizing yet, specifically for fresh updates released just recently.

Thanks for the additional message - I marked the config change as solution to avoid that issue in the future.

More generally, and opening the question to anyone of course, still wondering please if there are other users who experienced that issue as well : actually 25 mirrors in total returned a “404 not found” http message, so it may have been noticed elsewhere. And if that event happened precisely at the time of a synchronization of several servers, that would be good to know, especially with regards to my previous post on Fedora 40 download.

Many thanks.

Timing with updates is often the cause of this issue. The metadata is loaded by dnf first and the included files follow as time, bandwidth, and repo mirror server configs permit.

Usually when such errors are seen just wait a short while (maybe an hour or two) then repeat the update and the errors are usually no longer there.

You must have been doing an update just after the files were released.

Hi, many thanks for your inputs.

Reading the below quote about the topic, I would like to re-clarify though what the actual issue is please:

Indeed, I know that open source mirrors can be unavailable sometimes because of file synchronization or other causes - and that’s of course fine. It happened to me several times in the past and that wasn’t an issue at all for me.

What was the actual issue however is the fact that after a redirection from a Belgian mirror - which used to work fine - a cascade of 25 errors with other European mirrors took that Fedora update all the way to Ukraine and even a few thousand kilometers away to Russia, which was not only unexpected but can be also very problematic for the impacted users whose internet connections are taken to a place connected with a war zone.

The inputs given above - what I marked as solution - help users to restrict Fedora reaching for updates only to a list of mirrors defined by the user.

The current incident still has two matters about which I would like to get support and information please :

1°) Choice and information of users / management of mirrors during Fedora updates: this incident brought to my knowledge - because I thought it was prudent to pay some extra attention to network activity after this potential ransomware alert during my Fedora 40 upgrade from Fedora 39 - that during an update (ie. dnf update), if a mirror fails or is unresponsive for whatever reason (eg. synchronization), Fedora reaches out to another mirror, and then another etc. which can lead that update very far.

It is therefore not the case that if the user tries to update and the mirror is not working at that moment, that the user just has to try again a bit later because 1°) you don’t get information that your mirror fails and 2°) Fedora automatically reaches out to further mirrors.

I checked the man pages for dnf and dnf.confbut there is not much information as to mirrors choice or management during updates.

Could anyone please explain what is the way mirrors are reached / selected / managed during Fedora updates ? That could be maybe something to add in a man page, with the solution to restrict mirrors’ list (not only with a URL but also with a country list) at users’ choice.

The bottom line of this matter could be seen as a user story such as:

" As a Fedora user, I would need to know how Fedora updates (dnf, yum, etc) handles access to mirrors / remote mirrors so that I may know what network connections should happen and are legitimate ones".

2°) About the two mirrors in .ru that have been reached by Fedora update - not in the Fedora mirror list ?

As mentioned in my initial post, Fedora update reached out to these two domains in .ru:

  • Novotelecom(dot)ru
  • Sibirskie Seti Ltd - sdd3(dot)ru

I am even more puzzled about these domains that they don’t seem to appear on Fedora 40 mirror list .

Please find here attached screenshots showing the three official mirrors based in Russia, and two screenshots from the Fedora update showing that it interacted with two .ru domains (not in the official mirror list), the communications with the first one being mingled with a French mirror.

Inputs from Fedora experts to hopefully clarify and close down on these questions would be greatly appreciated.

Many thanks.