Re: buildfarm server suddenly not talking to old SSL stacks?

On 07/20/2018 01:11 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Tom, please see if adding this at the top of the failing script fixes it:
>>      use IO::Socket::SSL qw (inet);
> 
> No, that doesn't work at all, but
> 
>        use IO::Socket::SSL qw (inet4);
> 
> does fix it.  Not sure how far that helps though --- we'd not want to put
> that in the buildfarm client would we?

maybe a more general option to "force ipv4 or ipv6" akin to what most 
unix networking related utilities support with -4 and -6 might be useful?

On the other side I wonder whether passing in "MultiHomed" to the 
IO::Socket::INET6 Constructor behind LWPs back might work - though the 
docs are pretty light on any details on its actual behaviour:

https://metacpan.org/pod/release/SHLOMIF/IO-Socket-INET6-2.72/lib/IO/Socket/INET6.pm#CONSTRUCTOR


> 
> Some more detail: tracing shows that IO::Socket::INET6 is getting used,
> and that contains code that purports to make the correct decision between
> IPv6 and IPv4, but it's going wrong.  It looks like what it *actually*
> does is make sure that both the local and remote addresses can be resolved
> in the same address family.  I think that the local address is probably
> "localhost", which RHEL6 will helpfully resolve as either 127.0.0.1 or ::1
> regardless of whether there's any other support for IPv6 anyplace,
> allowing INET6 to predict that the connection will work ... which it
> doesn't, but the code doesn't want to retry after failing that step.
> 
> Perhaps I could fix this by rejiggering things so that localhost only
> resolves as 127.0.0.1, but I don't really want to muck with that.
> Removing the perl-IO-Socket-INET6 package would be less invasive.

yeah the removal seems easier but do you actually know yet why the 
system started behaving differently in that regard?



Stefan