- Icinga 2 – Monitoring automatisiert mit Puppet Teil 1: Installation
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 2: Features
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 3: Plugins
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 4: Konfiguration I
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 5: Konfiguration II
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 6: Agenten
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 7: Objekte aus Hiera erzeugen
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 8: Integration von Icinga Web 2
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 10: Profile Part II
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 11: Profile Part III
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 12: Profile Part IV
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 13: Profile Part V
- Icinga 2 – Monitoring automatisiert mit Puppet Teil 14: Profile Part VI
In Weiterführung vom letzten Post dieser Serie, beschäftigen wir uns zuerst damit dem Icinga-Server eine CA hinzuzufügen. Dies erledigt die Deklaration der Klasse icinga2::pki::ca. Sie erzeugt auch noch gleich ein Zertifikat für den eigenen Server.
Das ist auch der Grund, warum im Folgenden der Parameter pki des Features API mit none belegt werden muss, da genau dies verhindert, dass nochmals versucht wird ein Zertifikat zu generieren. Dieser Wert für pki ist also nur sinnvoll für Hosts mit einer Icinga-2-CA.
[ruby]class profile::icinga2::server {
…
#
# CA / API
#
include ::icinga2::pki::ca
class { ‘::icinga2::feature::api’:
pki => ‘none’,
accept_commands => true,
}
[/ruby]
Als nächstes widmen wir uns dem Feature IDO, welches die IDO-DB befüllt, hier eine MySQL-Datenbank, die ebenfalls per Puppet verwaltet werden soll und sich auch dem gleichen Server befindet. Hierfür ist zusätzlich das MySQL-Puppetmodule erforderlich. Das Datenbank-Schema kann vom Icinga2-Modul automatisch angelegt werden. Hierfür ist dann zu den üblichen Berechtigungen auch CREATE für den Benutzer, den auch Icinga für den Zugriff verwendet, erforderlich, da auch dieser zum initalen Erzeugen der Tabellen vom Icinga2-Modul verwendet wird.
In Bezug auf die Reihenfolge der Abarbeitung unserer Ressourcen, muss nur dafür Sorge getragen werden, dass die Datenbank für die IDO vor dem IDO-Feature dran kommt.
Für den zu verwenden Benutzernamen, das zugehörige Passwort und den eigentlichen Datenbanknamen fügen wir der Profilklasse Parameter hinzu. Im Gegensatz zum Datenbank- und Benutzernamen, die beide als Default icinga2 gesetzt bekommen, ist das Passwort als Parameter vom Endbenutzer immer selbst anzugeben.
[ruby]class profile::icinga2::server(
String $ido_db_pass,
String $ido_db_name = ‘icinga2’,
String $ido_db_user = ‘icinga2’,
) {
case $::osfamily {
‘redhat’: {
…
package { [ ‘nagios-plugins-all’, ‘icinga2’, ‘icinga2-ido-mysql’ ]:
ensure => installed,
before => User[‘icinga’],
}
…
}
…
}
#
# Icinga 2
#
class { ‘::icinga2’:
manage_package => $manage_package,
manage_repo => $manage_repo,
}
#
# IDO database
#
include ::mysql::server
mysql::db { $ido_db_name:
user => $ido_db_user,
password => $ido_db_pass,
host => ‘127.0.0.1’,
grant => [‘SELECT’, ‘INSERT’, ‘UPDATE’, ‘DELETE’, ‘DROP’, ‘CREATE VIEW’, ‘CREATE’, ‘INDEX’, ‘EXECUTE’, ‘ALTER’],
before => Class[‘icinga2::feature::idomysql’]
}
class{ ‘::icinga2::feature::idomysql’:
user => $ido_db_user,
password => $ido_db_pass,
database => $ido_db_name,
import_schema => true,
}
[/ruby]
Auf RedHat-Systemen musste, wie in vorherigen Teil zu sehen war, da Paketmanagement aus dem eigentlichen Icinga-Modul herausgezogen werden, um den Benutzer icinga zwischen Paketinstallation und Icinga-Klasse verwalten zu können. Das bezieht sich nun ebenfalls auf das Paket icinga2-ido-mysql, das für das IDO-Feature erforderlich ist. Debianbasierte Systeme sind hiervon nicht betroffen.
