RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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: 1113520 rhsm-rhel72 1205796
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.