Dogtag listens on port 8080, which is a very common port. pkisilent takes a config file which can include a value for ports. But this is not exposed via the installer command line switches. If the server needs to run on a machine with other process (such as Openstack swift) that are required to listen on port 8080, it conflicts and one or the other cannot run.
There are several spots in the FreeIPA code that hardcodes the port as 8080. See below.
The file ./ipapython/dogtag.py has support for reading the port from the environement via the logic: conn = httplib.HTTPConnection( ca_host, api.env.ca_install_port or 8080)
This approach should be usable in all parts of the code.
./ipaserver/install/cainstance.py: conn = httplib.HTTPConnection(self.fqdn, 8080) ./ipaserver/plugins/dogtag.py: ipautil.format_netloc(self.ca_host, 8080), ./ipaplatform/base/services.py: 'pki-tomcatd@pki-tomcat.service': [8080, 8443], ./ipaplatform/base/services.py: 'pki-tomcat': [8080, 8443], ./ipaplatform/base/services.py: 'pki-tomcatd': [8080, 8443], # used if the incoming instance name is blank
Patch that shows the general approach freeipa-admiyo-0297-Use-Env-Var-for-Dogtag-port.patch
Note that the above patch merely shows using the Env Var everywhere; there still needs to be some documented way to trigger that Env.
I was not able to test the build/install with the patch as I have configure: error: Package requirements (sss_nss_idmap >= 1.13.90) were not met:
Requested 'sss_nss_idmap >= 1.13.90' but version of sss_nss_idmap is 1.13.4
the sssd dependency can be obtained in @freeipa/freeipa-master COPR repo
More context: http://adam.younglogic.com/2016/07/defconflicting-swift-proxy-with-freeipa/
Per triage on Jul 12, moving to Future release for consideration.
Patches welcome!
I am not sure the importance of this capability is properly assessed. This seems to be a blocker for use of IdM as a part of OpenStack automated deployment.
I think we need to evaluate this ticket in that context. I suggest re-tiage.
Metadata Update from @admiyo: - Issue assigned to someone - Issue set to the milestone: Future Releases
We have always said that IPA should run on its own and not co-exist with other software so I'm going to close this as wontfix. Yes it can be a constraint that yet-another-large VM is hard to provision but IPA makes a lot of assumptions because it has so many cats to herd.
Metadata Update from @rcritten: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.