Bug 133442

Summary: if up2date is going to use a mirror, is should be chekcing the mirror for available updates
Product: [Fedora] Fedora Reporter: Rodd Clarkson <rodd>
Component: up2dateAssignee: Bret McMillan <bretm>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: mattdm
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-07-12 03:32:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Rodd Clarkson 2004-09-24 00:16:21 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)

Description of problem:
using the default up2date sources ('/etc/sysconfig/rhn/sources') with
FC3t2, it seems that up2date is checking downloads.fedora.redhat.com
for  updates, but trying to download them from one of the mirrors.

Because the mirrors haven't synced up to the main repository, up2date
fails, claiming there are no new updates to download, even though the
rhn icon in the panel shows that updates are available

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Use up2date with a couple of mirrors when they haven't had a chance
to sync.

Actual Results:  up2date claims the system is up to date, while
showing that updates are avaiable.

Expected Results:  up2date should be download updates.  I guess it
needs to check for updates on the same server it intends to use for
downloading the updates.  This may mean getting rhn to check the
mirror first and if no updates exist, then checking one of the main

To minimize load on the main repository, it might be appropriate
(having check a mirror) to only ask for security related updates on
the main repo.  This would allow systems to remain as secure as
possible without overloading the main repo with downloads for
enhancements or non-security related upgrades.

Additional info:

Comment 1 Need Real Name 2004-10-19 13:03:52 UTC
> to only ask for security related updates on the main repo.
> This would allow systems to remain as secure as possible

The rpms are signed, so this bit isn't necessary.

Comment 2 Neil Weisenfeld 2005-01-11 21:19:07 UTC
Yeah, this is a really annoying problem.  The issue seems to be (i.e.
I have no *real* knowledge, but am making assumptions) that the list
of updates is kept centrally, hence the notification (rhn_applet
exclamation mark and notice that updates are available), but then when
one goes to retrieve the updates, they may not have yet been pushed
out to the mirrors.

An alternate strategy would be to get the update list from the
mirrors, HOWEVER, this strategy has the risk that if a mirror stops
updating, then one would never know that he/she is falling behind and
should change mirrors.

Maybe we *can* trust the mirrors to serve the update list, but also
have a central server that keeps track of when a mirror updates and
gives a warning through the rhn stuff if someone is relying on a
mirror that has become far out-of-date.

Comment 3 Rodd Clarkson 2005-01-11 23:33:44 UTC
Just a thought, some questions and a possible solution.

Aren't there checksums for the file containing the list of updates? 
MD5 or something?  And aren't they fairly small files?

If the answer to both of these questions are yes, then couldn't a
quick comparison be made between the checksum files for both the main
repo and the mirrors to see that they are the same.  If they are then
you could assume that the mirror is up-to-date and use it, if not then
the mirror could be ignored.

This would allow you to check the main repo for updates, while
ensuring that only mirrors that are currently synced are used for
updating, solving the problem where you check mirrors for updates but
the mirror is very out-of-date.

Is this feasible?

Comment 4 Matthew Miller 2006-07-10 21:45:05 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!