|
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: kickstart-list-bounces@xxxxxxxxxx <kickstart-list-bounces@xxxxxxxxxx> on behalf of Young, Gregory <gregory.young@xxxxxxxxxxxxxx>
Sent: 04 October 2019 15:01 To: Discussion list about Kickstart <kickstart-list@xxxxxxxxxx> 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: kickstart-list-bounces@xxxxxxxxxx <kickstart-list-bounces@xxxxxxxxxx>
On Behalf Of Lee, David (LA Int,RAL,LSCI)
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. |
_______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
