Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Following Anaconda traceback appears in the 'Configuring Addons' installation phase / stage using current Fedora SSG SCAP content: OSCAPaddonError: Content evaluation and remediation with the oscap tool failed: .. And see attached Anaconda traceback (notice the 'fpath' variable). Version-Release number of selected component (if applicable): oscap-anaconda-addon-0.3-1.fc20 How reproducible: Always Steps to Reproduce: 1. Use boot.iso from http://vpodzime.fedorapeople.org/oscap_ana_addon_boot.iso.xz or own generated Fedora install image supporting oscap-anaconda-addon 2. Start the installation 3. Click on the 'SECURITY' section, provide: http://fedorapeople.org/~jlieskov/ssg-fedora-xccdf-1-1.noarch.rpm as remote HTTP URI of SCAP content, that should be retrieved. 4. Select the profile, click Done (in SECURITY section) 5. Possibly configure other Anaconda sections (complete all the required fields) 6. Click 'Begin Installation' 7. Go make a tea and watch the installation to progress. 8. In the 'Configuring Addons' stage notice how following traceback is displayed. Actual results: Python traceback 'An unknown error has occurred' is displayed after performing the oscap remediation (in the 'Configuring Addons' stage) System is installed successfully. Can be rebooted, and remediation run manually after that (and it succeeds with the provided content). Expected results: No Anaconda traceback. Configuring Addons finishes successfully. System is remediated according to the provided content. Additional info: Maybe this is related with bug #1049989 , but since the error message is different from that one (notice the strange looking 'fpath' variable without heading '/' character), dedicated new bug for this case.
That exception is raised if the oscap tool exits with status different from 0. From the stdout of the run I cannot see any reason for it to do so. Will have a look at this issue tomorrow.
(In reply to Vratislav Podzimek from comment #2) > That exception is raised if the oscap tool exits with status different from > 0. From the stdout of the run I cannot see any reason for it to do so. Will > have a look at this issue tomorrow. Just out of curiosity, under which user account is the oscap evaluation / remediation performed under? The current Fedora SSG content already requires root privileges, otherwise the following rules: Title Virtual Console Root Logins Restricted Rule securetty_root_login_console_only Result error Title Serial Port Root Logins Restricted Rule restrict_serial_port_logins Result error .. Title SSH Root Login Disabled Rule sshd_disable_root_login Result error Title SSH Access via Empty Passwords Disabled Rule sshd_disable_empty_passwords Result error Title SSH Idle Timeout Interval Used Rule sshd_set_idle_timeout Result error Title SSH Client Alive Count Used Rule sshd_set_keepalive Result error will end up with error (exit code 2) due to missing privileges. That might be the reason why that traceback is shown (when oscap is run with root privileges the results are just one of pass / fail [but oscap exit code is still 2])
(In reply to Jan Lieskovsky from comment #3) > (In reply to Vratislav Podzimek from comment #2) > > That exception is raised if the oscap tool exits with status different from > > 0. From the stdout of the run I cannot see any reason for it to do so. Will > > have a look at this issue tomorrow. > > Just out of curiosity, under which user account is the oscap evaluation / > remediation performed under? It is run with root privileges. > will end up with error (exit code 2) due to missing privileges. That might > be the reason why that traceback is shown (when oscap is run with root > privileges the results are just one of pass / fail [but oscap exit code is > still 2]) Hmm, I'll have to make the exit code evaluation more granular then. Hope there are only few non-error exit codes. The addon needs to distinguish between failed run of the oscap tool (e.g. something crucial missing, wrong file path or something like that) and failed checks appearing in the run. Thanks for the additional info!
(In reply to Vratislav Podzimek from comment #4) > (In reply to Jan Lieskovsky from comment #3) > > (In reply to Vratislav Podzimek from comment #2) > > > That exception is raised if the oscap tool exits with status different from > > > 0. From the stdout of the run I cannot see any reason for it to do so. Will > > > have a look at this issue tomorrow. > > > > Just out of curiosity, under which user account is the oscap evaluation / > > remediation performed under? > It is run with root privileges. Ok, good. Then this shouldn't be a problem. > > > will end up with error (exit code 2) due to missing privileges. That might > > be the reason why that traceback is shown (when oscap is run with root > > privileges the results are just one of pass / fail [but oscap exit code is > > still 2]) > Hmm, I'll have to make the exit code evaluation more granular then. Hope > there are only few non-error exit codes. The addon needs to distinguish > between failed run of the oscap tool (e.g. something crucial missing, wrong > file path or something like that) and failed checks appearing in the run. AFAICT there are only three possible exit codes (0, 1, 2). From oscap manual page: EXIT STATUS Normally, the exit status is 0 when operation finished successfully and 1 otherwise. In cases when oscap performs evaluation of the system it may return 2 indicating success of the operation but incompliance of the assessed system. Based on the above the OAA should be able to determine which of the scenarios happened. > > Thanks for the additional info!
Exactly. Patch is in the world, ready to be pushed and appear in the next release.
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
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).
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.