Bug 1609009
| Summary: | oscap reports not showing in Satellite when using LB capsules setup | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | sthirugn <sthirugn> |
| Component: | SCAP Plugin | Assignee: | Ondřej Pražák <oprazak> |
| Status: | CLOSED ERRATA | QA Contact: | sthirugn <sthirugn> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.3.1 | CC: | egolov, jhutar, mhulan, oprazak, sthirugn, zhunting |
| Target Milestone: | 6.4.0 | Keywords: | Triaged |
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | tfm-rubygem-foreman_openscap-0.10.3-1,foreman-installer-1.18.0.2-1,rubygem-smart_proxy_openscap-0.6.11-1 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-16 19:09:35 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: | |||
|
Description
sthirugn@redhat.com
2018-07-26 17:28:49 UTC
Error seen in production.log:
2018-07-26 17:29:35 d5ee8eea [app] [I] Started POST "/api/v2/compliance/arf_reports/da83e819-1418-4f60-a785-bbdc7a43b362/1/1532624714" for 192.168.121.94 at 2018-07-26 17:29:35 +0000
2018-07-26 17:29:35 d5ee8eea [app] [I] Processing by Api::V2::Compliance::ArfReportsController#create as HTML
2018-07-26 17:29:35 d5ee8eea [app] [I] Parameters: {"logs"=>[], "digest"=>"160ddb2889af6c10ad0720e4ecbc6094d691b4dd51cf148faf24d56c72935038", "metrics"=>{"passed"=>0, "failed"=>0, "othered"=>0}, "apiv"=>"v2", "cname"=>"da83e819-1418-4f60-a785-bbdc7a43b362", "policy_id"=>"1", "date"=>"1532624714", "arf_report"=>{"logs"=>[], "digest"=>"160ddb2889af6c10ad0720e4ecbc6094d691b4dd51cf148faf24d56c72935038", "metrics"=>{"passed"=>0, "failed"=>0, "othered"=>0}}}
2018-07-26 17:29:35 d5ee8eea [app] [I] Current user: foreman_api_admin (administrator)
2018-07-26 17:29:35 d5ee8eea [app] [E] Failed to upload Arf Report, no OpenSCAP Capsule set for host client01.satellite6.example.com
2018-07-26 17:29:35 d5ee8eea [app] [I] Completed 422 Unprocessable Entity in 31ms (Views: 0.3ms | ActiveRecord: 4.4ms)
The error is gone and the report started showing up when I associated a random capsule by editing the Host -> OpenSCAP Capsule. So, perhaps for the LB capsules setup: - The hostgroup (or the host) must be associated to one of the random capsules although the clients don't know about specific capsules they are attached to because they register using Load Balanced capsule FQDN. - foreman_scap_client overridden as shown in the description of this bug. If I do the above, the puppet class parameters of foreman_scap_client is modified automatically by Satellite as follows: For server: a new `Specify matcher` item is created in Smart Class Parameter with the following rule: fqdn = client01.satellite6.example.com value = capsule01.satellite6.example.com (random capsule specified by me in the Hostgroup) Due to the above automatically created rule, the LB capsule name which I overrode in the puppet class as mentioned in the bug description is not taken into account. Only workaround I see is: - Register the client with no OpenSCAP Capsule specified in Hostgroup. - Then edit the host to select a random capsule in OpenSCAP Capsule dropdown. Created redmine issue http://projects.theforeman.org/issues/24472 from this bug We do not allow reports to be created for hosts without openscap capsule because it was previously causing problems (see #1334035). There is one possible issue with the workaround. The report xml files are stored on the capsule. Assigning a random capsule may lead to users not being able to view and download the 'full report' as generated by openscap because it is stored on a different capsule than the random one that is assigned. Would it be feasible to use a NFS for load balanced capsules? The problem with report files might be solved this way. The capsules store the files in location specified in /etc/foreman-proxy/setting.d/openscap.yml, it defaults to /var/lib/foreman-proxy/openscap. (In reply to Ondřej Pražák from comment #6) > Would it be feasible to use a NFS for load balanced capsules? > > The problem with report files might be solved this way. The capsules store > the files in location specified in > /etc/foreman-proxy/setting.d/openscap.yml, it defaults to > /var/lib/foreman-proxy/openscap. Can you explain it further? You mean using an NFS shared storage for /var/lib/foreman-proxy/openscap so all capsules point to the same folder? Yes, exactly. That way it does not matter which capsule is asked for the xml file as the capsules access the same shared folder with all the files. Upstream bug assigned to oprazak Upstream bug assigned to oprazak separate fix in foreman_openscap and smart_proxy_openscap is needed Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/24504 has been resolved. This failed for me in 6.4 Snap 23. I get the same error as mentioned in Comment 1. Verified in Satellite 6.4 Snap 25. I followed the exact same steps mentioned in the bug description, now the openscap reports uploaded without errors. # rpm -qa | grep scap perl-Pod-Escapes-1.04-292.el7.noarch puppet-foreman_scap_client-0.3.16-3.el7sat.noarch rubygem-smart_proxy_openscap-0.6.11-1.el7sat.noarch scap-security-guide-0.1.36-9.el7_5.noarch tfm-rubygem-foreman_openscap-0.10.3-1.el7sat.noarch tfm-rubygem-hammer_cli_foreman_openscap-0.1.6-1.el7sat.noarch openscap-1.2.16-8.el7_5.x86_64 openscap-scanner-1.2.16-8.el7_5.x86_64 rubygem-openscap-0.4.7-3.el7sat.noarch # rpm -q satellite satellite-6.4.0-15.el7sat.noarch 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:2927 |