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: always 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: https://nvd.nist.gov/ncp/checklist/811 -> scap-security-guide-0.1.41-oval-510-nist.zip -> 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.
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
Fixed in upstream spacewalk git by commit 83c460b061589ef67c9a10b5dcc7374253ad9c8a 1688743 - don't mix scapActionDetail and xccdfTestResult ids
Backported to SATELLITE-5.8 as commit 1b836475a7935c52124323986c26a90904b73993 1688743 - don't mix scapActionDetail and xccdfTestResult ids
I have tested the basic scenario - schedule two separate OSCAP scans on two clients, let them run, check their results both in Audit tab and in History (of scheduled actions) tab. Both scenarios work now, even for the updated reproducer from comment #1. Problem is, the same issue appeared when scheduling OSCAP scan for multiple hosts using the System Manager. The symptoms are very similar - links to scan results are correct on the Audit tab, but if you go into History tab, you will get an "We're sorry, but the XCCDF scan could not be found." error on all systems included in the scan except one. It seems all hosts included in the scan get the same "&xid=XX" link to a scan report in the History tab, while the id is valid only for one host (probably the one that finished the scan first). This id is actually different for each host. FailedQA
Fixed in upstream spacewalk git by commit 0c353993bb0a6e98dc4ed77efe8065f689171f8c 1688743 - find proper result detail for a given server
Backported to SATELLITE-5.8 commit dbadfbb27f4b1acfa749ebbc43aff03d8e5bc571 1688743 - find proper result detail for a given server
Tested on spacewalk-java-2.5.14-131. As stated in the comment #5, the basic scenario works. Checking the results produced by OSCAP scans scheduled by the System Manager now works as well - logs are available for all hosts included in the scan. VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:1551
*** Bug 1686599 has been marked as a duplicate of this bug. ***