Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1517722 - ipv6 of compute-0.localdomain resolves to ::1 instead NOTFOUND and then fallback to ipv4
Summary: ipv6 of compute-0.localdomain resolves to ::1 instead NOTFOUND and then fallb...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 10.0 (Newton)
Assignee: James Slagle
QA Contact: Amit Ugol
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-27 10:15 UTC by Mehdi ABAAKOUK
Modified: 2019-04-15 13:53 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-15 13:53:51 UTC


Attachments (Terms of Use)

Description Mehdi ABAAKOUK 2017-11-27 10:15:43 UTC
Description of problem:

Some services uses fqdn (like "compute-0.localdomain") generated by tripleo in configuration file.

But when application try to get the IP behind "compute-0.localdomain" it got "::1" instead of the real IPV4.

This makes the application connecting to localhost instead of the expected  server.


Additional info:

This behavior is due to this weird nsswitch.conf change done by tripleo:

#hosts:     db files nisplus nis dns
hosts:      files dns myhostname

The module "myhostname" resolves any NOTFOUND finishing by .localdomain to ::1 and 127.0.0.1.

For me, "myhostname" module should never ever be used, /etc/hosts should be filled correctly with all expected entry instead.

Comment 1 Mehdi ABAAKOUK 2017-11-27 10:28:48 UTC
maybe related to this: https://access.redhat.com/solutions/2766251

Comment 3 James Slagle 2017-12-08 14:03:23 UTC
sounds like the cause is the referenced systemd solution.

however, you should have still had all hostnames written statically to /etc/hosts, so nsswitch.conf never should have fallen back to the myhostname service.

Can you check what you have in /etc/hosts?

Comment 4 James Slagle 2017-12-08 14:03:56 UTC
(In reply to James Slagle from comment #3)
> sounds like the cause is the referenced systemd solution.
> 
> however, you should have still had all hostnames written statically to
> /etc/hosts, so nsswitch.conf never should have fallen back to the myhostname
> service.
> 
> Can you check what you have in /etc/hosts?

For clarification, I mean /etc/hosts on one of the overcloud nodes, such as one of the controllers.

Comment 5 Mehdi ABAAKOUK 2017-12-08 17:06:24 UTC
The following /etc/hosts have not been touched, this is the one deployed by OSP.

The thing is that the hosts file only contains IPV4. So when the application asks a dns resolution, ipv6 is tried first, because no address is found for ipv6 in the hosts file, it use "myhostname" module and returns ::1 and does not try ipv4.

# HEADER: This file was autogenerated at 2017-10-14 19:40:47 -0400
# HEADER: by puppet.  While it can still be managed manually, it
# HEADER: is definitely not recommended.
127.0.0.1       localhost       localhost.localdomain localhost4 localhost4.localdomain4
::1     localhost       localhost.localdomain localhost6 localhost6.localdomain6


# HEAT_HOSTS_START - Do not edit manually within this section!
192.168.5.182 overcloud-controller-xxxxxx-0.xxxxxx.xxxxxx.com overcloud-controller-xxxxxx-0
10.251.132.192 overcloud-controller-xxxxxx-0.external.xxxxxx.xxxxxx.com overcloud-controller-xxxxxx-0.external
192.168.5.182 overcloud-controller-xxxxxx-0.internalapi.xxxxxx.xxxxxx.com overcloud-controller-xxxxxx-0.internalapi
192.168.3.180 overcloud-controller-xxxxxx-0.storage.xxxxxx.xxxxxx.com overcloud-controller-xxxxxx-0.storage
192.168.4.182 overcloud-controller-xxxxxx-0.storagemgmt.xxxxxx.xxxxxx.com overcloud-controller-xxxxxx-0.storagemgmt
192.168.6.184 overcloud-controller-xxxxxx-0.tenant.xxxxxx.xxxxxx.com overcloud-controller-xxxxxx-0.tenant
192.168.8.185 overcloud-controller-xxxxxx-0.management.xxxxxx.xxxxxx.com overcloud-controller-xxxxxx-0.management
192.168.2.21 overcloud-controller-xxxxxx-0.ctlplane.xxxxxx.xxxxxx.com overcloud-controller-xxxxxx-0.ctlplane
...

Comment 6 Mehdi ABAAKOUK 2018-01-09 15:02:15 UTC
*** Bug 1516711 has been marked as a duplicate of this bug. ***


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