[mirror-admin] Blocking ips on dl.fedoraproject.org (Or Please update your mirrors in mirror-manager)

[Stephen John Smoogen]

On 28 March 2016 at 12:38, Carlos <carlos at inf.ufpr.br> wrote:
> Stephen John Smoogen (smooge at gmail.com) wrote on Fri, Mar 25, 2016 at 04:01:26PM BRT:
>> uk-noc.com.
>> wideopenwest.com.
>> alshamil.net.ae.
>> ip-connect.net.ua.
>> math.uh.edu.
>> main.ad.rit.edu.
>> mirror.yandex.net.
>> pdx.edu.
>> unicamp.br.
>> sl-reverse.com.
>> univ-ubs.fr.
>> isp.ip.pt.
>> c3sl.ufpr.br.
>>
>> None of these mirrors are registered in mirrormanager exactly as the
>> ip address which is coming.
>
> I don't know how you get these domains but ours is wrong. We are
> fedora.c3sl.ufpr.br, not c3sl.ufpr.br, and our IPs are correctly listed in
> mirrormanager.
>

The server we are seeing is

download05/rsyncd-fedora.log:2016/03/28 17:20:05 [34236] connect from
sagres.c3sl.ufpr.br (200.236.31.1)
download05/rsyncd-fedora.log:2016/03/28 17:20:05 [34236] rsync on
fedora-enchilada0/fullfilelist from sagres.c3sl.ufpr.br (200.236.31.1)

Not

[smooge at smooge-laptop00 Rsync-Stats]$ host fedora.c3sl.ufpr.br
fedora.c3sl.ufpr.br has address 200.236.31.8
fedora.c3sl.ufpr.br has IPv6 address 2801:82:80ff:8000::9

At this point the following IPs are blocked:

DROP       all  --  8.39.100.100         0.0.0.0/0
DROP       all  --  46.29.92.6           0.0.0.0/0
DROP       all  --  69.47.68.211         0.0.0.0/0
DROP       all  --  83.110.159.237       0.0.0.0/0
DROP       all  --  103.193.116.147      0.0.0.0/0
DROP       all  --  130.193.57.106       0.0.0.0/0
DROP       all  --  130.193.60.205       0.0.0.0/0
DROP       all  --  158.39.4.2           0.0.0.0/0
DROP       all  --  169.53.165.245       0.0.0.0/0
DROP       all  --  193.52.32.69         0.0.0.0/0
DROP       all  --  195.23.131.253       0.0.0.0/0
DROP       all  --  198.11.167.9         0.0.0.0/0
DROP       all  --  202.202.43.41        0.0.0.0/0


>> If that doesn't work we will be putting firewall rules that only Tier 0 and
>> Tier 1 mirrors are allowed to connect to the download servers.
>
> Great. This is how it should be. I'm tired of getting "max connections"
> rejections...
>

Me too.

>> Using the last-sync to schedule updates when they actually occur can
>> help lower rsync usage.
>
> Certainly. Here's the log from one of these runs:
>
> Usando dl.fedoraproject.org=209.132.181.24
> RSYNC_PROTOCOL=30
> TEMPO inicializacao: 4s
> Mon Mar 28 07:20:05 BRT 2016
>
> TEMPO timestamp upstream: 2s
> Mon Mar 28 07:20:07 BRT 2016
>
> upstream_timestamp: Mon Mar 28 07:29:40 UTC 2016
> local_timestamp:    Mon Mar 28 07:29:40 UTC 2016
>
> TEMPO verificacao de timestamp: 0s
> Mon Mar 28 07:20:07 BRT 2016
>
> Timestamp upstream nao e' mais recente
> Abortando
>
> The last sentences mean "Timestamp upstream is not more recent [then local
> one]. Aborting"
>

What was the command you are using to generate that one? The reason is
I am trying to see if it generates a large load on the backend NFS and
if there is a better way for us to get that information to you.

> You can see that it takes only a few seconds. All mirrors should check the
> timestamp.
>
> --



-- 
Stephen J Smoogen.

--