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.
Als erstes Teilziel für diesen Artikel soll Icinga 2 nebst Plugins enthalten sein. Bei den Plugins soll auch berücksichtig sein, dass es Plugins wie check_icmp oder check_dhcp gibt, die erweiterte Berechtigungen benötigen. So dürfen ICMP-Pakete oder auch DHCP-Request auf Unix nur im Ring-0 erzeugt werden. Auf RedHat wird dies über das Setzen des setuid-Bits erreicht, unter Debian mittels 
