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.

For a Handful of (Vagrant) Boxes

Servus alle miteinand,


Wer kennt das folgende Szenario nicht? Mit viel neuer Software, welche gerade (manuell) getestet werden muss, dachte ich mir, ich baue mal schnell eine Vagrant Box auf Basis von Debian 9, um Tests unter einem Stretch durchzuführen.
Falsch gedacht !!
Anstelle eines libvirt install auf der Kommandozeile und eines tar-Befehls zum Packen des eigentlichen Box-Images,
musste ich mit einer kleinen Widrigkeiten im Bereich der Netzwerkkonfiguration kämpfen.
Aber eins nach dem anderen.
Fangen wir mit dem Image für die libvirt Maschine an:

virt-install --name=linuxconfig-vm \
--vcpus=1 \
--memory=1024 \
--cdrom=/tmp/debian-9.4.0-amd64-netinst.iso \
--disk size=10 \
--os-variant=debian9

Dies war noch der unproblematische Teil der Installation.
Danach erfolgt in der VM das nachziehen von Berechtigungen für den Vagrant User.

sudo visudo -f /etc/sudoers.d/vagrant
vagrant ALL=(ALL) NOPASSWD:ALL

Hinzufügen des Vagrant public Keys:

mkdir -p /home/vagrant/.ssh
chmod 0700 /home/vagrant/.ssh
wget --no-check-certificate \
https://raw.github.com/mitchellh/vagrant/master\/keys/vagrant.pub \
-O /home/vagrant/.ssh/authorized_keys
chmod 0600 /home/vagrant/.ssh/authorized_keys
chown -R vagrant /home/vagrant/.ssh

Wenn man nicht so Wach war, um rechtzeitig im Installationsmenü schon SSH mitzuinstallieren, muss es per Hand nachgeholt werden:

sudo apt-getinstall -y openssh-server
sudo nano /etc/ssh/sshd_config
AuthorizedKeysFile %h/.ssh/authorized_keys

Danach kann das System so präpariert werden, wie man es benötigt.
Das Image der VM noch verkleinern und in box.img umbenennen:

qemu-img convert -c -O qcow2 debian9.qcow2 small.qcow2
mv small.qcow2 box.img

Alles handlich verpacken und dem Vagrant Box Store hinzufügen:

tar czvf debian9.box ./metadata.json ./Vagrantfile ./box.img
vagrant box add --name debian9 debian9.box

Hier allerdings fingen meine Probleme an.
Nach dem Packen der Box, dem Hinzufügen zum Boxstore und einem Erwartungsvollen “vagrant up” erhielt ich “==> default: Waiting for domain to get an IP address…”, was zu keinem Erfolg führte und ich wahrscheinlich jetzt immer noch warten würde.

Nach einem erneuten Hochfahren der VM mit dem virt-manager und nachschauen, ob das network device fehl konfiguriert ist, konnte ich keinen Fehler feststellen.

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

Gefühlte Jahrtausende von Recherche später, wurde mir folgendes klar:
Debian hat in neuen Versionen eine Änderung der Device-Namen vorgenommen.
Vagrant wartet vergeblich auf “eth0”, weil ein network device Namens “ens21” existiert, wenn ich die VM mit “vagrant up” starte.
Also zurück in die VM und das folgende Kommandos abgesetzt:

sudo nano /etc/default/grub

Im Editor dann folgende Anpassungen vornehmen:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

Damit das auch greift, muss abschließend die Konfiguration für den Grub-Bootmanager neu erstellt werden:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Reboot. “vagrant up” und Tada … Spannung Trommelwirbel => Tusch ! Die VM erhält eine IP und startet wie man es schon von Anfang an erwartete.
Ich hoffe ich konnte damit den ein oder anderen vor dem Verlust von allzuviel Lebenszeit bewahren.
Ein sonniges WE wünscht

David Okon
David Okon
Senior Consultant

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

Serverwartung für Kollegen

