Bug 1444824 - Disabling ipv6 on RHEL7.3 still fetches ipv6 entry for getent `uname -n` command
Summary: Disabling ipv6 on RHEL7.3 still fetches ipv6 entry for getent `uname -n` command
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.3
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jan Synacek
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-24 11:49 UTC by Yogita
Modified: 2020-06-11 13:40 UTC (History)
12 users (show)

Fixed In Version: systemd-219-44.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 11:19:30 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0711 0 None None None 2018-04-10 11:20:54 UTC

Description Yogita 2017-04-24 11:49:07 UTC
Description of problem:
Disabling ipv6 on RHEL7.3 still fetches ipv6 entry for getent `uname -n` command

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Server release 7.3 (Maipo)
iptables-1.4.21-17.el7.x86_64

How reproducible:
1) Disable IPV6 on RHEL7.3 machine -
# vim /etc/sysctl.d/ipv6.conf
net.ipv6.conf.all.disable_ipv6 = 1
:wq
#sysctl -p /etc/sysctl.d/ipv6.conf
#dracut -f

2)[root@client ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4

3) Execute below command -
[root@client ~]# getent hosts `uname -n`
::1             client.example.com localhost

The output should actually have shown ipv4 address , please see this KCS article - https://access.redhat.com/solutions/1287253

Following the steps in KCS does resolves the issue -
[root@client ~]# getent hosts `uname -n`
192.168.100.120 client.example.com


Actual results:
::1             client.example.com localhost

Expected results:
It should have shown no entry for ipv6

Additional info:
Customer needs to know why is it showing entry for ipv6 , despite it being disabled , which is not covered in the KCS article.

Comment 2 Thomas Woerner 2017-04-24 12:08:05 UTC
This is not an iptables issue.

Reassigning to

Comment 3 Florian Weimer 2017-04-24 12:18:11 UTC
(In reply to Yogita from comment #0)
> 3) Execute below command -
> [root@client ~]# getent hosts `uname -n`
> ::1             client.example.com localhost
> 
> The output should actually have shown ipv4 address , please see this KCS
> article - https://access.redhat.com/solutions/1287253

“getent hosts” is implemented by performing an AF_INET6 lookup first, and if that fails, an AF_INET lookup.  The host IPv6 capability does not matter in this context.  This is working as intended, I would say.

What is the actual bug here?

