Bug 126667
| Summary: | up2date incorrectly reports "no updates available" | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Don Russell <fedora> |
| Component: | up2date | Assignee: | Adrian Likins <alikins> |
| Status: | CLOSED WONTFIX | QA Contact: | Fanny Augustin <fmoquete> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2 | CC: | mattdm, pmacedo |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| URL: | http://www.redhat.com/archives/fedora-list/2004-June/msg03798.html | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-04-24 20:35:07 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 124619 | ||
|
Description
Don Russell
2004-06-24 15:21:15 UTC
I should have included this in the original text... > I see this a "server side" fix, if up2date works the way I think it does (asking a common server for a mirror site to use) then no change at the client-side is required. The above solution will guarantee that up2date only sees synch'd sites. > Cummulatively this will save a lot of bandwidth and people-hours because up2date won't be run over and over and over again trying to get updates unsuccessfully. > Thanks, Don An idea I came up with for another application: Create a scripted Apache error document that returns a 302 (document moved) and the location on a mirror known to have the desired update. A cron job periodically collects file listings from all mirrors to update the database used by the error document. This could even be hosted locally, needing only the master file list and the list of mirrors from the master server. You could serve those by rsync to cut the bandwidth needed. Kenneth, that's not so much "another application" as it is another "implementation" (of the same application)... :-) It looks like a nice refinement to the original idea... an "up2date/yum/apt whatever) request goes to the redhat server, where it gets a "this is temporarily moved to <synch'd site>" brilliant! Then NOTHING has to change at the client side... (Unless the client side doesn;t know what to do with that response) I don't see the benefit of "hosting it locally"... Maybe I'm not understanding what "it" is... :-) I don't see a benefit of keeping a list of synch'd sites on my machine since that list can be obsoleted any time... that means the first thing I have to "up2date" is the list of servers... On the other hand if the main server just replies with "file temporarily moved to <synch'd site>, then I don't care what the sites are, the main server sends me somewhere that has what I want.. Round-robin or random, as long as only synch'd sites are used, update should work much better than it does now. :-) Given the volume of people getting updates, I don't see any benefit of choosing a random site... simply picking the next one in the list is "random enough". The point really is that the solution is not at the client side.... this has to be fixed at the server end... Or... maybe uppdates can be distributed by bittorrent... it seems like a perfect application... a new software thing is released... thousands want it at the same time... then no traffic until the next update... That's more work though... not a bad idea, just more work. :-) So... now that it's IN bugzilla... how do we get "somebody with influence" to look at it/do it? :-) Seems when I updated this, it removed the QA contact... I'm trying to add that back now... Don About the first comment (and the original thread on fedora-list), I've implemented a script in perl that compares a set of mirrors with a server defined as being the original server. The script produces as output a file , fedora-core-$releasever , using the same format as used by up2date's mirror file (using $ARCH instead of yum's $basearch). It's run every 30 minutes against the redhat server and all the http mirrors available. The code is available at http://www.dcc.ufmg.br/~pmacedo/fedora , and needs two files , all available in the same place (the config file and the mirror list). This code is just a proof of concept about the original thread and many things can be implemented to improve it , specially in the mirror checking... Fedora Core 2 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 FC3 updates or in the FC4 test release, reopen and change the version to match. I changed the version from FC2 to FC4 because this problem still occurs. Because this had so many problems, I really stopped using it, and now use yum. Should up2date be fixed? hmmm, maybe just removed. :-) Well, that didn't work... apparently I'm not "sufficiently authorized" to change the version number in the problem report, I get to create a new report... no thanks, been there, bought the T-Shirt. It's just not that important to me. :-) So, I guess this will just be relegated to the annals of time... "Should up2date be fixed? hmmm, maybe just removed. :-)" Well, it has been removed. Of course, something similar occasionally occurs in yum-- the mirror hit to see what updates are available isn't always the first mirror chosen to download packages from, and since the mirrors aren't always in sync... But I suppose this can be closed, since up2date isn't even in FC5. |