Philipp und ich haben diese Woche das Vergnügen mit zwei Servern eines Kollegen bekommen. Unsere Aufgabe war im grunde ganz einfach.
Zu machen war:
– Server ausbauen
– Reset iLO Board + neues Passwort vergeben
– Lizenz für iLO Board einspielen
– Upgrade iLO Firmware
– Upgrade Bios
– Upgrade RAID-Controller
– RAID 1 aus 2x 146 GB SAS Festplatten bauen
– RAID 5 aus 3x 5TB SATA Festplatten bauen
– Quad-Port Netzwerkkarte ausbauen
– 10 GBit Netzwerkkarten einbauen
– Debian Minimalinstallation
– Netzwerkkonfiguration für externes Netzwerkinterface (1 GBit)
– Netzwerkkonfiguration für internes Netzwerkinterface (10 GBit)
– Server einbauen
Ich dachte nicht, dass es einfach wird, aber auch nicht, dass es so Zeitintensiv wird. Nachdem wir die Server dann ausgebaut auf dem Tisch liegen hatten, schlossen wir unsere Monitore und Tastaturen an. Als wir dann den Strom anschalteten, ging der Server in den Standby-Leerlauf. In diesem ‘Modus’ liefen die Lüfter schon langsam an. Zuerst war ich überrascht. Einer von diesen Servern ist, im Standby, schon so laut wie mein Gaming-PC, wenn er unter Volllast läuft.
Nun war es an der Zeit uns mal die Software genauer anzuschauen. Wir mussten rausfinden, auf welcher Version das BIOS, das iLO und der RAID-Controller momentan laufen. Nachdem wir das herausgefunden hatten, suchten wir nach den passenden Updates im Internet. Wie wir es gewohnt waren, haben wir mit unserer Suche nach Updates, bei der Herstellerseite angefangen. Wer sich jetzt denkt, “Modellnummer oder Modellbezeichnung suchen und Downloaden”, liegt hiermit allerdings falsch. Wir haben etwa drei Stunden damit verbracht, herauszufinden welches vorgeschlagene Update denn nun das richtige ist und wie man dieses dann Einspielen muss. Die Größe der Updatedatei, belief sich auf sieben Megabyte. Für uns waren normale Updategrößen irgendwo zwischen 500 Megabyte und 1,5 Gigabyte, weswegen wir auch unter großer Verwunderung die heruntergeladene Updatedatei mehrmals überprüften. Nachdem uns unser Ausbilder mitteilte, dass der Server nur noch als “lauter Türstopper” benutzt werden kann, wenn man eine falsche Firmware-Version installiert, bekamen wir nochmehr Angst etwas kaputt zu machen. Bei einer weiteren Überprüfung stellten wir dann fest, dass die Datei, ein einfaches Shell-Script war. Mit einem USB-Stick haben wir dann innerhalb von Sekunden die Updates installiert.
Nachdem wir dann die Firmware-Updates fertiggestellt hatten, galt es die Hardwareteile einzubauen. Wir sollten sechs 5TB HDD Platten und zwei 10 GBit Netzwerkkarten einbauen. Zusätzlich sollten wir auch die vorhandene Quad-Port Netzwerkkarte ausbauen. Philipp schrieb die Seriennummer der einzubauenden HDD Platten auf und ich baute diese dann letztendlich ein.
Jetzt stand noch die iLO Lizenz aktivierung und die RAID-Controller konfiguration an. Das alles ließ sich ganz einfach beim Boot einstellen. Während wir diese Einstellungen vornahmen, hat uns unser Ausbilder noch erklärt was RAID ist und was man damit machen kann. Nun da wir die nötigen Einstellungen vorgenommen hatten, mussten wir nur noch eine Debian 9 Minimalinstallation durchführen und die Netzwerkkarten konfigurieren. Die OS installation war total schnell fertig. Für die Konfiguration der Netzwerkkarten, haben wir in der Konfigurationsdatei (/etc/network/interfaces) die Netzwerkkarte eingetragen und eine statische IP-Adresse vergeben.
Das Projekt hat mir sehr viel Spaß gemacht. Ich freue mich schon sehr darauf, mal wieder mit der Hardware arbeiten zu dürfen.

