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!
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!
FS#16441 - {mirror} Request for mirror access / inclusion
Attached to Project:
Arch Linux
Opened by John 'Warthog9' Hawley (warthog9) - Saturday, 03 October 2009, 02:37 GMT
Last edited by Roman Kyrylych (Romashka) - Tuesday, 06 October 2009, 08:51 GMT
Opened by John 'Warthog9' Hawley (warthog9) - Saturday, 03 October 2009, 02:37 GMT
Last edited by Roman Kyrylych (Romashka) - Tuesday, 06 October 2009, 08:51 GMT
|
DetailsThis, while seemingly a simple request is going to be a bit complicated. Specifically we have gotten enough interest / requests that kernel.org is now interested in becoming a mirror for Archlinux. I've done an initial sync from outside of the official mirroring system but would like to switch over to the official rsync as soon as possible.
While I said this would be a seemingly simple request, the kernel.org infrastructure has a tendency to cause some confusion and head scratching in how to handle it from a mirror perspective. mirror domain: Primary: mirrors.kernel.org <-- This is our primary interface, we have a tendency to prefer using this as it will engage geodns and route a user to a machine, or a round robin of machines that is theoretically closest to them GeoDNS Overrides: mirrors.us.kernel.org <-- Round Robin of machines in North America mirrors.eu.kernel.org <-- Round Robin of machines in Europe mirrors.se.eu.kernel.org <-- Mirror machines in Sweden mirrors.nl.eu.kernel.org <-- Mirror machines in Amsterdam Geographical Location of the mirror: See Above, we are 'complicated' Supported access methods: http: http://mirrors.kernel.org/archlinux/ ftp: ftp://mirrors.kernel.org/archlinux/ rsync: rsync://mirrors.kernel.org/archlinux/ IP: I would actually *GREATLY* appreciate being issued a username/password combo for rsync as opposed to doing this on an IP basis. This makes life for everyone easier, particularly since I have a whole slew of machines to manage, a number of ip spaces and the looming need to change at least one of them within the next year. Administrative contact e-mail: ftpadmin@kernel.org Administrative irc channel: Linuxnet #korg I personally can be found on most of the normal irc networks as warthog9. We sync once an hour, from all four machines. We have a total outgoing bandwidth of 4gbps (worldwide) currently (this will be changing within the next year I believe). We are also quite happy and capable of acting as a "tier 1" style mirror, and allowing protected 3rd party access to the archive, and we have a general goal of mirroring all of a distributions available content, both current and archive (http://archive.kernel.org for examples). General inclusion will eventually get you set up on http://boot.kernel.org as well as the normal mirroring. |
This task depends upon
Closed by Roman Kyrylych (Romashka)
Tuesday, 06 October 2009, 08:51 GMT
Reason for closing: Implemented
Tuesday, 06 October 2009, 08:51 GMT
Reason for closing: Implemented
Thanks kernel.org!
eliott: glad I could be of service :-)
So, I'll get this setup sometime today, I believe.
Regarding the password based access, do you happen to know a way to selectively turn this on? It's going to be a big hassle for all our mirrors if we have to switch to a username/password system. What is wrong with ip-based whitelisting? Note that I'm asking because I'm curious. I'm not an admin-y type :)
I added an "ftp_auth" module that accepts user/password authentication. John, I will email you the info and get the rest of this setup in our DB in a sec.
Added to the DB, all should be good now
1) The usernames & passwords can live in a separate file from the primary rsync configuration which makes it a lot easier to automate the creation and management of those
2) It means that a mirror can shift IPs, change machines (add, subtract, change hardware), change names, etc without having to get the upstream admins involved.
In the end it gives the mirror a bit more flexibility, and should generally save the upstream a little bit of a headache. And with kernel.org having, currently, 4 different incoming IPs we can easily collapse ourselves down to looking like a single entity vs. 4 separate entities.
For mirrors of kernel.org content (like the t2 mirrors or the mirrors of www.kernel.org/pub) we use a username/password combo just to make things simple for us and as you found out the hosts / auth users are on a per module basis so it's reasonably simple to support both mechanisms (just use a different module for each authentication type)
rsync://mirrors.kernel.org/archlinux/
Is this really what we want? I think we should at least include other.