Bug 905754 - 3.3 scratch or upgraded installation must use apache proxy
Summary: 3.3 scratch or upgraded installation must use apache proxy
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-installer (Show other bugs)
(Show other bugs)
Version: 3.2
Hardware: Unspecified Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.3
Assignee: Sandro Bonazzola
QA Contact:
URL:
Whiteboard: integration
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-30 06:13 UTC by Alex Lourie
Modified: 2013-09-23 07:34 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 967353 (view as bug list)
Environment:
Last Closed: 2013-09-23 07:34:31 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
engine-upgrade output (9.65 KB, text/plain)
2013-07-24 14:12 UTC, Michal Skrivanek
no flags Details
engine upgrade log (1.46 MB, text/plain)
2013-07-24 14:20 UTC, Michal Skrivanek
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 15038 None None None Never
oVirt gerrit 15051 None None None Never
oVirt gerrit 17310 None None None Never

Description Alex Lourie 2013-01-30 06:13:19 UTC
Description of problem:

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

Comment 1 Itamar Heim 2013-01-30 08:54:09 UTC
shouldn't this be "any 3.3"?

Comment 2 Sandro Bonazzola 2013-04-29 15:26:41 UTC
(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.

Comment 3 Sandro Bonazzola 2013-05-02 14:26:01 UTC
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?

Comment 4 Sandro Bonazzola 2013-05-20 13:54:58 UTC
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.

Comment 5 Sandro Bonazzola 2013-05-24 13:59:02 UTC
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 7 Michal Skrivanek 2013-07-24 14:10:55 UTC
doesn't honor the existing ports and set them to 80/443

Comment 8 Michal Skrivanek 2013-07-24 14:12:58 UTC
Created attachment 777805 [details]
engine-upgrade output

3.2 setup was using port 8887 as http and 8888 as https, no iptables or firewalld was selected during original 3.2 installation

Comment 9 Alon Bar-Lev 2013-07-24 14:17:46 UTC
(In reply to Michal Skrivanek from comment #8)
> Created attachment 777805 [details]
> engine-upgrade output
> 
> 3.2 setup was using port 8887 as http and 8888 as https, no iptables or
> firewalld was selected during original 3.2 installation

I do not understand.

Did you have jboss without apache or with apache at non standard port?

Comment 10 Michal Skrivanek 2013-07-24 14:20:00 UTC
Created attachment 777817 [details]
engine upgrade log

Comment 11 Michal Skrivanek 2013-07-24 14:21:26 UTC
(In reply to Alon Bar-Lev from comment #9)
> Did you have jboss without apache or with apache at non standard port?
jboss without apache at non standard ports

Comment 12 Alon Bar-Lev 2013-07-24 14:26:36 UTC
(In reply to Michal Skrivanek from comment #11)
> (In reply to Alon Bar-Lev from comment #9)
> > Did you have jboss without apache or with apache at non standard port?
> jboss without apache at non standard ports

Right. Apache will be served using standard ports.
You should be still able to access the legacy ports directly to jboss.

Comment 13 Michal Skrivanek 2013-07-24 14:31:46 UTC
and that's not correct anymore as jboss is running on different ports. It was originally 8887,8888 (http and httpd I configured in 3.2 in engine-setup) and 8703 listening on localhost only.
Now after upgrade I see:

[root@dhcp131-154 ~]# netstat -lpnt|egrep 'ovir|htt'
tcp        0      0 127.0.0.1:8706          0.0.0.0:*               LISTEN      743/ovirt-engine    
tcp        0      0 127.0.0.1:8702          0.0.0.0:*               LISTEN      743/ovirt-engine    
tcp        0      0 127.0.0.1:8703          0.0.0.0:*               LISTEN      743/ovirt-engine    
tcp6       0      0 :::80                   :::*                    LISTEN      400/httpd           
tcp6       0      0 :::443                  :::*                    LISTEN      400/httpd

Comment 14 Michal Skrivanek 2013-07-24 14:32:25 UTC
...8887,8888 (http and https I configured in 3.2 in engine-setup)...

Comment 15 Alon Bar-Lev 2013-07-24 15:32:43 UTC
(In reply to Alon Bar-Lev from comment #12)
> (In reply to Michal Skrivanek from comment #11)
> > (In reply to Alon Bar-Lev from comment #9)
> > > Did you have jboss without apache or with apache at non standard port?
> > jboss without apache at non standard ports
> 
> Right. Apache will be served using standard ports.
> You should be still able to access the legacy ports directly to jboss.

We have done this in legacy setup, but not sync it into the new setup.

Comment 16 Sandro Bonazzola 2013-07-31 07:47:23 UTC
patch 17310 merged upstream master for 3.3.0

Comment 17 Itamar Heim 2013-08-21 16:41:38 UTC
as RC is built, moving to ON_QA (hopefully did not catch incorrect bugs when doing this)

Comment 18 Itamar Heim 2013-09-23 07:34:31 UTC
closing as this should be in 3.3 (doing so in bulk, so may be incorrect)


Note You need to log in before you can comment on or make changes to this bug.