Fix ipa-server-configure-first script to work with ipv4 and ipv6 addrs

[SJay3]

Сontinuing work on pull request #617
Parsing --ip-address option from server-install or replica-install options instead of using environment variable
Update configure-first script to work in dual stack mode
Fix rootless podman tests

[SJay3]

Rerun failed tests please! They didn't pass because they reached a timeout

[adelton]

I did rerun it but upon closer inspection, the Fedora 41 on K3s did not fail because of timeout but because of the replica setup failing ...

[adelton]

But anyway, as we've already discussed in #617, it is not clear to me why you try to add this logic at all. What exactly in the current behaviour prevents you from achieving the setup you need.

If I understand the problem correctly, it's not about IPv6 addresses at all -- if you set those explicitly with the --ip-address arguments during the FreeIPA server initialization, they will be left alone exactly as you set them. So no logic about IPv6 is needed.

The problem might be with the IPv4 addresses. If the IPA_SERVER_IP is not explicitly set, the DNS record in the internal DNS server will be updated with the internal IPv4 address of the container, which is undesirable if you've carefully set a different externally accessible (outside of the current host) address with --ip-address.

It seems to me that the best way forward is actually to add a logic to disable this internal update of the IPv4 address of the container. Please see #640 for a possible approach. It should allow you to use multiple IPv4 addresses with multiple --ip-address arguments as well (and have them left alone), something you mentioned in #617 (comment).

[SJay3]

I did rerun it but upon closer inspection, the Fedora 41 on K3s did not fail because of timeout but because of the replica setup failing ...

That is not right. I run tests many times and k3s in fedora didn't fail https://github.com/SJay3/freeipa-container/actions/runs/11911454741/job/33193138724 https://github.com/SJay3/freeipa-container/actions/runs/11912673594/job/33196965918
I`ll try to increase timeouts for tests that could potentially crash due to timeout

But anyway, as we've already discussed in #617, it is not clear to me why you try to add this logic at all. What exactly in the current behaviour prevents you from achieving the setup you need.

If I understand the problem correctly, it's not about IPv6 addresses at all -- if you set those explicitly with the --ip-address arguments during the FreeIPA server initialization, they will be left alone exactly as you set them. So no logic about IPv6 is needed.

Thast is also not correct. The problem is that freeipa-container works with ipv4 adresses. Not with ipv6 and dualstack. it's obvious from the ipa-server-configure-first script. If we didn't set IPA_SERVER_IP environment variable we didn't have /run/ipa/ipa-server-ip file with ip address. So afterr freeipa server install or start this script set detect ip address from global interface in the container https://github.com/freeipa/freeipa-container/blob/master/ipa-server-configure-first#L40 and then update dns with detected address https://github.com/freeipa/freeipa-container/blob/master/ipa-server-configure-first#L53 . Script ignores --ip-address parameter.
For example, if we run container with this command

docker run -d --name freeipa-master -v freeipa-data:/data:Z  localhost/freeipa-server:fedora-40 ipa-server-install -U -r EXAMPLE.TEST --setup-dns --no-forwarders --auto-reverse --allow-zone-overlap --ip-address=2001:db8:d5cf:a8c8:8db4:195e:1ee9:fc1 --no-ntp

script ipa-server-configure-first will update address in dns to ipv4 internal address of the container.
This means that we must use IPA_SERVER_IP environment variable with -ip-address parameter.

docker run -d --name freeipa-master -v freeipa-data:/data:Z -e IPA_SERVER_IP=2001:db8:d5cf:a8c8:8db4:195e:1ee9:fc1 localhost/freeipa-server:fedora-40 ipa-server-install -U -r EXAMPLE.TEST --setup-dns --no-forwarders --auto-reverse --allow-zone-overlap --ip-address=2001:db8:d5cf:a8c8:8db4:195e:1ee9:fc1 --no-ntp

But this not works because script trying to update only ipv4 addresses in dns https://github.com/freeipa/freeipa-container/blob/master/ipa-server-configure-first#L53
My changes solve this problem. And now, we don't need to use IPA_SERVER_IP environment variable at all. We only need to use --ip-address parameter to set ip address of server and container.

It seems to me that the best way forward is actually to add a logic to disable this internal update of the IPv4 address of the container. Please see #640 for a possible approach. It should allow you to use multiple IPv4 addresses with multiple --ip-address arguments as well (and have them left alone), something you mentioned in #617 (comment).

Why we need to disable this logic? if we set ip address with --ip-address parameter, then we expect that ip address of freeipa may change. If this happens then we have to update the address in dns.
In #640 you said

When an IPv4 address is set using the ipa-server-install's --ip-address parameter and the DNS record gets populated with that value, the current logic in ipa-server-configure-first rewrites that value after the ipa-server-install finishes and then during the subsequent container starts with the current internal IPv4 address of the container. Admins then have to use the IPA_SERVER_IP environment variable to force the value to be left alone.

If this is true, then I don't see the point in the script logic for updating the address in DNS. Maybe I should remove it completely? Then, if freeipa is launched in a container, we always need to set the IP address parameter when launching the container so that the correct addresses get into DNS, unless we launch the container with network=host. Or if we need to update address after freeipa server-install or container restart could you explain why?

[SJay3]

That is not right. I run tests many times and k3s in fedora didn't fail https://github.com/SJay3/freeipa-container/actions/runs/11911454741/job/33193138724 https://github.com/SJay3/freeipa-container/actions/runs/11912673594/job/33196965918
I`ll try to increase timeouts for tests that could potentially crash due to timeout

