Bug 840098 - freeipa-server conflicts with mod_ssl-2.2.22
freeipa-server conflicts with mod_ssl-2.2.22
Status: CLOSED WONTFIX
Product: ovirt-engine
Classification: oVirt
Component: Setup.Engine (Show other bugs)
4.0.0
x86_64 Linux
unspecified Severity low (vote)
: ---
: ---
Assigned To: Rob Crittenden
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-13 13:22 EDT by Jason Brooks
Modified: 2016-03-10 04:05 EST (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-10 04:05:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Integration
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description Jason Brooks 2012-07-13 13:22:40 EDT
Description of problem:

freeipa-server conflicts with 1:mod_ssl-2.2.22-4.fc17.x86_64

Version-Release number of selected component (if applicable):

2.2.0-1.fc17

How reproducible:

On Fedora 17 system with mod_ssl-2.2.22-4.fc17.x86_64 installed, yum install freeipa-server.
  
Actual results:

Package conflict, freeipa-server won't install.

Expected results:

freeipa-server installs

Additional info:

mod_ssl is a dependency of ovirt-engine. I'm attempting to install freeipa-server on the same machine as ovirt-engine 3.1 (from http://www.ovirt.org/releases/beta/fedora/17/) to use as an identity provider.
Comment 1 Rob Crittenden 2012-07-13 13:25:35 EDT
The Conflicts is there because mod_ssl conflicts with mod_nss when mod_proxy is used, and it is with IPA.

mod_proxy provides a single SSL interface and mod_ssl grabs it by default, preventing mod_nss from using it. So if mod_ssl.so is loaded by Apache, whether it is used in any way or not, mod_nss cannot do SSL proxy.

See BZ https://bugzilla.redhat.com/show_bug.cgi?id=805720
Comment 2 Jason Brooks 2012-07-13 14:26:32 EDT
Changing to oVirt project, ovirt-engine-installer, for further discussion. FreeIPA and engine on the same server seems like a potentially common scenario.
Comment 3 Dmitri Pal 2012-07-13 14:38:55 EDT
Sure that is why fixing https://bugzilla.redhat.com/show_bug.cgi?id=805720 is very important (but unfortunately out of our control).
Please add your use case to the referenced bug to escalate its priority.
Comment 4 Alex Lourie 2013-01-23 16:44:33 EST
Jason

We require mod_ssl to allow ports redirection, so that engine could be used on 80/443 instead of 8080/8443 ports. It is the new default in 3.1, thus the conflict.

I don't think we can "fix" this in our packaging, as we use standard apache/httpd packaging in this case.

Please let us know if we can do anything to help.
Comment 5 Sandro Bonazzola 2013-11-07 04:28:45 EST
Closing because we have insufficient data for helping fixing the issue.
Please reopen if you think we can do anything to help.
Comment 6 Martin Kosek 2013-11-07 06:29:43 EST
Hello, please note that since FreeIPA 3.3.3 (F19, F20), FreeIPA can co-live with mod_ssl running on non-443 port.

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3974

RHEL-7.0 Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1018172

I assume this opens the door to having FreeIPA and oVirt on a single machine. Do you have an RFE like that open?
Comment 7 Sandro Bonazzola 2013-11-07 09:24:29 EST
No, I don't think so.
Comment 8 Alon Bar-Lev 2013-11-07 15:10:43 EST
(In reply to Martin Kosek from comment #6)
> Hello, please note that since FreeIPA 3.3.3 (F19, F20), FreeIPA can co-live
> with mod_ssl running on non-443 port.
> 

But why ovirt should give up of standard port... why not IPA use non standard port?

This indeed "solves" conflict, but is not exactly valid solution.

Interesting to investigate if two ip addresses can be setup to a machine, one will be bind to 443 and mod_ssl and the other bind to 443 and mod_nss, this is better solution, admin can set it up before installing ovirt-engine.
Comment 9 Martin Kosek 2013-11-08 02:53:08 EST
(In reply to Alon Bar-Lev from comment #8)
...
> But why ovirt should give up of standard port... why not IPA use non
> standard port?

This is of course a valid question. oVirt could share the 443 with FreeIPA, it would just need to run on mod_nss, at the moment.

IPA client and server use XMLRPC/JSONRPC (in /ipa/* URL space)  on this port to communicate, e.g. to join the IPA domain, manipulate with users and similar. If this would run on an non-standard port, we would need some way to communicate it to clients. Maybe by resurrecting the idea to have _ipa._tcp SRV records which could hold the port number (https://fedorahosted.org/freeipa/ticket/1159) or by allowing to use mod_ssl (https://fedorahosted.org/freeipa/ticket/3757) for IPA https handling.

Jan, did you come to any applicable solution to this issue in your integration efforts?
Comment 15 Itamar Heim 2013-11-10 10:09:03 EST
upgrade problem was from EAP 5 to EAP 6. may happen again with AS8 or EAP 7, etc.
Comment 16 Alon Bar-Lev 2013-11-10 10:52:43 EST
(In reply to Itamar Heim from comment #15)
> upgrade problem was from EAP 5 to EAP 6. may happen again with AS8 or EAP 7,
> etc.

So ovirt-engine conflict to it-self the same way ovirt-engine conflict with any jboss depended application out there.

The fact that we provide upgrade path that manipulate machine packages is totally invalid. 'yum update' should have updated the system properly, currently this is done to solve ovirt-engine specific issue of not supporting previous version's database scheme, lets not extend the use case to be able to upgrade jboss as well.

It is unacceptable that jboss requires package removal in order to perform upgrade, or that entire system upgrade is required (yum update *). Once again 'yum update jboss-<shomething>' should have been sufficient to pull and update the entire jboss eap.

Another abnormality is the requirement to have only one jboss major version and not allow having several jboss eap versions on system, allowing existing applications to keep provide service while new/updated application use new jboss.
Comment 17 Jay Turner 2013-11-11 07:11:37 EST
(In reply to Alon Bar-Lev from comment #16)

[snip]

> It is unacceptable that jboss requires package removal in order to perform
> upgrade, or that entire system upgrade is required (yum update *). Once
> again 'yum update jboss-<shomething>' should have been sufficient to pull
> and update the entire jboss eap.

Just a note here . . . 'yum update *' is pretty much the only way that Red Hat products are supported.  And I saw "pretty much" only because I know there are some side agreements with specific customers.  The expectation of customers is their machines are running the latest available code.
Comment 18 Jan Pazdziora 2013-11-11 21:22:26 EST
(In reply to Jay Turner from comment #17)
> 
> Just a note here . . . 'yum update *' is pretty much the only way that Red
> Hat products are supported.  And I saw "pretty much" only because I know

Except for going across versions -- Satellite, even RHEL itself do require additional steps and are not supported via plain yum upgrade. Not sure about EAP but if it is supported across major versions without additional steps, it's more an exception than rule.

> there are some side agreements with specific customers.  The expectation of
> customers is their machines are running the latest available code.

... within one stream.
Comment 19 Alon Bar-Lev 2013-11-12 02:30:28 EST
(In reply to Jan Pazdziora from comment #18)
> (In reply to Jay Turner from comment #17)
> > 
> > Just a note here . . . 'yum update *' is pretty much the only way that Red
> > Hat products are supported.  And I saw "pretty much" only because I know
> 
> Except for going across versions -- Satellite, even RHEL itself do require
> additional steps and are not supported via plain yum upgrade. Not sure about
> EAP but if it is supported across major versions without additional steps,
> it's more an exception than rule.
> 
> > there are some side agreements with specific customers.  The expectation of
> > customers is their machines are running the latest available code.
> 
> ... within one stream.

If we find that acceptable, we are going back to Windows state instead of forward for enterprise grade. yum should be improved / replaced until platform upgrade can be done using single tool and methods for all the cases, support proper automation and API for enterprise to be able to manage an entire infrastructure without handling each application's proprietary sequence.
Comment 20 Itamar Heim 2014-01-12 03:42:13 EST
setting target release to current version for consideration and review. please do not push non-RFE bugs to an undefined target release to make sure bugs are reviewed for relevancy, fix, closure, etc.
Comment 21 Sandro Bonazzola 2014-01-24 09:44:05 EST
Re targeting to 3.5.0, I doubt we'll have enough time for working on this for 3.4.0.
Comment 22 Sandro Bonazzola 2015-09-04 05:00:09 EDT
This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.
Comment 23 Red Hat Bugzilla Rules Engine 2015-10-19 06:55:53 EDT
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

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