Comment configurer le client distant Icinga2 sans utiliser l'assistant CLI?

Je veux configurer des clients distants Icinga2 via Puppet, mais toute la page de la documentation officielle parle de l'utilisation de leur formidable assistant CLI, qui doit être exécuté manuellement.

Une solution? Peut-être que je devrais juste retourner à Nagios?

J'ai eu le même problème. C'est ce que j'utilise, après avoir extrait la logique du code de l'assistant de nœud icinga2.

Variables dont vous aurez besoin:

$pki_dir - /etc/icinga2/pki in the default installation
$fqdn - fully host+domain name of the client.
$icinga2_master - resolvable fqdn of the master
$icinga2_master_port - the port the master is connectable on.
$ticket - generated on the master via 'icinga2 pki ticket --cn $fqdn'

Le code:

mkdir icinga:icinga 0700 $pki_dir
icinga2 pki new-cert --cn $fqdn --key $pki_dir/$fqdn.key --cert $pki_dir/$fqdn.crt
icinga2 pki save-cert --key $pki_dir/$fqdn.key --cert $pki_dir/$fqdn.crt --trustedcert $pki_dir/trusted-master.crt --host $icinga2_master
icinga2 pki request --host $icinga2_master --port $icinga2_master_port --ticket $ticket --key $pki_dir/$fqdn.key --cert $pki_dir/$fqdn.crt --trustedcert $pki_dir/trusted-master.crt --ca $pki_dir/ca.key
icinga2 node setup --ticket $ticket --endpoint $icinga2_master --zone $fqdn --master_host $icinga2_master --trustedcert $pki_dir/trusted-master.crt
systemctl restart icinga2  # or however you restart your icinga

C'est comme TryTryAgain l'a écrit. Les derniers documents décrivent deux façons différentes. Descendante d' exécution de commandes à distance et descendante Config Sync

La différence de cette approche est que l'exécution de commandes à distance déclenchera toutes les commandes du maître tandis que la synchronisation de configuration synchronisera tous les fichiers de configuration situés dans /etc/icinga2/zones.dles nœuds enfants (satellites ainsi que les clients) et déclenchera l'exécution de commandes directement sur le point de terminaison.

Je préfère utiliser l' approche de synchronisation descendante parce que le client exécutera des vérifications même si le maître perd la connexion avec l'enfant.

Vous devez activer la APIfonctionnalité sur tous les nœuds.

# /etc/icinga2/features-enabled/api.conf

object ApiListener "api" {
  cert_path = "/etc/ssl/{{ hostname }}.pem"
  key_path = "/etc/ssl/{{ hostname }}-key.pem"
  ca_path = "/etc/ssl/rootca.pem"

  // only on satelites and clients
  accept_config = true
}

Créez maintenant un fichier de zone et copiez-le sur tous les nœuds

# /etc/icinga2/zones.conf

// global zone used for zone overlapping configs
object Zone "global" {
  global = true
}

// endpoints
object Endpoint "fqdn1.of.host" {
  host = "fqdn1.of.host"
}

object Endpoint "fqdn2.of.host" {
  host = "fqdn2.of.host"
}

// for each endpoint one zone
object Zone "fqdn1.of.host" {
  endpoints = [ "fqdn1.of.host" ]
}

object Zone "fqdn2.of.host" {
  endpoints = [ "fqdn2.of.host" ]
  parent = "fqdn1.of.host"
}

la meilleure pratique consiste à utiliser le nom de domaine complet de vos nœuds comme nom de point de terminaison ainsi que nom de zone. N'oubliez pas : copiez-le zones.confsur tous les nœuds.

La prochaine étape serait de définir tous les services, modèles et groupes à l'intérieur de /etc/icinga2/zones.d/et chaque hôte dans son propre hosts.conf à l'intérieur de son répertoire de zone.

# /etc/icinga2/zones.d/global/templates.conf

template Host "generic-host" {
  max_check_attempts = 3                                                                                                                     
  check_interval = 1m 
  retry_interval = 30s

  check_command = "hostalive"
}

# /etc/icinga2/zones.d/fqdn1.of.host/hosts.conf

// this is the master
object Host "fqdn1.of.host" {
  import "generic-host"
  address = "fqdn1.of.host"
}

# /etc/icinga2/zones.d/fqdn2.of.host/hosts.conf

// this is a satelite/client
object Host "fqdn2.of.host" {
  import "generic-host"
  address = "fqdn2.of.host"
}

Mon approche était d'empêcher l'utilisation des configs à l'intérieur /etc/icinga2/conf.dcar j'ai ajouté toutes les choses génériques (et utilisées globalement) /etc/icinga2/zones.d/globalet les choses spécifiques à l'hôte à l'intérieur/etc/icinga2/zones.d/fqdnX.of.host

Enfin, vous devez supprimer l'instruction include pour conf.d

# /etc/icinga2/icinga2.conf

[...]
// include_recursive "conf.d"

C'est ça. Cette configuration nécessite de gérer vos certificats manuellement ou avec la gestion de configuration de votre choix. Il ne le générera pas et n'utilisera pas icinga pki. Je ne vois aucune raison pour laquelle je devrais utiliser un outil spécifique pki tant qu'il existe des outils spécifiques pour cela.