|
Quoting dbart:
"The current way yum.mariadb.org is set up is not good. The two yum
servers' primary function is with buildbot.askmonty.org and hosting the
yum repos is just a secondary thing. Also, the decision to use them was
made back when there were four such servers available, instead of just
the two that are available now, which helped, but it has still never
been an ideal setup.
We can definitely use the mirrors for hosting the yum repositories.
It's just a matter of putting the correct logic into the repository
configuration tool https://downloads.mariadb.org/mariadb/repositories
so that it spits out the correct configuration information. The mirrors
all already have the yum repositories on them, they're just not exposed
in the configuration tool for people to use.
Even better than just outputting a baseurl line with a single mirror on
it would be if we did something like what Fedora does where yum/dnf
automatically chooses from a list of mirrors to find the best one to
use.
I just fired up my Fedora 31 VM to take a look and in the fedora
repository configuration files there is a baseurl line, like we give
people through our configurator, but it is commented out, so it is just
there as a backup, and then the next line is a metalink line that
points to a page on mirrors.fedoraproject.org that spits out an xml
formated 'metalink' file appropriate for the version of Fedora and
CPU arch that you're using. yum/dnf then uses this xml file to pick the
actual mirror to use.
Here's an example line:
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-31&arch=x86_64
The actual line in the repo config on my Fedora-31 VM replaces the '31'
with '$releasever' and the 'x86_64' with '$basearch', but you get the
idea. I don't know how they set it all up in the backend, but the
metalink xml file does include checksums of the current repomd.xml file
so that yum/dnf can verify the repository on the mirror you are
accessing is correct and up-to-date. The xml file also mentions a tool
called MirrorManager and includes an old inactive URL, but I found this
page on the Fedora wiki:
https://fedoraproject.org/wiki/Infrastructure/MirrorManager
That page talks about the metalink file and also about an alternative
mirrorlist txt file that is much simpler and doesn't offer the same
level of validation (packages in each repo are still validated but you
don't know if your mirror has the latest version of the repository or
not). Here's an example line:
mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-31&arch=x86_64
If we had a script on downloads.mariadb.org that output either the
fancy metalink xml file or the much simpler mirrorlist txt file
directly from our database of mirrors, with some geoip logic (Fedora
looks like they're at least detecting the country you're coming from)
that sorts the mirrors for the user based on where they are coming from,
that would probably work the best, it's just a matter of coding it such
that something similar to the following url outputs the correct
information:
https://downloads.mariadb.org/mirrorlist?ver=10.4&repo=fedora-31&arch=x86_64
The url lines for a mirrorlist from us would look similar to this (but
with obviously more than three entries):
https://mirror.marwan.ma/mariadb/yum/10.4/fedora/31/x86_64/
http://mirror.rise.ph/mariadb/yum/10.4/fedora/31/x86_64/
http://mariadb.mirror.nucleus.be/yum/10.4/fedora/31/x86_64/
The pattern for a script to use when generating these lines is:
{mirror_url}yum/{mariadb_ver}/{distro}/{distro_ver}/{arch}
|
There's no slash '/' between
{mirror_url}
and 'yum' because all mirror urls in our mirror database end with a slash.
So, anyway, my vote would be to set up a script on
downloads.mariadb.org to generate a mirrorlist on the fly as described
above and then to update the repo configuration tool to output a
'mirrorlist=...' configuration line as part of the config with some
reliable mirror as a commented out 'baseurl=...' line, just like Fedora
does (we could even continue to use yum.mariadb.org for this). Once a
mirrorlist script is in place, I can make the necessary updates to the
repository configuration tool.
Later on we could add support for the fancier metalink xml files if
we want, but doing the mirrorlist would definitely be worlds better than
what we have now."
|