Come configurare il client remoto Icinga2 senza usare la procedura guidata della CLI?


11

Voglio configurare i client remoti Icinga2 tramite Puppet, ma l'intera pagina della documentazione ufficiale parla dell'utilizzo della loro fantastica procedura guidata della CLI, che richiede di essere eseguita manualmente.

Qualche soluzione? Forse dovrei tornare a Nagios?


I documenti a cui ti colleghi fanno riferimento solo a una configurazione della GUI per Windows. È questo che stai chiedendo?
Keith,

1
docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/… ... dove gli ultimi documenti hanno una sezione dedicata proprio a questa domanda.
Prova TryAgain

1
Aggiornamento: la documentazione è stata spostata nella nuova posizione di icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/…
Věroš K.

Risposte:


16

Ho avuto lo stesso problema. Questo è quello che uso, dopo aver estratto la logica dal codice della procedura guidata del nodo icinga2.

Le variabili di cui avrai bisogno:

$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'

Il codice:

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

1

È come ha scritto Try TryAgain. Gli ultimi documenti descrivono due modi diversi. Top-Down esecuzione remota di comando e Top-Down Config Sync

La differenza di questi approcci è che l'esecuzione remota dei comandi attiverà tutti i comandi dal master, mentre la sincronizzazione della configurazione sincronizzerà tutti i file di configurazione situati nei /etc/icinga2/zones.dnodi figlio (satelliti e client) e attiverà l'esecuzione dei comandi direttamente sull'endpoint.

Preferisco usare l' approccio Top-Down Config Sync perché il client eseguirà i controlli anche se il master perde la connessione con il bambino.

Devi abilitare la APIfunzione su tutti i nodi.

# /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
}

Ora crea un file di zona e copialo su tutti i nodi

# /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"
}

è consigliabile utilizzare fqdn dei nodi come nome dell'endpoint e nome della zona. Ricorda : copia questo zones.confsu tutti i nodi.

Il prossimo passo sarebbe quello di definire tutti i servizi, i modelli e i gruppi all'interno di /etc/icinga2/zones.d/e ogni host nel suo host.conf all'interno della sua directory di zona.

# /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"
}

Il mio approccio è stato quello di impedire l'uso delle configurazioni all'interno /etc/icinga2/conf.dperché ho aggiunto tutte le cose generiche (e usate a livello globale) /etc/icinga2/zones.d/globale le cose specifiche dell'host all'interno/etc/icinga2/zones.d/fqdnX.of.host

Ultimo ma non meno importante, è necessario rimuovere l'istruzione include per conf.d

# /etc/icinga2/icinga2.conf

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

Questo è tutto. Questa configurazione richiede la gestione manuale dei certificati o con la gestione della configurazione desiderata. Non lo genererà e non sta usando l'icinga pki. Non vedo alcun motivo per cui dovrei usare uno strumento specifico pki purché ci siano strumenti specifici per questo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.