Seite wählen

NETWAYS Blog

Icinga 2 – Monitoring automatisiert mit Puppet Teil 13: Profile Part V

This entry is part 13 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Im heutigen Teil dieser Reihe, fügen wir den ausstehenden Code zur Konfiguration von Nginx als Webserver für Icinga Web 2 hinzu. Neben den benötigten Nginx-Ressources, vor allem der Umleitung auf den PHP-FPM, ist darauf zu achten, dass Nginx vor der Klasse icingaweb2 und damit vor dem Paket icingaweb2 abzuarbeiten ist. Wird dies nich beachtet installiert das icingaweb2-Paket automatisch den Apache als Abhängigkeit und man hätte zwei Webserver bei sich auf dem Icinga-2-Server.
Damit das Icinga-Web-2-Modul für seine Konfigurationsdateien den korrekten Benutzer verwenden kann, ziehen wir diesen nach der Abarbeitung der Klasse nginx aus dessen Modul.
[ruby] […]
if $web_server == ’nginx‘ {
#
# Nginx
#
$manage_package = true
Class[’nginx‘]
-> Class[‚icingaweb2‘]
class { ‚::nginx‘:
manage_repo => false,
server_purge => true,
confd_purge => true,
}
$web_conf_user = $::nginx::daemon_user
nginx::resource::server { ‚icingaweb2‘:
server_name => [ ‚localhost‘ ],
ssl => false,
index_files => [],
use_default_location => false,
}
nginx::resource::location { ‚icingaweb2‘:
location => ‚~ ^/icingaweb2(.+)?‘,
location_alias => ‚/usr/share/icingaweb2/public‘,
try_files => [‚$1‘, ‚$uri‘, ‚$uri/‘, ‚/icingaweb2/index.php$is_args$args‘],
index_files => [‚index.php‘],
server => ‚icingaweb2‘,
ssl => false,
}
nginx::resource::location { ‚icingaweb2_index‘:
location => ‚~ ^/icingaweb2/index\.php(.*)$‘,
server => ‚icingaweb2‘,
ssl => false,
index_files => [],
fastcgi => ‚127.0.0.1:9000‘,
fastcgi_index => ‚index.php‘,
fastcgi_param => {
‚SCRIPT_FILENAME‘ => ‚/usr/share/icingaweb2/public/index.php‘,
‚ICINGAWEB_CONFIGDIR‘ => ‚/etc/icingaweb2‘,
‚REMOTE_USER‘ => ‚$remote_user‘,
},
}
} else {
[…][/ruby]
Beim Nginx selbst werden alle von der Standard-Installation kommenden virtuellen Hosts (server_purge => true) und sonstigen Konfigurationsdateien entfernt. Der Artikel der kommenden Woche schließt diesen Abschnitt über eine komplexere Konfiguration vorerst ab. Dort wird dann der noch fehlende Code präsentiert, der einen Apache-Webserver zum Ausliefern von Icinga Web 2 verwendet.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 12: Profile Part IV

This entry is part 12 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Heute geht es mit der Konfiguration von Icinga Web 2 weiter, nach dem im letzte Teil als Voraussetzung PHP konfiguriert wurde. Als Backend zur Speicherung von Authentifizierungs- und Benutzerdaten, kommt eine eigene MySQL Datenbank auf dem gleichen lokalen System zum Einsatz. Der Datenbank- und der Benutzername, sowie dass Passwort soll mittels Parameter festgelegt werden könnten, das gleiche gilt für den zum Senden von Kommandos an Icinga benötigten API-Benutzer und man soll sich als Webserver zwischen einem Apache bzw. einem Nginx entscheiden können. Die Konfiguration letztgenannter, wird im nächsten Teil der kommenden Woche behandelt.
[ruby]class profile::icinga2::server(
String $web_db_pass,
String $web_api_pass,

String $web_db_user = ‚icingaweb2‘,
String $web_db_name = ‚icingaweb2‘,
String $web_api_user = ‚icingaweb2‘,
Enum[‚apache‘, ’nginx‘] $web_server = ‚apache‘,
) {

mysql::db { $web_db_name:
host => $web_db_host,
user => $web_db_user,
password => $web_db_pass,
grant => [‚ALL‘],
before => Class[‚icingaweb2′],
}
if $web_server == ’nginx‘ {
$manage_package = true
# $web_conf_user =
} else {
$manage_package = false
# $web_conf_user =
package { ‚icingaweb2‘:
ensure => installed,
}
}
class { ‚icingaweb2‘:
db_username => $web_db_user,
db_password => $web_db_pass,
import_schema => true,
config_backend => ‚db‘,
conf_user => $web_conf_user,
manage_package => $manage_package,
}
::icinga2::object::apiuser { $web_api_user:
ensure => present,
password => $web_api_pass,
permissions => [ ’status/query‘, ‚actions/*‘, ‚objects/modify/*‘, ‚objects/query/*‘ ],
target => ‚/etc/icinga2/conf.d/api-users.conf‘,
}
class { ‚::icingaweb2::module::monitoring‘:
ido_db_host => ‚127.0.0.1‘,
ido_db_name => $ido_db_name,
ido_db_username => $ido_db_user,
ido_db_password => $ido_db_pass,
commandtransports => {
‚icinga2‘ => {
transport => ‚api‘,
username => $web_api_user,
password => $web_api_pass,
}
}
}
}[/ruby]

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 11: Profile Part III

This entry is part 11 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Die heutige Fortsetzung dieser Serie befasst sich mit dem Management einer PHP-Umgebung für daen Betrieb eines Icinga Web 2 auf dem Icinga-Server. Icinga Web 2 benötigt in aktuellen Versionen mindestens ein PHP in der Version 5.6, kommen dann noch Module hinzu, wird damit einhergehend ein PHP 7 oder neuer vorausgesetzt.
Server mit Debian Stretch bekommen ein aktuelles PHP aus ihren eigenen Repositories, bei RedHat 7 muss auf das SCL (Softwarer Collection Linux) Repository zurückgegriffen werden.
[ruby]class profile::icinga2::server(

) {
case $::osfamily {
‚redhat‘: {
require ::profile::repo::epel
require ::profile::repo::icinga
require ::profile::repo::scl
$manage_package = false
$manage_repo = false
$php_globals = {
php_version => ‚rh-php71‘,
rhscl_mode => ‚rhscl‘,
}
$php_extensions = { mbstring => {}, json => {}, ldap => {}, gd => {}, xml => {}, intl => {}, mysqlnd => {}, pgsql => {}, },

}
‚debian‘: {
$manage_package = true
$manage_repo = true
$php_globals = {}
$php_extensions = { mbstring => {}, json => {}, ldap => {}, gd => {}, xml => {}, intl => {}, mysql => {}, pgsql => {}, },

}
default: {
fail("’Your operatingsystem ${::operatingsystem} is not supported.’")
}
}
…[/ruby]
PHP selbst lässt sich mit dem Puppet-Module puppet/php des Projektes Vox Pubuli konfigurieren. Hierbei werden über die Klasse php::globals Einstellungen getätigt, welches PHP, aus welchen Quellen benutzt werden soll. Im Anschluss wir über die Hauptklasse php das Management auf das Betreiben eines FPM (FastCGI Process Manager) eingeschränkt. Dieser lauscht standardmäßig auf TCP-Port 9000 ausschließlich auf localhost.
Neben einem erhöhen des Speicherlimits und dem Setzen der Zeitzone, werden auch die von Icinga Web vorausgesetzten PHP-Extensions aktiviert.
[ruby]

#
# PHP
#
class { ‚::php::globals‘:
* => $php_globals,
}
class { ‚::php‘:
ensure => installed,
manage_repos => false,
apache_config => false,
fpm => true,
extensions => $php_extensions,
settings => {
‚PHP/memory_limit‘ => ‚128M‘,
‚Date/date.timezone‘ => ‚Europe/Berlin‘,
},
dev => false,
composer => false,
pear => false,
phpunit => false,
require => Class[‚::php::globals‘],
}[/ruby]
Bei der Klasse profile::repo::scl beschränken wir uns im folgenden Beispiel auf CentOS basierte Systeme, wie es auf RHEL einzubinden ist muss aus der Installations-Dokumentation abgeleitet werden.
[ruby]class profile::repo::scl {
case $::operatingsystem {
‚centos‘: {
package { ‚centos-release-scl‘:
ensure => installed,
}
} # CentOS
default: {
fail("’Your plattform ${::operatingsystem} is not supported.’")
}
} # case
}[/ruby]

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 10: Profile Part II

This entry is part 10 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

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.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile

This entry is part 9 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Es ist nun nahzu schon ein Jahr her, dass in dieser Blogserie ein Artikel erschien. Zeit diese Serie fortzusetzen, auch weil wir für diese Jahr noch den Release 2.0.0 des Moduls puppet-icinga2 planen. In den kommenden Artikeln möchte ich sukezessive eine Profil-Klasse entwickeln, die einen Icinga-2-Server inklusive Plugins, IDO, Api und Icinga Web 2 installiert und konfiguriert. Als weitere Anforderung soll dies erfolgreich auf RedHat- wie auch Debian-Systemen durchgeführt werden können. Getestet wurde der Code auf Debian-9 (stretch) und CentOS-7.
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 Posix Capabilities. Damit stellt uns Debian nicht vor größere Herausforderungen, die Plugins für RedHat-Systeme erfordern jedoch, dass der Aufrufende Benutzer Mitglied der Gruppe nagios sein muss. Um dies Anforderung zu realisieren, muss der Benutzer icinga der Gruppe nagios hinzugefügt werden, dass bei Puppet heißt, er ist via User-Resource zu verwalten. Am besten überlässt man das Anlegen vom Benutzer icinga weiterhin dem Paket icinga2, damit werden solche Eigenschaften wie UID oder das Home-Verzeichnis dem Paketverantwortlichen überlassen, d.h. aber auch die Paketinstallation muss vor der User-Resource und die wiederum vor der Klasse icinga2 abgearbeitet werden. Der Service, der von der Klasse verwaltet wird, darf erst gestartet werden, wenn der Benutzer schon korrekt konfiguriert ist. Andernfalls würde Icinga als Prozess weiterhin unter einem Benutzer laufen, der zum Startzeitpunkt von seiner Zugehörigkeit zur Gruppe nagios noch nichts wusste.
Zusätzlich muss auch die Gruppe nagios vor der User-Resource vorhanden sein, was sichergestellt ist, wenn vorher das Paket nagios-plugins-all installiert ist.
[ruby]class profile::icinga2::server {
case $::osfamily {
‚redhat‘: {
require ::profile::repo::epel
require ::profile::repo::icinga
$manage_package = false
$manage_repo = false
package { [ ’nagios-plugins-all‘, ‚icinga2‘ ]:
ensure => installed,
before => User[‚icinga‘],
}
user { ‚icinga‘:
groups => [ ’nagios‘ ],
before => Class[‚icinga2‘]
}
} # RedHat
‚debian‘: {
$manage_package = true
$manage_repo = true
package { ‚monitoring-plugins‘:
ensure => installed,
}
} # Debian
default: {
fail("’Your operatingsystem ${::operatingsystem} is not supported.’")
}
} # case
class { ‚::icinga2‘:
manage_package => $manage_package,
manage_repo => $manage_repo,
}
}[/ruby]
Die Plugins befinden sich bei RedHat in einem zusätzlichen Repository, dem EPEL-Repository, das in der dedizierten Profilklasse profile::repo::epel verwaltet wird. Gleiches gilt für das Icinga-Repo mit der Klasse profile::repo::icinga, was auf RedHat für die gesonderte Paketinstalltion vorhanden sein muss und damit nicht, wie unter Debian, der Klasse icinga2 überlassen werden kann.
[ruby]class profile::repo::epel {
yumrepo { ‚epel‘:
descr => "Extra Packages for Enterprise Linux ${::operatingsystemmajrelease} – \$basearch",
mirrorlist => "https://mirrors.fedoraproject.org/metalink?repo=epel-${::operatingsystemmajrelease}&arch=\$basearch",
failovermethod => ‚priority‘,
enabled => ‚1‘,
gpgcheck => ‚1‘,
gpgkey => "http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-${::operatingsystemmajrelease}",
}
}
class profile::repo::icinga {
yumrepo { ‚ICINGA-release‘:
descr => ‚ICINGA (stable release for epel)‘,
baseurl => ‚http://packages.icinga.org/epel/$releasever/release/‘,
failovermethod => ‚priority‘,
enabled => ‚1‘,
gpgcheck => ‚1‘,
gpgkey => ‚http://packages.icinga.org/icinga.key‘,
}
}[/ruby]

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.