Red Hat Bugzilla – Bug 133442
if up2date is going to use a mirror, is should be chekcing the mirror for available updates
Last modified: 2007-11-30 17:10:49 EST
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):
Steps to Reproduce:
1. Use up2date with a couple of mirrors when they haven't had a chance
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.
> 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.
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.
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?
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.