Seite wählen

Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile

von | Nov 16, 2018 | Linux, DevOps, Icinga, Puppet, Betriebssysteme

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.

0 Kommentare

Trackbacks/Pingbacks

  1. Icinga 2 – Monitoring automatisiert mit Puppet Teil 10: Profile Part II › NETWAYS Blog - […] Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile […]
  2. Monthly Snap November: vSphere® and x509 certificate monitoring, OSMC & Icinga Camp Berlin | Icinga - […] their Icinga 2 migration tools used at Syseleven. Lennart wrote a thing about Icinga and Puppet profiles part I and…
  3. Monthly Snap November › NETWAYS Blog - […] Betz continues his blogpost-seminar Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile and Teil 10: Profile Part…

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema Linux | DevOps | Icinga | Puppet | Betriebssysteme

Kritischer Fehler in Puppet Version 7.29.0 und 8.5.0

Eine Warnung an alle Nutzer von Puppet, aber auch Foreman oder dem Icinga-Installer, die Version 7.29.0 und 8.5.0 von Puppet enthält einen kritischen Fehler, der die Erstellung eines Katalogs und somit die Anwendung der Konfiguration verhindert. Daher stellt bitte...

Trainings

Web Services

Events

Series



Other posts in series: