Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#45178 - {mirror} New Mirror (Dallas, Tx, USA, 100/100 Mbps, no limits)

Attached to Project: Arch Linux
Opened by Hon1nbo (dajjhman) - Tuesday, 02 June 2015, 19:17 GMT
Last edited by Florian Pritz (bluewind) - Sunday, 09 July 2017, 18:54 GMT
Task Type Feature Request
Category Mirrors
Status Closed
Assigned To Florian Pritz (bluewind)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
New mirror running based out of Dallas, Texas, USA.
Have bandwidth for Tier 1, but would like to stay at Tier 2 until it has been running stable for a while (mirror management's call anyway).

Additional info:
* http://mirror.gawsolutions.us/arch
* rsync://mirror.gawsolutions.us::arch

Mirror is currently updated off of the RIT.edu mirror via rsync.

Bandwidth: 100 Mbps symmetrical, no data limit.

Contact info:
Admin direct: jhartnett@gawsolutions.us
General Mirror Updates: mirrors@gawsolutions.us

HTTP Servers are Apache based, and uses a load balancer over several nodes. Rsync is currently only available on the primary node, but can be made available on other nodes (however, the load balancer is not compatible with rsync, so the user would have to select a node or the mirror bouncer would have to).

For rsync updates, the following IP is the source: 64.182.234.101
Auxiliary IPs for rsync source if primary is down: 64.182.235.4 ; 64.182.235.5

-Jim

This task depends upon

Closed by  Florian Pritz (bluewind)
Sunday, 09 July 2017, 18:54 GMT
Reason for closing:  Implemented
Additional comments about closing:  This seems done. If not, please request reopen.
Comment by Florian Pritz (bluewind) - Wednesday, 03 June 2015, 07:29 GMT
Added.

Thanks for the offer to become tier 1, but I'm not sure if a 100Mbit mirror should really do that in a country that large. We already have some rather fast tier 1 mirrors in the US. Keeping this open anyway, I'll decide later.
Comment by Hon1nbo (dajjhman) - Wednesday, 03 June 2015, 15:42 GMT
fine staying as a tier 2, if there are already a lot of faster mirrors in the region then that works, but my consideration is the locality of those mirrors within the US.
Do any of the mirror lists have region support more granular than the Country?
Judging by the organisations running Tier 1 in the USA, most are on the east cost or far north. The only one I can't nail down an accurate location for are the kernel.org mirrors.
In the end, may not make a difference as the average user will likely not select a tier 1 manually, but it might be worth considering for syncing purposes due to the hazard of update sources being in the same geographical regions.

Currently I'm syncing off of RIT. However, in an event like Sandy, RIT and NYU would both be at serious risk. The UGA mirror is on the coast as well, and I don't know where kernel.org's are. he Michigan mirror is not in a particularly hazardous region geographically as far as I am aware, however this would put a strain on them if they end up being the only one safe for continuity purposes.
I'm not really suggesting me being a tier one due to speed, but rather just to get some extra regional coverage and provide an alternative syncing source.

Another solution to the same situation would be a mirror bouncer that supports rsync. I've user mirror brain, but I don't know of one that does rsync effectively. If there was an rsync bouncer, then the situation could be resolved such that rsync updates can resolve to an available host for mirror admins, rather than script to a single tier 1 mirror (I'm personally working on scripting this check for myself, but maybe something like a round-robin DNS with a ping check would work well for this purpose?)

EDIT: Clarified statement of geographical situation for Michigan mirror.
Comment by Florian Pritz (bluewind) - Wednesday, 03 June 2015, 16:21 GMT
So far our system worked well enough, but I agree that better geo information might be a good idea. I'm not so sure if we want bouncers since those are also a source of failure.

I don't have too much time right now, but I might try to write a script that uses geoip to figure out where our mirrors actually are (our database only stores countries). If you want to you can also do that. This should contain enough data to extract all URLs and then do the necessary lookups: https://www.archlinux.org/mirrors/status/json/
Comment by Hon1nbo (dajjhman) - Wednesday, 03 June 2015, 19:27 GMT
if I get my script working I'll share it here, or open a new request.
Comment by Andy Poe (andypoe2012) - Thursday, 26 January 2017, 07:59 GMT
I could provide a mirror in Dallas hosted in Vultr dc, same as http://buywebtrafficexperts.com/ server.
Comment by Florian Pritz (bluewind) - Thursday, 26 January 2017, 09:36 GMT
Please don't hijack existing tasks. Thank you.

Loading...