Hide Forgot
Description of problem: ABRT is not verifying release before reporting. There has been bug reported today with release - CentOS Linux release 6.0 Check case number 00506079 Actual results: ABRT bug reported from CentOS has been populated on GSS open queue. Expected results: Bugs reported from CentOS should have been filtered out from GSS queue Additional info: Customer used evaluation account to report the bug
I saw something similar: Reported from Fedora to Avalon and it marked the report as coming from RHEL 6 and successfully created the issue case. However, I am not sure this is ABRT bug, I always thought Avalon should deny reports from non-supported/non-RH product.
Hmm, that's bad not cool from them to do so. More steps are required here: 1. The product should be checked on the server side and not allow CentOS bugs to be filled 2. We can check the product and release and refuse to report if it's not supported product - the problem is, that both of these informations can be changed by either changing the code or simply by rewriting /etc/release, is there some way to detect if the system is genuine Red Hat?
How about # rpm -V -f /etc/redhat-release | grep 5
Can this help? # rpm -qi kernel Then check for signature,
I agree, ABRT shouldn't have to track what RHT-corp tracks as supported. In this situation, the customer used an entitlement which should allow support to create the case. The portal API should fix that specific problem soon: https://bugzilla.redhat.com/show_bug.cgi?id=637478 We can enforce additional checks on the actually reported product, but is there a consistent way we should do this? Parsing /etc/redhat-release, in comment #4, makes sense to me, then ABRT would need to make sure it handled the right error response.
(In reply to comment #5) > Can this help? > # rpm -qi kernel > Then check for signature, - checking the kernel signature seems good, but still not reliable, I bet you can run centos with rhel kernel rpm... To me this seems like something we can make 100% reliable, since the sstem is opensource everything can be faked, so this seems more like political question and maybe banning the accounts used to report centos bugs to our portal could be the way...
With BZ#637478 fixed, only customers with valid, current entitlement can create support cases. I don't think there should be any changes to ABRT to model the current support strategy, except to ensure that we always get some decent identifying information. Generally, we get this in the sos report, but in case the sos collection fails, maybe we can collect the contents of /etc/redhat-release and running kernel as part of the basic meta-data? Since we already get both in the current version of ABRT, my recommendation is that the ABRT side is CLOSED->CURRENTRELEASE, and then we can tweak the behavior of the internal toolchain...
(In reply to comment #13) > With BZ#637478 fixed, only customers with valid, current entitlement can create > support cases. > > I don't think there should be any changes to ABRT to model the current support > strategy, except to ensure that we always get some decent identifying > information. Generally, we get this in the sos report, but in case the sos > collection fails, maybe we can collect the contents of /etc/redhat-release and > running kernel as part of the basic meta-data? > - release is send as "os_release" - kernel version is in "kernel"