My apologies. I don't understand yet the reason why the tests fail. They do it every other time. I'll continue to figure it out.

[adelton]

script ipa-server-configure-first will update address in dns to ipv4 internal address of the container. This means that we must use IPA_SERVER_IP environment variable with -ip-address parameter.

docker run -d --name freeipa-master -v freeipa-data:/data:Z -e IPA_SERVER_IP=2001:db8:d5cf:a8c8:8db4:195e:1ee9:fc1 localhost/freeipa-server:fedora-40 ipa-server-install -U -r EXAMPLE.TEST --setup-dns --no-forwarders --auto-reverse --allow-zone-overlap --ip-address=2001:db8:d5cf:a8c8:8db4:195e:1ee9:fc1 --no-ntp

But this not works because script trying to update only ipv4 addresses in dns https://github.com/freeipa/freeipa-container/blob/master/ipa-server-configure-first#L53 My changes solve this problem.

But for the IPv6 address, there is nothing to solve. After the ipa-server-install ... --ip-address=2001:db8:d5cf:a8c8:8db4:195e:1ee9:fc1 finishes, the DNS record is set. If you do

docker exec freeipa-master dig @127.0.0.1 -t aaaa <the-FQDN-of-the-FreeIPA-server-that-you-likely-need-to-set-with--h>

the address is there, set by ipa-server-install itself, with no extra logic needed. At least that's what I observe.

if we set ip address with --ip-address parameter, then we expect that ip address of freeipa may change. If this happens then we have to update the address in dns.

Yes. But not by running the container again with a different --ip-address parameter and somehow parsing the value out of it, but by using a standard mechanism, like ipa dnsrecord-mod.

If this is true, then I don't see the point in the script logic for updating the address in DNS. Maybe I should remove it completely? Then, if freeipa is launched in a container, we always need to set the IP address parameter when launching the container so that the correct addresses get into DNS, unless we launch the container with network=host. Or if we need to update address after freeipa server-install or container restart could you explain why?

When you run the container, the IP address which will be assigned to that container and through which it will be accessible from other containers might not be known before the container is created. So we need some logic in the container to put the A record to the DNS so that other containers on the same host or the same virtual network can resolve that FreeIPA server's hostname. That's the reason for the ipa-server-update-self-ip-address.service service in the FreeIPA container.

