- Arch-mirrors - lists.archlinux.org

[arch-mirrors] kitchensink_auth failed for mirrors.kernel.org
by Konstantin Ryabitsev 08 Jul '20

08 Jul '20

Hello: It seems that we're unable to rsync from the following location any more: rsync://kernelorg@rsync.archlinux.org/kitchensink_auth The error we get back is: @ERROR: auth failed on module kitchensink_auth If this is no longer the proper way to authenticate, then please let me know so we can fix our mirror. Best regards, -K

2 1

[arch-mirrors] Huge traffic from China
by Johannes Findeisen 02 Jul '20

02 Jul '20

Hello, I am driving the mirror arch.unixpeople.org. Since some months I encounter a lot of traffic from China which seems to be like a DDoS. I fixed this some month ago by blocking all IP address ranges from China. This stopped the traffic. Yesterday I tried to remove all my firewall rules and to see what happens... Just some hours ago the DDoS startet again so I really had to block China from my mirror again because it would become a fulltime job to monitor my host. While all this happened I tried to figure out what's going on and saw endless downloads of the arch .iso file from many many IP addresses in China. When the download from one IP had finished the download directly started again from exactly the same IP in an endless loop. Does anyone other here encounter such things? Regards Johannes

5 8

Re: [arch-mirrors] Huge traffic from China (services)
by Ave 02 Jul '20

02 Jul '20

