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.

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,
  }
}

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.

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',
  }
}
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.

Running RedHat SCL PostgreSQL with Puppet

On a test system for a customer I wanted to bring up a newer PostgreSQL version on CentOS 7 (same for RHEL 7). Software Collections (also for RedHat) gives you a neat distribution method that is not very invasive into your existing distribution. So you can install a PostgreSQL 9.4 under RHEL 7 without replacing any of the existing packages. This is a bit tricky in terms of paths, but just works.
I found a relatively simple way to install, configure and run such a SCL with Puppet, with just using the existing PostgreSQL module.
https://gist.github.com/lazyfrosch/1926b17d1d605bfb819e899ef6bd4b63
Have fun trying it out and let me know what you think.

Markus Frosch
Markus Frosch
Principal Consultant

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

yum Plugins

Auch wenn viele ihn regelmäßig verwenden, so haben sich doch nur wenige mit seinen Möglichkeiten auseinander gesetzt: yum, der Paketmanager von RHEL, CentOS, Fedora (bis vor kurzem) und einigen anderen Distributionen aus dem RedHat Dunstkreis.
Zwar wird er in absehbarer Zeit durch dnf ersetzt werden, aber bis dahin zahlt es sich durchaus aus, nochmal ein wenig Energie in yum zu investieren.Yum
Eine meiner liebsten Funktionalitäten ist die Verwendung von Delta RPMs. Dabei werden Updates nicht mehr als ganzes Paket heruntergeladen, sondern nur der Unterschied zwischen der installierten und geplanten Version. Lokal am System wird aus dem installierten Paket und dem Delta RPM dann das neue RPM zusammengebaut und installiert. Je nachdem, welches Paket aktualisiert wird, kann sowas schon einiges an zu übertragenden Daten sparen. Ja, heutzutage sind Netzwerkleitungen oft dick genug, dass es ziemlich wurscht ist, ob man LibreOffice nochmal komplett herunterlädt, oder nur die paar kleinen Änderungen, aber in einigen Situationen fällt es sogar heute noch ins Gewicht. Nicht jeder hat eine überall eine Leitung, die dick genug ist. Z.B. in Schulungssituationen oder auf Konferenzen, kann es schon mal eng werden mit der Bandbreite. Ausserdem entlastet es natürlich die Server, die die Updates zur Verfügung stellen. Hauptsächlich finde ich es aber einfach eine gute Idee und ich hab’ Spass, wenn sich jemand bei einer Lösung was gedacht hat und ich sie einsetzen kann.
Musste man früher noch ein eigenes yum Plugin installieren, reicht seit CentOS 7 die Installation des deltarpm Pakets, um diese Funktionlität zu aktivieren, wenn die verwendeten Repos das anbieten.
Zwei Plugins befassen sich mit dem Entfernen von Paketen, die als Abhängigkeit installiert wurden, aber nun nicht mehr benötigt werden: yum-plugin-remove-with-leaves und yum-plugin-show-leaves. Damit lässt sich beispielsweise durch yum autoremove jedes Paket anzeigen und deinstallieren, das einmal als Abhängigkeit installiert wurde, dessen Grund, weshalb es installiert wurde, inzwischen schon wieder entfernt wurde. Ja ich weiß, Debian kann das auch so.
Mit yum-plugin-protectbase und yum-plugin-versionlock lassen sich einfach ungewollte Updates von bestimmten Paketen, insbesondere über Repository Grenzen hinweg verhindern.
Die Erweiterung yum-plugin-local erstellt aus heruntergeladenen und installierten Paketen ein lokales Repository. Gerade im Zusammenhang mit Containern oder virtuellen Maschinen kann ich es mir praktisch vorstellen, etwas zu bauen, mit dem sich einmal heruntergeladene Pakete leichter weiter verteilen lassen.
Ein besonders praktisches Plugin finde ich search-disabled-repos . Das gibt es unter CentOS 7 nicht als eigenes Paket, sondern nur als Teil des Subscription Managers, der eigentlich für die Verwaltung von RedHat Subscriptions auf RedHat Systemen gedacht ist, aber auch auf CentOS im Paket subscription-manager verfügbar ist. Damit laufen Installationen zukünftig folgendermassen ab: Versucht man ein Paket zu installieren, dessen Abhängigkeiten nicht aufgelöst werden können, bietet yum an, auch alle aktuell deaktivierten Repositories vorübergehend zu aktivieren und dort nach den fehlenden Abhängigkeiten zu suchen. Werden sie dort gefunden, bietet yum an, die nötigen Repos einmalig für die Installation zu aktivieren oder dauerhaft. Die Default Konfiguration verhindert dabei, dass ein -y beim yum Aufruf automatisch alle nötigen Repos aktiviert.
Ein recht hilfreiches Plugin für eine defensive Versionsstrategie ist yum-plugin-security. Dafür müssen aber alle verwendeten Repositories mitspielen. Ist es installiert, können mit yum update --security nur Security-relevante Updates installiert werden und alle anderen werden außen vor gelassen. Aber nicht alle Repos stellen diese Information zur Verfügung.
Was alle Plugins gemeinsam haben ist, dass ihre Konfigurationsdateien unter /etc/yum/pluginconf.d/ liegen. Da bei einigen nur enabled=1 drin steht, ist es wahrscheinlich einfacher, das Plugin einfach wieder zu deinstallieren, als es extra zu deaktivieren. Ansonsten lohnt sich oft durchaus ein Blick in die Dateien dort, um weitere Möglichkeiten zu entdecken.
Das waren nur ein paar der verfügbaren Plugins und auch nur als Anregung gedacht, sich mal näher damit auseinander zu setzen. Die meisten Plugins sind relativ eingägig in der Verwendung und fügen sich nahtlos in die übrigen yum Kommandos (z.B. auch in help) ein.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Paketstation

