Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 786565 - [RFE] More robust hostname determination needed for facts
Summary: [RFE] More robust hostname determination needed for facts
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: subscription-manager
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 7.0
Assignee: candlepin-bugs
QA Contact: Entitlement Bugs
URL:
Whiteboard:
: 841689 (view as bug list)
Depends On: 656944
Blocks: rhsm-rhel72
TreeView+ depends on / blocked
 
Reported: 2012-02-01 19:10 UTC by Alex Wood
Modified: 2015-07-12 08:26 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 656944
Environment:
Last Closed: 2015-04-07 14:53:34 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Alex Wood 2012-02-01 19:10:01 UTC
In hwprobe.py's getNetworkInfo() method, we are determining the hostname with socket.gethostname().  The hostname returned by this call does not need to return a FQDN, and it may not be resolvable from outside of the one particular machine.

Imagine a machine with two network interfaces eth0 and eth1.  eth0 has an address 192.168.0.2 and goes to a private network where it is known as myserver.private.net.  This hostname is resolvable only in the private network.  eth1 has an address 10.34.32.149 and goes to the internet.  The public DNS record, which resolves to this IP address, is myserver.redhat.com.

We do not want the hostname from the private network.  We want the hostname which is accessible and usable from the machine which manages this server (e.g. the Candlepin installation).

The snippet below is a more robust way of finding the hostname.

       for family in (AF_INET6, AF_INET):
            try:
                s = socket.socket(family)
            except socket.error:
                continue

            try:
                s.settimeout(5)
                s.connect((candlepin_server, port))
                intf_tmp = s.getsockname()[0]
                if family == AF_INET:
                    intf = intf_tmp
                else:
                    intf6 = intf_tmp
                hostname_tmp = socket.getfqdn(intf_tmp)
                if hostname_tmp != intf_tmp:
                    hostname = hostname_tmp

This snippet connects to the Candlepin installation, identifies the IP address we are connecting from and then tries to determine the FQDN from this IP address.

Since a server can have different DNS records for IPv4 and IPv6 addresses, one interface can return different hostnames.  The code above favors the IPv4 hostname as in the current state of the world that is the name that is most likely correct.

Comment 6 Adrian Likins 2013-10-16 21:43:07 UTC
Why is this TestBlocker?

Comment 10 Devan Goodwin 2014-10-07 15:08:09 UTC
*** Bug 841689 has been marked as a duplicate of this bug. ***

Comment 11 Adrian Likins 2015-01-19 15:25:33 UTC
This would be more or less the same as rhn-client-tools 'findHistByRoute'.

https://github.com/spacewalkproject/spacewalk/blob/master/client/rhel/rhn-client-tools/src/up2date_client/hardware.py#L481

But that still just returns 1 hostname and 1 intf. For cases where the result there doesn't match socket.gethostname(), there is a high chance that any 1 hostname isn't going to be sufficient. And at the moment, the network info collected for facts isn't fine grained enough to represent that as well. It
may be worth expanding that.


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