Bug 160873 - rhn-applet-tui can't handle repomd repos
rhn-applet-tui can't handle repomd repos
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rhn-applet (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Robin Norwood
Beth Nackashi
: Security
: 160921 162036 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-17 17:38 EDT by Ian Pilcher
Modified: 2007-11-30 17:11 EST (History)
33 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-21 13:59:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ian Pilcher 2005-06-17 17:38:37 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4

Description of problem:
The text mode RHN applet (rhn-applet-tui) doesn't seem to grok repomd
repositories.  When run with the '--verbose' switch, it complains:

  Failed to read sources from /etc/sysconfig/rhn/sources, assuming up2date only

The only repository configured in the default FC4 sources file is:

  repomd fedora http://fedora.redhat.com/

(BTW, that comma in the error message should be a semi-colon.)

Version-Release number of selected component (if applicable):
rhn-applet-2.1.17-3

How reproducible:
Always

Steps to Reproduce:
1.  Run 'rhn-applet-tui --verbose' on a new FC4 install.

Actual Results:  Failed to read sources from /etc/sysconfig/rhn/sources, assuming up2date only

Expected Results:  Program should check configured repository.

Additional info:

I'm not sure if the GUI applet suffers from this problem or not.  It doesn't
seem to have a '--verbose' option.
Comment 1 Pete Chown 2005-06-18 11:11:10 EDT
My system is set up the same way and I am seeing the same behaviour with
rhn-applet-tui.  I think the GUI version must suffer from the problem as well,
because it seems to be showing a tick even when updates are available.  (If I
run "yum update" the updates are installed okay.)
Comment 2 Mike Chambers 2005-06-20 19:23:19 EDT
Same thing here with the GUI RHN icon.
Comment 3 Jeroen Beerstra 2005-06-21 20:35:51 EDT
Same here both on i386 and x86_64 FWIM
Comment 4 Ian Pilcher 2005-06-22 12:40:01 EDT
This could cause users to think everything is hunky-dory when a critical
security update needs to be installed.  Changing severity to "Security."

Maybe someone will actually look at it now?
Comment 5 Brandon Amaro 2005-06-23 01:00:49 EDT
I think you should change the priotity to high as well as that this is a realy
big problem.
Comment 6 Cole 2005-06-24 04:09:52 EDT
This one might be a duplicate of
#160921 - Redhat Network Alert Icon falsely shows no available updates?
Comment 7 Rahul Sundaram 2005-06-27 11:22:03 EDT
*** Bug 160921 has been marked as a duplicate of this bug. ***
Comment 8 Brandon Amaro 2005-06-27 12:38:24 EDT
(In reply to comment #6)
> This one might be a duplicate of
> #160921 - Redhat Network Alert Icon falsely shows no available updates?

Its actualy the other way around since this one was posted first as it has a
lower ID number.

Anyways, any idea when this will get fixed?
Comment 9 Hans de Goede 2005-06-29 07:45:35 EDT
*** Bug 162036 has been marked as a duplicate of this bug. ***
Comment 10 Ian Pilcher 2005-06-29 14:39:03 EDT
Re comment #8:  Forget getting this bug fixed, I'd just like to see some sign
that someone has looked at it!
Comment 11 petrosyan 2005-06-29 16:15:11 EDT
Ian Pilcher, do you know what "NEEDINFO" means?
It means that the bug cannot be fixed since the reporter of the bug didn't 
provide enough information about the bug. Since it is not the case with this 
bug, remove the "NEEDINFO" flag.
Comment 12 Ian Pilcher 2005-06-29 16:26:26 EDT
I didn't change the status to NEEDINFO.  (I don't have the authority to
do so, even if I wanted to, and I don't have the authority to change it
back.)
Comment 13 Stephen Biggs 2005-06-30 16:01:36 EDT
This seemed to work for me.  Your mileage may vary.

Add the following lines to /etc/sysconfig/rhn/sources (note that they need to be
all one line but this comment window forces wrapping):
yum fedora-core-4
http://download.fedora.redhat.com/pub/fedora/linux/core/4/$ARCH/os/

yum updates-released-fc4
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/$ARCH/
#
yum-mirror fedora-core-4
http://fedora.redhat.com/download/up2date-mirrors/fedora-core-4

yum-mirror updates-released-fc4
http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc4

and make sure that the line:
repomd fedora http://fedora.redhat.com/

is commented out.
Comment 14 Stephen Biggs 2005-06-30 16:09:20 EDT
(sorry for replying to my own post, but I forgot something.)

Can someone verify that this indeed works?  I already ran up2date before I added
these changes and would not have hit on any updates needed afterwards.

I am only going on the fact that 'rhn-applet-tui --verbose' now shows that it is
actually trying to read these repositories. I don't know for sure that this is a
good fix.  Up2date seems to read the correct values now.  I would only use these
repositories for up2date as security updates to inform me that there is
something needed.  Any other updates I take care of either by yum or by apt-get.
Comment 15 Hans de Goede 2005-06-30 17:18:20 EDT
The above will work but is not a solution, because this won't get you update
notifications for FC4-extras and won't get you updates from FC4-extras when
running up2date.
Comment 16 Brandon Amaro 2005-06-30 17:27:15 EDT
There is one problem with that solution.  That doesn't solve it not being able
to handle repomd repos.
Comment 17 William Hooper 2005-06-30 18:43:09 EDT
Re: Comment #13 - The updates directories have no header info, so this will
break up2date and still not alert you when there are updates.
Comment 18 Tim Maes 2005-07-06 11:28:00 EDT
Any word on a resolution for this?  The problem seems to be the lack of a header
directory for yum, don't know what the problem is for the repomd repos.
Comment 19 Paul Howarth 2005-07-07 04:49:02 EDT
yum itself hasn't used the headers directory since FC2. There was a headers
directory on the FC3 repos only because up2date hadn't been modified to use the
new style metadata in the repodata directory. In FC4, up2date *can* handle
repodata (using repomd) so the headers directory isn't needed (and using "yum"
repos with up2date in FC4 is unlikely ever to work as a result).

