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: | up2date | Assignee: | Bret McMillan <bretm> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | mattdm |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
> 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. Thank you! |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 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): up2date-4.3.38-1.1 How reproducible: Sometimes 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 repositories. 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: