Description of problem
======================

Errors from module that must have been printed to stderr are
found in stdout XML node.

I have only found this by accident with `mysql_configuration_changes`
where the errors come from syntax errors and file-not-found errors(!),
but since there's no redirection, I'm assuming the output is merged on
PA level.

Relevant XML node from mentioned module looks like this:

    <ns0:rule-result idref="xccdf_preupg_rule_databases_mysql_configuration_changes_configuration" time="2016-02-17T18:39:28" weight="1.000000">
          <ns0:result>needs_action</ns0:result>
          <ns0:check system="http://open-scap.org/page/SCE">
            <ns0:check-import import-name="stdout">/usr/share/preupgrade/common.sh: line 226: syntax error near unexpected token `}'
    /usr/share/preupgrade/common.sh: line 226: `}'
    /root/preupgrade/RHEL6_7/databases/mysql/configuration_changes/configuration.sh: line 24: check_rpm_to: command not found
    /root/preupgrade/RHEL6_7/databases/mysql/configuration_changes/configuration.sh: line 29: check_root: command not found
    /root/preupgrade/RHEL6_7/databases/mysql/configuration_changes/configuration.sh: line 31: ../mysql-common.sh: No such file or directory
    /root/preupgrade/RHEL6_7/databases/mysql/configuration_changes/configuration.sh: line 57: backup_config: command not found
    INPLACERISK: MEDIUM: /etc/my.cnf: option 'plugin-load=innodb=' is not supported
    sed: can't read /root/preupgrade//etc/my.cnf: No such file or directory
    INPLACERISK: HIGH: /etc/my.cnf: option 'innodb_file_io_threads' is not supported
    sed: can't read /root/preupgrade//etc/my.cnf: No such file or directory
    INPLACERISK: HIGH: /etc/my.cnf: option 'language' is deprecated
    sed: can't read /root/preupgrade//etc/my.cnf: No such file or directory
    /root/preupgrade/RHEL6_7/databases/mysql/configuration_changes/configuration.sh: line 103: : No such file or directory
    INPLACERISK: HIGH: /etc/my.cnf: option 'log-bin-trust-routine-creators' was removed in MariaDB 5.5
    sed: can't read /root/preupgrade//etc/my.cnf: No such file or directory
    /root/preupgrade/RHEL6_7/databases/mysql/configuration_changes/configuration.sh: line 103: : No such file or directory
    INPLACERISK: HIGH: /etc/my.cnf: option 'table_lock_wait_timeout' was removed in MariaDB 5.5
    sed: can't read /root/preupgrade//etc/my.cnf: No such file or directory

    The files mentioned above are backups of your original configuration files.
    After the upgrade you must manually replace the contents of the default
    MariaDB 5.5 configuration (as is appropriate to your environment), with the
    information provided about replaced or deprecated options listed in the
    backups.  You must restart MariaDB for these changes to take effect.

    </ns0:check-import>
            <ns0:check-import import-name="stderr">
                </ns0:check-import>
            <ns0:check-export export-name="RESULT_PART" value-id="xccdf_preupg_value_databases_mysql_configuration_changes_configuration_state_result_part" />
            <ns0:check-export export-name="CURRENT_DIRECTORY" value-id="xccdf_preupg_value_databases_mysql_configuration_changes_configuration_state_current_directory" />
            <ns0:check-export export-name="SOLUTION_FILE" value-id="xccdf_preupg_value_databases_mysql_configuration_changes_configuration_state_solution_file" />
            <ns0:check-export export-name="REPORT_DIR" value-id="xccdf_preupg_value_report_dir" />
            <ns0:check-export export-name="UPGRADE" value-id="xccdf_preupg_value_upgrade" />
            <ns0:check-export export-name="MIGRATE" value-id="xccdf_preupg_value_migrate" />
            <ns0:check-export export-name="DIST_NATIVE" value-id="xccdf_preupg_value_dist_native" />
            <ns0:check-export export-name="DEVEL_MODE" value-id="xccdf_preupg_value_devel_mode" />
            <ns0:check-export export-name="TMP_PREUPGRADE" value-id="xccdf_preupg_value_tmp_preupgrade" />
            <ns0:check-content-ref href="databases/mysql/configuration_changes/configuration.sh" />
          </ns0:check>
        </ns0:rule-result>

As you can see, the syntax and sed errors are in `<ns0:check-import
import-name="stdout"/>` node, although they must have been printed to
stderr by relevant programs.  At the same time, `stderr` node is empty.


Version-Release number of selected component
============================================

preupgrade-assistant-2.1.4-9.el6.noarch
preupgrade-assistant-contents-0.6.43-1.el6.noarch
preupgrade-assistant-contents-67-0.6.43-1.el6.noarch
preupgrade-assistant-staticdata-0.1.2-1.el6.noarch
preupgrade-assistant-staticdata-67-0.1.2-1.el6.noarch


How reproducible
================

Always


Steps to Reproduce
==================

 1. Have a module print something to stderr

 2. Look for the string in following nodes:

        <ns0:check-import import-name="stdout"/>
        <ns0:check-import import-name="stderr"/>


Actual results
==============

The string is found in stdout node but not in stderr node.


Expected results
================

The string should be found in stderr node but not in stdout node.


Additional info
===============

 *  This bug is not about the actual problems in the mysql-related module;
    separate bug will be recorded for that.

 *  As a consequence, this disables a routine test "no stderr printed"
    since from XML POV there's never any stderr.

 *  It would make sense for PA to raise error state just based on the
    presence of stderr.  I don't know if PA has such functionality (due
    to this bug we can't know); if not, let's open RFE for that...