Bug 160873

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.)

Same thing here with the GUI RHN icon.

Same here both on i386 and x86_64 FWIM

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?

I think you should change the priotity to high as well as that this is a realy
big problem.

This one might be a duplicate of
#160921 - Redhat Network Alert Icon falsely shows no available updates?

*** Bug 160921 has been marked as a duplicate of this bug. ***

(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?

*** Bug 162036 has been marked as a duplicate of this bug. ***

Re comment #8:  Forget getting this bug fixed, I'd just like to see some sign
that someone has looked at it!

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.

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.)

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.

(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.

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.

There is one problem with that solution.  That doesn't solve it not being able
to handle repomd repos.

Re: Comment #13 - The updates directories have no header info, so this will
break up2date and still not alert you when there are updates.

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.

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.

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. 

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.

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.

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

I understand, Mike, thanks anyway.

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.

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.

(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

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 ?

(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

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. 

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'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

Escalating to security response team. Kindly look into this

looking into a fix

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...

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. 

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.

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".

(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. 

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.

Please fix this bug.

Is there any chance to fix this before Core 4?

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....?

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...

> 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 ? 

(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.

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.

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

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).

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).

(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.

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

(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?

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.

(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.

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.

A work around would be to put your normal user in an sudoer group that can run  
yum.  

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?

My normal user is in an sudoer group and it still doesn't work.