Mit FPM stellt Jordan Sissel, der führende Kopf hinter Logstash, ein Tool zur Verfügung mit dem man sehr einfach Pakete für die gängigsten Distributionen erstellen kann.
Für Effing Package Management (=FPM) muss Ruby und ein C-Compiler vorhanden sein:

# apt-get install ruby-dev gcc
# yum install ruby-devel gcc

Danach kann die eigentliche Installation des Ruby-Moduls erfolgen:

# gem install fpm

Als Beispiel für die Erstellung von Paketen mit FPM habe ich im Folgenden LConf Standalone Web gewählt, natürlich kann dies auch auf andere Softwareprodukte abgewandelt werden.
Zuerst muss bei LConf Web das Archiv mit dem Quellcode herunter geladen und entpackt werden, danach wechselt man wie gewohnt in das extrahierte Verzeichnis. Im Anschluss wird hier der configure-Befehl ausgeführt:

# ./configure --with-user=icinga --with-group=icinga

Bis zu diesem Zeitpunkt besteht noch kein Unterschied zum üblichen Installationsvorgang, erst bei make install unterscheidet sich der Aufruf. Statt die Dateien an den dafür vorgesehenen Stellen im Dateisystem abzulegen, leitet man sie mit dem DESTDIR-Parameter um:

# make install DESTDIR=/usr/local/src/lconf-web-1.4.0_installdir

Jetzt ist die Zeit von FPM gekommen, den hier kann nun das DESTDIR-Verzeichnis als Chroot verwendet und die darin enthaltene Verzeichnisstruktur “usr/local/lconf-web” beispielsweise in ein Debian-Paket integriert werden:

# fpm -s dir -t deb -n lconf-web -v 1.4.0 --deb-use-file-permissions \
-C /usr/local/src/lconf-web-1.4.0_installdir usr/local/lconf-web

Das dabei entstandene Paket lconf-web-1.4.0_amd64.deb kann nun natürlich mit dpkg auf einem Debian basierten System installiert werden.

Markus Waldmüller
Markus Waldmüller
Lead Senior Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Weekly Snap: Using DRBD with Redhat, Time Machine with Network Sharing & Coding with Artistic Style

13 – 17 June offered tips galore, from implementing code standards to using Time Machine with network drives and DRBD with Redhat.
To begin, Julian updated his tip for Apple Time Machine with network sharing. Previously, he explained how to set up Time Machine to back up to shared network drives with the help of Snow Leopard. Now in 8 steps, he offered a new method starting from setting a hidden configuration parameter, host name and MAC address, to creating a local sparse bundle on the network drive and adjusting Time Machine’s settings.
From using shared storage to avoiding them, Philipp shared his recipe for using DRDB to mirror hard disks over multiple servers on Redhat. He first offered a simple method with CentOS Extra Repository that works for versions up to RHEL 5.6. For version 6 and onwards, Philipp showed how to prepare and compile a DRBD package to allow DRBD to be used as the kernel module.
To close the week, Marius gave developers a helping hand in dealing with unreadable code. Following on from a prior post on PHP coding standards, he found that most tools which homogenise code tend to rigidly follow standards such as K&R and Allman. As a substitute he suggested Artistic Style (Astyle) for more freedom and speed in formatting code. Written in C++, it modifies the entire code base within seconds and allows the user to finely prescribe his own standards in configuration. Marius gave an example using Oracle’s Java coding conventions, and then used Astyle to apply his new standard to the relevant files.
Have a question or suggestion for any of our tips? Simply add a comment to the relevant post!