The problem with repomd affects only the rhn-applet, not up2date itself. The
applet throws an exception when trying to parse the repomd entry but I don't
know enough python to understand the issue or to fix it.
Comment 20 Tim Maes 2005-07-07 21:25:36 EDT
Paul,

The reason I was thinking it was a lack of a header directory is because when I
input this:

# up2date -u --nox

I get this:

There was a fatal error communicating with the server. The message was:

An HTTP error occurred:
URL: http://mirror.linux.duke.edu/pub/fedora/linux/core/updates/4/i386//headers/
header.info
Status Code: 404
Error Message: Not Found

This box is an upgrade from FC1 all the way through FC4, so I'm thinking I may
have some configuration issues which I need to sort out, but for the life of me
I can't find any documentation on a troubleshooting process for this combination
of yum, up2date, etc. 
Comment 21 Mike Chambers 2005-07-07 21:54:47 EDT
Because your up2date (sources file) program is configured to look for headers,
instead of repodata.  And no, the headers dir is not in the up2date dir no
longer, just repodata.  So you need to change your /etc/sysconfig/rhn/sources
file to one that has the updated info, which you can get an example from the FC4
dir.  But the problem is the rhn-applet, isn't programmed to use repodata just
yet.  So it doesn't show that we need updates yet.
Comment 22 Tim Maes 2005-07-08 01:47:27 EDT
Mike,

Changing my sources file to updated info (as shown on another FC4 fresh install)
and running:
# up2date -u --nox

Gives me this:
An error has occurred:
yum.Errors.RepoError
See /var/log/up2date for more information

The /var/log/up2date file reads:

[Thu Jul  7 22:41:28 2005] up2date   File "/usr/sbin/up2date", line 1265, in ?
    sys.exit(main() or 0)
   File "/usr/sbin/up2date", line 328, in main
    sources = sourcesConfig.getSources()
   File "/usr/share/rhn/up2date_client/sourcesConfig.py", line 264, in getSources
    scfg = SourcesConfigFile(filename="/etc/sysconfig/rhn/sources")
   File "/usr/share/rhn/up2date_client/sourcesConfig.py", line 42, in __init__
    self.load()
   File "/usr/share/rhn/up2date_client/sourcesConfig.py", line 85, in load
    self.parseRepomd(line)
   File "/usr/share/rhn/up2date_client/sourcesConfig.py", line 230, in parseRepomd
    repo.baseurlSetup()
   File "repos.py", line 532, in baseurlSetup
   File "repos.py", line 423, in check

