The official Icinga2 documentation heavily relies on their interactive CLI wizard for setting up remote monitoring clients. While this works fine for manual setups, it becomes problematic when you need to automate deployments through configuration management tools like Puppet.

To bypass the wizard, we need to manually configure these essential components:

• Node certificates and trust relationship
• Endpoint and zone configuration
• Required features (checker, command, etc.)
• Parent-child zone hierarchy

Here's a complete Puppet manifest that automates the client setup:

class icinga2::client (
  String $parent_zone,
  String $parent_endpoints,
  String $ca_server,
) {
  package { 'icinga2':
    ensure => installed,
  }

  file { '/etc/icinga2/features-available/api.conf':
    ensure  => file,
    content => template('icinga2/api.conf.erb'),
    notify  => Service['icinga2'],
  }

  exec { 'setup-icinga2-client':
    command => "icinga2 pki new-cert --cn ${::fqdn} --key /etc/icinga2/pki/${::fqdn}.key --cert /etc/icinga2/pki/${::fqdn}.crt",
    creates => "/etc/icinga2/pki/${::fqdn}.crt",
    path    => ['/usr/bin', '/bin'],
    require => Package['icinga2'],
  }

  icinga2::object::zone { $::fqdn:
    global => false,
    endpoints => [$::fqdn],
    parent => $parent_zone,
  }
}

The most complex part is handling the PKI certificates. Here's how to do it manually:

# On master:
icinga2 pki save-cert --key /var/lib/icinga2/ca/ca.key --cert /var/lib/icinga2/ca/ca.crt --trustedcert /var/lib/icinga2/ca/trusted-cert.crt --host remote-client.example.com

# On client:
icinga2 pki request --host remote-client.example.com --port 5665 --ticket 'TICKET_ID' --key /etc/icinga2/pki/remote-client.example.com.key --cert /etc/icinga2/pki/remote-client.example.com.crt --trustedcert /etc/icinga2/pki/trusted-cert.crt --ca /etc/icinga2/pki/ca.crt

Essential configuration files that need to be managed:

# /etc/icinga2/constants.conf
const NodeName = "$::fqdn"
const ZoneName = "$::fqdn"

# /etc/icinga2/zones.conf
object Endpoint "$::fqdn" {
}

object Zone "$::fqdn" {
  endpoints = [ "$::fqdn" ]
  parent = "master"
}

After deployment, verify with these commands:

icinga2 daemon -C
systemctl restart icinga2
icinga2 node list

• Time synchronization between master and clients
• Firewall rules for port 5665
• Certificate expiration issues
• Zone hierarchy mismatches

For large deployments:

• Use a dedicated Puppet environment for Icinga2 clients
• Implement certificate caching
• Consider using Hiera for zone configuration
• Batch certificate signing requests

When automating infrastructure monitoring with Puppet or other configuration management tools, the Icinga2 documentation's heavy reliance on their interactive CLI wizard becomes problematic. The wizard requires manual intervention, breaking the automation pipeline we DevOps engineers cherish so much.

To bypass the wizard, we need to manually set up these key elements:

# /etc/icinga2/conf.d/zones.conf
object Endpoint "client.example.com" {
  host = "192.168.1.100"
}

object Zone "client-zone" {
  endpoints = [ "client.example.com" ]
  parent = "master-zone"
}

The trickiest part is handling TLS certificates. Here's how to generate them manually:

# On master node
icinga2 pki new-cert --cn client.example.com --key client.key --cert client.crt
icinga2 pki sign-cert --cert client.crt --key client.key --trustedcert ca.crt

# On client node
icinga2 pki save-cert --key client.key --cert client.crt --trustedcert ca.crt

Here's a complete Puppet class for automated deployment:

class profile::icinga2::client (
  String $master_host,
  String $client_name = $facts['fqdn'],
) {
  package { 'icinga2':
    ensure => installed,
  }

  file { '/etc/icinga2/features-enabled/api.conf':
    content => template('profile/icinga2/api.conf.erb'),
    notify  => Service['icinga2'],
  }

  exec { 'icinga2-node-setup':
    command => "/usr/bin/icinga2 node setup --endpoint ${client_name} --zone ${client_name} --master_host ${master_host} --trustedcert /var/lib/icinga2/certs/trusted-cert.crt --cn ${client_name} --accept-commands --accept-config",
    creates => '/var/lib/icinga2/certs//var/lib/icinga2/certs/${client_name}.crt',
    require => Package['icinga2'],
  }

  service { 'icinga2':
    ensure => running,
    enable => true,
  }
}

After deployment, verify connectivity with:

icinga2 daemon -C
systemctl restart icinga2
tail -f /var/log/icinga2/icinga2.log

Common issues include certificate permission problems (ensure icinga user can read /var/lib/icinga2/certs/) and firewall blocks on port 5665.

For large deployments, consider these optimizations:

• Pre-generate certificates in batches
• Use Puppet's stored configs for faster catalog application
• Implement a certificate rotation strategy