Project

General

Custom queries

Profile

Actions
Copy link

Bug #29407

open

Provisioning a host when the OS hostname is altered through DHCP splits host into 2 separate hosts

Added by Damon Maria about 5 years ago. Updated 6 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Host creation
Target version:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:
1.24.2
Red Hat JIRA:

Description

During provisioning a host with DHCP, if the OS hostname is altered by the response from the DHCP server (I've observed this with Ubuntu 18.04) the facts host record lookup fails to find the host and therefore creates a new one. Subsequent Puppet reports and facts will go to the new host, not the original one created by the user.

The root cause is this code in Host::Base.import_host finding the host to apply the first facts from Puppet:

      host = Host.find_by_certname(certname) if certname.present?
      host ||= Host.find_by_name(hostname)
      host ||= new(:name => hostname) # if no host was found, build a new one

The first query finds nothing because the host record in the DB does not have a certname yet. The 2nd finds nothing because the hostname in facts has been altered by the DHCP server. So a new host is created and the certname will be applied to that. Thus, that new host record will match any future calls to Host::Base.import_host.

Original description

I'm using bootdisk plugin to provision Ubuntu 18.04 hosts behind DHCP servers not managed by Foreman. I create the host in Foreman with its name and install from a generic bootdisk ISO. This correctly pulls the correct information from Puppet, installs, and completes the Foreman build process.

But when Puppet calls in the hostname of the machine has changed from what Foreman set through preseed because it has been updated with the domain and hostname from the local DHCP server. We don't control the network this is deployed in, and Foreman doesn't setup netplan in preseed_networking_setup template. Even tho the host already exists in Foreman, and matches the certname sent by Puppet, Foreman adds a new host under the hostname fact set by the DHCP server, and the facts and Puppet report go there.

So I end up with 2 hosts. A managed one I setup, and an unmanaged one generated by Puppet.

I presume this is a bug? I would have thought if the certname matches an existing host then that should be used?

I've found previous reports questioning this behaviour:

Some of those also mention the security implications which I think are fairly serious and easily exploitable in this situation.

#2

Updated by Lukas Zapletal about 5 years ago

  • Category set to PuppetCA
#24

Updated by Damon Maria almost 5 years ago

  • Subject changed from Provisioning a host with DHCP half-applies to a generated host from DHCP provided name, not built host to Provisioning a host when the OS hostname is altered through DHCP splits host into 2 separate hosts
  • Description updated (diff)
  • Category changed from PuppetCA to Host creation
Actions
Copy link

Also available in: Atom PDF