On Tue, 21 Sep 2021, Yaniv Kaul wrote:
However, I do feel 'transport.address-family' should have been set to
IPv4 to force IPv4 regardless. Then the question is why
socket_client_get_remote_sockaddr() is calling
client_fill_address_family() to get the family address, but then the
next flow, a call to af_inet_client_get_remote_sockaddr() - which has
this information, but ignores it (as we see above). Y.
This isn't the only problem.
The code in the gluster servers has pretty strong assumptions in it that
IP must resolve to a hostname that resolves to the IP. Presumably as a
security check, presumably from the original (pre-SSL) security model.
This is a fragile assumption, both security wise, and operationally.
With every additional network and/or address this constraint gets harder
to maintain / more fragile.
And of course, dual-stack networks will have multiple addresses. And you
don't per se want to list an IPv6 address in the main service hostname.
You may have IPv6 only hosts and dual-stack hosts. You may use IPv6
privacy addresses, which rotate.
This assumption may work initially, but then fail later down the road.
It makes gluster very flakey operationally, with IPv6.
When you're using SSL for security, which provides a _secure_ notion of
identity (unlike IP and hostname), independent of addresses, this
fragile assumption feels antiquated.
regards,
--
Paul Jakma | paul@xxxxxxxxx | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
At the source of every error which is blamed on the computer you will find
at least two human errors, including the error of blaming it on the computer.
-------
Community Meeting Calendar:
Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: https://meet.google.com/cpu-eiue-hvk
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel
