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