Jak skonfigurować klienta zdalnego Icinga2 bez korzystania z kreatora CLI?

Chcę skonfigurować zdalnych klientów Icinga2 za pośrednictwem Puppet, ale cała strona oficjalnej dokumentacji mówi o korzystaniu z ich niesamowitego kreatora CLI, który wymaga ręcznego uruchomienia.

Jakieś obejście? Może powinienem po prostu wrócić do Nagios?

Miałem ten sam problem. Właśnie tego używam po wyodrębnieniu logiki z kodu kreatora węzła icinga2.

Zmienne, których będziesz potrzebować:

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

Kod:

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

To tak, jak napisał TryTryAgain. Najnowsze dokumenty opisują dwa różne sposoby. Top-Down zdalne wykonanie poleceń i odgórne Config Sync

Różnica w tym podejściu polega na tym, że zdalne wykonywanie poleceń spowoduje wyzwolenie wszystkich poleceń z mastera, natomiast synchronizacja konfiguracji zsynchronizuje wszystkie pliki konfiguracyjne znajdujące się w /etc/icinga2/zones.dwęzłach potomnych (satelitach i klientach) i wyzwoli wykonanie poleceń bezpośrednio w punkcie końcowym.

Wolę używać metody synchronizacji konfiguracji z góry na dół, ponieważ klient uruchomi kontrole, nawet jeśli master utraci połączenie z dzieckiem.

Musisz włączyć tę APIfunkcję na wszystkich węzłach.

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

Teraz utwórz plik strefy i skopiuj go do wszystkich węzłów

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

najlepszą praktyką jest użycie nazwy fqdn węzłów jako nazwy punktu końcowego oraz nazwy strefy. Pamiętaj : skopiuj to zones.confdo wszystkich węzłów.

Następnym krokiem byłoby zdefiniowanie wszystkich usług, szablonów i grup wewnątrz /etc/icinga2/zones.d/i każdego hosta we własnym hosts.conf w katalogu strefy.

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

Moje podejście polegało na zapobieganiu używaniu konfiguracji wewnątrz, /etc/icinga2/conf.dponieważ dodałem wszystkie ogólne (i globalnie używane) elementy /etc/icinga2/zones.d/globali specyficzne dla hosta elementy wewnątrz/etc/icinga2/zones.d/fqdnX.of.host

Na koniec należy usunąć instrukcję include dla conf.d

# /etc/icinga2/icinga2.conf

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

Otóż ​​to. Ta konfiguracja wymaga ręcznego zarządzania certyfikatami lub zarządzania konfiguracją według własnego wyboru. Nie wygeneruje go i nie używa pektu icinga. Nie widzę żadnego powodu, dla którego powinienem używać pki dla konkretnego narzędzia, o ile istnieją do tego specjalne narzędzia.