At 11:22 PM +0930 5/29/06, Tim wrote:
>On Mon, 2006-05-29 at 12:15 +0100, Robert Spanton wrote:
>> Wait... I've just found that it's because the mirror I'm looking at is
>> somehow out of sync.
>
>Yes, what is it with nearly ALL of the mirrors being really crappy the
>last few weeks? Is there some sort of attack being carried out on then?
I've been working out what's going on, and I think I'm getting a handle on
it. I've got a program that lists the current state of a repo's mirrors.
I'll try next to write a yum plugin that fixes the issue I think I've
identified. I don't think there has been any attack. I think this is just
"normal operation".
Yum basically assumes that all the mirrors are in sync, though it has some
ways to cope when they aren't. When a repo is updated, it takes generally
up to a day for all the mirrors to notice and fetch the changes, both the
actual data and the repo metadata files. If a repo is updated frequently,
the way updates is, usually some of the mirrors are up-to-date and some are
not. That is, there will be transient "groups" of mirrors that agree with
each other, but not with the other "groups". There can be several such
"groups" if the repo is updated more than once in a day.
When yum choses a mirror, the default policy is to pick one at random.
That mirror may be less up-to-date than the mirror last used to update. If
there is any trouble communicating with the current mirror, yum will try
another mirror. If that mirror is in the same transient "group" as the
original mirror, it will (or at least can) work, but if it is in some other
"group", whatever metadata is downloaded from it will be rejected. If the
original mirror was more up-to-date than the current mirror, the requested
package may not even be there. If the original mirror was in a small
"group", most of the other mirrors won't work, and this is often the case
lately.
I think what yum needs is something like:
* reject any mirror if it is less up-to-date than the last
update
* when changing mirrors, reject any that don't have the same
repomd file as the first mirror
* normally, stick with the same mirror that was used last time
unless the user rejects that mirror
I'll try to write a plugin that does this, and possibly a bit more.
____________________________________________________________________
TonyN.:' <mailto:tonynelson@xxxxxxxxxxxxxxxxx>
' <http://www.georgeanelson.com/>
