[Feat] Support dual-stack IPv4 and IPv6 when configuring pg_hba.conf for replication hosts

[bkhomuts]

Problem

At this moment pg_hba.conf is configured only with IPv4 address of each node. As a result, connections may fail, if replicas connect using the domain name (expected to be supported #1228).

Description

When autobase configures pg_hba.conf, it should also allow the IPv6 address of the hostname.

Importance

nice to have

Proposed implementation

Define bind_address_v6 for each host in inventory, and then update pg_hba.conf.j2 to look like

{% for host in groups['postgres_cluster'] %}
  hostssl      replication              {{ patroni_replication_username }}               {{ hostvars[host]['patroni_bind_address'] | default(hostvars[host]['bind_address'], true) }}/32         {{ postgresql_password_encryption_algorithm }}
  {% if hostvars[host]['bind_address_v6'] %}
  hostssl      replication              {{ patroni_replication_username }}               {{ hostvars[host]['patroni_bind_address_v6'] | default(hostvars[host]['bind_address_v6'], true) }}/128  {{ postgresql_password_encryption_algorithm }}
  {% endif %}
{% endfor %}

[vitabaks]

I have a vague idea of a scenario where ipv6 might be needed. ipv4 is usually always sufficient.

Just don't use domain names for this purpose.

[vitabaks]

This would require modifying at least two roles:

• bind_address: https://github.com/vitabaks/autobase/blob/2.3.2/automation/roles/bind_address/tasks/main.yml#L49
• tls_certificate: https://github.com/vitabaks/autobase/blob/2.3.2/automation/roles/tls_certificate/tasks/main.yml#L95

[cod3mas0n]

I have a vague idea of a scenario where IPv6 might be needed. IPv4 is usually always sufficient.

Just don't use domain names for this purpose.

Agree with IPv4 is usually always sufficient., in a production environment, the database has to be in an isolated environment with so many network policies and restrictions, so I also think IPV6 is an overkill.

[bkhomuts]

IPv6 is already possible with the existing autobase by manually specifying pg_hba entries and updating the inventory file to have IPv6 instead of v4 - I have tried it on existing machines with pre-configured IPv6.

If cloud providers are used, it allows to save money, which will be noticeable especially when autobase manages many clusters, assuming each node has a public IP.

[vitabaks]

So, if this works for you, can we close the issue?

[bkhomuts]

I described a workaround. I'd recommend keeping this ticket open to have a correct solution - management of the clusters will then be predictable. As there is a workaround, priority can be low. It would be nice to implement it though.

[vitabaks]

Why do you consider this a workaround? Filling in variables such as postgresql_pg_hba is a normal practice.

The current default values for all variables are selected quite well, but it is assumed that users will specify the values necessary for their environment.

[bkhomuts]

Why do you consider this a workaround? Filling in variables such as postgresql_pg_hba is a normal practice.

In case of IPv4, addresses are detected and added to pg_hba automatically, so normal behavior is to expect the same for IPv6. That's why I consider adding the IPs manually a workaround.

I described a situation, where I deploy the hosts myself, but what if autobase does it, say on Hetzner? It won't know about the IPs to add to pg_hba.conf in advance.