[MDEV-32905] Clarification regarding gmcast.listen_addr (wsrep_provider_options) Created: 2023-11-29  Updated: 2023-12-12

Status: Open
Project: MariaDB Server
Component/s: Galera
Fix Version/s: 10.4, 10.5, 10.6

Type: Task Priority: Major
Reporter: Edward Stoever Assignee: Teemu Ollakka
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Customer claims this value for gmcast.listen_addr worked in 10.3:

gmcast.listen_addr=ssl://RH1.edw.ee:4567

I don't think a hostname could work.

In my tests on 10.4 and higher, if you use a hostname for gmcast.listen_addr, the command galera_new_cluster hangs indefinitely (unless wsrep_cluster_address is defined with only one host).

Part of this question relates to the difference between tcp and ssl. It appears that you can define in either one of these ways:

gmcast.listen_addr=tcp://192.168.8.111:4567
gmcast.listen_addr=ssl://192.168.8.111:4567

Only tcp is mentioned as a possibility in documentation. Is ssl also a supported possibility? Is ssl handled different from tcp?

IPV6 is another undocumented issue. IPV6 for gmcast.listen_addr is discussed here:
https://github.com/codership/galera/issues/534
Documentation should discuss IPV6 with an example of how to define an address.

We need to clarify what is supported and what is not. Supported configuration needs to be included in documentation. If a hostname is not possible, documentation could mention this too.



 Comments   
Comment by Daniel Black [ 2023-11-29 ]

TLS requires a DH exchange between client and server which both preserve shared secrets on both sides. Its not possible on a multicast environment where nodes don't share secrets.

DTLS where there is some communication of the key upon joining the cluster is a possibility of DTLS over multicast and I think there's some defined protocols for this, they just haven't been implemented.

listen_addr would require a multicast address so normal unicast addresses can't be used. If DNS is used that needs to resolve to a multicast address.

Generated at Thu Feb 08 10:34:55 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.