Description of problem: It seems like abrt has taken over the role of the old kerneloops reporter? Kernel oopses are not visible in abrt-gui for ordinary users, so there is no longer a simple way to report oopses. That is a regression. There entries in /var/log/messages gives no hint that the gui tool should be run as root(!): Oct 11 23:31:07 localhost abrt: Kerneloops: Reported 1 kernel oopses to Abrt Oct 11 23:31:07 localhost abrtd: Directory 'kerneloops-1255296667-1' creation detected I assume that polkit should allow local users to report oopses (and crashes in daemons etc). Version-Release number of selected component (if applicable): abrt-0.0.9-2.fc12.i686
Yeah. It used to be easy to configure kerneloopses to automatically report without any interaction from the user. Is this possible anymore?
+1 Not obvious at all that you need to run abrt-gui as root to see some of the problems.
*** Bug 525868 has been marked as a duplicate of this bug. ***
Whoa. It doesn't even report them automatically? Is this true?
FWIW, abrt-gui is very broken when run as root. I'm unable to report any of the crashes I see when I run it as root - none of which I even knew about since they were hidden from the normal user view...
It is very unfortunate this reporting was broken before the beta, and I believe that if it is not restored soonish we'll pay the price in kernel stability at release time This could qualify as release blocker IMHO
I have been testing/beating/bugreporting a lot on abrt. It is a young project and has the potential to become a good and central hub in Fedora. But I think it is fair to say that it just isn't production quality yet. It is a fine and usable alpha release. It is not just a single bug; abrt is lacking in many areas, both regarding usability, functionality and stability. It obviously haven't been widely used, loved and polished yet. It is definitely not as mature as the old kerneloops reporter and similar tools like bugbuddy and the selinux reporter and similar tools used by other distributions. I don't think abrt is ready for a role where it _can_ be a release blocker. It should not be the default kerneloops reporter yet, and it probably shouldn't be installed by default yet.
(In reply to comment #7) > > I don't think abrt is ready for a role where it _can_ be a release blocker. It > should not be the default kerneloops reporter yet, and it probably shouldn't be > installed by default yet. If people get a bad impression from abrt now, it will be hard to rebuild its reputation later. And it would be a step back to have abrt replace the kerneloops daemon before it has replicated all of its functionality and configurability. I think that abrt has a lot of potential, but it should really wait until Fedora 13.
It's not that big deal guys, we can easily remove the kerneloops plugin from abrt and use the old kerneloops in F12 and let abrt handle only the python and C/C++ stuff. What do you think? Jirka
(In reply to comment #9) > It's not that big deal guys, we can easily remove the kerneloops plugin from > abrt and use the old kerneloops in F12 and let abrt handle only the python and > C/C++ stuff. What do you think? That would solve the current bug, so I think it's a first step. However, it wouldn't address any of the other UI and stability issues. I'm sure these will get fixed, and abrt will be great, but I'm skeptical that this will happen before the Fedora 12 release.
The priority is to restore previously working functionality Fedora depended on (ie kerneloops). I don't think it's too bad if abrt is a little raw for other stuff we had no tool for before
+1 ... in F12, use kerneloops for kernel problems but leave abrt in and installed by default. I believe that some thought should be given to what functionality is missing and/or does not work right and then prioritize the problems ... Yes, some things may be easy to fix but does the problem matter much. On the other hand, some problems may be really hard to fix (require lots of effort) but be really important. While abrt can currently handle user-mode application failures, there are problems with things which are root mode such as the kernel (but not just the kernel) ... e.g., I am having a problem with the plymouth daemon.
I already fixed some bugs related to reporting failures from under root and we're going to release and updated version which should also allow non-root users to see and report kerneloopses (and also remove the oops plugin from abrt default installation). As for other ideas and improvements please use crash-catcher.org so other people interested in ABRT will notice it. Thank you, Jirka
Is there anything like "allow-submit = yes" (a configuration option in /etc/kerneloops.conf)? Setting this allows me to send kerneloops reports without any interaction from the users. I would hate to have to run a GUI tool as root on each of 50 machines just to submit reports, not to mention that many machines don't even have "users". Thanks.
In the latest git version there is no need to run the GUI as root to see the oopses, but even having to run the gui is not a solution for a server. That's why we have abrt-cli, which can be used in scripts and you can use cron to make abrt report new oopses when you want. I don't like the idea of reporting it automatically when it happens, as the computer might be loaded with some other work, so the solution with cron seems better to me. Or if you don't like the cli, you can write your own script talking to abrt daemon over dbus which will suit your needs. Jirka
Jirka, You are free to implement it however you want, but it must work by default with no GUI/CLI or any other user intervention. If you think a cron is the best solution, ship the cron file in your package and make sure it works for selinux. The previous kerneloopser worked fine; it would be nice if abrt allowed more flexibility, but if abrt means something that just worked is now unreliable and requiring manual management, it is a regression.
I agree it's a regression, that's why I removed the kerneloops plugin from the default ABRT installation, comment #15 is just hint or workaround how to make abrt work as old kerneloops if someone desperately wants to use ABRT instead of kerneloops. Jirka
I just installed a fresh Rawhide machine (with abrt abrt-0.0.10-1.fc12.x86_64), but the abrt Kerneloops plugins were still loaded, and there is no kerneloops package available for installation. Comment #17 seemed to say that the abrt kerneloops plugin was being removed and the kerneloops package was being reintroduced. Is that not the case?
kerneloops has been completely removed from F-12 and is marked as a dead package in devel.
Ouch. I hope no one needs kerneloops reports. :(
Jiri, I can't believe you switched off kerneloops plugin... Is it so difficult to introduce the automagically and blindly report the kernel oopses to kerneloops.org? afaik, this is the field of abrt, to make this happen, not the reporting plugin itself... it's a matter of configuration of the plugin, right? /me hopes to see plugin enabled and 'report automatically' feature as soon as possible. :)
Anton, I did this as it was the fastest solution which we can provide and we needed to fix this before F12 RC. We'll fix this ASAP, but we couldn't afford to push unstable daemon+plugins to F12.
But if the old kerneloops are not in F12, I'm going to re-enable it in ABRT, as the only feature missing is automatic reporting of oopses (yes, the non-root users can report the oopses now) and the automatic reporting will be the part of next update (in a week). Jirka
Re comment #21: For privacy reasoons it is not acceptable that kerneloopses are reported silently. A sufficiently authorized user must authorize it - and that user can then authorize abrt to report it silently. I think it would be nice if abrt used PolicyKit for such policy handling. (There will also be a need for reporting oopses from other system processes and daemons. Perhaps abrt-gui should notify un-authorized users that "something which might be interesting" can be seen, but only allow the user to see it after sufficiently authentication.) (For privacy reasons it is also very important that submitters can review _exactly_ what is reported so they can make sure that nothing confidential is submitted.)
(In reply to comment #24) > Re comment #21: > For privacy reasoons it is not acceptable that kerneloopses are reported > silently. What kind of confidential/private information is going to be in a /kernel oops/? Is the type of video card one uses considered "confidential"?
Re comment 25: I don't know how much a kerneloops can reveal, but I don't think that matters. Users should be able to trust that a Fedora system _never_ calls home silently. Fedora should not decide if users should trust that kerneloops doesn't reveal IP addresses. Some users might have a local policy that _nothing_ may be leaked. Some examples could be MS test labs, NVidia next-generation driver development department, NSA, google. (AFAIK yum repos and ntp servers are the most obvious exceptions to this in Fedora, and AFAIK they take care to reveal as little as possible to the server) (Obviously this is _my_ opinion. Others with authority might have a different opinion.)
Mads: you are mixing two things - the accessibility of OOPS message and automatic sending of that information. The former is not going to be affected by ABRT's existence (you can see OOPS message in dmesg as well as in abrt-gui), the letter is not implemented yet (and will auto-send OOPS only on user's demand).
Re Comment #27: I might have misunderstood it, but in comment #24 I was responding to comment #21 which AFAICS mentioned "blindly report" and "report automatically" as a solution. If that was said under the assumption that an authorized user had told it so then we all agree ;-)
(In reply to comment #23) > But if the old kerneloops are not in F12, I'm going to re-enable it in ABRT, as > the only feature missing is automatic reporting of oopses (yes, the non-root > users can report the oopses now) and the automatic reporting will be the part > of next update (in a week). > > Jirka In abrt-0.0.10-1.fc12.x86_64, I can't see oopses as non-root (and I can't report them as root from within my non-root session).
It will be in new release. Coming soon.
(In reply to comment #30) > It will be in new release. Coming soon. Okay. Thanks!
#29 Should be fixed in abrt 0.0.11, you can find the build in koji, but it should hit the rpeository soon.
1.0.0 F12 in koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=142493
Yes, but it is my experience that sometimes I can see oopses as an ordinary user, but not always. How is it supposed to work? Who can see what when and how is it controlled? And still I see: https://fedorahosted.org/abrt/ticket/102 - it catches something which definitely isn't an oops. Is that what it is uploading? https://fedorahosted.org/abrt/ticket/96 - there is no way (AFAICS) to find out what has been uploaded.
(In reply to comment #34) > Yes, but it is my experience that sometimes I can see oopses as an ordinary > user, but not always. How is it supposed to work? Who can see what when and how > is it controlled? It is controlled in /etc/abrt/plugins/Kerneloops.conf with InformAllUsers option. In default installation it is set to InformAllUsers = yes. > And still I see: > > https://fedorahosted.org/abrt/ticket/102 - it catches something which > definitely isn't an oops. Is that what it is uploading? This is fixed in 1.0.0 > https://fedorahosted.org/abrt/ticket/96 - there is no way (AFAICS) to find out > what has been uploaded. Will look into this one.
> It is controlled in /etc/abrt/plugins/Kerneloops.conf with InformAllUsers > option. > In default installation it is set to InformAllUsers = yes. And default option is also AutoReportUIDs = root that means kerneloops is automatically reported.
Re #36: Nikola, what do "automatically reported" mean? Where are these options documented?
(In reply to comment #37) > Re #36: > > Nikola, what do "automatically reported" mean? > When kerneloops is detected in /var/log/messages and in kerneloops.conf is set option AutoReportUIDs = root then we will send report to kerneloops.org without any user action > Where are these options documented? For now we have kerneloops as plugin, but we have a plan to make kerneloops as daemon. For now, nowhere. Thx for info I will add this option into documentation.
I should perhaps wait for the explanation in the upcoming documentation of these options, but: As I understand it from what you are saying here then I don't think AutoReportUIDs=root is an acceptable default. But I don't understand why "UID" and "root" is used for something that sounds like a boolean. The name "InformAllUsers" also confuses me. I am looking forward to the description in the documentation.
I propose the following default Kerneloops.conf: # Do we want kernel oopses to be visible to any user? # Set to "yes" for compatibility with kerneloops.org tool. InformAllUsers = yes # Automatically perform reporting. # With default abrt.conf, it invokes KerneloopsReporter # and thus reports oops to kerneloops.org. # ("root" because all oopses are filed by abrt with user "root") AutoReportUIDs = root # Kerneloops Scanner configuration ################################## SysLogFile = /var/log/messages # KerneloopsReporter configuration ################################## SubmitURL = http://submit.kerneloops.org/submitoops.php
Is "visible" and "inform" only about showing kerneloopses? Or is it also about being able to report them? IMHO it looks like AutoReportUIDs solves a different problem and isn't a good solution to this problem. But this all means that kerneloopses by default are reported silently to a non-Fedora site and we can't tell where the user can see the report? IMHO that isn't good enough. To rephrase my understanding of the original problem: By default ordinary users should be notified that there is a oops, but only root should be able to see and report it, and reporting must be explicitly approved - exactly like package updates are handled. I suggest something like: # Notify all users when a kerneloops is detected and allow them # to see and report it if they can provide root credentials? NotifyUsers = yes # Report kerneloopses automatically without explicit approval? AutoReport = no # The KerneloopsReporter monitors this file for new kerneloopses # See the abrt-KerneloopsScanner man page. SysLogFile = /var/log/messages # KerneloopsReporter reports kerneloopses at this URL # See the abrt-KerneloopsReporter man page. SubmitURL = http://submit.kerneloops.org/submitoops.php
(In reply to comment #41) > Is "visible" and "inform" only about showing kerneloopses? Or is it also about > being able to report them? > - if user sees it, he can report it > IMHO it looks like AutoReportUIDs solves a different problem and isn't a good > solution to this problem. > > But this all means that kerneloopses by default are reported silently to a > non-Fedora site and we can't tell where the user can see the report? IMHO that > isn't good enough. - this is exactly the same behavior as the old kerneloops > To rephrase my understanding of the original problem: By > default ordinary users should be notified that there is a oops, but only root > should be able to see and report it, and reporting must be explicitly approved > - exactly like package updates are handled. > - but we're trying to act exactly as the old kerneloops as this BZ requires
>> But this all means that kerneloopses by default are reported silently to a >> non-Fedora site and we can't tell where the user can see the report? IMHO that >> isn't good enough. > > - this is exactly the same behavior as the old kerneloops http://git.infradead.org/kerneloops.git/blob/HEAD:/kerneloops.conf says: Default is "ask" which uses a UI application t ask the user for permission So no, silent reporting by default is not the same behavior as the old kerneloops, AFAICS. The old kerneloops did however notificaty users that "something happended", and it trusted some users to report it. >> To rephrase my understanding of the original problem: By >> default ordinary users should be notified that there is a oops, but only root >> should be able to see and report it, and reporting must be explicitly approved >> - exactly like package updates are handled. > > - but we're trying to act exactly as the old kerneloops as this BZ requires Ok. This issue is a request for removing a regression. That shouldn't prevent you from solving the minor problems of the old kerneloops. PackageKit is a very good model for how it can be done even better than the kerneloops. There are good reasons why PackageKit does what it does, and these reasons could also apply to abrt.
The "Privilege escalation policy" discussed on http://lists.fedoraproject.org/pipermail/test/2010-January/088177.html seems relevant for what we are discussing here. I will Cc Adam Williamson - I hope that is Ok. The policy draft mentions * Read from system logs containing any information about user activities I think that covers what abrt does - including kerneloops and crashes in system daemons. I think that something like "change settings for automatic reporting of potentially privacy-sensitive information" should be added. (That might however be a overly complex wording because all automatic reporting is potentially privacy critical ...)
as the privilege escalation policy draft is currently worded, yes, it would be wrong for abrt to extract information from logs the unprivileged user is intentionally denied access to (such as /var/log/messages) and let the user see/submit them without authentication. Of course, the draft is very very much a draft at present, has not been accepted at any official level, and has absolutely no force.
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.