Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
As the first step of remote scan, system capabilities are queried via "oscap --v". This is kind of hackish, as it depends on oscap not having another long option starting with "v". I suggest to change it to "oscap -V".
Second issue is when machine does not have openscap-scanner package installed. In that case, query do not finish itself, and after user cancels it, error shows that remote machine [RHEL6] asked whether it should install the package.
Version-Release number of selected component (if applicable):
scap-workbench-1.1.2-1.el7
How reproducible:
reliably
Steps to Reproduce:
1. install scap-workbench
2. prepare RHEL6 machine without openscap installed
3. remote scan to the RHEL6 machine
Actual results:
1) remote machine queried by "oscap --v" command
2) query never finishes, and after cancel, error prints out:
Failed to query capabilities of oscap on local machine. Diagnostic info: Starting process 'Remote command 'oscap --v' on machine 'root.172.158'' Starting process 'Remote command 'oscap --v' on machine 'root.172.158'' Cancel was requested! Sending terminate signal to the process... stdout: =============================== Install package 'openscap-scanner' to provide command 'oscap'? [N/y] stderr: =============================== Command not found.
Expected results:
1) remote machine is queried by "oscap -V" command
2) in case oscap command is not present, no attempt to call it is performed
Additional info:
This is a serious issue that is quite common among users. SCAP Workbench should probably do something like `which oscap` before trying to run `oscap --v`.
I agree with the `-V` vs `--v` change, that is an easy fix and won't break compatibility with any version of OpenSCAP.
Comment 2Watson Yuuma Sato
2016-12-08 08:26:37 UTC
Verified fix on version:
[dahaic@localhost ~]$ rpm -qa openscap-scanner
openscap-scanner-1.2.14-2.el7.x86_64
Attempt to scan system without openscap-scanner now results in:
13:24:34 error Failed to locate oscap on remote machine. Please, check that openscap-scanner is installed on the remote machine.
When (fake) oscap binary errors and returns only parameters, output is:
13:33:09 error Failed to query capabilities of oscap on remote machine. Diagnostic info: Starting process 'Remote command 'oscap -V' on machine 'root.122.10'' Starting process 'Remote command 'oscap -V' on machine 'root.122.10'' stdout: =============================== -V stderr: ===============================
So version is queried correctly now (this error won't show, unless oscap utility is malformed on the target machine)
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-2017:2296