Bug 967353

Summary: PRD33 - force Apache proxy on upgrade and clean install
Product: Red Hat Enterprise Virtualization Manager Reporter: Itamar Heim <iheim>
Component: ovirt-engine-setupAssignee: Sandro Bonazzola <sbonazzo>
Status: CLOSED ERRATA QA Contact: Tareq Alayan <talayan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.3.0CC: acathrow, adahms, alonbl, bazulay, iheim, jkt, mgoldboi, Rhev-m-bugs, sbonazzo, thildred
Target Milestone: ---Keywords: FutureFeature
Target Release: 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: integration
Fixed In Version: is6 Doc Type: Enhancement
Doc Text:
This update enforces the use of an Apache proxy during a new installation of Red Hat Enterprise Virtualization version 3.3 if it is not enabled already, and forces migration to an Apache proxy during an upgrade from earlier versions of Red Hat Enterprise Virtualization Manager. Redirection of the ports for http and https to ports 80 and 443 respectively is also recommended. However, while the user is prompted to use ports 80 and 443 for http and https during the engine-setup process, existing ports are preserved when this process is performed without user interaction. Conflicts with freeipa-server and ipa-server are now also detected, and installation or upgrade of Red Hat Enterprise Virtualization Manager on systems running these servers is disallowed.
Story Points: ---
Clone Of: 905754
: 975670 (view as bug list) Environment:
Last Closed: 2014-01-21 17:23:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 975670, 1019470    

Description Itamar Heim 2013-05-26 19:29:05 UTC
cloned upstream ovirt bug to rhev

+++ This bug was initially created as a clone of Bug #905754 +++

Description of problem:

Any 3.2 should use apache and ports redirection on the default 80/443 ports.

--- Additional comment from Itamar Heim on 2013-01-30 03:54:09 EST ---

shouldn't this be "any 3.3"?

--- Additional comment from Sandro Bonazzola on 2013-04-29 11:26:41 EDT ---

(In reply to comment #0)

> Any 3.2 should use apache and ports redirection on the default 80/443 ports.

the above statement become:
Any 3.3 instance must use apache and should use ports redirection.
So, httpd proxy enabled (not an option) on scratch installation and forced migration to http proxy on upgrade.
Port redirection must be still configurable by the user during setup (80/443 by default)

engine-upgrade must keep the existing ports in non-interactive executions and prompt the user in interactive executions allowing to change them to 80/443.

--- Additional comment from Sandro Bonazzola on 2013-05-02 10:26:01 EDT ---

I'm looking in the code and I've found a point where I'm in doubt about how to handle the case.

The current engine-setup implementation perform some checks that change the behavior of the installer documented as:

1. Check whether the relevant httpd configuration files were changed,
   As it's an indication for the setup that the httpd application is being actively used,
   Therefore we may need to ask (dynamic change) the user whether to override this configuration.
2. Check if IPA is installed and drop port 80/443 support.

What the script really do is setting OVERRIDE_HTTPD_CONFIG default to False in both cases and just for case 2 call also setHttpPortsToNonProxyDefault.

How have I to handle those 2 cases which conflict with the forced proxy policy?

--- Additional comment from Sandro Bonazzola on 2013-05-20 09:54:58 EDT ---

We split the http configuration into three:
1. Install ajp proxy per our URIs[1][2].
2. Optionally set root redirection from / to /ovirt-engine
3. Optionally configure mod_ssl with our certificate.

The mandatory apache configuration[1] does not alter any configuration file.
[1] http://gerrit.ovirt.org/13318
[2] http://gerrit.ovirt.org/14304

So there is no reason for checking if user has changed the http
configuration for just forcing proxy.

About IPA conflicts if I've understood correctly there is only collision
between mod_nss used by IPA and mod_ssl used if we enable mod_ssl
configuration.
It seems there was an issue with mod_proxy and using 2 different SSL
certificates (IPA & RHEV) on the same apache server.

So, I can force proxy enabled and I can force SSL configuration disabled
if IPA is detected.
I can leave root redirection optional in any case.

otopi implementation already force proxy enabled so there should be just
to disable ssl if IPA is detected.

--- Additional comment from Sandro Bonazzola on 2013-05-24 09:59:02 EDT ---

patches pushed upstream for legacy engine-setup and engine-upgrade.

engine-upgrade verified only upgrading from nightly because it seems that engine-upgrade from master fails on fkvalidator_sp.sql when upgrading from 3.2.2 stable.

otopi implementation of engine-setup-2 doesn't need any change for the setup mode. It may need some changes in upgrading mode.

Comment 1 Sandro Bonazzola 2013-06-20 07:27:07 UTC
patch pushed and merged upstream master:

patch 15038 merged upstream master: http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=3c8dd89c3226f276eb1d821ebbbdc158d3f76a2d

patch 15051 merged upstream master: http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=38c0a408c0e71d2fc5d83808343eb1837b78f806

Modified per future rebase.

Comment 2 Charlie 2013-11-28 00:23:34 UTC
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Comment 3 errata-xmlrpc 2014-01-21 17:23:10 UTC
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/RHSA-2014-0038.html