Bug 1575585

Summary:	RFE : Haproxy does not resolve ipv6 resolvable hostnames in the backend section.
Product:	Red Hat Software Collections	Reporter:	Sangam <sababu>
Component:	haproxy	Assignee:	Ryan O'Hara <rohara>
Status:	CLOSED ERRATA	QA Contact:	Brandon Perkins <bperkins>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	rh-haproxy18	CC:	pasik, redhat-bugzilla, robert.scheck, tborcin
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	3.3
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	rh-haproxy18-haproxy-1.8.17-1.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1576047 (view as bug list)		Environment:
Last Closed:	2019-06-11 12:01:34 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1576047

Description Sangam 2018-05-07 11:07:15 UTC

Description of problem: Haproxy does not resolve ipv6 resolvable ipv6 hostnames in backend section.


Version-Release number of selected component (if applicable):
rh-haproxy18-haproxy-1.8.4-1.el7.x86_64
rh-haproxy18-3.1-2.el7.x86_64
rh-haproxy18-runtime-3.1-2.el7.x86_64

How reproducible:
In one of the backend sections, if we just provide a hostname which resolves to ipv6 address, HAProxy fails to resolve ipv6 hostnames.

IPv6 hostnames being added to /etc/hosts fails to detect resolve.

Error with older version :
=============================
ipv6 address in /etc/hosts and hostname in haproxy.conf
======================================================
[root@keepalived-master ~]# haproxy -c -f /etc/haproxy/haproxy.cfg 
[ALERT] 126/093318 (9295) : parsing [/etc/haproxy/haproxy.cfg:86] : 'server app1' : invalid address: 'backend-server2' in 'backend-server2:80'

[ALERT] 126/093318 (9295) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg
[ALERT] 126/093318 (9295) : Fatal errors found in configuration.

ipv4 address in /etc/hosts and hostname in haproxy.conf
========================================================
[root@keepalived-master ~]# haproxy -c -f /etc/haproxy/haproxy.cfg 
Configuration file is valid
[root@keepalived-master ~]# 

Error with new version 1.8
=============================
[root@keepalived-master haproxy]# /opt/rh/rh-haproxy18/root/usr/sbin/haproxy -c -f /etc/opt/rh/rh-haproxy18/haproxy/haproxy.cfg
[ALERT] 126/162823 (20375) : parsing [/etc/opt/rh/rh-haproxy18/haproxy/haproxy.cfg:87] : 'server app1' : could not resolve address 'backend-server2'.
[ALERT] 126/162823 (20375) : Failed to initialize server(s) addr.
[root@keepalived-master haproxy]# 


Steps to Reproduce:
1. Add a ipv6 resolvable hostname to backend server.
2. Add appropriate ipv6 address to /etc/hosts.
3. Reload haproxy configuration, or validate the configuration.



Actual results: IPv6 hostnames does not resolve.


Expected results: IPv6 hostnames should be resolved to ip addresses


Additional info:
Note from customer referring to github page : 
=================================================
https://discourse.haproxy.org/t/haproxy-fails-to-start-with-invalid-address-when-using-ipv6-resolvable-name-in-the-backend/526
+ quote from github:
Recent systems can resolve IPv6 host names using getaddrinfo(). This primitive
is not present in all libcs and does not work in all of them either. Support in
glibc was broken before 2.3. Some embedded libs may not properly work either,
thus, support is disabled by default, meaning that some host names which only
resolve as IPv6 addresses will not resolve and configs might emit an error
during parsing. If you know that your OS libc has reliable support for
getaddrinfo(), you can add USE_GETADDRINFO=1 on the make command line to enable
it. This is the recommended option for most Linux distro packagers since it's
working fine on all recent mainstream distros. It is automatically enabled on
Solaris 8 and above, as it's known to work.

Comment 3 Ryan O'Hara 2018-05-08 13:42:47 UTC

(In reply to Sangam from comment #0)
> Additional info:
> Note from customer referring to github page : 
> =================================================
> https://discourse.haproxy.org/t/haproxy-fails-to-start-with-invalid-address-
> when-using-ipv6-resolvable-name-in-the-backend/526
> + quote from github:
> Recent systems can resolve IPv6 host names using getaddrinfo(). This
> primitive
> is not present in all libcs and does not work in all of them either. Support
> in
> glibc was broken before 2.3. Some embedded libs may not properly work either,
> thus, support is disabled by default, meaning that some host names which only
> resolve as IPv6 addresses will not resolve and configs might emit an error
> during parsing. If you know that your OS libc has reliable support for
> getaddrinfo(), you can add USE_GETADDRINFO=1 on the make command line to
> enable
> it. This is the recommended option for most Linux distro packagers since it's
> working fine on all recent mainstream distros. It is automatically enabled on
> Solaris 8 and above, as it's known to work.

Right. I was just talking with upstream about why USE_GETADDRINFO was not set for the 'linux2628' target in the Makefile. We're talking about adding an additional make target that defines USE_GETADDRINFO, but in the meantime the quick/easy solution is to add it to the make command in the spec file. Simple fix.

Comment 6 Ryan O'Hara 2018-05-09 14:06:28 UTC

*** Bug 1576047 has been marked as a duplicate of this bug. ***

Comment 7 Robert Scheck 2018-07-05 15:57:02 UTC

Cross-filed case 02135416 in the Red Hat customer portal.

Comment 8 Robert Scheck 2018-07-20 19:01:09 UTC

What's the target timeframe for getting this addressed in rh-haproxy18?

Comment 14 errata-xmlrpc 2019-06-11 12:01:34 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:1436