[CentOS-mirror] Ideas on steering yum to local mirrors

Wed Sep 29 13:05:53 UTC 2010
Ralph Angenendt <ralph.angenendt at gmail.com>

On Wed, Sep 29, 2010 at 1:40 PM, Bangladeshi CentOS Mirror Maintainer
[BD-SERVERS.NET] <centos-org at bauani.org> wrote:
> Hello All
> If the CentOS Master Mirror want to announce and meeting, the date
> can't be fixed by getting input from member of list.

I am not sure about that. Getting to know the timeframe which people
have and if they are interested at all helps a lot when determining a
date for such an event.

> We, the maintainer of CentOS mirror around is a part of CentOS family
> and we are human being. Everyone has their own work schedule. Like in
> 6th October, Internet Society [ISOC] has conference in Bangladesh for
> first time and I wish to join the event. 12th October is my birthday
> etc etc.

So it is neither the 11th, nor the 12th nor the 13th :)

I guess weekend is out of the question anyway?

I then propose Monday, October 18th(!) at 20:00 UTC,

> So it would be better fix a date and announce it via list. If most
> people don't agree to join on said date, the date of event can change
> 1 to 3 days plus and minus.

See above.

> >From my point of view, it seems if the GeoIP database of CentOS is up
> to date, currently problem might solve in most case.

It is up to date (well, from now on it will, at least). One problem is
that the data sometimes really is off, so machines in the UK are
flagged as being in the US or Canada and things like that.

Second: It doesn't help in cases when you'd like all the machines in
your DC to hit the mirror which also is in that DC. If you aren't the
admin of all of those machines, using the same AS or /16 would be
great. And that is what our mirroring system cannot do.

> Among other
> distribution, CentOS mirror maintaining system is the most easy system
> in current scenario.

Not really :)

> If we want to move from current system, then ASN based system to
> determine closest mirror might work.Though It also have pro & cons. So
> my suggestion is to work with current system  and find out where is
> the problem so that the problem can be fixed.

The problem is that we can *only* do GeoIP. The granularity of that
isn't fine enough at times (see above or other examples in this