Installation des ersten Windows-Client

Transkript

1 Installation des ersten Windows-Client Festlegungen 1. Der Master funktioniert und kann lokal checken. 2. Auf dem Master wurde bereits ìcinga2 node wizard` als Master ausgeführt und sein FQDN als CN gewählt. 3. Er hat bei mir den Hostnamen und Endpoint-Nanmen debian85.local und die IP Der Client heisst LAPTOP-AUQ5DGU2. 5. Es wird eine Verbindung vom Client zur IP des Masters initiert und nicht umgekehrt. Modifikationen auf dem Master zones.conf object Endpoint NodeName { object Endpoint "LAPTOP-AUQ5DGU2"{ object Zone ZoneName { endpoints = [ NodeName ] object Zone "LAPTOP-AUQ5DGU2" { endpoints= [ "LAPTOP-AUQ5DGU2" ] parent= ZoneName object Zone "global-templates" { global = true Folgende Befehle absetzen root@debian85:/etc/icinga2/zones.d# mkdir /etc/icinga2/zone.d/globaltemplates root@debian85:/etc/icinga2/zones.d# mkdir /etc/icinga2/zone.d/laptop- AUQ5DGU2 root@debian85:/etc/icinga2/zones.d# icinga2 pki ticket --cn 'LAPTOP- 1 von :45

2 2 von :45 AUQ5DGU2' 2483cf6f158c06f362b2f2a7ea29b72b25d14d17 root@debian85:/etc/icinga2/zones.d# icinga2 feature list Disabled features: compatlog debuglog gelf graphite influxdb livestatus opentsdb perfdata statusdata syslog Enabled features: api checker command ido-mysql mainlog notification Installation auf dem Windows Client Binary von ( /windows/icinga2-v2.6.0-x86_64.msi) herunterladen und starten, nach untenstehenden Screenshots ausfüllen:

3 3 von :45

4 4 von :45

5 5 von :45 Anpassen auf dem Windows Client zones.conf Konfig Dateien liegen unter C:\ProgramData\icinga2\etc\icinga2. object Endpoint "debian85.local" { ### Folgende Zeile legt fest, dass der Client die Verbindung zum Master aufbaut und nicht umgekehrt host = " " port = "5665" object Zone "master" { endpoints = [ "debian85.local" ] ### NodeName ist eine Konstante aus constants.conf object Endpoint NodeName {

6 nstallation des ersten Windows-Client 6 von :45 ### ZoneName ist eine Konstante aus constants.conf object Zone ZoneName { endpoints = [ NodeName ] parent = "master" object Zone "global-templates" { global = true Anlegen des ersten Dienstes auf dem Master, um die Top Down Replikation zu prüfen File /etc/icinga2/zone.d/laptop-auq5dgu2/services.conf ### Wir nennen den Service hier loadtmp, weil load bereits existiert. apply Service "loadtmp" { import "generic-service" check_command = "load" enable_flapping = true /* Used by the ScheduledDowntime apply rule in `downtimes.conf`. */ vars.backup_downtime = "02:00-03:00" assign where host.name == "LAPTOP-AUQ5DGU2" Zur Diagnose ausführen auf dem Master: service icinga2 restart icinga2 object list --type service --name loadtmp Der Host (nicht Endpunkt!) LAPTOP-AUQ5DGU2 ist dem Master nicht bekannt. Also kann er auch keinen Service dafür erstellen. Damit taucht weder der Host noch der Service im icingaweb2 auf. Zur Diagnose ausführen auf dem Client: C:\Program Files\ICINGA2\sbin>icinga2.exe object list --type service --name loadtmp Service wird ausgegeben. Wir haben eine erfolgreiche Replikation, aber kein erfolgreiches Monitoring. Modifikationen, um das Monitoring zum Laufen zu bekommen. auf dem Client conf.d\hosts.conf entfernen: C:\ProgramData\icinga2\etc\icinga2\conf.d>ren hosts.conf hosts.conf.orig C:\ProgramData\icinga2\etc\icinga2\conf.d>net stop icinga2 C:\ProgramData\icinga2\etc\icinga2\conf.d>net start icinga2

7 7 von :45 auf dem Master /etc/icinga2/zone.d/laptop-auq5dgu2/services.conf anlegen: object Host "LAPTOP-AUQ5DGU2" { import "generic-host" address = " " address6 = "::1" vars.os = "Windows" vars.disks["disk"] = { /* No parameters. */ vars.disks["disk C:"] = { disk_win_path = "C:" vars.notification["mail"] = { groups = [ "icingaadmins" ] Damit erreichen wir, dass das Host-Object vom Master auf den Client repliziert wird. Somit kennen nun sowohl Master als auch Client das Host Object, und das Monitoring funktioniert. Hätten wir die hosts.conf auf dem Client nicht entfernt, hätte dieser bei seiner Validierung des replizierten Host Objectes festgestellt: "Hab ich schon in meiner conf.d/hosts.conf, Invalid, Dienst stoppen!!!" Zur Diagnose ausführen auf dem Master: service icinga2 restart icinga2 object list --type service --name loadtmp Dienst wird gefunden und ausgegeben. Zur Diagnose ausführen auf dem Client: C:\Program Files\ICINGA2\sbin>icinga2.exe object list --type service --name loadtmp Service wird ausgegeben. Wir haben eine erfolgreiche Replikation und ein erfolgreiches Monitoring auf dem Master:

8 8 von :45 Weiteres Vorgehen Wir wollen nun noch die services.conf zentral auf dem Master verwalten. Ändern wir sie hier, geht dies an alle Zonen. Es sind dort apply rules drinn, die jeden Host erst einmal mit Basis - Services versorgen. Zunächst entfernen wir daher die services.conf auf dem Client, er erhält sie danach vom Master repliziert zurück: C:\ProgramData\icinga2\etc\icinga2\conf.d>ren services.conf services.conf.orig C:\ProgramData\icinga2\etc\icinga2\conf.d>net stop icinga2 C:\ProgramData\icinga2\etc\icinga2\conf.d>net start icinga2 Auf dem Master verschieben wir die services.conf nun in die global-templates: root@debian85:/etc/icinga2/conf.d# mv services.conf../zones.d/globaltemplates/

9 9 von :45 und ändern den Service load dort ab von: apply Service "load" { import "generic-service" check_command = "load" enable_flapping = true /* Used by the ScheduledDowntime apply rule in `downtimes.conf`. */ vars.backup_downtime = "02:00-03:00" assign where host.name == NodeName nach: apply Service "load" { import "generic-service" check_command = "load" enable_flapping = true /* Used by the ScheduledDowntime apply rule in `downtimes.conf`. */ vars.backup_downtime = "02:00-03:00" assign where host.name Die temporäre können wir nun löschen (müssen aber nicht...): root@debian85:/etc/icinga2/conf.d# rm../zones.d/laptop-auq5dgu2 /services.conf root@debian85:/etc/icinga2/conf.d# service icinga2 restart und prüfen, dass das Monitoring nun noch läuft. Der Service loadtmp wurde durch load ersetzt. Nun solltest Du gelernt haben: Objekte, die in allen Zonen existieren sollen, gehören nach zones.d/global-templates. Objekte, die in einer speziellen Zone existieren sollen, gehören nach zones.d/[zonename]. Objekte, die in conf.d existieren, können mit den vom Master replizierten konflikten und sind daher soweit möglich zu vermeiden.