I'm Pascal Panneels, System engineer working for Belnet, the Belgian
National Research and Education Network.
We want to become a mirror for fedora;
Here are the details of our server/capability :
Location: Brussels, Belgium
Available Bandwidth : 10 Gbps
We have 2 servers :
- IP of the mirroring one: 184.108.40.206
- IP of the service one : 220.127.116.11
Protocols available: ftp, http, https, rsync
Thanks for considering the request,
with kind regards,
Belnet - Services
Simon Bolivarlaan 30 Boulevard Simon Bolivar
Brussel 1000 Bruxelles
België - Belgique
T: +32 2 790 33 33
is Fedora 29 still needed on the mirrors, according to policy? Or could
that be moved to archive sometime soon? We're on Fedora 31 currently, so
even if you intend to keep one old version keeping 30 around would be
Blindeisenweg 43, 41468 Neuss
Tel.: 02131 88591-0, Fax: 02131 88591-10
Eingetragen unter HRB 13256 beim Amtsgericht Neuss
Geschäftsführer: Michael Metz-Martini, Stefan Neufeind
We're adding some more storage to our mirrors - how big is buffet?
Disclaimer: This message contains information which may be confidential and
privileged. Unless you are the intended recipient you may not use, copy,
disseminate or disclose to anyone the message or any information contained
in the message. Thank you.
my name is Sebastian Bobriuc - i represent a hosting company in Romania
and i would like to list a new public mirror for EPEL .
It's our way of giving back something to the community.
IPv4 : 18.104.22.168
IPv6 : 2a00:ece1::19
Country : Romania
Bandwidth : 1Gbps
Mirroring only Epel for x86_64 .
The site and host for this was added in the Fedora Mirror Manager.
The requirements for becoming a tier 1 mirror are listed on
and I think most of them make sense. At the same time there are not many
new tier 1 mirror requests. I also think the current number of tier 1
mirrors is adequate (this is is not a request for more tier 1 mirrors).
We still do not get many requests for new tier 1 mirrors but if we get
one it often feels like we are discussing too much about it, which is
probably related to the fact that the listed requirements are not what
we actually expect of a tier 1 mirror to provide.
That's why I would like to change the requirements of a tier 1 mirror.
The biggest change I would like to make is to require mirroring of
fedora-buffet. As I am mirroring fedora-buffet on my mirror I know that
this requires a lot of space (3.8TB). The reason to require mirroring
fedora-buffet for a new tier 1 mirror is so that quick-fedora-mirror
works for tier 2 mirrors.
The new tier 1 mirror requirement list would look like this:
* Must carry everything under fedora-buffet. This allows tier 2 mirrors
to use quick-fedora-mirror for quicker and more effective mirroring.
* Should use quick-fedora-mirror to access the master.
* Must have a 1 Gigabit connection to the Internet, or faster.
* Must have an active, available, responsive mirror administrator
during the days content is staged.
* Must serve private rsync (see below for configuration).
I would drop the following requirements:
* Must have at least 2 Internet2-connected Tier 1 mirrors.
(This seems less important today)
* Must have at least 1 Tier 1 mirror on each continent for which we
have Tier 2 mirrors.
(This is a strange requirement)
* Limit the number of Tier 1 mirrors, to ensure adequate bandwidth for
(With the requirement to mirror fedora-buffet with its 3.8TB the
number of tier 1 mirrors will be limited anyway)
Tier 1 mirrors means being on the ACL to access the tier 1 only rsync
There are no plans to remove existing tier 1 mirrors or anyone from the
rsync ACL, but for new tier 1 requests I would like to use the above
My main goal is to make sure that tier 2 mirrors can use
quick-fedora-mirror when syncing from (new) tier 1 mirrors and by
explicitly mentioning the requirements in the guidelines as we already
kind of expect that from new tier 1 mirrors.
Any comments or objections?
Fedora 32 has been staged and should now be available at
it is 495G in pub/fedora, 23G in pub/alt, 214G in pub/fedora-secondary
and the rpms are hardlinked to
Our release is Tuesday the 28th of April 2020, at 14:00 UTC.
Fedora Release Engineering
So I know this doesn't affect a lot of mirrors, but we have added snapshots
of various EPEL releases to /pub/archive/epel. The current format will be
/pub/archive/epel/<major_release>.<year_month_date_of_snapshot>/ and will
be a hardlink copy of the data that is in /pub/epel/<major_release>. This
will be done at 'regular' intervals in the future so that people who need
to stick to an old version of epel packages can have a 'reliable' copy of
the archives at that time.
Currently we have:
lrwxrwxrwx. 1 root root 12 Apr 21 11:18 7 -> 7.2020-04-20
drwxr-xr-x. 7 ftpsync ftpsync 4096 May 29 2019 7.2019-05-29
drwxr-xr-x. 7 ftpsync ftpsync 4096 Apr 21 11:51 7.2020-04-20
lrwxrwxrwx. 1 root root 15 Apr 22 15:31 8 -> 8.1.2020-04-22/
drwxr-xr-x. 4 root root 4096 Apr 22 15:31 8.1.2020-04-22
Stephen J Smoogen.
We would like to register as a public mirror of Fedora Archive, Fedora
Secondary Architectures and EPEL.
Fedora Archive: mirrors.bfsu.edu.cn/fedora
Secondary Arch: mirrors.bfsu.edu.cn/fedora-altarch
HTTP, HTTPS and RSYNC are supported.
Sync schedule: Every 4 hrs
Location: Beijing, China
Sponsor: Beijing Foreign Studies University
Sponsor URL: http://global.bfsu.edu.cn
IPv4 address to authorize: 22.214.171.124
IPv6 address to authorize: 2001:da8:20f:4435:4adf:37ff:fe55:2840
Email contact: aron(a)bfsu.edu.cn
The Fedora main Infrastructure will be moving to a new datacenter in late
May/early June. During this time we will have only 3 download servers on
possibly overloaded virtual servers.
I would like to restrict rsync down to only tier 1 mirrors during this
time. We normally allow others to get in and have a tier-1 mirror set on
dl04.fedoraproject.org and download05.fedoraproject.org. I believe to help
deal with allowing tier-1 mirrors priority access that we just restrict the
new mirrors to tier-1 until we have a better idea of how to work in the new
datacentre and can guarantee better access.
I do not have the ip address numbers for the new space yet, but I will
publish them and their names as soon as I do.
Stephen J Smoogen.