How to Configure Hostname Using Puppet in Masterless Mode: A Complete Guide

When managing infrastructure with Puppet in masterless mode (where each node runs its own catalog), configuring hostnames presents unique challenges. Unlike traditional Puppet setups where the master can control naming conventions, masterless configurations require self-contained solutions.

Puppet provides several built-in approaches for hostname management:


# Method 1: Using the hostname resource type (requires puppetlabs/host_core module)
hostname { 'my-server':
  ensure => present,
  provider => 'posix'
}

# Method 2: Using exec resource for cross-platform compatibility
exec { 'set-hostname':
  command => "/bin/hostnamectl set-hostname ${::fqdn}",
  unless  => "/bin/hostname | /bin/grep -q '^${::fqdn}$'",
  path    => ['/bin','/usr/bin']
}

For a robust masterless solution, combine hostname settings with other system configurations:


class profile::hostname {
  $fqdn = 'web01.example.com'

  # Set transient hostname
  exec { 'set-transient-hostname':
    command => "hostname ${fqdn}",
    path    => ['/bin','/usr/bin'],
    unless  => "test $(hostname) = '${fqdn}'"
  }

  # Set persistent hostname (Debian/Ubuntu)
  file { '/etc/hostname':
    ensure  => file,
    content => "${fqdn}\n",
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
    notify  => Exec['set-transient-hostname']
  }

  # Update hosts file
  host { $fqdn:
    ensure       => present,
    host_aliases => ['web01'],
    ip           => $::ipaddress,
    comment      => 'Managed by Puppet'
  }
}

For enterprise environments, consider these additional factors:

DNS integration using exported resources
Conditional logic for different OS families
Using Hiera for hostname configuration
Validating hostname patterns

Common issues and solutions:


# Debugging command to verify hostname settings
puppet apply --debug --trace --verbose --eval 'include profile::hostname'

When working with Puppet in masterless mode (where each node runs its own catalog), configuring the hostname requires special consideration. Unlike master-agent setups where certificates handle naming, standalone Puppet needs explicit hostname management.

Modern Puppet versions include built-in hostname management through the hostname fact and hostname type:

# Example using hostname resource (Puppet 6+)
hostname { 'set-hostname':
  ensure => present,
  name   => 'web-prod-01',
}

For wider compatibility across Linux distributions:

case $::osfamily {
  'RedHat': {
    file { '/etc/hostname':
      ensure  => file,
      content => "web-prod-01\n",
    }
    ~> exec { 'set-hostname':
      command     => "/bin/hostname web-prod-01",
      refreshonly => true,
    }
  }
  'Debian': {
    # Similar approach with Debian-specific considerations
  }
  default: {
    warning("Hostname configuration not implemented for ${::osfamily}")
  }
}

Here's a full example demonstrating hostname setting in a masterless environment with proper dependencies:

class profile::hostname {
  $hostname = 'db-primary-02'

  # System configuration
  file { '/etc/hostname':
    ensure  => file,
    content => "${hostname}\n",
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
  }

  exec { 'set-hostname':
    command     => "/bin/hostname ${hostname}",
    unless      => "/bin/hostname | grep -q '^${hostname}$'",
    path        => ['/bin', '/usr/bin'],
    refreshonly => true,
  }

  # Update hosts file
  host { $hostname:
    ensure       => present,
    ip           => $::ipaddress,
    host_aliases => [$::fqdn],
  }
}

Some systems require reboots for hostname changes to fully take effect. Consider this notification pattern:

exec { 'hostname-change-notify':
  command     => '/bin/true',
  notify      => Reboot['after-hostname-change'],
  refreshonly => true,
}

reboot { 'after-hostname-change':
  apply   => finished,
  message => 'Rebooting to apply hostname changes',
  timeout => 30,
}