But you might not want the internal container address in the DNS because access from other hosts is what you desire and you have port mapping or Kubernetes ingress or OpenShift route set. That's what the IPA_SERVER_IP mechanism does. In the past ipa-server-install was much more picky about the IP addresses it allowed so --ip-address couldn't be used (see https://pagure.io/freeipa/issue/4317), so we went with that IPA_SERVER_IP approach.

Today you are able to use the --ip-address option for the initial setup but then the ipa-server-update-self-ip-address.service logic might be in your way. But at the same time we cannot just remove the IPA_SERVER_IP logic like your PR proposes because we would break setups of folks who rely on that mechanism for ages, in their CIs and other setups. Stability is important for infrastructure projects.

[SJay3]

But for the IPv6 address, there is nothing to solve. After the ipa-server-install ... --ip-address=2001:db8:d5cf:a8c8:8db4:195e:1ee9:fc1 finishes, the DNS record is set.

That is not quite true. In ipv6 only I want to have only AAAA DNS record. But after ipa-server-configure-first script finish I have AAAA dns record with my ipv6 address and A record with 172.17.0.2 docker internal address

Yes. But not by running the container again with a different --ip-address parameter and somehow parsing the value out of it, but by using a standard mechanism, like ipa dnsrecord-mod.

Why not? This is exactly what the script does through the IPA_SERVER_IP variable

But at the same time we cannot just remove the IPA_SERVER_IP logic like your PR proposes because we would break setups of folks who rely on that mechanism for ages, in their CIs and other setups. Stability is important for infrastructure projects.

Agree. I'll save compatibility

[adelton]

But for the IPv6 address, there is nothing to solve. After the ipa-server-install ... --ip-address=2001:db8:d5cf:a8c8:8db4:195e:1ee9:fc1 finishes, the DNS record is set.

That is not quite true. In ipv6 only I want to have only AAAA DNS record. But after ipa-server-configure-first script finish I have AAAA dns record with my ipv6 address and A record with 172.17.0.2 docker internal address

That's why I said "after the ipa-server-install" and I talked about IPv6 specifically. It just proves that for IPv6, no extra logic is needed.

The A record gets there exactly via the mechanism that can be disabled with #640 and -e IPA_SERVER_IP=no-update; it does not get populated by ipa-server-install. I suggest you try that PR.

Yes. But not by running the container again with a different --ip-address parameter and somehow parsing the value out of it, but by using a standard mechanism, like ipa dnsrecord-mod.

Why not? This is exactly what the script does through the IPA_SERVER_IP variable

I explained the (historical) reasons for that approach above. But any time we can use existing functionality in FreeIPA, I prefer that over adding another one to the containerization layer.

[SJay3]

That's why I said "after the ipa-server-install" and I talked about IPv6 specifically. It just proves that for IPv6, no extra logic is needed.

Ok. What should I do if I need to update ipv6 address?

The A record gets there exactly via the mechanism that can be disabled with #640 and -e IPA_SERVER_IP=no-update; it does not get populated by ipa-server-install. I suggest you try that PR.

I will definitely check this mechanism as soon as I fix the problem in my PR that causes tests to fail.
But setting the variable IPA_SERVER_IP to no-update does not seem like a logical way to disable the address update functionality. The name of this environment variable implies the presence of an address or addresses inside it. But not a specialized string. It makes more sense to introduce a variable NO_IP_ADDRESS_UPDATE=1 or NO_IP_ADDRESS_UPDATE=true

I explained the (historical) reasons for that approach above. But any time we can use existing functionality in FreeIPA, I prefer that over adding another one to the containerization layer.

My question was, why can't we use the --ip-address parameter not only for the initial address setup, but also for updating? If there is a mechanism for updating IPv4 addresses, then why isn't the same needed for IPv6? And what should we do if we need to change the service address from IPv4 to IPv6?

[adelton]

Ok. What should I do if I need to update ipv6 address?

The same thing you would do on a FreeIPA server installed on a bare metal host or on a VM -- ipa dnsrecord-mod.

[SJay3]

Why should I do this manually if a script can do it automatically? Besides, such functionality already exists for IPv4 address. I just extended it so that it works for IPv6 or dualstack.

Please run tests for new changes

[SJay3]

Rebase PR. Please run tests

[adelton]

Why should I do this manually if a script can do it automatically?

Can you elaborate what you view as manual vs. automatic here? What is that "it" that you are after? AFAICS, all those setups are (or can be) scripted. The use of ipa dnsrecord-mod, besides being aligned with the administration of on-host FreeIPA installation, furthermore allows you do make the change without restarting the container -- think changing Service or ingress in a Kubernetes cluster.

Besides, such functionality already exists for IPv4 address. I just extended it so that it works for IPv6 or dualstack.

I already explained that the IPA_SERVER_IP functionality was primarily created as a workaround for behaviour of older versions of FreeIPA. Since --ip-address now can be used (for the initial setup) and with #640 merged the value does not need to be explicitly repeated in IPA_SERVER_IP, the significance of IPA_SERVER_IP for specifying the IP address from outside of the container really goes down.

To be explicit: I do not intend to merge your pull request since it seems to evolve in more band-aids and workarounds, not less.

If you have a specific use case or setup which cannot be achieved with the current images, please describe it (and only it), ideally in a new issue.