Comment 4 Yogita 2017-04-24 12:30:57 UTC
(In reply to Florian Weimer from comment #3)

> What is the actual bug here?
The bug is despite ipv6 being disabled , why is it showing the output in -
"getent hosts `uname -n`" ???

Comment 5 Florian Weimer 2017-04-24 14:10:11 UTC
Reassigning to systemd for further debugging.

glibc gets an IPv6 address from myhostname for an AF_INET6 name lookup, while the intent clearly is that myhostname should not deliver any address information:

                if (af == AF_INET6 && !socket_ipv6_is_supported()) {
                        n_addresses = 0;
                } else {
                        n_addresses = local_addresses(NULL, 0, af, &addresses);
                        if (n_addresses < 0)
                                n_addresses = 0;
                }

Seen with systemd-libs-219-30.el7_3.8.x86_64.

Our shipped systemd package does not have usable debugging symbols, so I don't know how to debug this further.  I don't know if socket_ipv6_is_supported returns true or not in the system configuration, for example.

Comment 6 Yogita 2017-04-25 04:13:51 UTC
Below is working from Customers system -

Hostname configured as dnvtest01 in /etc/hostname.
resolv.conf contains ‘search amd.three.ie’.

With myhostname enabled in nsswitch.conf:

IPv6 disabled:
[root@dnvtest01 ~]# sysctl -a | grep ipv6 | grep disable
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

[root@dnvtest01 ~]# getent hosts `uname -n`
::1             dnvtest01 localhost    <---expect IPv4 shown here as received from DNS as IPv6 is disabled

IPv6 enabled:
[root@dnvtest01 ~]# sysctl -a | grep ipv6 | grep disable
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.eth0.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

[root@dnvtest01 ~]# getent hosts `uname -n`
fe80::250:56ff:fea0:2d56 dnvtest01   <--- result coming from myhostname as no entry in /etc/hosts and not ipv6 DNS available; however, expect both (IPv4 & IPv6, as mentioned in myhostname man page “The local, configured hostname is resolved to all locally configured IP addresses ordered by their scope”)

With myhostname removed from nsswitch.conf:

IPv6 disabled:
[root@dnvtest01 ~]# sysctl -a | grep ipv6 | grep disable
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1


[root@dnvtest01 ~]# getent hosts `uname -n`
198.18.228.143  dnvtest01.amd.three.ie                <--- expected result; IPv6 disabled result coming from DNS

IPv6 enabled:
[root@dnvtest01 ~]# sysctl -a | grep ipv6 | grep disable
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.eth0.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

[root@dnvtest01 ~]# getent hosts `uname -n`
198.18.228.143  dnvtest01.amd.three.ie                <--- expect both (IPv4 & IPv6, as mentioned in myhostname man page “The local, configured hostname is resolved to all locally configured IP addresses ordered by their scope”)

--------
Summary:
--------
Expected behaviour would be to show both entries (ipv4 & ipv6) in case IPv6 is enabled, and only IPv4 in case IPv6 is disabled. Entries in /etc/hosts seem to be ignored completely.

Comment 7 Jan Synacek 2017-04-26 08:14:35 UTC
(In reply to Yogita from comment #6)
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1

This only disables IPv6 functionality on all interfaces, but the ipv6 kernel modules still load.

This is how we check if IPv6 is supported:

bool socket_ipv6_is_supported(void) {
        _cleanup_free_ char *l = NULL;

        if (access("/sys/module/ipv6", F_OK) != 0)
                return false;

        /* If we can't check "disable" parameter, assume enabled */
        if (read_one_line_file("/sys/module/ipv6/parameters/disable", &l) < 0)
                return true;

        /* If module was loaded with disable=1 no IPv6 available */
        if (l[0] == '1')
                return false;

        free(l);
        l = NULL;

        if (read_one_line_file("/proc/sys/net/ipv6/conf/all/disable_ipv6", &l) < 0)
                return true;

        /* If IPv6 was disabled via sysctl during runtime */
        return l[0] == '0';
}

If you really want to disable IPv6, you should specify "ipv6.disable=1" on the kernel command line (see https://access.redhat.com/solutions/8709).

I believe that this is not a bug.

Comment 8 Yogita 2017-04-27 02:29:54 UTC
Hello Jan ,

IPv6 IS disabled. If you read farther along in the article you referred me to https://access.redhat.com/solutions/8709 it says 'Alternatively this can be done ...'. That's exactly what we used - disable ipv6 using sysctl. 

I also tried the first approach using ipv6.disable=1 in grub. This did not change anything. Still I see only '::1 ...'.

[root@server ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
192.168.100.170	server.example.com

[root@server ~]# getent hosts `uname -n`
::1             server.example.com localhost  <--- Still showing ipv6 entry.

And this is the bug exactly , please can you justify despite disabling the entry for ipv6 at both kernel and file level , why is it showing the entry in getent command?

Comment 10 Jan Synacek 2017-05-03 06:09:26 UTC
(In reply to Yogita from comment #8)
> Hello Jan ,
> 
> IPv6 IS disabled. If you read farther along in the article you referred me
> to https://access.redhat.com/solutions/8709 it says 'Alternatively this can
> be done ...'. That's exactly what we used - disable ipv6 using sysctl. 

Depends on what you call disabled ipv6. Using the sysctl method disables ipv6 on all ethernet devices, but the ipv6 kernel modules still load. I don't know exactly what else from ipv6 functionality can be used if the modules are loaded but the devices don't support it. I really think that the article should be modified, because it's misleading, especially the "Alternatively this can be done..." part.

> And this is the bug exactly , please can you justify despite disabling the
> entry for ipv6 at both kernel and file level , why is it showing the entry
> in getent command?

It's probably a bug in nss-myhostname, I was too quick in my decision. Sorry about the confusion.

Comment 11 Need Real Name 2017-05-03 12:17:18 UTC
As as aside, this was already documented in
https://access.redhat.com/solutions/2909021

nss-myhostname was unconditionally added to nsswitch.conf by systemd in the RHEL7.3 update. Previously it was not present in our build.
# sed-fu to add myhostname to the hosts line of /etc/nsswitch.conf'

This caused an unexpected change in the behaviour for us.

Comment 15 Jan Synacek 2017-05-04 10:45:32 UTC
https://github.com/lnykryn/systemd-rhel/pull/116

Comment 23 Lukáš Nykrýn 2017-09-07 08:15:57 UTC
fix merged to upstream staging branch -> https://github.com/lnykryn/systemd-rhel/pull/116 -> post

Comment 28 errata-xmlrpc 2018-04-10 11:19:30 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/RHBA-2018:0711


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