For a long time, I've been having a whole lot of trouble downloading updates. Files download *very* slowly and often arrive corrupted[*] (and therefore fail GnuPG verification). Even downloading using a web browser gave dismal results.
I switched to a mirror, and everything works fine... better, in fact, and more reliably than it ever did with RedHat's server.
If any of you are having trouble with up2date or yum, I'd suggest editing your /etc/sysconfig/rhn/sources file and selecting a mirror from the list [http://fedora.redhat.com/download/mirrors.html] as a first course of action.
It might even be worth while to add some functionality to up2date to download a list of mirrors and choose one (possibly interactively with the user, CPAN-style) rather than always using RedHat. The general public isn't going to know how to do all this manually. And if you browse the fedora-list archives, you'll see that people are really feeling the pain.
[*] - The fact that a server under load would transmit corrupted data is disturbing in itself. The problem's not the network: TCP give you the right data, or no data at all. It's either the client (that works fine with other mirrors, BTW) or the server. I'm under the conviction that the issue should be investigated at least.
On Tue, 13 Jan 2004, Tyler larson wrote:
[*] - The fact that a server under load would transmit corrupted data is disturbing in itself. The problem's not the network: TCP give you the right data, or no data at all. It's either the client (that works fine with other mirrors, BTW) or the server. I'm under the conviction that the issue should be investigated at least.
I am not an expert (IANAE?) but I imagine that the problem may lie in the client - after a set idle timeout in up2date it seems to just drop the connection to the server and move onto the next package. The resulting RPM is obviously corrupt since it is incomplete. I am probably wrong there, but that's what it seems like to me - I can't imagine apache (or whatever download.fedora.redhat.com uses for HTTP) dropping a connection itself simply because of high load .
Just my 2c.
-Dan
On Tue, 2004-01-13 at 16:21, Dan Goodes wrote:
On Tue, 13 Jan 2004, Tyler larson wrote:
[*] - The fact that a server under load would transmit corrupted data is disturbing in itself. The problem's not the network: TCP give you the right data, or no data at all. It's either the client (that works fine with other mirrors, BTW) or the server. I'm under the conviction that the issue should be investigated at least.
I am not an expert (IANAE?) but I imagine that the problem may lie in the client - after a set idle timeout in up2date it seems to just drop the connection to the server and move onto the next package. The resulting RPM is obviously corrupt since it is incomplete. I am probably wrong there, but that's what it seems like to me - I can't imagine apache (or whatever download.fedora.redhat.com uses for HTTP) dropping a connection itself simply because of high load .
Just my 2c.
-Dan
Sounds very plausible. I just looked over the up2date source (briefly, mind you) and it looks like it's programmed to handle that situation ("except httplib.IncompleteRead": rpcServer.py,line 125), though I didn't delve deep enough to see *how* the situation is handled.
Still depending on how things are done at the HTTP level, it's possible for a terminated download to be falsely interpreted as a successful download. (If no content-length is specified, the download is considered complete when the server terminates the connection). This, of course, *should never* be the case when using apache with static files, but it's a possible cause.
Perhaps we might do something like check an MD5 sum for downloaded files, and delete the bad RPM from /var/spool/up2date if it doesn't match. As things stand, if you get a bad RPM in the download directory, it stays there and is never re-downloaded, making updates fail every time. The user has to delete the bad file manually, and obviously most users don't know how, so up2date becomes "broken".
Tyler,
I experienced exactly the same problems with up2date. I'm principally using yum in a shell now, with multiple mirrors for each label.
I do agree that some dynamic look-up of mirrors would be a much better solution than having users edit files in /etc.
Gentoo Linux has an automated mirror selection tool called mirrorselect which could do this kind of thing very nicely.
On Tue, Jan 13, 2004 at 04:18:02PM -0700, Tyler larson wrote:
For a long time, I've been having a whole lot of trouble downloading updates. Files download *very* slowly and often arrive corrupted[*] (and therefore fail GnuPG verification). Even downloading using a web browser gave dismal results.
I switched to a mirror, and everything works fine... better, in fact, and more reliably than it ever did with RedHat's server.
If any of you are having trouble with up2date or yum, I'd suggest editing your /etc/sysconfig/rhn/sources file and selecting a mirror from the list [http://fedora.redhat.com/download/mirrors.html] as a first course of action.
It might even be worth while to add some functionality to up2date to download a list of mirrors and choose one (possibly interactively with the user, CPAN-style) rather than always using RedHat. The general public isn't going to know how to do all this manually. And if you browse the fedora-list archives, you'll see that people are really feeling the pain.
client with mirror support should be hitting rawhide any time now...
Adrian
Adrian Likins wrote:
On Tue, Jan 13, 2004 at 04:18:02PM -0700, Tyler larson wrote:
For a long time, I've been having a whole lot of trouble downloading updates. Files download *very* slowly and often arrive corrupted[*] (and therefore fail GnuPG verification). Even downloading using a web browser gave dismal results.
I switched to a mirror, and everything works fine... better, in fact, and more reliably than it ever did with RedHat's server.
If any of you are having trouble with up2date or yum, I'd suggest editing your /etc/sysconfig/rhn/sources file and selecting a mirror from the list [http://fedora.redhat.com/download/mirrors.html] as a first course of action.
It might even be worth while to add some functionality to up2date to download a list of mirrors and choose one (possibly interactively with the user, CPAN-style) rather than always using RedHat. The general public isn't going to know how to do all this manually. And if you browse the fedora-list archives, you'll see that people are really feeling the pain.
client with mirror support should be hitting rawhide any time now...
Adrian
After hunting through a lot of mirrors manually, this will be a great feature. I hope it works to spread out the workload and prevent errors with a great program.
This automation ought to be interesting to try out.
Jim