We're having this too. ave@owobox:/home/ave $ sudo grep iso /var/log/nginx/access.log | awk '{ print $1 }' | sort -n | uniq -c | sort -nr | grep 27.221.66 29 27.221.66.139 27 27.221.66.136 26 27.221.66.137 26 27.221.66.133 25 27.221.66.134 24 27.221.66.144 23 27.221.66.148 21 27.221.66.143 21 27.221.66.138 21 27.221.66.132 20 27.221.66.141 18 27.221.66.147 17 27.221.66.153 16 27.221.66.151 16 27.221.66.146 16 27.221.66.142 16 27.221.66.131 15 27.221.66.149 13 27.221.66.154 13 27.221.66.152 They all seem to be trying to fetch "/iso/2020.02.01/archlinux-2020.02.01-x86_64.iso" and "/iso/2020.03.01/archlinux-2020.03.01-x86_64.iso", which are 404 on our end. UA for all is "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3". I personally blocked the /24 (sudo ufw insert 1 deny from 27.221.66.0/24 to any). The behavior seems like it's not in good faith (the requests have 30s-4m between them), and while I don't think much will happen, but I'll be filing an IP abuse notice to china unicom about this (hqs-ipabuse(a)chinaunicom.cn) On 7/2/20 3:00 PM, arch-mirrors-request(a)archlinux.org wrote: > Send arch-mirrors mailing list submissions to > arch-mirrors(a)archlinux.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.archlinux.org/listinfo/arch-mirrors > or, via email, send a message with subject or body 'help' to > arch-mirrors-request(a)archlinux.org > > You can reach the person managing the list at > arch-mirrors-owner(a)archlinux.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of arch-mirrors digest..." > > > Today's Topics: > > 1. Re: Huge traffic from China (services) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 2 Jul 2020 09:06:05 +0200 > From: services <services+mirrors(a)eric.ovh> > To: arch-mirrors(a)archlinux.org > Subject: Re: [arch-mirrors] Huge traffic from China > Message-ID: <7066fda6-b2f2-b1b9-90fd-ef257920ee72(a)eric.ovh> > Content-Type: text/plain; charset=utf-8; format=flowed > > Ip is on same range for me > > and found 4 new ip yesterday on another range (scan 22H CEST) : > 119.176.61.18 > 119.176.61.22 > 119.176.61.16 > 119.176.61.12 > > > On 7/2/2020 8:25 AM, Siyuan Miao wrote: >> We also received lots requests from 27.221.66.0/24 >> <http://27.221.66.0/24>. >> >> aveline@mirror-iad01-a:~# sudo grep iso >> /var/log/nginx/mirrors.access.log | awk '{ print $1 }' | sort -n | >> uniq -c | sort -nr >> ? ? 178 27.221.66.133 >> ? ? 176 27.221.66.144 >> ? ? 163 27.221.66.143 >> ? ? 163 27.221.66.132 >> ? ? 158 27.221.66.138 >> ? ? 155 27.221.66.141 >> ? ? 153 27.221.66.131 >> ? ? 150 27.221.66.149 >> ? ? 144 27.221.66.147 >> ? ? 137 27.221.66.142 >> ? ? 136 27.221.66.136 >> ? ? 136 27.221.49.135 >> ? ? 133 27.221.66.154 >> ? ? 133 27.221.66.134 >> ? ? 131 27.221.66.151 >> ? ? 131 27.221.66.146 >> ? ? 130 27.221.66.137 >> ? ? 124 27.221.66.139 >> ? ? 120 27.221.66.153 >> ? ? 102 27.221.66.148 >> ? ? ?93 27.221.66.152 >> >> On Thu, Jul 2, 2020 at 2:14 PM mirror-admin <mirror-admin(a)labkom.id >> <mailto:mirror-admin@labkom.id>> wrote: >> >> Hi, >> >> we got request from fraction of subnet 27.221.66.0/24 >> <http://27.221.66.0/24> >> >> thx >> >> On 7/2/2020 12:52, services via arch-mirrors wrote: >> >> > Hello, >> > >> > Same case here. >> > >> > Impact is low here (via one ip only), because a file which don't >> exist >> > (old iso) : >> > arch//iso/2020.03.01/archlinux-2020.03.01-x86_64.iso" failed (2: No >> > such file or directory) >> > >> > Can you share ip on the list for compare and block all ip before >> ddos ? >> > >> > Regards, >> > Eric. >> > >> > On 7/2/2020 5:02 AM, mirror-admin wrote: >> >> Hello, >> >> >> >> Yes, we notice same download pattern from china IP. Not only for >> >> Archlinux, but for other archive as well. >> >> >> >> What we do is try to be nice, we throttling down our upload >> speed to >> >> their IP. >> >> >> >> Thx >> >> >> >> On 7/2/2020 09:49, Johannes Findeisen wrote: >> >>> Hello, >> >>> >> >>> I am driving the mirror arch.unixpeople.org >> <http://arch.unixpeople.org>. Since some months I >> >>> encounter a lot of traffic from China which seems to be like a >> DDoS. I >> >>> fixed this some month ago by blocking all IP address ranges >> from China. >> >>> This stopped the traffic. Yesterday I tried to remove all my >> firewall >> >>> rules and to see what happens... Just some hours ago the DDoS >> startet >> >>> again so I really had to block China from my mirror again >> because it >> >>> would become a fulltime job to monitor my host. >> >>> >> >>> While all this happened I tried to figure out what's going on >> and saw >> >>> endless downloads of the arch .iso file from many many IP >> addresses in >> >>> China. When the download from one IP had finished the download >> directly >> >>> started again from exactly the same IP in an endless loop. >> >>> >> >>> Does anyone other here encounter such things? >> >>> >> >>> Regards >> >>> >> >>> Johannes >> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > arch-mirrors mailing list > arch-mirrors(a)archlinux.org > https://lists.archlinux.org/listinfo/arch-mirrors > > > ------------------------------ > > End of arch-mirrors Digest, Vol 98, Issue 2 > ******************************************* -- -Ave https://ave.zone

3 2

[arch-mirrors] Possibility of adding debug repositories
by Eli Schwartz 12 Jun '20

12 Jun '20

