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 DHCP during install #726

Merged

Conversation

tserong
Copy link
Contributor

@tserong tserong commented May 8, 2024

Problem:
We need to provide the option of allowing system hostnames to be set via DHCP.

Solution:
When installing Harvester, if the management interface is configured via DHCP, we will default the system hostname to the client hostname specified by the DHCP server.

For interactive installation, the order of the "Configure hostname" and "Configure network" pages is swapped, 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.

For automated/PXE installation, it works like this:

  • If os.hostname is specified in the harvester config, we use that.
  • If os.hostname is not specified, we use the DHCP provided hostname if set, otherwise we fall back to a randomly generated hostname.

(This is an alternative to #717 - the advantage with this approach is that we set the hostname once, during installation, whereas #717 potentially allows the DHCP server to change the hostname of an installed system later, which would likely cause all sorts of trouble)

Related Issue:
harvester/harvester#1444

Test plan:

  • Configure a DHCP server, but don't have it set to provide client hostnames (i.e. don't use option host-name XXX or use-host-decl-names on in dhcpd.conf)
  • Boot the installer ISO and walk through the installation process, selecting DHCP for the management interface.
  • Verify that the network page now comes before the hostname page, but that the hostname by default remains blank.
  • Verify that installation completes successfully
  • Do a PXE install, set to use DHCP, and verify that it completes as usual.
  • Reconfigure the DHCP server to provide client hostnames.
  • Boot the installer ISO and walk through the installation process, selecting DHCP for the management interface.
  • Verify that when you get to the hostname page, the hostname defaults to whatever was specified in the DHCP server config for this host, but that you can also still change the hostname if you want.
  • Verify that the install completes successfully
  • Do a PXE install, but make sure os.hostname is not set in the harvester config yaml.
  • Verify that the installation completes successfully, and that the system picks up the DHCP-provided hostname.

Example dhcpd.conf snippet which should set the hostname to "harv-0-dhcp" for the MAC address 02:00:00:0D:62:E2:

host harvest_node_0 {
    hardware ethernet 02:00:00:0D:62:E2;
    fixed-address 192.168.0.30;
    option host-name "harv-0-dhcp";
}

@tserong tserong requested review from bk201 and ibrokethecloud May 8, 2024 09:13
@tserong tserong marked this pull request as draft May 8, 2024 09:13
@tserong tserong marked this pull request as ready for review May 9, 2024 03:25
@tserong tserong force-pushed the wip-set-hostname-via-dhcp-installer-only branch from 9f637c2 to c12f838 Compare May 14, 2024 04:10
tserong added 2 commits May 14, 2024 18:08
When installing Harvester, if the management interface is configured
via DHCP, we will default the system hostname to the client hostname
specified by the DHCP server.

For interactive installation, the order of the "Configure hostname"
and "Configure network" pages is swapped, 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.

For automated/PXE installation, it works like this:

- If os.hostname is specified in the harvester config, we use that.
- If os.hostname is not specified, we use the DHCP provided hostname
  if set, otherwise we fall back to a randomly generated hostname.

Related issue: harvester/harvester#1444

Signed-off-by: Tim Serong <[email protected]>
Copy link
Contributor

@ibrokethecloud ibrokethecloud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm. thanks.

tserong added 2 commits May 21, 2024 13:55
We need to get the remote config before looking up MAC addresses,
otherwise config.ManagementInterface.Interfaces might not yet be
set up correctly, and the later call to applyNetworks() will fail.

This commit also simplifies the MAC address lookup loop to not
need tmpInterfaces.

Signed-off-by: Tim Serong <[email protected]>
@tserong
Copy link
Contributor Author

tserong commented May 21, 2024

re: those last two commits, printing the yip output means we get some sort of error message if we can't apply the network config, e.g.:

cant-apply-networks

...and re-ordering the config merge means we can correctly handle remote config that specifies MAC addresses but not interface names.

Copy link
Member

@bk201 bk201 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@bk201 bk201 merged commit c6014e3 into harvester:master May 23, 2024
5 checks passed
@tserong tserong deleted the wip-set-hostname-via-dhcp-installer-only branch May 23, 2024 12:26
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