Certain foundational system configurations must exist before Puppet can assume management responsibilities. These include:

# Example of network pre-configuration needed for Puppet
# /etc/network/interfaces on Debian systems (must exist pre-Puppet)
auto eth0
iface eth0 inet static
    address 192.168.1.100
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 8.8.8.8

While Puppet can manage network interfaces, it's often safer to:

• Pre-configure primary management interface
• Let Puppet manage secondary interfaces
• Use exported resources for complex setups

BMC/IPMI configurations present a chicken-and-egg problem:

# Partial Puppet code for IPMI - use with caution!
define ipmi::network (
  $ipaddress,
  $netmask,
  $gateway
) {
  exec { "ipmi-set-${ipaddress}":
    command => "/usr/bin/ipmitool lan set 1 ipaddr ${ipaddress}",
    unless  => "/usr/bin/ipmitool lan print | grep -q 'IP Address.*${ipaddress}'",
  }
}

Three common approaches to updates:

These services often require special handling:

• Database schema migrations
• LDAP directory modifications
• Certificate Authority operations
• Filesystem resizing operations

# Example of safe database management with Puppet
exec { 'run-db-migrations':
  command     => '/usr/bin/rake db:migrate',
  cwd         => '/opt/app',
  environment => 'RAILS_ENV=production',
  refreshonly => true,
  subscribe   => File['/opt/app/config/database.yml'],
}

Never use Puppet to manage the components required for Puppet to function. This includes:

• Primary network configuration
• Puppet agent installation/configuration
• SSL certificate infrastructure
• Basic system authentication

When implementing configuration management with Puppet, there's an inherent tension between automation purity and operational reality. While Puppet excels at managing most system configurations, certain infrastructure elements require special consideration.

The chicken-and-egg problem of network configuration is particularly acute:

# Bad practice - attempting to manage primary network interface
node 'webserver01' {
  network::interface { 'eth0':
    ipaddress => '192.168.1.100',
    netmask   => '255.255.255.0',
    gateway   => '192.168.1.1'
  }
}

Instead, consider these approaches:

• Bootstrap networking via DHCP/PXE or cloud-init
• Use Puppet for secondary interfaces only
• Implement network bonding/teaming configurations

IPMI/BMC configurations present unique challenges:

# Questionable practice - full IPMI management
exec { 'set_ipmi_ip':
  command => '/usr/bin/ipmitool lan set 1 ipsrc static',
  unless  => '/usr/bin/ipmitool lan print | grep -q "IP Address Source.*Static"'
}

Better alternatives include:

• Configure base IPMI settings during provisioning
• Use Puppet only for monitoring configurations
• Implement read-only checks for critical parameters

The package update paradox requires careful balance:

# Safe approach - version pinning
package { 'nginx':
  ensure => '1.18.0-1.el7',
}

# Riskier approach - automatic updates
package { 'security_updates':
  ensure  => latest,
  require => Exec['apt-get update'],
}

These components typically belong outside Puppet's scope:

• Initial Puppet agent installation
• SSL certificate trust chains
• Low-level kernel parameters affecting Puppet operation
• Time synchronization (before Puppet can manage it)

Services with persistent state require special handling:

# Problematic - managing database contents
exec { 'init_mysql_db':
  command => '/usr/bin/mysql < /root/init.sql',
  unless  => '/usr/bin/mysql -e "SHOW DATABASES" | grep production',
}

# Better approach - schema management only
file { '/etc/mysql/my.cnf':
  ensure  => file,
  content => template('mysql/my.cnf.erb'),
  notify  => Service['mysql'],
}

1. Never manage the network stack required for Puppet communication
2. Keep hardware management interfaces as static bootstrap configurations
3. Treat package updates as a separate lifecycle from configuration management
4. Maintain manual control over security-sensitive authentication systems
5. Document all out-of-band configurations in your infrastructure wiki