Bug 110133 - rhn-applet is unable to access fedora-core-1 and updates-released
Summary: rhn-applet is unable to access fedora-core-1 and updates-released
Alias: None
Product: Fedora
Classification: Fedora
Component: rhn-applet   
(Show other bugs)
Version: 1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-15 00:40 UTC by Anders Kaseorg
Modified: 2007-11-30 22:10 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-12-19 15:03:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Anders Kaseorg 2003-11-15 00:40:34 UTC
Even though up2date tells me there are updates available, rhn-applet
never does, and the following is always in the Critical Information tab:

The applet has been unable to access the following information sources
in its last attempts: fedora-core-1 @
http://fedora.redhat.com/releases/fedora-core-1, updates-released @

This happens on two FC1 systems. The problem is specific to these two
channels; the other yum channels I added *do* work.

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

How reproducible:

Steps to Reproduce:
1. Right-click on RHN applet.
2. Select Check for updates

Actual Results:  No updates available, error in Critical Information tab

Expected Results:  6 updates available

Comment 1 Anders Kaseorg 2003-11-15 00:47:35 UTC
This may have something to do with the URLs being redirects to
locations on download.fedora.redhat.com. Changing the URLs in
/etc/sysconfig/rhn/sources to the targets of the redirections makes
rhn-applet work.

Comment 2 Jean Francois Martinez 2003-11-16 07:22:48 UTC
The same problem (wrong URLs) is in yum via yum.conf.   I suggest you
put a symlink in the web site as it is the quickest and most
transparent way to fix a bug who is crucial for Fedora's reputation
(before the reviewers have evaluated Fedora).

There was a similar problem with redhat-config-packages who was still
looking /mnt/cdrom/RedHat/RPMS when the right place is 
/mnt/cdrom/Fedora/RPMS: a production realease is NOT the place to go
changing paths who could acffect important tools: there has been 3
(three test releases), those changes whould have gone in one of them

Comment 3 Anders Kaseorg 2003-11-16 15:24:44 UTC
Now the redirecting URLs have been completely removed, causing up2date
to fail as well.

If up2date is going to be changed to use the
download.fedora.redhat.com URLs, that creates an awful chicken-and-egg
problem: most users won't know that the update exists, and won't be
able to receive the update if they do! It's clearly impossible to get
everyone to download an update manually, so the only real solution is
to fix the original URLs without redirects.

Comment 4 Bart Martens 2003-12-19 09:38:43 UTC
Confirming... same problem here. Ethereal says:

--- begin ---
GET /updates/released/fedora-core-1/headers/header.info HTTP/1.1
Host: fedora.redhat.com
Accept-Encoding: identity
User-Agent: RHN-Applet/2.1.2

HTTP/1.1 302 Found
Date: Fri, 19 Dec 2003 09:27:20 GMT
Server: Apache
Content-Type: text/html; charset=iso-8859-1
Age: 0
Connection: close
Via: HTTP/1.1 bruink (Traffic-Server/5.2.1-58896 [cMsSf ])

<TITLE>302 Found</TITLE>
The document has moved <A
--- end ---

I agree with Anders Kaseorg on the only real solution.

Comment 5 Daniel Veillard 2003-12-19 10:29:47 UTC
User-Agent: RHN-Applet/2.1.2

This has been fixed in teh latest versions of the applet.
Upgrade ! Up2date support redirections, the upgrade should work.


Comment 6 Bart Martens 2003-12-19 12:33:48 UTC
Daniel, this doesn't solve the chicken-and-egg problem described above
by Anders Kaseorg. Can you comment on Anders Kaseorg's message please?

Comment 7 Daniel Veillard 2003-12-19 12:45:02 UTC
Well I think I did !
up2date handles redirection. so running up2date will upgrade
the rhn applet.
W.r.t. changing the web site, I don't know who can do this.


Comment 8 Anders Kaseorg 2003-12-19 14:45:58 UTC
Here's the problem:

1. Joe User downloads and installs Fedora Core 1 on his shiny new desktop.
2. Joe logs in, and the old rhn-applet starts.
3. rhn-applet accesses the fedora.redhat.com updates URL.
4. rhn-applet gets redirected to download.fedora.redhat.com.
5. Because of this bug, rhn-applet gets confused, gives up, and
displays a blue checkmark with a "no updates available" tooltip.
6. Joe thinks he doesn't need to run up2date because he thinks there
are no updates available!
7. So rhn-applet never gets updated, and neither does anything else.
8. Joe runs into a critical bug in some other package, gets really mad
that Red Hat "doesn't" release an update, writes nasty reviews of
Fedora Core flaming Red Hat, and goes out to buy Windows XP.

You see, the update is worthless if users don't know it exists.
Therefore, it is critical for Fedora's reputation that the website be
changed to accomodate the old, buggy rhn-applet, for as long as Fedora
Core 1 is in use.

Comment 9 Daniel Veillard 2003-12-19 15:03:33 UTC
I understand your problem. I cannot fix it. It's not a rhn-applet 
problem. It's not the initial bug reported against rhn-applet.
It's useless to reopen a rhn-applet bug for something which is a 
web site update request.


Comment 10 Bart Martens 2003-12-19 16:25:31 UTC
Daniel, Anders Kaseorg meant to report a problem, not just the bug
causing the problem. If you want to keep the scope of this bug report
to the bugfix itself, then I think you should split Anders Kaseorg's
problem report into two (or more) bug reports before closing this bug

Comment 11 Daniel Veillard 2003-12-19 16:46:52 UTC
There is no component for the web site. It's not even a pure web
site problem. The data are on a different machine !
I'm checking if that can be fixed in some way, but it's not
related to rhn_applet, so closing the bug is fine !


Note You need to log in before you can comment on or make changes to this bug.