Is this what everybody else is getting?  Thanks.
Comment 23 Mike Chambers 2005-07-08 05:36:27 EDT
Well, since this is a problem you are having with up2date itself, you should
join (if not already) the fedora-list and post your problem there, with a copy
of your sources file to see if anything is wrong.

This bug is for the rhn-applet and it not using repomd repos.  Bugzilla isn't
used just to fix people's problems, but to fix program problems.

Sorry if this doesn't help and would love to help you personnally, but I would
get smacked on the hand from the folks on here :P
Comment 24 Tim Maes 2005-07-08 18:19:29 EDT
I understand, Mike, thanks anyway.
Comment 25 Tom Chiverton 2005-07-15 05:42:06 EDT
Guys, can we get this bug fixed ?
It's fairly serious that we say to people 'add this, when it isn't a tick, you
need to upgrade something for security reasons', and the thing *never* changes.
Comment 26 Adam Bowns 2005-07-15 05:58:13 EDT
Is it just me that thinks rhn-applet is out of place on a fedora system?

Surely an applet which directly communicates with yum would be much better, use
far less system resources, and need no further configuration.

Something that does a “yum check-update” at set time intervals and changes state
accordingly would do the trick just fine. At least it would provide a reliable
reading, which is all I want it for.

Are there any plans to remove rhn related stuff from fedora at some stage?
Because now is as good a time as any and I’d be willing to help do it.
Comment 27 Rahul Sundaram 2005-07-15 06:01:30 EDT
(In reply to comment #26)
> Is it just me that thinks rhn-applet is out of place on a fedora system?
> 
> Surely an applet which directly communicates with yum would be much better, use
> far less system resources, and need no further configuration.
> 
> Something that does a “yum check-update” at set time intervals and changes state
> accordingly would do the trick just fine. At least it would provide a reliable
> reading, which is all I want it for.
> 
> Are there any plans to remove rhn related stuff from fedora at some stage?
> Because now is as good a time as any and I’d be willing to help do it.

May not be the right place to discuss this but thats the plan for Fedora Core 5.
Replace RHN Applet and system-config-packages with a new system based on yum

http://www.fedoraproject.org/wiki/FC5Future


Comment 28 Srini 2005-07-17 00:42:48 EDT
According to
http://www.archivum.info/fedora-list@redhat.com/2005-06/msg04376.html this fix
is in rawhide already.  Any chances that we will get an FC4 update ?
Comment 29 Rahul Sundaram 2005-07-17 00:46:59 EDT
(In reply to comment #28)
> According to
> http://www.archivum.info/fedora-list@redhat.com/2005-06/msg04376.html this fix
> is in rawhide already.  Any chances that we will get an FC4 update ?

I was referring to a new program that provides the update functionality. It is
not a direct fix for this applet. Pup I heard does work in FC4
Comment 30 Mark Koljack 2005-07-17 03:39:51 EDT
I'm just reading this as a former Fedora Core 3 user and now a Fedora Core 4 
user.  We like the RHN applet because it tells us to update the system.  We 
don't care that it's a Red Hat applet.  It's really useful.  If you read posts 
on the forums, you will form the same impression.  As a user, I would love for 
you guys to be able to fix the applet.  Thank you. 
Comment 31 Pete Chown 2005-07-17 08:57:59 EDT
Personally I'm not bothered by the *mechanism* that the applet uses.  I'm only
bothered by what I see; and what I see at the moment is a big tick even when
security-relevant updates are required.  Over the lifetime of FC4, this is
likely to lead to lots of boxes being compromised.  Many admins will probably
not even realise that there are updates out there, which they should be
installing.  They will rely on the information they are given by the applet.

If the applet is to be replaced in FC5 then I do understand that it is annoying
to have to fix it.  However, not fixing it risks sending the message that Fedora
(and by extension, Red Hat) consider security to be a low priority.
Comment 32 Rahul Sundaram 2005-07-17 09:02:28 EDT
>I'm just reading this as a former Fedora Core 3 user and now a Fedora Core 4 
> user.  We like the RHN applet because it tells us to update the system.  We 
> don't care that it's a Red Hat applet.  It's really useful.

You will continue to get similar functionality. Its just the implementation that
is being changed to use yum 


(In reply to comment #31)
> Personally I'm not bothered by the *mechanism* that the applet uses.  I'm only
> bothered by what I see; and what I see at the moment is a big tick even when
> security-relevant updates are required.  Over the lifetime of FC4, this is
> likely to lead to lots of boxes being compromised.  Many admins will probably
> not even realise that there are updates out there, which they should be
> installing.  They will rely on the information they are given by the applet.
> 
> If the applet is to be replaced in FC5 then I do understand that it is annoying
> to have to fix it.  However, not fixing it risks sending the message that Fedora
> (and by extension, Red Hat) consider security to be a low priority.

I was only clarifying my earlier statement on the users list. It doesnt lower
the priority of this bug

Comment 33 Rahul Sundaram 2005-07-17 12:00:02 EDT

Escalating to security response team. Kindly look into this
Comment 34 Adrian Likins 2005-07-27 13:17:42 EDT
looking into a fix
Comment 35 darren.blaser 2005-08-23 20:11:27 EDT
I am rather amazed that this issue has not been addressed yet. I don't mean to
whine but it seems really strange that one of the very few applets that are used
universally by every single user in the default use senario is completely broken
and providing misleading (and potentially dangerous invalid security)
information to all users and no one cares enough to address it!?!? Sorry for the
rant I wish I had time to just provide a patch instead, but I've always been a
very strong RedHat and Fedora advocate and having the most basic (and the single
most visible) security feature available still being in a broken non working
state this long after the release of FC4 is very disheartening to me...
Comment 36 Rahul Sundaram 2005-08-23 20:24:52 EDT
I am not the developer or the maintainer of this package but I thought about the
security part of this and having a fix wouldnt resolve that problem. 

Lets suppose a patch was provided for this and an errata package released as an
update. The status of the RHN applet for the user would still show up that no
new packages are available as an update. The only for the users to fix any
potential security issues as a result of this is for them to run something like
"yum update" .An update to the RHN applet wouldnt change this factor. 

Comment 37 Brandon Amaro 2005-08-23 20:32:31 EDT
I totaly agree with you Darren.  It is shocking that nobody has addressed it. 
Its been 2 months and it is still not fixed.  It is also sad to know that when
it is fixed, people won't know unless they are subscribed to a mailing list of
something like that.  Never the less, a fix needs to be made.
Comment 38 Christopher Brown 2005-08-25 14:52:49 EDT
In response to Rahul's comments, doesn't yum run nightly by default? Therefore
it would catch the update, even if the host were only up by chance on the
occasion that the cron job ran. Of course, this removes the requirement to have
hosts that run 24/7 have a working applet however I feel to ignore this is
pretty bad form. I'm in agreement with many others - this really should be
fixed. Its not best when demonstrating Fedora to others to have to say "Oh, the
update thingy doesnt work".
Comment 39 Rahul Sundaram 2005-08-26 01:23:49 EDT
(In reply to comment #38)
> In response to Rahul's comments, doesn't yum run nightly by default? Therefore
> it would catch the update, even if the host were only up by chance on the
> occasion that the cron job ran. Of course, this removes the requirement to have
> hosts that run 24/7 have a working applet however I feel to ignore this is
> pretty bad form. I'm in agreement with many others - this really should be
> fixed. Its not best when demonstrating Fedora to others to have to say "Oh, the
> update thingy doesnt work".

Yum doesnt run nightly by default. You will have to enable this explicitly. So
fixing this bug and releasing an errata wouldnt by itself resolve any security
concerns with it. I am not in any way claiming that the bug should be ignored. 
Comment 40 Phil Barnes 2005-08-27 14:13:31 EDT
I believe that this system needs updating, running yum nightly is only practical
on servers which are switched on at night. A desktop is only on while its used
and the last thing I wany is for yum to update when I've switched it on to use.

At the moment I click the up2date icon when I think about it, maybe once a
fortnight. With FC3 I got rid of the Red icon on the day it appeared by running
it before I go to the pub or while I'm watching TV.

This bug really needs fixing.
Comment 41 Uwe Kubosch 2005-08-30 17:47:07 EDT
Please fix this bug.
Comment 42 Stefan Plewako 2005-09-05 11:12:57 EDT
Is there any chance to fix this before Core 4?
Comment 43 Christopher Brown 2005-09-05 18:02:05 EDT
Core 4 has already been released. Do you mean Core 5? Or perhaps Core 44? Hell,
if I was any kind of programmer I'd try and solve this one myself. The total
lack of action is starting to get a bit embarassing. Ho hum, I guess we will
have to wait until core 5....?
Comment 44 Brandon Amaro 2005-09-05 18:22:43 EDT
If you are worried about missing updates, I found in the Fedora Extras list an
RPM that installs updates when you turn your computer on.  It doesn't let you
choose what updates to install but that's better then missing updates...
Anyways, the RPM  is at
http://download.fedora.redhat.com/pub/fedora/linux/extras/4/i386/yum-updateonboot-0.2-2.fc4.noarch.rpm
. You will have to edit the services settings on your computer to get it to work
though...
Comment 45 Tom Chiverton 2005-09-06 04:07:59 EDT
> that's better then missing updates... 
But the lack of progress on this bug is still not good enough.  
 
I assume this bug is present in the pay-for version that RedHat sells too - 
I'd be *really* annoyed if so, and I'd paid for it... does the security team 
not think this is important ? 
Comment 46 Paul Howarth 2005-09-06 04:47:12 EDT
(In reply to comment #45)
> I assume this bug is present in the pay-for version that RedHat sells too - 
> I'd be *really* annoyed if so, and I'd paid for it... does the security team 
> not think this is important ? 

Red Hat Enterprise Linux doesn't currently support repomd metadata in
up2date/rhn, so the paying customers aren't seeing this issue yet.

Having looked a little at the code
(http://www.redhat.com/archives/fedora-list/2005-July/msg02190.html), I came to
the conclusion that work had only just started on adding repomd support and
there was a fair bit to do to get it working. Not being a python programmer
myself though, I'm not able to fix it myself.
Comment 47 Pete Chown 2005-09-06 05:07:58 EDT
Looking at this problem the other way round, do Fedora users really care about
RHN?  Speaking for myself I only care about yum.  The only reason I'd have
something to do with RHN is because the applet doesn't support yum yet.

If it's true that we don't care about RHN, the applet surely becomes much
simpler.  All it has to do is run "yum check-update" every few hours, and turn
red if yum reports available updates.
Comment 48 Kasper Dupont 2005-09-06 06:27:41 EDT
Is that "yum check-update" command supposed to work on all FC versions? Because
on a FC3 system where rhn-applet-tui reports 61 available updates I get the
following from yum:

yum check-update ; echo $?
Setting up Repos
Reading repository metadata in from local files
base      : ################################################## 1663/1663
updates   : ################################################## 447/447
0
Comment 49 Tom Chiverton 2005-09-06 06:42:34 EDT
Kasper: On FC4 check-update works for me fine:
# yum check-update ; echo $?
Setting up repositories
updates-released          100% |=========================|  951 B    00:00
.
.
.
perl-Compress-Zlib.i386                  1.37-1.fc4             updates-released
.
.
.
100 

Pete: I'm not a python programmer, but I agree - it looks easy enough to do. And
I suggest that Fedora users do not care about RHN, just that they have an
indication of if there are updates to install or not (without running yum update
by hand every few days).
Comment 50 Pete Chown 2005-09-06 06:57:20 EDT
If yum recognises check-update, I think it is expected to work.  I believe very
old versions of yum may not recognise the check-update command.  Unfortunately I
don't have an FC3 system to test on, but it certainly works with FC4.  Is it
possible that your /etc/sysconfig/rhn/sources file is out of step with
/etc/yum.conf?

This is actually very relevant to this bug.  If the chosen solution was to run
check-update every few hours, it would also make sure that the two configuration
files can't get out of step (since /etc/sysconfig/rhn/sources would cease to exist).
Comment 51 Paul Howarth 2005-09-06 07:16:26 EDT
(In reply to comment #50)
> If yum recognises check-update, I think it is expected to work.  I believe very
> old versions of yum may not recognise the check-update command.  Unfortunately I
> don't have an FC3 system to test on, but it certainly works with FC4.

check-update works in yum on all versions of Fedora.

> Is it possible that your /etc/sysconfig/rhn/sources file is out of step with
> /etc/yum.conf?

That's the most likely reason.

> This is actually very relevant to this bug.  If the chosen solution was to run
> check-update every few hours, it would also make sure that the two configuration
> files can't get out of step (since /etc/sysconfig/rhn/sources would cease to
exist).

This is how the applet (and up2date) are *supposed* to work in FC4 (in fact
up2date itself does actually work). The /etc/sysconfig/rhn/sources file contains
a single "repomd" entry meaning "use the yum repositories". up2date then imports
code from yum to handle those repositories. The /etc/sysconfig/rhn/sources file
can't be removed completely yet because up2date understands additional
repository formats (e.g. old-style yum, apt, RHN) that yum doesn't understand.
Comment 52 Kasper Dupont 2005-09-06 14:44:38 EDT
Turns out something was wrong with /etc/yum.conf on the system where I tested.
Now I tested on an FC3 and an FC4 system where nobody has been messing with
/etc/yum.conf I got the following results:

FC3:
yum check-update ; echo $?
Setting up Repos
Cannot access repository dir //var/cache/yum/base
1

FC4:
yum check-update ; echo $?
Setting up repositories
Cannot access repository dir //var/cache/yum/updates-released
1
Comment 53 Paul Howarth 2005-09-06 15:49:36 EDT
(In reply to comment #52)
> Turns out something was wrong with /etc/yum.conf on the system where I tested.
> Now I tested on an FC3 and an FC4 system where nobody has been messing with
> /etc/yum.conf I got the following results:
> 
> FC3:
> yum check-update ; echo $?
> Setting up Repos
> Cannot access repository dir //var/cache/yum/base
> 1
> 
> FC4:
> yum check-update ; echo $?
> Setting up repositories
> Cannot access repository dir //var/cache/yum/updates-released
> 1

You are running this as root, right?
Comment 54 Kasper Dupont 2005-09-07 00:12:17 EDT
Why should I be running it as root? rhn-applet-tui was always able to check for
updates without root permissions. It is important to know when updates are
available even if you rarely log in as root.
Comment 55 Paul Howarth 2005-09-07 01:57:32 EDT
(In reply to comment #54)
> Why should I be running it as root? rhn-applet-tui was always able to check for
> updates without root permissions. It is important to know when updates are
> available even if you rarely log in as root.

I agree but yum needs to run as root in order to cache the metadata it downloads
(containing details of the packages in each repo). And if there are updates
available, you'd need to be root to install them.
Comment 56 Kasper Dupont 2005-09-07 04:43:05 EDT
rhn-applet-tui can do this without root permissions, yum should be able to do
that as well. And there really is a need for this. But I guess that should be
opened as a seperate bug report against yum.
Comment 57 Tom Chiverton 2005-10-07 04:05:16 EDT
A work around would be to put your normal user in an sudoer group that can run  
yum.  
Comment 58 Kasper Dupont 2005-10-07 06:02:21 EDT
Using sudo is not really an option when I want any user to be able to verify if
there are updates to install. You might as well make yum suid root then. Does
people expect the applet to use sudo to call yum and check for updates that way?
Comment 59 Brandon Amaro 2005-10-07 12:35:53 EDT
My normal user is in an sudoer group and it still doesn't work.

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