Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1688743 - OpenSCAP scan history item point to non-existent/wrong detailed result for the scan
Summary: OpenSCAP scan history item point to non-existent/wrong detailed result for th...
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: WebUI
Version: 580
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Michael Mráka
QA Contact: Red Hat Satellite QA List
Depends On:
TreeView+ depends on / blocked
Reported: 2019-03-14 10:58 UTC by Radovan Drazny
Modified: 2019-03-28 13:52 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Target Upstream Version:

Attachments (Terms of Use)

Description Radovan Drazny 2019-03-14 10:58:24 UTC
Description of problem:
When checking OpenSCAP scan item in the schedule history for a system, its link to detailed results points to a non-existent (or possibly wrong) data.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Have two RHEL7 clients registered to a Satellite server and enable all remote action on it:
    # rhn-actions-control --enable-all
2. Install client OpenSCAP tools on clients:
    # rpm -q spacewalk-oscap
3. Get yourself some rules definitions:
       -> ssg-rhel7-ds.xml
   and place it on clients
4. Schedule multiple (at least two, better more) OpenSCAP scans on both clients, using the rules defenitions from the step 3 and using profile name xccdf_org.ssgproject.content_profile_standard.
5. When all scans are finished, go to <System Details> -> Events -> History page, and check there is a list of "OpenSCAP xccdf scanning scheduled by admin". 
6. Open one of the items (newer is better, oldest one usually doesn't show the issue, but newer ones do). 
7. There is a link "View detailed results". Try to open it. 

Actual results:
There is an error page "We're sorry, but the XCCDF scan could not be found."

Expected results:
The XCCDF scan results page is opened.

Additional info:
It is possible the issue can be reproduced with only one registered system.
The links to detailed results in the systems actions history seem to get much higher IDs than they should. For example correct xid's for one of my systems were 9, 11, 13 and 15 (correctly present in <System Details page> -> Audit -> List Scans). Xid's present in corresponding items in Events -> History were 38,39,40 and 41. It is virtually guaranteed that on a more busy system with regular OpenSCAP scanning, after some time older history items start to point to newer (and wrong) results.

Comment 1 Michael Mráka 2019-03-28 13:49:09 UTC
Reproducer update:
4. schedule some tests on both hosts
5. schedule tests which will fail, e.g. use /noteexist as a path to xccdf file.
6. schedule working tests on both hosts again
7. go to  <System Details> -> Audit -> List Scans and notice test xids (when you hover over the links with test names)
8. go to <System Details> -> Events -> History page
9. open the OpenSCAP event details, check test xids whe you hover over "View detailed results"
10. (try to) open "View detailed results" link

Comment 2 Michael Mráka 2019-03-28 13:49:56 UTC
Fixed in upstream spacewalk git by
commit 83c460b061589ef67c9a10b5dcc7374253ad9c8a
    1688743 - don't mix scapActionDetail and xccdfTestResult ids

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