CA not working on brand new fedora-33 install #385
Comments
|
Given that error, I'd assume that the container has a problem resolving that What's in |
|
|
That seems sane. @abbra, any hints what could be causing the tomcat startup issues, what to look for? @thinkl33t, can you try to run |
|
No idea for this specific Java issue. However, on IPA side we do not support single label domains (like |
|
`ipa7.dev` isn't `ipa7.dev` on the actual instance, it is an fqdn with a
valid a record pointing to the dockerhost
…On Fri, 19 Mar 2021, 12:21 Alexander Bokovoy, ***@***.***> wrote:
No idea for this specific Java issue. However, on IPA side we do not
support single label domains (like dev above).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#385 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHYHTBI37RXAEIXVNU5GLLTEM6THANCNFSM4ZMX2DDA>
.
|
|
Is it plausible that this lookup isn't looking at /etc/hosts at all, is doing a (forwarded) dns lookup for the FQDN, and trying to assign the external ip address of the container host where it should be trying to assign the container's internal ip address? |
|
That's rather unlikely, unless in the container return? Were you able to run the test with |
|
I've not had a chance to do so yet, will hopefully be able to test that
today :)
nsswitch.conf:
```
hosts: files resolve [!UNAVAIL=return] myhostname dns
```
…On Mon, 22 Mar 2021 at 10:50, Jan Pazdziora ***@***.***> wrote:
That's rather unlikely, unless nsswitch.conf was updated in some creative
way. What does
grep host /etc/nsswitch.conf
in the container return?
Were you able to run the test with tests/run-master-and-replica.sh?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#385 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHYHTFUQU47AQBKMR23FCTTE4OGNANCNFSM4ZMX2DDA>
.
|
|
We seem to have lost traction there. |
|
Apologies, i've been off work for the past few weeks and have just managed to hop back on this again. I think i've tracked down the issue though! The CA for freeipa is provided via an AJP proxy to port 8009, which doesn't have anything connected to it. This is provided by the pki-tomcat service. Having a look at journalctl for the pki-dogtag instance shows the following line: When we discussed this above we assumed that it couldn't see ipa7.dev.example.org, as the stacktrace was surrounded by things accessing that. This isn't correct though! If we have a look at the pki-tomcat config file at These are the ajp connector configs for tomcat, and ask the ajp connectors to bind to localhost4 and localhost6, which don't exist in Adding localhost4 and localhost6 entries manually to the hostfile appears to fix the issue: |
|
I think this is a difference between fedora upstream (which has My current thought is to add something to the entrypoint that will make sure localhost4 and localhost6 are in /etc/hosts, and in the right place - that should be after the point at which docker has generated The other option would be to patch server.xml to hard-code |
|
Passing in |
|
I agree that the assumptions that FreeIPA / Dogtag makes about the environment (specifically hostnames specified in The @abbra, what are your thoughts about this? Assuming we'd be able to reproduce this outside of container, would an issue "FreeIPA does not setup fully working CA on host that does not have |
|
FreeIPA doesn't modify server.xml's host references. They come from dogtag and need to be handled in dogtag installer. They'd be affecting PKI container in the same way. So please open a bug against dogtag. |
|
Looks like dogtagpki/pki@1906afb is the commit in dogtag that has caused this issue |
What is the Dogtag-only equivalent to |
|
IPA calls |
|
The defaults file in the container at |
|
ipa builds out the dict that is passed through to pkispawn here so its plausible we could patch ipa to allow specifying what host to use for ajp, either at the docker container level or upstream. |
|
you already can pass PKI override config to ipa-server-install, where these overrides can be specified. They'll be automatically applied on top of IPA configuration. See |
|
Sadly, following https://www.dogtagpki.org/wiki/Installing_Custom_CA does not give me error-free setup. So I tried The problem -- I was not able to reproduce the issue on host (outside of containers) as then passes just fine. (Internal reference J:5258540.) |
|
I can confirm that passing in a file And adding |
|
Since there is a solution / workaround and at the same time I was not able to reproduce the problem outside of containers to be able to report it to either Dogtag or FreeIPA projects, I'm inclined to close this issue. |
|
Closing. |
|
I'd like to add that I too have been able to replicate this issue during migration of a legacy installation. Adding the following to the docker-compose file solved it: Just for anyone else encounters this issue! |
I'm installing freeipa using the
fedora-33container from dockerhub as follows. I'm orchestrating the container using ansible to template theipa-server-install-optionsfile to/dataon the server:The realm and domain are both valid, and the hostname has an A record pointing to the docker server. To run the container itself, i'm running it as follows:
The install all seems to go fine, and
docker exec -ti freeipa ipactl statusshows all the services as running:The webui is running fine at
https://fqdn/, but the ca athttps://fqdn/ca/rest/securityDomain/domainInfogives a 503 error. That URL is proxied via apache httpd to pki-tomcat on port 8009, but if we look inside the container, nothing is running on port 8009.I've had a dig through the logs for pki-tomcat using journalctl, the section that appears unhappy is here, but i'm at a loss how to interpret this into an actionable fix.
The text was updated successfully, but these errors were encountered: