Description of problem: Hi After upgrading RHEV environment to 3.3, I was unable to properly start apache (server was upgraded from 3.0 -> 3.1 -> 3.2 -> 3.3 during all its life). Once apache was working and RHEV-M too, I got one ETL error, so I proceeded to reinstall DWH and Reports, but reports was not installing: Customizing Server... [ DONE ] Return Code is not zero Error encountered while installing rhevm-reports, please consult the log file: /var/log/ovirt-engine/ovirt-engine-reports-setup-2014_01_26_12_31_48.log The relevant part from that log was: 2014-01-26 12:36:34::DEBUG::common_utils::1018::root:: Executing command --> '/usr/share/ovirt-engine-reports/ssl2jkstrust.py --host=myserver.com --port=443 --keystore=/etc/ovirt-engine/ovirt-engine-reports/trust.jks --storepass=mypass' in working directory '/root' 2014-01-26 12:36:35::DEBUG::common_utils::1073::root:: output = 2014-01-26 12:36:35::DEBUG::common_utils::1074::root:: stderr = Traceback (most recent call last): File "/usr/share/ovirt-engine-reports/ssl2jkstrust.py", line 116, in <module> main() File "/usr/share/ovirt-engine-reports/ssl2jkstrust.py", line 114, in main os.rename(tmp, options.keystore) OSError: [Errno 2] No such file or directory So we have two issues: 1- os.rename should check that the file was created before trying to remove it 2- the file wasn't created by ssl2jkstrust.py because it uses: "for c in getChainFromSSL((options.host, int(options.port)))[1:]:" Which fails when certificate is provided in return place '0' instead of '1'. Changing that line to read "0:" instead of "1:" allowed installation to continue without any detectable issue Version-Release number of selected component (if applicable): rhevm-reports-3.3.0-28.el6ev.noarch How reproducible: Steps to Reproduce: 1. Ensure that certificate provides 'CERTIFICATE' in argument 0, probably because of missing chain 2. Run rhevm-reports-setup 3. Actual results: Setup fails because of the "No such file or directory messages" Expected results: Setup should have succeeded. Additional info: Patching the call to just try to gather certificate from all/any return arguments instead of "1" should have not raised this issue. As the whole environment is working fine, we could raise instead a warning during setup/upgrade phase.
Can you please attach /etc/httpd/conf.d/ssl.conf? Can you please attach the output of: $ openssl s_client -showcerts -connect localhost:443 < /dev/null Thanks!
Alon, Let me know if any additional file is needed. Regards, Pablo
Thanks! Can you please try to remove SSLCertificateChainFile? I have a solution also in this state, just want to confirm.
Alon, Removing the SSLCertificateChain from ssl.conf and restarting apache, and using the original ssl2jkstrust.py gives no complain, but also it's not creating the file. Regards, Pablo
Do we want z stream on this? Yaniv
Is this bug should be verified on upstream, or downstream ? It is under rhev product, in which it is not implemented yet (av1), therefore not on qa. But targeted to ovirt-3.4.0-beta3, which has a different location in products tree. Please solve it out.
(In reply to Barak Dagan from comment #11) > Is this bug should be verified on upstream, or downstream ? > It is under rhev product, in which it is not implemented yet (av1), > therefore not on qa. ovirt-3.4.0-beta3 has been delivered to QA for testing and referenced patches points to upstream gerrit. So this BZ should be ON_QA unless it's missing references to downstream gerrit > But targeted to ovirt-3.4.0-beta3, which has a different location in > products tree. > > Please solve it out.
alonbl: 3.4 does not use this method to acquire ceritificate, it is 3.3 only bug. you must have 3.4 bug to clone it into 3.3.
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. http://rhn.redhat.com/errata/RHEA-2014-0602.html