Bug 1637809

Summary: ovirt-imageio-proxy should use apache's pki
Product: [oVirt] ovirt-imageio Reporter: Yedidyah Bar David <didi>
Component: ProxyAssignee: Yedidyah Bar David <didi>
Status: CLOSED CURRENTRELEASE QA Contact: Petr Matyáš <pmatyas>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.1.0CC: aefrat, amashah, bugs, damion.brown, derez, jhocutt, nsoffer, tnisan
Target Milestone: ovirt-4.3.6Flags: rule-engine: ovirt-4.3+
Target Release: 1.5.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-imageio-proxy-1.5.2 Doc Type: Bug Fix
Doc Text:
Doc team: Please see the discussion on doc bug 1385617. Copying the commit message text of the main patch for current bug, which explains what the patch does. As is common in git commits, this is in imperative style, not doc style. Feel free to keep content but convert style, or write your own. With this bug fixed, the change for doc bug 1385617 will be just a single small item (to restart the proxy). Commit message follows: packaging: setup: proxy: Use apache pki instead of own Use apache httpd key/cert/ca_cert instead of engine-ca-generated ones. This should make it easier to use: - If using engine-ca for apache, user most likely already approved it in the browser when logging in, so will not have to handle again for imageio. - If using 3rd party CA for apache, CA cert likely already added to the browser. In a normal upgrade, where the user didn't touch the conf manually, notify the user and update the proxy conf. In an upgrade where the user changed the conf manually after setup, create a new file with a different name and notify the user, suggesting to check the diff and update. In an upgrade where the user changed the conf manually after setup, but changed it to have the content we want it to have with current patch, only log, but still "update" the file, so that a following setup or especially cleanup will consider the file "ok" (not changed manually). The only case that will be broken by current patch is if a user needs, for some reason, two different certs for the two different https services on two different ports, on the engine machine. In a discussion in bugzilla it was decided that this is not an issue.
Story Points: ---
Clone Of:
: 1725734 (view as bug list) Environment:
Last Closed: 2019-09-26 19:43:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1385617, 1725734    

Description Yedidyah Bar David 2018-10-10 07:01:41 UTC
Description of problem:

Please see the long discussion on bug 1385617.

If the only client to ovirt-imageio-proxy is the admin's browser, which IIUC is correct, I think by now everyone agrees it does not need its own keypair, but should use apache's.

Please make the proxy's engine-setup config plugin generate a conf file with:

ssl_key_file = /etc/pki/ovirt-engine/keys/apache.key.nopass
ssl_cert_file = /etc/pki/ovirt-engine/certs/apache.cer

We should also consider what to do on upgrades. IMO we can check if the file was changed outside of engine-setup, and if not, update it on upgrades.

Comment 1 Daniel Erez 2018-10-10 10:00:58 UTC
*** Bug 1575979 has been marked as a duplicate of this bug. ***

Comment 2 Sandro Bonazzola 2019-01-28 09:41:20 UTC
This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

Comment 3 Sandro Bonazzola 2019-07-11 07:03:33 UTC
Re-targeting to 4.3.6 not being identified as blocker for 4.3.5.

Comment 4 Yedidyah Bar David 2019-07-24 09:23:57 UTC
98739 was already merged.

98403 is for the engine, bug 1687301.

95408 is also for the engine, and we need it. I'll push another patch to require a new engine.

Comment 5 Petr Matyáš 2019-08-26 10:59:25 UTC
Verified on ovirt-engine-4.3.6.3-0.1.el7.noarch

Comment 6 Sandro Bonazzola 2019-09-26 19:43:36 UTC
This bugzilla is included in oVirt 4.3.6 release, published on September 26th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.6 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.