Bug 1049989 - oscap-anaconda-addon: _fetch_http_data() - Don't raise FetchError in case SCAP data / content retrieval failed
Summary: oscap-anaconda-addon: _fetch_http_data() - Don't raise FetchError in case SCA...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: oscap-anaconda-addon
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vratislav Podzimek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-08 15:15 UTC by Jan Lieskovsky
Modified: 2014-01-23 11:08 UTC (History)
2 users (show)

Fixed In Version: oscap-anaconda-addon-0.4-1.fc20
Clone Of:
Environment:
Last Closed: 2014-01-23 11:08:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jan Lieskovsky 2014-01-08 15:15:59 UTC
Description of problem:
oscap-anaconda-addon:
  https://fedorahosted.org/oscap-anaconda-addon/

provides capability to specify SCAP content to be used for system installation configuration when performing the Fedora OS install.

After a customized Fedora compose / boot.iso is created, and that install image is used for system installation, oscap-anaconda-addon presents new SECURITY section.

After click on the section, display to retrieve desired SCAP content (RPM or datastream) is presented. After entering the SCAP content URI, and clicking 'Fetch' button, a

"An unknown error has occurred"

  error message dialog with FetchError exception details is presented (detailing further information why the fetch actually failed).

The proposal is to get rid of raising FetchError message completely in case remote SCAP data retrieval failed, display error label above the SCAP content URI, and return back to the content retrieval dialog.

Version-Release number of selected component (if applicable):
oscap-anaconda-addon-0.3-1.fc20

How reproducible:
Always

Steps to Reproduce:
1. Boot customized Fedora install image / boot.iso with oscap-anaconda-addon Anaconda addon included.
2. During installation click on the 'SECURITY' section.
3. Provide invalid / un-resolvable SCAP content URI

Actual results:
Python traceback (An unknown error has occured) dialog is displayed, and whole installation needs to be aborted and retried.

Expected results:
FetchError message / exception is not raised. When the SCAP content / data retrieval fails, particular exception message (reason of the failure) is displayed in the label above the SCAP content URI and whole installation process control is returned back to the function expecting user to provide URI for remote SCAP content.

Additional info:
Current implementation of (/usr/share/anaconda/addons/org_fedora_oscap/data_fetch.py):

       96 def _fetch_http_data(url, out_file, ca_certs=None):

looks like the following (problem irrelevant code parts skipped for brevity):

    140     try:
    141         with open(out_file, "w") as fobj:
    142             curl.setopt(pycurl.WRITEDATA, fobj)
    143             curl.perform()
    144     except pycurl.error as err:
    145         # first arg is the error code
    146         if err.args[0] == pycurl.E_SSL_CACERT:
    147             msg = "Failed to connect to server and validate its "\
    148                   "certificate: %s" % err
    149             raise CertificateValidationError(msg)
    150         else:
    151             msg = "Failed to fetch data: %s" % err
    152             raise FetchError(msg)

So current implementation calls pycurl.Curl.perform() method to obtain the data. In case pycurl.error occurred in the attempt to retrieve them, FetchError (with underlying exception message) is raised further to Anaconda.

The proposal is to get rid of raising FetchError completely:

    152             raise FetchError(msg)

and instead of it, in case some error occurred when trying to retrieve SCAP data, originally invisible label, placed above the SCAP data URI location field would be:
1) made visible,
2) filed with the error message (from traceback) itself, so user can correct reason of the failure (for messages like "Could not resolve host: my.host.name") and retry the retrieval.
3) the SCAP content retrieval process control would be moved back to the point where providing SCAP content URI is expected.

Advantage to the end user:
--------------------------
In case of above proposal being implemented, the user would not need to abort the whole Anaconda install (like it is the case currently), and could fix the reason (set up proper DNS resolving) and retry to obtain the remote SCAP data.

Comment 1 Vratislav Podzimek 2014-01-08 16:31:59 UTC
There already is a fix for this, but it needs a change in the anaconda installer's codebase which is pushed to master (Rawhide), but that didn't make it to F20's Anaconda.

Comment 2 Fedora Update System 2014-01-14 17:34:17 UTC
oscap-anaconda-addon-0.4-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/oscap-anaconda-addon-0.4-1.fc20

Comment 3 Fedora Update System 2014-01-15 06:01:53 UTC
Package oscap-anaconda-addon-0.4-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing oscap-anaconda-addon-0.4-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-0813/oscap-anaconda-addon-0.4-1.fc20
then log in and leave karma (feedback).

Comment 4 Fedora Update System 2014-01-23 11:08:44 UTC
oscap-anaconda-addon-0.4-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


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