Bug 1595384

Summary: getent play in validate_hostname_tasks.yml results in failure when short hostname listed first in /etc/hosts
Product: [oVirt] ovirt-hosted-engine-setup Reporter: Dustin Black <dblack>
Component: NetworkAssignee: Simone Tiraboschi <stirabos>
Status: CLOSED CURRENTRELEASE QA Contact: Nikolai Sednev <nsednev>
Severity: medium Docs Contact:
Priority: medium    
Version: ---CC: bugs, jcall, lsurette, mkarg, stirabos
Target Milestone: ovirt-4.2.7Keywords: Triaged
Target Release: ---Flags: rule-engine: ovirt-4.2+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-hosted-engine-setup-2.2.27-1.el7ev.noarch.rpm Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-11-02 14:35:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1629888    

Description Dustin Black 2018-06-26 19:31:16 UTC
Description of problem:
Installation of hosted engine fails with a name resolution error. This can be traced to the getent play in the validate_hostname_tasks.yml playbook. When the node hostname is defined in the local /etc/hosts file with the short hostname listed first after the IP address, the getent command run against the FQDN will return only the short hostname, causing the piped grep in that play to fail to return a match.

Version-Release number of selected component (if applicable):
ovirt-hosted-engine-setup-2.2.20-1.el7ev.noarch

How reproducible:
consistently

Steps to Reproduce:
1. Add /etc/hosts entry with short hostname before long hostname as in:

10.10.5.2 hostname hostname.example.com

2. Run the hosted engine installer

Actual results:
Install fails with name resolution error

Expected results:
Install succeeds

Additional info:

Comment 1 Simone Tiraboschi 2018-07-25 12:14:40 UTC
According to 
 man hosts
the syntax of /etc/hosts is
IP_address canonical_hostname [aliases...]
so the first entry after the IP address is the canonical_hostname by design and it's correct to consume that one.

Comment 2 Marko Karg 2018-07-25 12:29:08 UTC
Correct, this is what the man page says. Unfortunately even Red Hat delivers an /etc/hosts files on a fresh installation that looks like this:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

That said it'd be great if we could make the hostname verification part more robust and less error-prone when it comes to resolving names via hosts.

Comment 3 Nikolai Sednev 2018-10-10 12:47:43 UTC
alma03 ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.35.92.51 nsednev-he-1 nsednev-he-1.qa.lab.tlv.redhat.com

Works for me on these components:
ovirt-engine-setup-plugin-ovirt-engine-4.2.7.3-0.0.master.20181008113103.git4718e0f.el7.noarch
ovirt-hosted-engine-setup-2.2.29-0.0.master.20181002122252.git9ae169e.el7.noarch
ovirt-hosted-engine-ha-2.2.19-0.0.master.20181002122327.20181002122322.gitb449616.el7.noarch
Red Hat Enterprise Linux Server release 7.5 (Maipo)
Linux 3.10.0-862.14.4.el7.x86_64 #1 SMP Fri Sep 21 09:07:21 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Comment 4 Sandro Bonazzola 2018-11-02 14:35:10 UTC
This bugzilla is included in oVirt 4.2.7 release, published on November 2nd 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.7 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.