Bug 1420439

Summary: Satellite does not push updated SCAP content on a policy
Product: Red Hat Satellite Reporter: Ryan Kimbrell <ryan.kimbrell>
Component: SCAP PluginAssignee: Ondřej Pražák <oprazak>
Status: CLOSED ERRATA QA Contact: Marek Hulan <mhulan>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.2.7CC: akarimi, bbuckingham, dcaplan, jcallaha, ktordeur, mhulan, nshaik, omaciel, oprazak, pmoravec, rbobek, sjagtap, sjr, szadok
Target Milestone: UnspecifiedKeywords: PrioBumpPM, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1482461 (view as bug list) Environment:
Last Closed: 2018-02-21 16:54:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1482461    

Description Ryan Kimbrell 2017-02-08 16:20:10 UTC
Description of problem: Updating SCAP content on an existing Compliance Policy does not result in synchronization of the new SCAP content on subsequent puppet runs. Content hosts continue to run openscap scans using the previous outdated SCAP content.


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


How reproducible: Always


Steps to Reproduce:
1. In the Satellite web UI, go to Hosts->Compliance->Policies
2. On an existing policy, click the drop-down arrow next to "Show Guide" and choose "Edit"
3. Click on the "SCAP Content" tab.
4. Use the drop-down in the SCAP Content field to choose different/new SCAP Content.
5. Click the "Submit" button.

Actual results:
Even after a puppet run, either waiting for the next run interval or manually running `puppet agent -t` on a host registered to Satellite, foreman_scap_client continues to scap using the old SCAP content.

Expected results:
foreman_scap_client should scan using the new/updated SCAP content.

Additional info:

Comment 1 Marek Hulan 2017-02-09 14:05:11 UTC
Thank you for the report with detailed reproducing steps. I believe this is covered by upstream issue http://projects.theforeman.org/issues/17464 so I'm linking it. It's not released yet but good thing is that the fix exists already. 

A quick workaround is to define a new policy and use that instead of the old one.

Comment 3 Marek Hulan 2017-02-09 14:19:11 UTC
*** Bug 1419860 has been marked as a duplicate of this bug. ***

Comment 4 Satellite Program 2017-02-12 09:01:31 UTC
Upstream bug assigned to oprazak

Comment 5 Satellite Program 2017-02-12 09:01:35 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/17464 has been resolved.

Comment 6 Sanket Jagtap 2017-02-20 06:06:53 UTC
just an update, While reproducing this bug with 6.2.8 snap 2 after performing above steps the error I got, 

[root@test-xyz ~]# foreman_scap_client 1
DEBUG: running: oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig-java-upstream --results-arf /tmp/d20170216-27115-19glfag/results.xml /var/lib/openscap/content/fe93f99c14251cc76e92b9da71c351c8ba45fbd3639a2cd55911ef6f7db1b650.xml
WARNING: Skipping http://www.redhat.com/security/data/oval/Red_Hat_Enterprise_Linux_7.xml file which is referenced from XCCDF content
Profile "xccdf_org.ssgproject.content_profile_stig-java-upstream" was not found. Get available profiles using:
$ oscap info "/var/lib/openscap/content/fe93f99c14251cc76e92b9da71c351c8ba45fbd3639a2cd55911ef6f7db1b650.xml"
Scan failed
This content points out to the remote resources. Use `--fetch-remote-resources' option to download them.

Comment 7 Pavel Moravec 2017-05-30 14:50:46 UTC
(In reply to Marek Hulan from comment #1)
> Thank you for the report with detailed reproducing steps. I believe this is
> covered by upstream issue http://projects.theforeman.org/issues/17464 so I'm
> linking it. It's not released yet but good thing is that the fix exists
> already. 
> 
> A quick workaround is to define a new policy and use that instead of the old
> one.

An alternative workaround is to delete the content on the client to let it force fetching a new one from the OpenScap server. I.e. if I know that the change is in:

13:
  :profile: ''
  :content_path: '/var/lib/openscap/content/96c2a9d5278d5da905221bbb2dc61d0ace7ee3d97f021fccac994d26296d986d.xml'
  # Download path
  # A path to download SCAP content from proxy
  :download_path: '/compliance/policies/13/content'

then I should delete the /var/lib/openscap/content/96c2a9d5278d5da905221bbb2dc61d0ace7ee3d97f021fccac994d26296d986d.xml file

Comment 11 Satellite Program 2018-02-21 16:54:17 UTC
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/RHSA-2018:0336