Bug 455818 - yum-fastestmirror doesn't remeasure when host is moved
Summary: yum-fastestmirror doesn't remeasure when host is moved
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: yum-utils
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-17 23:47 UTC by H. Peter Anvin
Modified: 2008-07-24 20:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-21 13:07:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description H. Peter Anvin 2008-07-17 23:47:04 UTC
Description of problem:

When dealing with a roaming host, e.g. a laptop, yum-fastestmirror doesn't
remeasure hosts unless the timedhosts.txt file is removed explicitly.


Version-Release number of selected component (if applicable):
yum-fastestmirror-1.1.14-4.fc9

How reproducible:
Always

Steps to Reproduce:
1. Run yum with yum-fastestmirror
2. Travel cross-country
3. Run yum again

Actual results:
Watch it try to connect to the same mirrors it did before
  

Expected results:
yum-fastestmirror should be able to note that the IP number of the host doesn't
match the one used when the cache file was created and therefore consider the
cache file stale.



Additional info:

Comment 1 seth vidal 2008-07-21 13:07:29 UTC
It should be rereading the mirrorlists and its cache whenever the
mirrorlist_expire happens (which should be once a day by default)

In addition fastest-mirrors maximum age before reprocessing the mirrorlist is
10s by default.

We've evaluated tracking the ip before and it is too error prone (with nat) and
not obviously worth it for all the pain it adds.

In this case set your mirrorlist_expire to a lower value and the problem goes away.


Comment 2 James Antill 2008-07-21 13:23:04 UTC
 Also there is "yum clean expire-cache" which will make yum re-fetch the
mirrorlist ... AIUI this was supposed to be called by NetworkManager whenever
the network "changed". So that should solve your problem too.


Comment 3 H. Peter Anvin 2008-07-24 20:53:07 UTC
Hm, I can pretty safely say that at least on my system, *neither* of these
actually happen, and the cache is only refreshed when I manually delete it.

I'm a bit confused about the statement:

We've evaluated tracking the ip before and it is too error prone (with nat) and
not obviously worth it for all the pain it adds.

Does that mean you tracked the interface address (which might be internal) or
bounced it off a server to get the external IP?  I can see the latter being
extremely unreliable.



Note You need to log in before you can comment on or make changes to this bug.