- Arch-mirrors - lists.archlinux.org

arch.takehiko.pl - unavilability note
by a＠takehiko.pl 09 Jul '24

09 Jul '24

1 0

T2 shutdown: archmirror.it
by Ernesto Castellotti 28 Jun '24

28 Jun '24

Hello everyone, I am writing to inform you that the tier-2 mirror archmirror.it will be shut down on 31 July 2024. I recommend removing the mirror as soon as possible and in any case before 30 July 2024. All the best Ernesto Castellotti

1 0

Shutdown tier 2 server mirror.erickochen.nl
by Eric Kochen 04 Jun '24

04 Jun '24

Hi everyone, The tier 2 'mirror.erickochen.nl' will shutdown this week. It was a pleasure. Best, Eric Kochen

2 1

mirror.qctronics.com mirror maintenance & outage
by Admin 27 May '24

27 May '24

OSS Mirror mirror.qctronics.com will be down on May 31st / June 1st because we are moving our servers to a new location. We are not sure if the servers are gonna be restored by June 2nd as we have to install new networking hardware that hasn't arrived yet (but scheduled to arrive on May 31st) We usually loadbalance our mirror accross two machines to avoid downtime, however, our current situation makes this impossible. We apologize for any inconvenience. -FF QCTronics Administrator / Administrateur de QCTronics *This email is used by multiple people from QCTronics. *Ce courriel est utilisé par plusieurs personnes travaillant pour QCTronics.

1 0

mirror list is not maintaine
by xuanzhong xuanzhong 26 May '24

26 May '24

it's been a month since we applied and no respons servers are just being run to waste

2 1

arch.takehiko.pl - maintenance notification
by a＠takehiko.pl 23 May '24

23 May '24

1 0

Regarding Arch Linux RFC 29
by pitastrudl 22 May '24

22 May '24

Dear mirror operators and contributors to the RFC 29[1], we would like to thank you for the participation in the process of writing this text. We worked on this topic enthusiastically in the hopes to not only improve our own workflows, but also provide mirror operators with a more streamlined workflow as well. Following the theme of the last Arch Summit, we had a lot of ideas that we wanted to include. We acknowledge, that our writing is in part scattered and covers a large set of topics, which may have been too spread out for one RFC. Furthermore we left out a lot of the reasoning and motivation that are crucial to follow the intent of the proposed changes. Therefore we are grateful for the diverse feedback on this RFC [1], which already helped us a great deal to shape the text. We realize, that the text still suffers from poor wording and too many topics that are not properly formalized. This has led to miscommunication and annoyances, that we would like to circumvent going forward. We understand that misunderstandings have led to resentment for some contributors and for this we apologize. Please bear with us until we have reworked the text according to the received feedback. Going forward we want to improve on the general introduction to the topic and revisit the mirror specification format. We will drop mirror requirements, the identity proof concept, as well as other not well-defined topics. We recognize that the proposed tier changes may have been taken as a form of penalty, therefore we will improve on wording and rephrase the tier model as well. In addition, we recognize that the topic introduced in RFC 35[2] is not well received and not worth pursuing. We will close that RFC and explore security concepts at a later stage and with a different approach. Again, we thank you all for your participation and hope to discuss our reworked document with you in the near future. @pitastrudl, @wahrwolf and @torxed [1]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/29/ [2]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/35/

1 0

mirror.lastmikoi.net migration and temporary bandwidth reduction
by lastmikoi+arch-mirrors＠lastmikoi.net 15 May '24

15 May '24

Hello, I'm moving to a new home and, until I'm settled, I've migrated my archlinux mirror to another host. However, one can expect up to 4x bandwidth reduction (1Gbps -> 0.25Gbps) until I get settled. HTTP(S) and rsync services will be maintained both on IPv4 and IPv6 for the foreseeable future. Have a good day, Mickaël FALCK.

1 0

kescher.at mirror outage
by Jeremy Kescher 12 May '24

12 May '24

The machine that hosts the mirror for at.arch.mirror.kescher.at is currently fully down due to an unexpected outage. Work on restoring it into working order is currently ongoing. In the spirit of prior mails here: Check your backups, they may end up becoming important one day. ~ kescher

1 1

Splitting the Arch Linux repo and archive server
by gromit 29 Apr '24

29 Apr '24

Hello Mirror Admins, the DevOps team [wants to split][0] the repo server and the archive server, which are currently still located on the same box (gemini.archlinux.org) The server in question is currently crumbeling under the load the I/O intensive tasks (such as btrfs scrub, hardlinking service, tons of rsync processes at the same time) are putting on it and is not well equipped to handle these loads as it has still regular HDDs (aka spinning rust) in it. This is of course great from a storage capacity perspective but not good for the peak performance scenarios mentioned before. Our plan is therefore to split out the repo server to a new one with SSDs and use the current server for archiving purposes only going forwad. We have drafted a rough plan on how we imagine this transition to go: 1. **Phase 1:** We will setup the new server and have the domain "rsync.archlinux.org" point to it, since this is the domain used by the T1 Mirrors. At this point the box itself is syncing from the "old" repo server. 2. **Phase 2:** After a grace period of 2 week the rsync deamon on the old box is shut off. This can possibly create problems as the mirrors might have hardcoded the IP, hence the afforementioned grace period. 3. **Phase 3:** We make the new box the cannonical home of our repo services. This change should not really be visible from outside and mostly concerns our packagers, which will be notified separately. We will update this thread with a schedule soon! It is important for us to make this process transparent to you because we recognize the effort it can take to run a mirror and don't want to make life hard for you. So if you see any problems with the plans outlined above feel free to let us know! Thanks for being awesome! 🎉 Cheers, Kristian and Christian from the Arch DevOps Team [0]: https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/531

1 2