Bug 1592974

Summary:	[RFE] If adcli requires FQDN in `hostname` output, would it be possible to have it use `hostname -f` instead?
Product:	Red Hat Enterprise Linux 6	Reporter:	Josip Vilicic <jvilicic>
Component:	adcli	Assignee:	Sumit Bose <sbose>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.9	CC:	mkosek, pcech
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-14 12:44:02 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Josip Vilicic 2018-06-19 18:12:49 UTC

1. Proposed title of this feature request  
   If a FQDN is required to properly join a RHEL host to Active Directory with `adcli`, and the RHEL host returns a shortname with `hostname` and `hostname -f` returns the FQDN, would it be possible to have `adcli` use `hostname -f` instead?


2. Who is the customer behind the request?  
   Account: University Of Central Florida (1295742)
   TAM customer:  Not that I can tell
   SRM customer:  Not that I can tell
   Strategic:  Not that I can tell
  

3. What is the nature and description of the request?  
   This customer has a large number of RHEL hosts joined to Active Directory with `adcli`.  Some return a FQDN with `hostname` and some return a short name.  Having the short name returned with `hostname` is preferable for some of their internal operations.
   After joining the servers to AD, the servers with shortname `hostname` output had their DNS records  scavenged by AD because their TTL had not been updated.  The workaround is to have "ad_hostname=fqdn" specified in sssd.conf.


4. Why does the customer need this? (List the business requirements here)  
   The customer is asking "if adcli truly needs a FQDN, why does it not use `hostname -f`?" which returns the FQDN in their environment.  Having to configure all their hosts to return a FQDN for `hostname` output would be a lot of work.


5. How would the customer like to achieve this? (List the functional requirements here)  
   Have `adcli` require `hostname -f` output instead of `hostname` if it truly requires a FQDN


6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.  
   The customer can verify if DNS records are updated and an AD join persists for hosts that have shortnames
   

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?  
   Related bug:  "Bug 86107 - adcli not using fqdn" -- https://bugs.freedesktop.org/show_bug.cgi?id=86107
   Upstream bug and discussion:  "DDNS not working due to non FQDN hostname" -- https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/QHBRCO2JR36PT5F4ZPZNGUHCEE5E4G42/


8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
   They have RHEL 6 hosts that they are joining to AD


9. Is the sales team involved in this request and do they have any additional input?  
   Not at the moment


10. List any affected packages or components.  
    adcli, sssd, Active Directory environment


11. Would the customer be able to assist in testing this functionality if implemented?
    Yes

Comment 2 Josip Vilicic 2018-06-19 18:16:04 UTC

Additional information:


1) The `hostname` output only has a shortname:

   $ cat hostname 
   net1682


2) Similarly, the kernel is only aware of the short name:

   $ cat proc/sys/kernel/hostname 
   net1682


3) But /etc/sysconfig/network has the FQDN:

   $ cat etc/sysconfig/network
   NETWORKING=yes
   HOSTNAME=net1682.net.ucf.edu


4) This may be what returns the shortname:

$ cat etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
BOOTPROTO="dhcp"
#GATEWAY="10.169.200.1"
HOSTNAME="net1682"            <----------
HWADDR="00:50:56:B1:8D:60"
#IPADDR="10.169.200.79"
IPV6INIT="no"
MTU="1500"
#NETMASK="255.255.255.0"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"
UUID="ddd7b117-364c-46be-b373-fc6f7c52e3d4"

Comment 3 Sumit Bose 2018-06-20 10:52:26 UTC

First, given that RHEL6 is in Maintenance Phase 2, most probable there will be no change to adcli in RHEL6 anymore, see https://access.redhat.com/support/policy/updates/errata for details.

As the adcli man page says adcli uses gethostname() to get the hostname not the hostname command. gethostname() uses the hostname data from the kernel. adcli does this to have a reliable and unique source of the name. The plain hostname command uses the same call.

'hostname -f' tries to canonicalize  the name with the help of a reverse DNS lookup. This might work in some environments but fail in others. Often AD DNS servers do not have the table needed for reverse lookups properly filled. Additionally you might run into issue if multiple network interfaces are used. That's why adcli does not use this as a fallback.

If 'hostname -f' is reliable working in the given environment and given that the chances for a change in RHEL6 are minimal I would suggest to join with:

    adcli join --host-fqdn=$(hostname -f) --domin=...

bye,
Sumit

Comment 4 Martin Kosek 2019-05-14 12:44:02 UTC

Red Hat Enterprise Linux 6 is in the Maintenance Support 2 Phase. During the Maintenance Support 2 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:
http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Maintenance Support 2 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification.  Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com