Bug 1444824
Summary: | Disabling ipv6 on RHEL7.3 still fetches ipv6 entry for getent `uname -n` command | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Yogita <ysoni> |
Component: | systemd | Assignee: | Jan Synacek <jsynacek> |
Status: | CLOSED ERRATA | QA Contact: | Frantisek Sumsal <fsumsal> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.3 | CC: | ashankar, fsumsal, fweimer, igreen, iptables-maint-list, jason.faultless, jsynacek, mjw, mnewsome, pfrankli, systemd-maint-list, wayne.johnson |
Target Milestone: | rc | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | systemd-219-44.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-04-10 11:19:30 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: |
Description
Yogita
2017-04-24 11:49:07 UTC
This is not an iptables issue. Reassigning to (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? (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`" ??? 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. 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. (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. 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? (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. 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. fix merged to upstream staging branch -> https://github.com/lnykryn/systemd-rhel/pull/116 -> post 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 |