Bug 1575585 - RFE : Haproxy does not resolve ipv6 resolvable hostnames in the backend section.
Summary: RFE : Haproxy does not resolve ipv6 resolvable hostnames in the backend section.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Software Collections
Classification: Red Hat
Component: haproxy
Version: rh-haproxy18
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
: 3.3
Assignee: Ryan O'Hara
QA Contact: Brandon Perkins
URL:
Whiteboard:
: 1576047 (view as bug list)
Depends On:
Blocks: 1576047
TreeView+ depends on / blocked
 
Reported: 2018-05-07 11:07 UTC by Sangam
Modified: 2022-03-13 14:57 UTC (History)
4 users (show)

Fixed In Version: rh-haproxy18-haproxy-1.8.17-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1576047 (view as bug list)
Environment:
Last Closed: 2019-06-11 12:01:34 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:1436 0 None None None 2019-06-11 12:01:48 UTC

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


Note You need to log in before you can comment on or make changes to this bug.