Revisited – Graphite-Web installation unter Debian 9

Erstmal wieso Revisited ?

Dies ist ein update meines älteren Blog Posts Blogpost 2016 welcher darauf einging das unter Debian 8.4 graphite-web wegen eines Fehlenden Eintrages in der Apache 2.4 Konfiguration nicht korrekt gestartet/aufgerufen werden konnte.
Es ist schon einige Zeit ins Land gegangen und ich habe weniger ein Auge darauf geworfen ob das weiterhin so Funktioniert.
Deshalb Revisited.

Here we Go again !

Ich gehe in diesem Fall von einer Debian Version der Nummer 9 aus und werde wie bei dem alten Blogpost. In der Grundannahme mal davon ausgehen das alles Funktioniert wie es soll:
Also hier die folgenden installationschritte:
#> apt-get install apache2 libapache2-mod-wsgi python-django python-django-tagging fontconfig python-tz python-pip python-dev python-twisted python-cairo
#> pip install carbon whisper graphite-web
#> pip install --upgrade twisted
#> cp /opt/graphite/conf/carbon.conf.example /opt/graphite/conf/carbon.conf
#> cp /opt/graphite/conf/storage-schemas.conf.example /opt/graphite/conf/storage-schemas.conf
#> /opt/graphite/bin/carbon-cache.py start
#> /opt/graphite/bin/carbon-cache.py status
#> cp /opt/graphite/examples/example-graphite-vhost.conf /etc/apache2/sites-available/graphite.conf
#> cp /opt/graphite/conf/graphite.wsgi.example /opt/graphite/conf/graphite.wsgi
#> cp /opt/graphite/webapp/graphite/local_settings.py.example \ /opt/graphite/webapp/graphite/local_settings.py
#> python /opt/graphite/webapp/graphite/manage.py syncdb
#> chown www-data. -R /opt/graphite/storage
#> a2dissite 000-default
#> a2ensite graphite
#> a2enmod wsgi
#> service apache2 restart
#> chmod +x /etc/init.d/carbon-cache // Damit 'carbon-cache.py start' mit Systemstart erfolgt

Ergebnis davon ist -> Nichts funktioniert.

Back to the Roots

Ab hier kommt der Weg graphite-web auf einem Debian 9 (Stretch) in Betrieb zu nehmen.
Ausgangspunkt ist ein frisch installiertes Debian 9.
#> apt-get install vim -y
#> vim /etc/apt/sources.list

Wir müssen die Sources auf die Jessie Repositories setzen da zum Zeitpunkt dieses Blogposts die graphite-web Pakete nicht abrufbar sind.
Daher fügen wir folgendes hinzu in der sources.list
deb http://httpredir.debian.org/debian jessie main
Gefolgt von einem frischem #> apt-get update -y .
Nun installieren wir den großteil der Pakete welche wir benötigen.
#> apt-get install graphite-web graphite-carbon mysql-server python-mysqldb python-pymysql apache2 libapache2-mod-wsgi apt-transport-https ssl-cert python-pip -y
Es folgen ca. 300MB an Daten.
Daraufhin stürzen wir uns direkt auf die Konfig.
Wir fangen an folgende Datei zu editieren.
#> vim /etc/graphite/local_settings.py
Darin ändern wir folgende Settings Sinnvoll in etwas was wir für unsere Installation benötigen.
Also SECRET_KEY, TIME_ZONE & ALLOWED_HOSTS setzen.
Danach muss in der folgenden Datei ein “true” gesetzt werden damit graphite & carbon gemeinsam starten.
#> vim /etc/default/graphite-carbon
Nun kommt der trickreichste Part wir sind leider dazu genötigt eine alte django Version zu installieren.
#> pip install "django==1.4"
Damit haben wir die Grundlage womit wir das folgende Kommando erfolgreich absetzen können.
#> graphite-manage syncdb
#> chown _graphite. /var/lib/graphite/graphite.db
HINWEIS ! Dies setzt erst mal die voreingestellte sqlitedb in Gang.
Wenn eine andere DB verwendet werden soll dann sollte dies bitte in der “local_settings.py” vorgenommen werden.
Wir sind fast am Ziel ein funktionierendes graphite-web zu haben.
Es fehlt nur etwas Apache2 Magie.
#>a2dissite 000-default.conf
#>cp /usr/share/graphite-web/apache2-graphite.conf /etc/apache2/sites-available/
#> a2ensite apache2-graphite.conf
#> systemctl restart apache2

