Thanks, Gregory. I think we're getting there. But fixing the content of the returned DHCP/ACK "domain-name" option doesn't fix the problem.
Another subtle difference in the initial DHCP exchange is that for the good network the returned DHCP 'ACK' includes a router (option 3), but on the small subdomain, there is no router information in the ACK. For local reasons, that subdomain is specifically un-routeable, and we use bastion hosts for access. So this configuration of not specifying a router is understandable. If I adjust the Infoblox/DHCP entry for the host to specify a router address (even though, of course, there is no router function at that address), then things work OK. So it seems that anaconda's(?) decision of whether or not to do that DNS PTR query is based on the presence or absence of the router option from the preceding DHCP/ACK. -- David ________________________________ From: [email protected] <[email protected]> on behalf of Young, Gregory <[email protected]> Sent: 04 October 2019 15:01 To: Discussion list about Kickstart <[email protected]> Subject: RE: RHEL7 kickstart: how is hostname determined? I would start by fixing the DHCP on the subdomain subnet. You will want to send the correct “sub.company.org” for the option 15. Gregory Young From: [email protected] <[email protected]> On Behalf Of Lee, David (LA Int,RAL,LSCI) Sent: October 4, 2019 4:22 AM To: [email protected] Subject: RHEL7 kickstart: how is hostname determined? All our hosts are registered in an Infoblox DHCP+DNS service as MAC+IP+hostname. We have two one domains and one subdomain. When we kickstart-install a new RHEL7 host on the main domain, it cleanly gets its intended hostname from Infoblox/DNS. We can see this very early on by doing an Alt-F2 and querying the hostname. All is well. But on the subdomain it gets the name "localhost.localdomain" (which seems to be the "in the absence of anything else" default). A wireshark trace of installations shows a DHCP request and ack. On the main domain this is quickly followed by a DNS PTR query from the host, giving the host's IP address and successfully returning the host's hostname. By contrast, on the subdomain, this query is never initiated. (On both domains, there are subsequent successful DNS queries of other things as part of the ensuing installation, demonstrating that DNS activity is happening.) What might be triggering the hosts on the two different domains to behave differently, that is, send or not send that DNS/PTR query? Looking deeper into that preceding DHCP request/ACK: The main domain, where all works well, is (for example) "company.org". The subdomain (where this lack of hostname issue arises) is a subdomain, e.g. "sub.company.org". One oddity I spotted, is that the DHCP/ACK returns the same "domain-name" option-15 "company.org" for both. I wonder if that is precipitating a subsequent problematical behaviour in that "sub.company.org" context? Any thoughts? Thanks. -- David Lee -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
_______________________________________________ Kickstart-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/kickstart-list
