Icinga 2 – Monitoring automatisiert mit Puppet Teil 7: Objekte aus Hiera erzeugen

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

Vor einiger Zeit trat der Wunsch auf mit dem aktuellen Icinga-2-Modul für Puppet beliebe Objekte aus Hiera heraus zu erzeugen. Zum Beispiel aus folgender Hiera-Datei sollen ein Host-Objekt und zwei Service-Objekte gebaut werden.

        os: Linux
      check_command: ping4
      apply: true
        - host.address
      check_command: ssh
      apply: true
        - host.address && host.vars.os == Linux

In Puppet 4 lässt sich dies nun sehr einfach mit zwei Schleifen realisieren:

class { 'icinga2':
  manage_repo => true,

$default = lookup('monitoring::default')

lookup('monitoring::object').each |String $object_type, Hash $content| {
  $content.each |String $object_name, Hash $object_config| {
      deep_merge($default[$type], $object_config))

Hierbei sind sogar für jeden Objekt-Type auch noch Defaults in Hiera gesetzt, z.B. in einer Datei common.yaml, die immer gelesen wird.

      - generic-host
    target: /etc/icinga2/conf.d/hosts.conf
      - generic-service
    target: /etc/icinga2/conf.d/services.conf

Dieses Verfahren ist mit dem selben Code auf Objekte mit allen möglichen Objekt-Typen erweiterbar. Passt man den Funktionsaufruf von lookup entsprechend an, kann auch über die Hiera-Struktur gemerged werden.

Lennart Betz

Autor: Lennart Betz

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.

A naturally grown .vimrc

Vim is pretty great, honestly. But since I started using vim after growing tired of nano, a lot in my .vimrc changed… To the point where colleagues who use vim on their machine rather use nano on mine before trying to wrap their head around my workflow. Every .vimrc is different and a lot of them exist out there, over twelve thousand repositories of shared vim configurations on GitHub alone and many more on private laptops and computers.

Generally creating a .vimrc works like creating a Makefile: Copy and paste from different sources with small changes until you have an approximation of the desired result and then need to decide whether you want to go the extra mile of dealing with your configurations’ and Vims’ quirks to get it working properly or you just leave it be. This is followed by years of incremental tweaking until you have a Vim environment which works perfectly but you don’t know why. At least that’s how I do it ¯\_(ツ)_/¯

So I took a dive into my own to see what kind of madness lurks down there…

set nocompatible
set t_Co=16
set shiftwidth=4
set tabstop=4
set autoindent
set smartindent
filetype plugin on
filetype indent on

So far, so good. Nothing special. Other than that indentation is set and overwritten three times, this has not lead to any problems (yet). The next lines are a bit more interesting:

call pathogen#infect()
call pathogen#helptags()
syntax on
set background=dark " dark | light "
colorscheme solarized


pathogen is a runtime manipulator which allows you to add additional plugins to Vim easier, in my case these are vim-solarized, a popular colourscheme, and vim-fugitive, a plugin that adds git commands within Vim. #infect() loads these plugins and #helptags() generates documentation. The following lines make use of solarized and add syntax highlighting.

set nu
set listchars=eol:$,tab:>-,trail:.,extends:>,precedes:<,nbsp:_
set list
let &colorcolumn="121"
set splitbelow
set splitright
set viminfo='20,<1000

This controls numbering and control characters, colorcolumn adds a ugly line over the 121’st char to keep up with coding styles. split tells vim where to add new views when splitting (I rarely use these) and viminfo sets the copy buffer to up to 1000 lines.
Now we get to the really interesting bits, key remaps!

Artist rendition of the authors .vimrc

"See :help map-commands
"n        = Normal only
"v        = Visual only
"i        = Insert only
"         = Normal+Insert+Select only
" nore    = disable recusiveness
"     map = Recursive map

"split window switching
nnoremap <C-J> <C-W><C-J>
nnoremap <C-K> <C-W><C-K>
nnoremap <C-L> <C-W><C-L>
nnoremap <C-H> <C-W><C-H>

"Make Up and Down Arrows move half a screen
"instead of 1 line
noremap <Up> <C-U>
noremap <Down> <C-D>

"BUFFERS Used to be F6,F7. Now used by flake
set hidden
noremap :bprevious
noremap :bnext

"Because buffers change Flake to use F3 instead of F7
"autocmd FileType python map :call Flake8()

"Smart Home key
noremap <expr> <Home> (col('.') == matchend(getline('.'), '^\s*')+1 ? '0' : '^')
imap <Home> <C-o><Home>

Switching windows can be hassle without the first four remaps, but again, I rarely use split windows. Mapping the up and down arrows to jump half a screen instead just one line I added to stop myself from using them instead of j and k, I have grown quite used to it, so it gets to stay ^_^
Buffer remaps are a must! Because I do use them a lot. There have been problems with Flake, a python lint tool, which I tried to avoid by remapping flakes key… Didn’t work out, so I got rid of Flake and call pylint when required instead.

The smart home key makes the <home>-key jump to the first non-whitespace char in a line instead of the begining of the line, quite handy!

"Access commandwindow with ctrl+f or :cedit

"For dorks
map q: :q
command Wsudo w !sudo tee % > /dev/null
"Jump to next line > 120 chars
command Warnl :/\%>120v./+
"For easy copy-paste
command Cpm :set nonu paste cc=  nolist
"Catch regular caps failure
command WQ :wq

These are just a few quality of life improvements, I tend to mistype :q as q: and :wq as :WQ. The :Wsudo command lets me edit read-only files and :Cpm is for easy mouse copy and paste. :Warnl jumps to the next line with more than 120 chars, this again is to check for style problems.

Alright, that’s it. My current .vimrc. There were a few commented out lines I omitted because I have no clue what I was thinking at the time anymore, but I hope there were a few little bits someone else might find useful to feed their own beast of a .vimrc with.

Image sources:
Vim logo from vim.sexy
Shoggoth by twitter.com/nottsuo

Jean-Marcel Flach

Autor: Jean-Marcel Flach

Auch wenn man Anderes vermuten möchte: Jean ist nicht unser französischer Austauschazubi, sondern waschechter Bamberger. Die Uni war ihm zu langweilig, deshalb knöpft er sich nun im Development gleich die kniffligsten Aufgaben vor.

Open Source Monitoring Conference 2017 – Stay tuned!

OSMC 2017 | The worldwide leading conference on open source monitoring solutions
November 21 to 24 | Nuremberg

In 10 parts of this series, we will give you some valuable information about the conference as well as some impressions of the last years.

What is the OSMC about?
The bilingual conference focuses on the latest trends and developments on open source monitoring solutions and offers a unique opportunity to meet the open source community
and to gain valuable expertise. The thematic focus is broadly diversified and equally suited for beginners and advanced users.

What makes the OSMC unique?
The conference offers Interesting talks with a real benefit for the attendees, as well as hands-on workshops to expand your knowledge and monitoring know- how.
Due to the great success in the past two years, we are again offering a hackathon, which is bookable as an add-on.

We’re very excited and would be happy to welcome you to Nuremberg in November!

And now, have a look at this high class talk of the Icinga Team!


Julia Hackbarth

Autor: Julia Hackbarth

Julia hat 2017 ihre Ausbildung zum Office Manager bei NETWAYS absolviert und währenddessen das Events&Marketing Team kennen und lieben gelernt. Besondere Freude bereiten ihr bei NETWAYS die tolle Teamarbeit und vielseitige Herausforderungen. Privat nutzt Julia ihre freie Zeit, um so oft wie möglich über's Handballfeld zu flitzen und sich auszutoben. In ihrer neuen Rolle als Marketing Managerin freut sie sich auf spannende Aufgaben und hofft, dass ihr die Ideen für kreative Texte nicht so schnell ausgehen.

Foreman’s 8th birthday – How was the party?

Foreman logo

As you may remember we gave the Foreman Project another party to celebrate its 8th birthday, so now it is time for a small recap.

At 12:30 I welcomed a group of about 20 people for the event coming mostly from Southern Germany, but with Ewoud Kohl van Wijngaarden coming down from the Netherlands we had again at least one international guest. Afterwards we started with the hands-on session. This session was planned as a completely open session, so some discussions and hacking started while others played around with the demo systems I prepared. In addition to the basic setup containing several ways of provisioning, Puppet for configuration management and some plugins like OpenSCAP, Remote Execution and Expire Hosts one demo setup included the Monitoring Plugin, so Host provisioning included adding them to Icinga Web 2 Director and monitor them. Another one had added Docker integration, CoreOS provisioning and updating via Foreman’s Omaha Plugin. The third one was installed using nightly builds of Foreman and the plugins to demonstrate Puppet 5 and Ansible. The last demo was showing Katello and its Lifecyclemanagement. I think every system has created some interest but this year the most persons were interested in Ansible and Monitoring Integration, followed by Lifecyclemanagement and OpenSCAP.

Foreman Event 2017 - Start

I tried to get the talks in a reasoned order, so Michael Moll started with his talk “The last year in Foreman” which gave a nice look inside last year’s development and changes and some hints on future improvements. The second speaker was Timo Goebel with “Foreman – Advanced Use Cases” who had many ideas what he could talk about from his experience at dm/filiadata, but in the end he demonstrated how to deploy a CoreOS cluster including update management via the Omaha Plugin he created. Third talk was “Refactoring Katello Installer modules” by Ewoud Kohl van Wijngaarden who is constantly improving the quality of the Puppet modules used by the Foreman, Katello and the Kafo installer. I and probably many others will be really happy when he reaches his goal to allow a distributed setup of Katello and users being capable of upgrading Foreman to Katello. Last but not least Evgeni Golov explained some lessons learned and showed possible problems he come across while migrating a big environment to Red Hat Satellite 6 (the Red Hat branded version of Katello) in his talk “Mass-Migration of 5000 Servers to Foreman/Katello with bootstrap.py”.

Foreman Event 2017 - Evening

The casual part started afterwards with beer and pizza but it did not stop nice and productive discussions from going on. From the feedback I got all attendees enjoyed the event like I did and everyone took some additional knowledge and ideas with him when I closed the door 3 hours later. So I think you can look forward for next year and Foreman’s 9th birthday. If you can not wait, our next Foreman training is already end of September.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.

“Willkommen auf der dunklen Seite der Macht, Alexander …”

Nein, ich meine nicht die antagonistische Fraktion aus einer sehr populären Filmreihe (deren Name nicht genannt werden muss), sondern die Apple-Fraktion bei NETWAYS.

Letzten Monat habe ich nämlich meine Ausbildung zum Fachinformatiker für Anwendungsentwicklung abgeschlossen und wurde in die Development-Abteilung übernommen.

Neuer Status – neues Gehalt, neue Aufgaben … und neues Arbeitsgerät. Ich habe mich bewusst für ein MacBook Pro entschieden, weil auf dieser Plattform sehr vieles viel besser und einfacher funktioniert und ich nicht bei jeder Kleinigkeit erst den Linux-Kernel patchen und neu kompilieren, SELinux abschalten oder die IPTables-Regeln anpassen muss. 😉

Wer weiß wann ich mit dem nächsten Kunden von Angesicht zu Angesicht zu tun haben werde – diesbzgl. will ich keine Risiken eingehen.

Abstriche muss ich keine machen – schließlich bietet MacOS X alles, was das Entwickler-Herz begehrt. Außer vielleicht …


Auf Linux haben sie sich breit gemacht wie ein Türsteher: Docker, LXC, LXD und wie sie alle heißen. Auch BSD macht mit seinen Jails keine Kompromisse in Sachen Virtualisierung und Sicherheit.

Umso mehr wundert es mich, dass das BSD-basierende MacOS X dieses Feature nicht übernommen hat. Aber es wäre kein *nix-System, wenn man das nicht mit ein wenig Geschick nachrüsten könnte …

Dann eben so …

Auf meinem alten Arbeitsgerät habe ich Ubuntu 16.04 verwendet. Diese GNU/Linux-Distribution enthält von Haus aus LXD in den Paketquellen, womit ich in einer leichtgewichtigen und sicher isolierten Umgebung mal schnell was ausprobieren konnte.

Dieses Werkzeug kann ich mit einer Virtuellen Maschine problemlos weiterhin verwenden – nicht nur in der VM selbst, sondern auch vom Mac-Host aus. Genau dafür braucht man das o. g. “wenig Geschick” …

LXD Server einrichten

Man logge sich in die VM ein und erlange Administratorrechte. Dann installiert man LXD und richtet diesen darauf hin ein:

$ sudo -i
# apt install lxd
# lxd init
Name of the storage backend to use (dir or zfs) [default=dir]: 
Would you like LXD to be available over the network (yes/no) [default=no]? yes
Address to bind LXD to (not including port) [default=all]: 
Port to bind LXD to [default=8443]: 
Trust password for new clients: 
Do you want to configure the LXD bridge (yes/no) [default=yes]?

Fast alle Abfragen des Installations-Assistenten können bedenkenlos mit der Eingabetaste bestätigt werden. Die von mir hervorgehobene Frage allerdings muss mit “yes” beantwortet werden – ansonsten fällt die Nutzung vom Host aus ins Wasser. Außerdem muss ein einigermaßen sicheres Passwort gewählt werden.

Der Frage nach der “LXD bridge” folgt ein weiterer, “pseudo-grafischer” Installations-Assistent. Dessen Fragen kann man ausnahmslos mit der Eingabetaste bestätigen.

Des weiteren wird später die IP der VM benötigt:

# ifconfig
enp0s5    Link encap:Ethernet  HWaddr 00:1c:42:8b:e9:ba  
          inet addr:  Bcast:  Mask:
          inet6 addr: fdb2:2c26:f4e4:0:880a:a527:1a6:1130/64 Scope:Global
          inet6 addr: fdb2:2c26:f4e4:0:fc54:870c:56af:cba0/64 Scope:Global
          inet6 addr: fe80::fbc7:ab4d:d29f:e227/64 Scope:Link

lo        Link encap:Local Loopback  
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host

lxdbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:  Bcast:  Mask:
          inet6 addr: fdb3:61e3:ffb6:f62f::1/64 Scope:Global
          inet6 addr: fe80::4024:c9ff:fe4a:691b/64 Scope:Link

LXD Client einrichten

Da die Entwickler von LXD sich bemüht haben, nicht von Linux-spezifischen Funktionalitäten Gebrauch zu machen, funktioniert der LXD Client auch auf MacOS. Den muss man nur noch vom LXD Server in Kenntnis setzen.

Sobald das getan ist, kann auch schon der erste Container in Betrieb genommen werden.

$ brew install lxc
$ lxc remote add u1604vm
Certificate fingerprint: a761f551dffdf47d9145da2aa16b4f6be242d960ce1697994c969e495b0724fd
ok (y/n)? y
Admin password for u1604vm:
Client certificate stored at server:  u1604vm
$ lxc launch ubuntu:16.04 u1604vm:test1
Creating test1
Starting test1ge: rootfs: 100% (37.78MB/s)
$ lxc exec u1604vm:test1 -- bash
root@test1:~# man perlfunc


Es muss nicht immer Docker sein.

Gerade wenn das Testsystem sich möglichst so verhalten soll wie eine VM oder eine Physische Maschine ist LXD auf jeden Fall einen Blick Wert – auch auf dem Mac.

Alexander Klimov

Autor: Alexander Klimov

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

SSL leicht gemacht – Zertifikat einbinden (Apache2)

This entry is part of 2 in the series SSL leicht gemacht

In meinem letzten Blogpost habe ich über die Erstellung eines Keyfiles und eines CSR geschrieben. Im zweiten Teil meiner Serie SSL leicht gemacht zeige ich den nächsten Schritt und beschreibe die Einrichtung des Zertifikates mittels der Webserversoftware Apache.

nun sollten folgende Dateien vorhanden sein

  • selbst erstellt
    • CSR (in unserem Beispiel netways.de.csr)
    • Privatekey (netways.de.key)
  • von Zertifizierungsstelle erstellt und übermittelt
    • cert.cabundle
    • certificate.crt

Diese Zertifikatsdateien können jetzt auf dem Webserver eingerichtet werden.

Als nächstes werden die Zertifikatsdateien im korrekten Verzeichnis abgelegt. Hierzu eignet sich zum Beispiel /etc/apache2/ssl/netways.de/. Der CSR wird übrigens nicht mehr benötigt und kann gelöscht werden.
Apache kann im Moment noch nichts mit den Zertifikatsdateien anfangen und noch lernen “SSL zu sprechen”. Dazu wird ein SSL-VHost eingerichtet. Als Basis hierfür kann der abzusichernde VHost vorerst kopiert werden.

cp /etc/apache2/sites-available/001-netways.de.conf /etc/apache2/sites-available/001-netways.de-ssl.conf

Diese neue SSL-Config wird nun angepasst, damit der Apache nun weiß, was er zu tun hat.

Innerhalb der nun betreffenden VHost-Definition werden nun noch ein paar Paramater für SSL angegeben

SSLEngine on
 SSLCertificateKeyFile /etc/apache2/ssl/netways.de/netways.de.key
 SSLCertificateFile /etc/apache2/ssl/netways.de/certificate.crt
 SSLCertificateChainFile /etc/apache2/ssl/netways.de/cert.cabundle

Übrigens in der Einleitung der VHost-Definition (i. d. R. ganz oben in der neuen Datei) sollte der angegebene Port 80 auf 443 geändert werden.

<VirtualHost 123.456.789.012:80> auf <VirtualHost 123.456.789.012:443>

Abschließend wird der Apache noch um ein paar Funktionalitäten erweitert (SSL und der neue VHost wird aktiviert):

a2enmod ssl
a2ensite 001-netways.de-ssl.conf
service apache2 restart

Der VHost ist nun zusätzlich mit SSL abgesichert und in unserem Beispiel via https://netways.de und http://netways.de erreichbar. Ob alles geklappt hat, sieht man nun am erfolgreichen Verbindungsaufbau via HTTPS oder kann es zum Beispiel bei SSL Labs ausführlich prüfen lassen.

Die Namensgebung der Zertifikate unterscheidet sich von Zertifizierungsstelle zu Zertifizierungsstelle und kann auch mal mit .pem bezeichnet sein usw. Dies kann “ignoriert” werden und beliebig selbst in der Config auf die neuen Endungen angepasst werden. Auch eine Umbenennung der Dateien auf das eigene Schema ist ein möglicher Lösungsansatz.

In den nächsten Blogposts zum Thema SSL leicht gemacht geht es um:

  • forcierte Weiterleitung von HTTP auf HTTPS einrichten
  • Hardening von unterstützen Ciphers und Protokollen – der Weg zum A+ Rating
  • Zertifikat einbinden (nginx)
  • Gitlab via TLS absichern
  • Zertifikate selbst signieren

Übrigens: Zertifikate müssen nichts kosten. Eine Alternative mittels Letsencrypt ist hier beschrieben.

Georg Mimietz

Autor: Georg Mimietz

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.