If Arch Linux were to add repositories containing split debug packages for all our x86_64 packages, this would obviously add a fair amount of space to the mirror requirements. It could possibly double or triple the size taken by non-data packages. I don't have real-world numbers for how much space it would take up, but I do have some comparisons. For my custom repo as a sample, which I do upload debug packages for, I am using 2.9Gi of space, and 1.7Gi comes from debug packages. On the other side of things, our biggest 2 official packages are cuda, 4137.96 MiB of proprietary blobs that aren't currently stripped and therefore even if we did split it into a debug package it wouldn't increase space usage at all, and kicad-library-3d, 5171.97 MiB of pure data in /usr/share, which is not eligible for debug packages anyway. A naive list of packages which would probably generate debug packages: $ expac -H M '%m %n %a' | grep -v 'any$' | sort --human-numeric-sort [...] 1109.50 MiB emscripten x86_64 1136.27 MiB python-tensorflow x86_64 1145.23 MiB python-tensorflow-opt x86_64 1286.69 MiB python-pytorch-cuda x86_64 1289.44 MiB python-pytorch-opt-cuda x86_64 1518.42 MiB ghc-static x86_64 2589.23 MiB python-tensorflow-cuda x86_64 2597.38 MiB python-tensorflow-opt-cuda x86_64 3757.68 MiB tensorflow-cuda x86_64 3765.75 MiB tensorflow-opt-cuda x86_64 4137.96 MiB cuda x86_64 (Basically all of the really big stuff is tensorflow/cuda/machine learning bits. We could selectively disable debug packages for two PKGBUILDs and avoid all the worst offenders, if we needed to. heh.) Packages which definitely would not (there's some big, high-profile packages here, and my custom repo doesn't reflect this sort of spread at all): $ expac -H M '%m %n %a' | grep -v 'any$' | sort --human-numeric-sort [...] 1202.02 MiB texlive-fontsextra any 1307.98 MiB texlive-fontsextra any 2006.67 MiB 0ad-data any 3112.39 MiB nltk-data any 5171.97 MiB kicad-library-3d any ... Anyway, providing these symbols would be generally desirable for users, and ideally it would work opt-out to make it easier for users to get access to them. It's something we've generally wanted to do, see for example https://bugs.archlinux.org/task/38755 And it's possible we may actually, at long last, get around to implementing this. So, question to mirror admins: if Arch was to add debug repositories, would you be okay syncing them? And should it be opt-in or opt out? The answers to these questions will influence the direction I will take in trying to devise a satisfactory resolution to this outstanding infrastructure request. So I would love to get some input from the people who would be affected by such a change. -- Eli Schwartz Bug Wrangler and Trusted User

7 8

[arch-mirrors] Decommissioning repo.sadjad.ac.ir
by pejman yaghmaie 08 May '20

08 May '20

Dear Arch Linux staff and community, It is unfortunate that I have to bring to you that Sadjad University has decided to cut the resources of it's Linux repository due to problems and shortcomings. Therefore I have to request that the mirror be removed from the list. The mirror will remain operating till 2020-05-08 before it stops syncing. Sincerely, Pejman Yaghmaie

1 0

[arch-mirrors] cyberbits is out of sync
by Sébastien Luttringer 18 Mar '20

18 Mar '20

Hello, I noticed cyberbits mirror last sync is March 14th. Last packages I pushed was not updated. Its score is still very good and no error messages are displayed in our interface. I didn't find the process to notify them on the wiki. Hints are welcomes. [1] https://www.archlinux.org/mirrors/cyberbits.eu/ [2] https://wiki.archlinux.org/index.php/Mirrors#Troubleshooting Sébastien "Seblu" Luttringer

2 2

[arch-mirrors] CDN based/caching mirror?
by Kristian Klausen 04 Mar '20

04 Mar '20

Hi I'm considering setting up a Arch Linux mirror and I'm considering a different design. So instead of mirroring the whole thing, the idea is to mirror only the database files (core.db etc) and download the packages on demand from a Tier 1 mirror (and let nginx cache them). By doing it that way, I only download requested packages from the Tier 1 mirrors, instead of downloading the whole thing (saving Tier 1 bandwidth). To provide even better performance a CDN (ex: Cloudflare) could be used to provide more caching. So we end up with a setup like this: Cloudflare -> Nginx cache -> Tier1 mirrors (nginx with multiple upstream) Do I miss something? Is this a bad idea? If I do setup a mirror like that, is there any chance it could be added as a official mirror? Best regards Kristian Klausen

8 12

[arch-mirrors] Changes to archmirror.lavatech.top
by Ave 13 Feb '20

13 Feb '20