Voilà !

Es sollte nun auf dem Host System das graphite-web aufrufbar sein.

Danke für die Aufmerksamkeit !

David Okon
David Okon
Senior Consultant

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

Foreman/Puppet vs. Gnome – Einstellungen automatisieren

foreman_small
Der Gnome Desktop ist prinzipiell eine sehr schöne Software, da durch seine Hilfe die Bedienung eines Linux Betriebssystems als Desktop deutlich einfacher wird. Ähnlich zu Windows Systemen können Einstellungen durch wenige Klicks mit der Maus getätigt werden.
Aber wie Automatisiert man diese Einstellungen? Und warum will man das? Für alle Teilnehmer unserer Schulungen stellen wir Notebooks zur Verfügung. Diese sind je nach Schulung (Icinga, Puppet, Ceph, usw.) unterschiedlich vorbereitet. Daher betanken wir alle Notebooks vor jeder Schulung mit unserem Foreman neu. Nach der frischen Grundinstallation müssen Einstellungen wie z. B. das Keyboard Layout dementsprechend neu konfiguriert werden.
Keyboard Layout ändern? Ja und? – Genau das dachte ich mir auch. Kann doch nicht so schwer sein…
Aber die Praxis belehrt eines besseren. Ändert man mit Puppet die /etc/default/keyboard ist dies bei unserem Debian 8.4 zwar theoretisch global gültig (z. B. für den Login-Screen), die einzelnen Benutzer-Accounts (mit Gnome) interessiert dies aber herzlich wenig. Wurde das Grundsystem in englischer Sprache installiert, ist das Tastaturlayout englisch und das völlig unabhängig von den Einträgen der /etc/default/keyboard.
Aber nichts leichter als das. Mit einem beherzten gsettings set org.gnome.desktop.input-sources sources "[('xkb', 'de')]" lassen sich solche Einstellungen schnell korrigieren. Pustekuchen! Das Kommando gsettings verlangt einen Execute über eine grafische Oberfläche, was Puppet und sein Manifest ziemlich uncool finden.
Rätsels Lösung ist in diesem Fall der für meine Begriffe etwas “dreckige” Workaround:
/usr/bin/sudo -u training dbus-launch --exit-with-session gsettings set org.gnome.desktop.input-sources sources "[('xkb', 'de')]"
Tja, wer hätte das gedacht. Es ist nicht sonderlich hübsch, funktioniert aber tadellos. In Zukunft kümmere ich mich lieber wieder um Serversysteme und behaupte nie wieder das die Umstellung des Keyboard Layouts nicht so schwer sein kann 😉

Tobias Redel
Tobias Redel
Head of Professional Services

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.

Sponsoring DebConf 2015

DebConf 15Die jährliche Debian conference, kurz DebConf, findet dieses Jahr in Heidelberg statt. Gleichzeitig wird es wohl die größte DebConf aller Zeiten sein, mit über 500 Teilnehmern.
Wir als NETWAYS benutzen Debian für viele unserer eigenen Server und die unserer Kunden. Da ich selbst Debian Entwickler bin, lasse ich mir die Gelegenheit natürlich nicht entgehen.
Da wir auch der Community etwas zurückgeben möchten, haben wir uns als Sponsor gemeldet und unterstützen die Konferenz. Auch Icinga soll dabei nicht zu kurz kommen, deswegen erkläre ich “Why favor Icinga over Nagios?” in einem kurzen Talk am kommenden Sonntag.
Vielleicht findet sich bei der Gelegenheit ein paar Interessenten für unser Team, denn wir suchen immer nach neuen Kollegen!
Wer jetzt noch Lust hat die DebConf zu besuchen, den muss ich enttäuschen, es sind keine Anmeldungen mehr möglich. Falls jemand von unseren Lesern auch dort ist, ich bin immer für ein Gespräch zu haben!

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.

