Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

tserong
Copy link
Contributor

@tserong tserong commented Apr 24, 2024

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".

image

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:

image

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

Test plan:

  • Configure a DHCP server to set the host name option (TBD: add more details here, possibly including tweaks to ipxe-examples)
  • Boot the installer, but leave "Set via DHCP" set to "no"
  • Verify that whatever hostname the DHCP server wants to set, doesn't get set.
  • Repeat the above, but set "Set via DHCP" to "yes"
  • Verify that whatever hostname the DHCP server wants to set, does get set, both during installation (after network config is applied), and then subsequently once the system comes up for real.

@mingshuoqiu
Copy link
Contributor

What will happen if the dhcp server doesn't set the hostname for the IP?
Will it fallback to manual hostname setting and give a warning or simply bypass?

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]>
@tserong tserong force-pushed the wip-set-hostname-via-dhcp branch from 5f2631a to b551632 Compare May 6, 2024 02:42
@tserong
Copy link
Contributor Author

tserong commented May 6, 2024

What will happen if the dhcp server doesn't set the hostname for the IP?
Will it fallback to manual hostname setting and give a warning or simply bypass?

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()
Copy link
Member

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.

Copy link
Contributor Author

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
Copy link
Member

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.

Copy link
Contributor Author

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.

tserong added a commit to tserong/harvester-installer that referenced this pull request May 8, 2024
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]>
tserong added a commit to tserong/harvester-installer that referenced this pull request May 8, 2024
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]>
@tserong
Copy link
Contributor Author

tserong commented May 16, 2024

Closing in favour of #726

@tserong tserong closed this May 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants