Bug 1635364
| Summary: | Failed to upload to Foreman, saving in spool. Failed with: Net::ReadTimeout | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Neal Kim <nkim> |
| Component: | SCAP Plugin | Assignee: | satellite6-bugs <satellite6-bugs> |
| Status: | CLOSED ERRATA | QA Contact: | Sanket Jagtap <sjagtap> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.4 | CC: | janarula, lzap, marjones, mhulan, oprazak, rurena, satellite6-bugs, shisingh |
| Target Milestone: | 6.5.0 | Keywords: | Triaged |
| Target Release: | Unused | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | rubygem-smart_proxy_openscap-0.7.1 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-05-14 12:38:11 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: | |||
This can happen because uploading to Satellite succeeds but generating answer takes to long. Meanwhile smart proxy gives up on waiting. Could you check load of Satellite when this happens? We could probably increase timeout time on client side. the satellite server is only being used for this environment so it should have light load. some 15 nodes are using it as a repo and to do these scans. How would i go about increasing the timeout? Created redmine issue http://projects.theforeman.org/issues/25501 from this bug Build: Satellite 6.5.0 snap 15
With the attached scap file
hammer> scap-content list
---|--------------------------------
ID | TITLE
---|--------------------------------
5 | Redhat Custom
1 | Red Hat firefox default content
2 | Red Hat jre default content
3 | Red Hat rhel6 default content
4 | Red Hat rhel7 default content
6 | rhel7 custom
---|--------------------------------
hammer> scap-content info --id 5
Id: 5
Title: Redhat Custom
Created at: 2019-02-13 08:23:28 UTC
Original filename: com.redhat.rhsa-all.ds.xml
SCAP content profiles:
Locations:
Default Location
Organizations:
Default Organization
hammer> policy list
---|----------------|------------------------
ID | NAME | CREATED AT
---|----------------|------------------------
3 | custom | 2019-02-13 08:46:02 UTC
2 | rhel6_poilicy | 2019-02-10 10:29:17 UTC
1 | rhel_7_policy2 | 2019-02-10 10:27:45 UTC
---|----------------|------------------------
hammer> policy info --id 3
Id: 3
Name: custom
Created at: 2019-02-13 08:46:02 UTC
Period: monthly
Weekday:
Day of month: 5
Cron line:
SCAP content Id: 5
SCAP Content profile Id:
Tailoring file Id:
Tailoring file profile Id:
Organizations:
Default Organization
Hostgroups:
hammer> arf-report info --id 911
Id: 911
Reported at: 2019-02-13 09:35:56 UTC
Host name: joy-bordin.rhts.eng.bos.redhat.com
OpenSCAP proxy name: sgi-uv20-01.rhts.eng.bos.redhat.com
Policy name: rhel_7_policy2
Passed: 34
Failed: 31
Othered: 5
Host Id: 2
OpenSCAP proxy Id: 1
Policy Id: 1
Locations:
Default Location
Organizations:
Default Organization
Report was successfully generated and uploaded, no errors recorded in logs
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-2019:1222 I do not think we will be backporting this to 6.4 |
Description of problem: OpenSCAP ARF report upload results in a somewhat ambiguous ReadTimeout error: E, [2018-09-21T10:17:09.709192 ] ERROR -- : Failed to upload to Foreman, saving in spool. Failed with: Net::ReadTimeout I, [2018-09-21T10:17:09.728357 ] INFO -- : 192.168.0.1 - - [21/Sep/2018:10:17:09 -0700] "POST /compliance/arf/28 HTTP/1.1" 200 - 70.2510 2018-09-21T10:17:11 [I|app|19be2] Parameters: {"callback"=>{"task_id"=>"db96e59e-9c20-4b91-8d23-a2623584f4e0", "step_id"=>3}, "data"=>{"result"=>[{"output_type"=>"stdout", "output"=>"DEBUG: running: oscap xccdf eval --results-arf /tmp/d20180921-211543-45jrjv/results.xml /var/lib/openscap/content/bbf01ea10e2d1d325d2966e58ea13c4de3fad921e425cc376fbb5728433ce9fe.xml\r\n", "timestamp"=>1537550046.5883553}, {"output_type"=>"stdout", "output"=>"DEBUG: running: /usr/bin/bzip2 /tmp/d20180921-211543-45jrjv/results.xml\r\n", "timestamp"=>1537550140.9453838}, {"output_type"=>"stdout", "output"=>"Uploading results to https://satellite.example.com:9090/compliance/arf/28\r\nUpload failed: Net::ReadTimeout\r\n", "timestamp"=>1537550217.9129632}], "runner_id"=>"78bb1e6e-0106-4ec8-84d0-ef8149dd4b23", "exit_status"=>4}, "task"=>{}} The odd thing is that despite the errors, the ARF reports appear to have been successfully submitted. Version-Release number of selected component (if applicable): tfm-rubygem-foreman_openscap-0.10.2-1.el7sat.noarch rubygem-smart_proxy_openscap-0.6.10-2.el7sat.noarch rubygem-openscap-0.4.7-3.el7sat.noarch puppet-foreman_scap_client-0.3.16-3.el7sat.noarch How reproducible: Fairly often in the customer's environment. Unable to reproduce locally. Steps to Reproduce: 1. Upload the attached SCAP contents file 2. Configure OpenSCAP on Satellite 3. Run OpenSCAP scan Actual results: Upload failed: Net::ReadTimeout Expected results: No error. Additional info: