Bug 1401394
| Summary: | Mismatch in the 'fqdn' fact on a machine which has differing ipv4 and ipv6 dns entries | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Rehana <redakkan> |
| Component: | subscription-manager | Assignee: | Kevin Howell <khowell> |
| Status: | CLOSED ERRATA | QA Contact: | John Sefler <jsefler> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.4 | CC: | khowell, redakkan, skallesh |
| Target Milestone: | rc | Keywords: | EasyFix, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 19:20:42 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: | |||
I am not a network expert, but it appears that this system is configured for both ipV4 and ipV6 using different hostnames for each...
[root@ibm-z-24 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 02:de:ad:be:ef:18 brd ff:ff:ff:ff:ff:ff
inet 10.16.66.215/21 brd 10.16.71.255 scope global eth0
inet6 2620:52:0:1040:de:adff:febe:ef18/64 scope global dynamic
valid_lft 2591987sec preferred_lft 604787sec
inet6 fe80::de:adff:febe:ef18/64 scope link
valid_lft forever preferred_lft forever
[root@ibm-z-24 ~]#
[root@ibm-z-24 ~]# subscription-manager facts | grep eth0.ipv
net.interface.eth0.ipv4_address: 10.16.66.215
net.interface.eth0.ipv4_address_list: 10.16.66.215
net.interface.eth0.ipv4_broadcast: 10.16.71.255
net.interface.eth0.ipv4_broadcast_list: 10.16.71.255
net.interface.eth0.ipv4_netmask: 21
net.interface.eth0.ipv4_netmask_list: 21
net.interface.eth0.ipv6_address.global: 2001:db8:1:0:de:adff:febe:ef18
net.interface.eth0.ipv6_address.global_list: 2620:52:0:1040:de:adff:febe:ef18, 2001:db8:1:0:de:adff:febe:ef18
net.interface.eth0.ipv6_address.link: fe80::de:adff:febe:ef18
net.interface.eth0.ipv6_address.link_list: fe80::de:adff:febe:ef18
net.interface.eth0.ipv6_netmask.global: 64
net.interface.eth0.ipv6_netmask.global_list: 64, 64
net.interface.eth0.ipv6_netmask.link: 64
net.interface.eth0.ipv6_netmask.link_list: 64
[root@ibm-z-24 ~]#
[root@ibm-z-24 ~]# host 10.16.66.215
215.66.16.10.in-addr.arpa domain name pointer ibm-z-24.rhts.eng.bos.redhat.com.
[root@ibm-z-24 ~]#
[root@ibm-z-24 ~]# host 2620:52:0:1040:de:adff:febe:ef18
8.1.f.e.e.b.e.f.f.f.d.a.e.d.0.0.0.4.0.1.0.0.0.0.2.5.0.0.0.2.6.2.ip6.arpa domain name pointer ibm-z10-24.rhts.eng.bos.redhat.com.
[root@ibm-z-24 ~]#
[root@ibm-z-24 ~]# host 2001:db8:1:0:de:adff:febe:ef18
Host 8.1.f.e.e.b.e.f.f.f.d.a.e.d.0.0.0.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN)
[root@ibm-z-24 ~]#
[root@ibm-z-24 ~]# host fe80::de:adff:febe:ef18
Host 8.1.f.e.e.b.e.f.f.f.d.a.e.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa not found: 3(NXDOMAIN)
[root@ibm-z-24 ~]#
[root@ibm-z-24 ~]#
[root@ibm-z-24 ~]# hostname --all-fqdn
ibm-z-24.rhts.eng.bos.redhat.com ibm-z10-24.rhts.eng.bos.redhat.com
[root@ibm-z-24 ~]#
In light of this observation, it feels like the single valued subscription-manager fact for "network.fqdn" is not sufficient. Maybe we should follow the lead from bug 874735 and add an additional list fact "network.fqdn_list" that would contain all of the fqdn's (which appears to be a mixture of hostnames that resolve from the found *.ipv4_address_list and *.ipv6_address.global_list addresses.
NOTE: right now we are using python's socket module to determine fqdn; instead if we use `hostname -f` (shell out), then we'll match what puppet and `hostname -f` treat as the fqdn. Retesting on s390x machine with latest subscription-manager versions [root@ibm-z-24 ~]# subscription-manager version server type: This system is currently not registered. subscription management server: 0.9.51.21-1 subscription management rules: 5.15.1 subscription-manager: 1.19.13-1.el7 python-rhsm: 1.19.6-1.el7 [root@ibm-z-24 ~]# subscription-manager facts --list | grep ens* lscpu.hypervisor_vendor: IBM lscpu.vendor_id: IBM/S390 net.interface.enccw0.0.8000.ipv4_address: 10.16.66.215 net.interface.enccw0.0.8000.ipv4_address_list: 10.16.66.215 net.interface.enccw0.0.8000.ipv4_broadcast: 10.16.71.255 net.interface.enccw0.0.8000.ipv4_broadcast_list: 10.16.71.255 net.interface.enccw0.0.8000.ipv4_netmask: 21 net.interface.enccw0.0.8000.ipv4_netmask_list: 21 net.interface.enccw0.0.8000.ipv6_address.global: 2001:db8:1:0:de:adff:febe:ef18 net.interface.enccw0.0.8000.ipv6_address.global_list: 2620:52:0:1040:de:adff:febe:ef18, 2001:db8:1:0:de:adff:febe:ef18 net.interface.enccw0.0.8000.ipv6_address.link: fe80::de:adff:febe:ef18 net.interface.enccw0.0.8000.ipv6_address.link_list: fe80::de:adff:febe:ef18 net.interface.enccw0.0.8000.ipv6_address.site: fec0::f101:de:adff:febe:ef18 net.interface.enccw0.0.8000.ipv6_address.site_list: fec0::f101:de:adff:febe:ef18 net.interface.enccw0.0.8000.ipv6_netmask.global: 64 net.interface.enccw0.0.8000.ipv6_netmask.global_list: 64, 64 net.interface.enccw0.0.8000.ipv6_netmask.link: 64 net.interface.enccw0.0.8000.ipv6_netmask.link_list: 64 net.interface.enccw0.0.8000.ipv6_netmask.site: 64 net.interface.enccw0.0.8000.ipv6_netmask.site_list: 64 net.interface.enccw0.0.8000.mac_address: 02:DE:AD:BE:EF:18 network.fqdn: ibm-z-24.rhts.eng.bos.redhat.com network.hostname: ibm-z-24.rhts.eng.bos.redhat.com The system is configured with a FQDN and short hostname [root@ibm-z-24 ~]# hostname -s ibm-z-24 [root@ibm-z-24 ~]# hostname -f ibm-z-24.rhts.eng.bos.redhat.com [root@ibm-z-24 ~]# hostname --all-fqdns ibm-z-24.rhts.eng.bos.redhat.com ibm-z-24.rhts.eng.bos.redhat.com ibm-z-24.rhts.eng.bos.redhat.com [root@ibm-z-24 ~]# subscription-manager facts --list | grep fqdn network.fqdn: ibm-z-24.rhts.eng.bos.redhat.com ^^ Observed that fact value for network.fqdn collected is matching the hostname -f value of the system. Marking as Verified!! 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-2017:2083 |
Description of problem: Version-Release number of selected component (if applicable): # subscription-manager version server type: Red Hat Subscription Management subscription management server: 0.9.51.20-1 subscription management rules: 5.15.1 subscription-manager: 1.18.5-1.el6 python-rhsm: 1.18.5-1.el6 How reproducible: always Steps to Reproduce: 1. check fqdn using hostname command # hostname --fqdn ibm-z-24.rhts.eng.bos.redhat.com 2.Verify the fqdn entry in fact list # subscription-manager facts --list | grep fqdn network.fqdn: ibm-z10-24.rhts.eng.bos.redhat.com ^^^^^^ Actual results: Instead of "z" the "fqdn" facts list shows 'z10'. Expected results: Value of fqdn in facts list should match the hostname --fqdn Additional info: could not find any error in rhsm.log except some warnings 2016-12-05 01:49:10,042 [INFO] subscription-manager:7224:MainThread @connection.py:758 - Connection built: host=subscription.rhsm.stage.redhat.com port=443 handler=/subscription auth=none 2016-12-05 01:49:10,046 [DEBUG] subscription-manager:7224:MainThread @hwprobe.py:174 - Not looking for DMI info since it is not available on 's390x' 2016-12-05 01:49:10,047 [WARNING] subscription-manager:7224:MainThread @hwprobe.py:908 - <bound method Hardware.get_proc_cpuinfo of <subscription_manager.hwprobe.Hardware instance at 0x893e9288>> 2016-12-05 01:49:10,047 [WARNING] subscription-manager:7224:MainThread @hwprobe.py:909 - Hardware detection failed: 2016-12-05 01:49:10,047 [DEBUG] subscription-manager:7224:MainThread @hwprobe.py:483 - /proc/sysinfo found, attempting to gather cpu topology info 2016-12-05 01:49:10,047 [DEBUG] subscription-manager:7224:MainThread @hwprobe.py:336 - Looking for 'CPU Topology SW' in sysinfo, but it was not found 2016-12-05 01:49:10,047 [DEBUG] subscription-manager:7224:MainThread @hwprobe.py:580 - cpu info: {'cpu.thread(s)_per_core': 1, 'cpu.socket(s)_per_book': 1, 'cpu.book(s)': 2, 'cpu.core(s)_per_socket': 1, 'cpu.topology_source': 's390 book_siblings_list', 'cpu.book(s)_per_cpu': 1, 'cpu.cpu_socket(s)': 2, 'cpu.cpu(s)': 2} 2016-12-05 01:49:10,225 [DEBUG] subscription-manager:7224:MainThread @hwprobe.py:808 - Running 'virt-what' 2016-12-05 01:49:10,309 [DEBUG] subscription-manager:7224:MainThread @hwprobe.py:812 - virt-what stdout: ibm_systemz ibm_systemz-zvm 2016-12-05 01:49:10,310 [DEBUG] subscription-manager:7224:MainThread @hwprobe.py:813 - virt-what stderr: 2016-12-05 01:49:10,310 [WARNING] subscription-manager:7224:MainThread @hwprobe.py:838 - Error finding UUID: Virtualization platform does not support UUIDs 2016-12-05 01:49:10,310 [INFO] subscription-manager:7224:MainThread @hwprobe.py:918 - collected virt facts: virt.is_guest=True, virt.host_type=ibm_systemz, ibm_systemz-zvm, virt.uuid=Not Set # cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 # cat /etc/resolv.conf # Generated by NetworkManager search rhts.eng.bos.redhat.com nameserver 10.11.5.19