Hello, I'm the sysadmin of archmirror.lavatech.top. I moved archmirror.lavatech.top's rsync source to mirror.pseudoform.org as f4st.host seems to be having issues (it didn't get updates in ~9 days) and is giving 502 on the main page. -Ave Ozkal

2 4

Re: [arch-mirrors] [sysadmin] CDN based/caching mirror?
by Kristian Klausen 03 Feb '20

03 Feb '20

On 30.01.2020 17.04, Konstantin Ryabitsev wrote: > On Sun, 26 Jan 2020 at 11:19, Kristian Klausen via arch-mirrors > <arch-mirrors(a)archlinux.org> wrote: >> I'm considering setting up a Arch Linux mirror and I'm considering a >> different design. >> >> So instead of mirroring the whole thing, the idea is to mirror only the >> database files (core.db etc) and download the packages on demand from a >> Tier 1 mirror (and let nginx cache them). By doing it that way, I only >> download requested packages from the Tier 1 mirrors, instead of >> downloading the whole thing (saving Tier 1 bandwidth). >> >> To provide even better performance a CDN (ex: Cloudflare) could be used >> to provide more caching. So we end up with a setup like this: >> Cloudflare -> Nginx cache -> Tier1 mirrors (nginx with multiple upstream) >> >> Do I miss something? Is this a bad idea? > If you are trying to save Tier1 some bandwidth, you'll probably > actually end up causing them more problems due to increased random > seek waits. Tier1 mirrors may not necessarily have fast storage -- for > example, all kernel.org mirror nodes have terabytes of spinning rust > and about half-a-TB of ssd used via lvm-cache. It works great for > Tier1 setups because most Tier2 mirrors want the same set of recent > updates that are served out of ssd cache. If a new mirror comes along > and wants to slurp and entire distro, that is fine too, because even > if there's higher iowait latency, the Tier2 mirror isn't working > against any HTTP timeouts or impatient clients and doesn't care if the > data arrives at a slower rate due to higher iowait. Tier1 can also > tell Tier2 mirror "I'm overloaded right now, please try again later" > and it'll be fine as most Tier2 mirrors can wait an hour or two before > receiving updates. > > Making Tier1 mirrors a "cold cache" for your setup will likely cause > more disk thrash for them, but will also result in poorer service for > people using your mirror due to the reasons I listed above. Tier 1 mirrors is also used directly by end-users (correct me if I'm wrong) So worst-case (cache miss) my SSD-backed shared cache won't be noticeable slower than pulling directly from the Tier 1 mirror. Best-case (cache hit) I'm saving the Tier 1 mirror some bandwidth and disk usage. My idea is basically tiered caching (CDN -> Nginx SSD-backed shared cache -> Tier 1 mirror(s)), is that worse than status quo? :) > If someone > tries to install a package and watches their download bar sit at 0 for > half a minute due to backend proxies fetching data from Tier1 origin, > that's going to result in frustrated people. Nginx streams the data as it is received from the upstream server, so worst-case (cache miss) the data can be delivered as fast as received from the upstream server. > TL;DR: If you can afford CDN-fronting your mirror, that should be > mostly fine, but I would recommend against using Tier1 as your > cache-miss backend. Storage is cheap and most Tier1 mirrors have > unlimited bandwidth, so just run a Tier2 mirror (with slow/fast > storage caching) and keep local copies of everything. > > -K > (mirrors.kernel.org administrator)

1 0

Re: [arch-mirrors] [syscom] CDN based/caching mirror?
by Kristian Klausen 26 Jan '20

26 Jan '20

On 26.01.2020 17.40, Yunxiang Li wrote: > https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Network_shared_… I'm aware of that. https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Dynamic_reverse… is more or less the idea. The idea is basically to mirror the packages when requested, instead of mirroring everything upfront. Is Arch Linux interested is that kind of mirrors? > On January 26, 2020 4:19:10 PM UTC, Kristian Klausen via arch-mirrors <arch-mirrors(a)archlinux.org> wrote: >> Hi >> >> I'm considering setting up a Arch Linux mirror and I'm considering a >> different design. >> >> So instead of mirroring the whole thing, the idea is to mirror only the >> database files (core.db etc) and download the packages on demand from a >> Tier 1 mirror (and let nginx cache them). By doing it that way, I only >> download requested packages from the Tier 1 mirrors, instead of >> downloading the whole thing (saving Tier 1 bandwidth). >> >> To provide even better performance a CDN (ex: Cloudflare) could be used >> to provide more caching. So we end up with a setup like this: >> Cloudflare -> Nginx cache -> Tier1 mirrors (nginx with multiple upstream) >> >> Do I miss something? Is this a bad idea? >> If I do setup a mirror like that, is there any chance it could be added >> as a official mirror? >> >> Best regards >> Kristian Klausen

1 0