-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ability to set hostname via DHCPv4 client #717
Conversation
What will happen if the dhcp server doesn't set the hostname for the IP? |
This adds a boolean config option, os.dhclient_set_hostname, which maps to DHCLIENT_SET_HOSTNAME in /etc/sysconfig/network/dhcp. When running the installer interactively, there's a new "Set via DHCP" drop down field on the hostname page. The default is "no". For automated installs, either set `os.dhclient_set_hostname: true` in the config yaml, or pass `harvester.os.dhclient_set_hostname=true` as a kernel command line argument. In order for this setting to take effect, your DHCP server needs to be configured to send the host name option to the client. For more information see `man dhcpd.conf` (look for "option host-name" and "use-host-decl-names on"). Note that even if os.dhclient_set_hostname is set to true, we still require the user to provide a hostname during installation, because that will be written to /etc/hostname and be used by the system briefly early in the boot process, before DHCP does its thing. Related issue: harvester/harvester#1444 Signed-off-by: Tim Serong <[email protected]>
5f2631a
to
b551632
Compare
It just falls back to the manual hostname setting. AFAICT there's no warnings anywhere if the DHCP server doesn't send a hostname. That would be up to wickedd and/or wickedd-dhcp4 to do, but from looking at the wicked code and experimenting with extra debugging information turned on, wicked doesn't seem to really care whether or not the DHCP server sends a hostname or not. If the server does send a hostname and DHCLIENT_SET_HOSTNAME is set to "yes", it will be used, but it won't complain at all if either of those things aren't true. |
} | ||
output, err := exec.Command("sed", "-i", | ||
fmt.Sprintf(`s/^DHCLIENT_SET_HOSTNAME=.*/DHCLIENT_SET_HOSTNAME="%s"/`, yesOrNo), | ||
"/etc/sysconfig/network/dhcp").CombinedOutput() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file control global settings. Should we set the value on the management interface only? Although we don't request IPs on VLAN bridges (those generated from harvester-network-controller), setting this per interface can lower the chance of interfering with other interfaces.
From the man page it seems we can override the setting in the ifcfg-mgmt-br
file. And if we make the change, we can consider moving the configuration field dhclientSetHostname
into install.management_interface
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree, setting this on the management interface only rather than globally makes good sense.
@@ -1188,6 +1192,13 @@ func addHostnamePanel(c *Console) error { | |||
return err | |||
} | |||
|
|||
askDhclientSetHostnameV, err := widgets.NewDropDown(c.Gui, askDhclientSetHostnamePanel, "Set via DHCP", func() ([]widgets.Option, error) { | |||
return []widgets.Option{{Value: "no", Text: "No"}, {Value: "yes", Text: "Yes"}}, nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll also suggest adding a warning message if the user selects yes
to get the hostname from the DHCP server. The idea is that the hostname should be always assigned persistently by the DHCP server. hostname changes can lead to unexpected consequences. etcd, certificates, and many services rely on the hostname.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. If we do take this change (rather than the alternative in #726) adding a warning here seems like a very good idea.
This is an alternative to harvester#717 Here we switche the order of the "Configure hostname" and "Configure network" installer pages, so that "Configure network" comes first. This allows us to set DHCLIENT_SET_HOSTNAME="yes" when applying the management NIC config. If DHCP is used, and the DHCP server is configured to specify a hostname, the live environment will then automatically have its hostname set to whatever it got from the DHCP server. Then, on the hostname page, we can default the hostname to that value, which the user is still free to change should they wish. If DHCP isn't used, or if the DHCP server doesn't specify a hostname, there's no change to the existing behaviour - the hostname field will initially be blank, and the user will be required to fill it out. Related issue: harvester/harvester#1444 Signed-off-by: Tim Serong <[email protected]>
This is an alternative to harvester#717 Here we switch the order of the "Configure hostname" and "Configure network" installer pages, so that "Configure network" comes first. This allows us to set DHCLIENT_SET_HOSTNAME="yes" when applying the management NIC config. If DHCP is used, and the DHCP server is configured to specify a hostname, the live environment will then automatically have its hostname set to whatever it got from the DHCP server. Then, on the hostname page, we can default the hostname to that value, which the user is still free to change should they wish. If DHCP isn't used, or if the DHCP server doesn't specify a hostname, there's no change to the existing behaviour - the hostname field will initially be blank, and the user will be required to fill it out. Related issue: harvester/harvester#1444 Signed-off-by: Tim Serong <[email protected]>
Closing in favour of #726 |
Problem:
We need to provide the option of allowing system hostnames to be set via DHCP.
Solution:
This adds a boolean config option, os.dhclient_set_hostname, which maps to DHCLIENT_SET_HOSTNAME in /etc/sysconfig/network/dhcp.
When running the installer interactively, there's a new "Set via DHCP" drop down field on the hostname page. The default is "no".
If the user selects "yes", this will later be shown on the confirmation screen as "hostname: XXXX (will be set via DHCP)", to indicate that the provided hostname will be overridden by DHCP:
For automated installs, either set
os.dhclient_set_hostname: true
in the config yaml, or passharvester.os.dhclient_set_hostname=true
as a kernel command line argument.In order for this setting to take effect, your DHCP server needs to be configured to send the host name option to the client. For more information see
man dhcpd.conf
(look for "option host-name" and "use-host-decl-names on").Note that even if os.dhclient_set_hostname is set to true, we still require the user to provide a hostname during installation, because that will be written to /etc/hostname and be used by the system briefly early in the boot process, before DHCP does its thing.
Related Issue:
harvester/harvester#1444
Test plan: