Bug 840098
Summary: | freeipa-server conflicts with mod_ssl-2.2.22 | ||
---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Jason Brooks <jbrooks> |
Component: | Setup.Engine | Assignee: | Rob Crittenden <rcritten> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.0.0 | CC: | abokovoy, bsettle, bugs, cristi.falcas, didi, dpal, iheim, jbrooks, jpazdziora, mkosek, rbalakri, rcritten, sbonazzo, s.kieske, srevivo, ssorce, ylavi |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | Flags: | ylavi:
planning_ack?
ylavi: devel_ack? ylavi: testing_ack? |
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-03-10 09:05:06 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: |
Description
Jason Brooks
2012-07-13 17:22:40 UTC
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 Changing to oVirt project, ovirt-engine-installer, for further discussion. FreeIPA and engine on the same server seems like a potentially common scenario. 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. 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. Closing because we have insufficient data for helping fixing the issue. Please reopen if you think we can do anything to help. 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? No, I don't think so. (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. (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? upgrade problem was from EAP 5 to EAP 6. may happen again with AS8 or EAP 7, etc. (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. (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. (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. (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. 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. Re targeting to 3.5.0, I doubt we'll have enough time for working on this for 3.4.0. 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. 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. |