You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been replicating from the ipa-re.{{root_domain}} to the ipa.{{root_domain}}, where ipa-re is a VM running the Rocky-9 with IPA 4.10.2.
Container used is freeipa/freeipa-server:rocky-9 (IPA 4.10.2), host is Ubuntu 22.04 LTS with Docker v25.
This seems work like it used to before (it's communicating with the other docker containers on the same network and with external hosts) and ipa-healthcheck in the container does not return anything.
But I've noticed that ipa-ca address is set to the 172.18.0.4 which is internal IP of the container. When I've originally created this IPA instance in container over 2years ago, I'm not sure if the ipa-ca had been set at all. When I search thought the snapshots I cannot find any mention of this field in the /var/named (it's mentioned only in the certmonger, pki-tomcatd and httpd configs).
When I issue the ipa dns-update-system-records --dry-run it still shows the 172.18.0.4 as the ipa-ca address, so I suppose that changing it manually won't last. What would be the expected solution for this?
As a sidenote: If I add the IPA_SERVER_IP to the docker-compose above it will configure replica as well but will never leave this loop
I've restored my freeipa instance from 2023-11-30 backup (rocky-8) and the ipa-ca had been correctly set to the external address, but ipa dns-update-system-records --dry-run is still suggesting the internal address
Last time we discussed this was in #321 and there we concluded that --ip-address (which you use) should be working. Albeit that was on a master, not replica. But with that and especially the extra_hosts which I assume set records in /etc/hosts in the container, there's not much more you could do to make FreeIPA happy.
Any chance you would be able to setup a replica in a VM with some nonstandard IP setup, instead of in a container, and see if the ipa dns-update-system-records works in that case?
I wish I'd stumble upon the #321 earlier, as it would save me some debugging time ;)
For the record, when creating a new container with a master, using the --ip-address also sets the ipa-ca A record to the internal address. I suppose there is no mechanizm to override this address within the ipa itself or it's kept like this by design.
If time permits I'll try to recreate similar setup in the VMs, but I'd have to figure out proper NAT for those first.
I've created a replica which was able to install itself successfully, with the following docker-compose.yml file (with some jinja2 templating):
I've been replicating from the
ipa-re.{{root_domain}}
to theipa.{{root_domain}}
, where ipa-re is a VM running the Rocky-9 with IPA 4.10.2.Container used is
freeipa/freeipa-server:rocky-9
(IPA 4.10.2), host is Ubuntu 22.04 LTS with Docker v25.This seems work like it used to before (it's communicating with the other docker containers on the same network and with external hosts) and
ipa-healthcheck
in the container does not return anything.But I've noticed that
ipa-ca
address is set to the172.18.0.4
which is internal IP of the container. When I've originally created this IPA instance in container over 2years ago, I'm not sure if the ipa-ca had been set at all. When I search thought the snapshots I cannot find any mention of this field in the/var/named
(it's mentioned only in the certmonger, pki-tomcatd and httpd configs).When I issue the
ipa dns-update-system-records --dry-run
it still shows the172.18.0.4
as theipa-ca
address, so I suppose that changing it manually won't last. What would be the expected solution for this?As a sidenote: If I add the
IPA_SERVER_IP
to the docker-compose above it will configure replica as well but will never leave this loopfreeipa-container/ipa-server-configure-first
Line 64 in f94501d
127.0.0.11
) (Also it does not fix the original issue anyway)The text was updated successfully, but these errors were encountered: