Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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.
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.
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.