Bug 1662142 - removing a content host should purge away SCAP config from the host
Summary: removing a content host should purge away SCAP config from the host
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: SCAP Plugin
Version: 6.4
Hardware: x86_64
OS: Linux
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Sanket Jagtap
: 1699260 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2018-12-26 11:53 UTC by Pavel Moravec
Modified: 2020-02-03 16:30 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-02-03 16:30:08 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 25763 0 Normal Needs design Removing a content host should purge away SCAP config from the host 2020-04-01 15:48:14 UTC

Description Pavel Moravec 2018-12-26 11:53:13 UTC
Description of problem:
Assume a Content Host with some OpenSCAP policy applied. That config (what policy to check against) is puppet based. Removing the policy means puppet will remove the config from the system, such that it wont further report any compliance to Satellite. So far so good.

Unregistering a Content Host (from the host side) or removing the Content Host (from Satellite side) currently makes no change to the SCAP config on the client. Which means, the system - after its removal from Satellite - is still reporting to Satellite. Such reports are denied with 404 Host unknown error, causing the reports are buffered in foreman-proxy spool for re-send (currently due to bz1651143, they sit there forever). This behaviour is unwanted and redundant.

Any decomissioning of a system should be preceded by (an attempt of) removal SCAP config - one possible scenario is 1) remove SCAP policy from the system, 2) run puppet against it (to purge the config), 3) remove the system snippets from Satellite. But that is just an idea / proposal, of course.

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

How reproducible:
100% (I guess)

Steps to Reproduce:
1. Assign some OpenSCAP policy to a Content Host
2. Wait for some OpenSCAP reports from the Content Host
3. Unregister the Content Host by either way (sub-man unregister or via Satellite). Let the system running.
4. Monitor if the system will send some more SCAP reports.

Actual results:
4. SCAP reports are still being sent.

Expected results:
4. No or at most one SCAP report is sent from the system.

Additional info:

Comment 3 Ondřej Pražák 2019-01-02 09:03:37 UTC
Created redmine issue https://projects.theforeman.org/issues/25763 from this bug

Comment 4 Brad Buckingham 2019-04-12 15:07:35 UTC
*** Bug 1699260 has been marked as a duplicate of this bug. ***

Comment 5 Bryan Kearney 2020-01-15 21:00:56 UTC
The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

Comment 6 Bryan Kearney 2020-02-03 16:30:08 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.

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