Neue Distributionen für das Icinga 2-Paket-Repository

Vor Kurzem wurden Debian 8.0 (“jessie”) und Ubuntu 15.04 (“Vivid”) veröffentlich. Für diese beiden Plattformen gibt es nun auch auf packages.icinga.org Pakete für Icinga 2 und Icinga Web 2.
Dabei wird für Debian auch die armhf-Architektur unterstützt, die beispielsweise der Raspberry Pi 2 verwendet (für Raspbian gibt es ein separates Repository, das allerdings nichts mit diesem Debian-Repo zu tun hat):
root@dashboard:~# uname -a
Linux dashboard.beutner.name 3.18.0-trunk-rpi2 #1 SMP PREEMPT Debian 3.18.5-1~exp1.co1 (2015-02-02) armv7l GNU/Linux
root@dashboard:~# icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: r2.3.4-1)
Copyright (c) 2012-2015 Icinga Development Team (https://www.icinga.org)
License GPLv2+: GNU GPL version 2 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Application information:
Installation root: /usr
Sysconf directory: /etc
Run directory: /run
Local state directory: /var
Package data directory: /usr/share/icinga2
State path: /var/lib/icinga2/icinga2.state
Objects path: /var/cache/icinga2/icinga2.debug
Vars path: /var/cache/icinga2/icinga2.vars
PID path: /run/icinga2/icinga2.pid
Application type: icinga/IcingaApplication
System information:
Operating system: Linux
Operating system version: 3.18.0-trunk-rpi2
Architecture: armv7l
Distribution: Debian GNU/Linux 8.0 (jessie)
root@dashboard:~#

Icinga2 und icinga-web für Debian/Ubuntu auf ARM-Prozessoren

Warum?

Das icinga PPA stellt fertige Pakete für i386 und amd64 bereit. Für den Betrieb auf ARM-Prozessoren (wie zum Beispiel beim Raspberry Pi oder dem hier verwendeten ODROID U3) muss man seine Installationspakete aber selber schnüren.
Aufgrund der exzellenten Build Tools von Debian sowie des fertig vorliegenden Debian Source Packages vom Icinga Package Maintainer  ist das allerdings eine sehr einfache Angelegenheit. Dieses HowTo verwendet pbuilder, welches den Bauprozess sauber in einer chroot-Umgebung ausführt und so das System nicht mit Fragmenten des Kompiliervorgangs kontaminiert.

pbuilder setup

Ersetze trusty durch die angepeilte Zieldistribution

sudo apt-get install pbuilder debootstrap devscripts
sudo pbuilder create --distribution trusty --debootstrapopts --variant=buildd

configure sources.list

sudo echo "deb-src http://ppa.launchpad.net/formorer/icinga/ubuntu trusty main" >> /etc/apt/sources.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 36862847
sudo apt-get update

icinga2

Herunterladen der Quellen in das aktuelle Verzeichnis

sudo apt-get source icinga2

Das Bauen der Pakete dauert auf einem ODROID U3 etwa eine Stunde (-j4 an die Anzahl der CPU-Kerne anpassen)

sudo pbuilder build --debbuildopts "-j4" icinga2_2.2.4-1~ppa1~trusty1.dsc

icinga-web

Das Ganze funktioniert entsprechend für icinga-web

sudo apt-get source icinga-web
sudo pbuilder build icinga-web_1.11.2+dfsg1-1~ppa1.dsc

Die Resultate liegen dann in /var/cache/pbuilder/result/

Vielen Dank an andrenarchy für die exzellente Zusammenarbeit bei der Erstellung dieses Artikels!

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.