Seite wählen

NETWAYS Blog

Icinga 2 – Monitoring automatisiert mit Puppet Teil 14: Profile Part VI

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

Nachdem letzte Woche der Nginx verwendet wurde, wenden wir uns im nun vorerst letzten Teil der Konfiguration des Apaches als Webserver zur Auslieferung von Icinga Web 2 zu.
Der Apache kommt unter Debian als abhängig zu installierendes Paket von icingaweb2 mit und wird ensprechend konfiguriert. Damit dies unsere Anforderung an den Apache nicht wieder überschreibt, sorgen wir dafür, dass das Paket icingaweb2 vor der Klasse apache installiert wird. Hierfür müssen wir das Managment des Pakets durch die Klasse icingaweb2 unterbinden.
Damit das Icinga-Web-2-Modul für seine Konfigurationsdateien den korrekten Benutzer verwenden kann, ziehen wir diesen nach der Abarbeitung der Klasse apache aus dessen Modul.

 

[ruby]
if $web_server == ’nginx‘ {
[…]
} else {
#
# Apache
#
$manage_package = false
Package[‚icingaweb2‘]
-> Class[‚apache‘]
package { ‚icingaweb2‘:
ensure => installed,
}
class { ‚::apache‘:
default_mods => false,
default_vhost =>false,
mpm_module => ‚worker‘,
}
apache::listen { ’80‘: }
$web_conf_user = $::apache::user
include ::apache::mod::alias
include ::apache::mod::status
include ::apache::mod::dir
include ::apache::mod::env
include ::apache::mod::rewrite
include ::apache::mod::proxy
include ::apache::mod::proxy_fcgi
apache::custom_config { ‚icingaweb2‘:
ensure => present,
source => ‚puppet:///modules/icingaweb2/examples/apache2/for-mod_proxy_fcgi.conf‘,
verify_config => false,
priority => false,
}
}
[…]
[/ruby]

Der Apache wird von uns komplett mit allen Modulen für Icinga Web 2 verwaltet, da sich die Defaults für RedHat und Debian zu sehr unterscheiden. Auch hier, wie bei Nginx, entfernen wird alle Konfiguration sonstiger auszuliefernder Webseiten und benutzen die vom Icinga-Web-2-Modul zur Verfügung gestellt Beispielkonfiguration.

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 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.