In diesem kurzen Beitrag will ich auf einen Fallstrick im Bezug von HAProxy und SQL Backends wie MySQL oder MariaDB eingehen. Speziell geht es um Grants und die damit verbunden Quell Hosts. Diese werden bei einem Standard Setup mit HAProxy durch die IP des Proxys ersetzt. Solange man sich in dem selben Netz wie die DB Server und dem Proxy befindet und die Host-Beschränkungen nicht all zu streng sind, kann es gut sein, das man dieses Szenario nicht erreicht. Sobald die Verbindungen aber Netz übergreifend erfolgen und die Grants damit umso wichtiger sind, kommt das Detail zum Tragen und stellt einen vor neue Herausforderungen. Dafür gibt es an sich schon etwas länger das Proxy Protokoll, welches aber erst nach und nach in mögliche Backend Software implementiert wurde/wird. Bei MariaDB war es mit der 10.3.1 z.B. erst Ende letzten Jahres soweit.
Die Arbeitsweise des Protokolls beschreibt sich einfach gesagt so, dass mit dem Aufbau der Verbindung zuerst ein zus. Header geschickt wird, in dem die IP des Quell Hosts bekannt gegeben wird. Dazu muss das Backend jedoch von der IP des HAProxys das Proxy Protokoll erlauben. Das Ganze drum rum kann mit Seiten über weitere Details und Sicherheit befüllt werden. Damit verschone ich Euch aber und weise nur auf eine schlichte Zusammenfassung im Blog von HAProxy hin.
NETWAYS Blog
Monthly Snap August – NETWAYS News | Tipps & Tricks | Upcoming… | Corporate Blogging
„Das @netways Blog kann man auch generell einfach mal empfehlen: https://www.netways.de/ – immer wieder spannende Sachen bei den Posts dabei“, twittert Felix Kronlage Anfang August. Das freut mich und meine Kolleginnen und Kollegen natürlich sehr! Denn, wie ihr als fleißige Blog-Leser/innen sicher wisst, das NETWAYS Blog ist, ganz im Geiste von Open Source, ein offenes Gemeinschaftsprojekt, geschrieben von uns, dem NETWAYS Team.
Wir haben unseren Redaktionsplan so organisiert, dass das Schreiben wie ein Staffelstab Tag für Tag durch unser Headquarter und von Team zu Team gereicht wird: Montags Shop & Sales, dienstags Events & Marketing, mittwochs Managed Services, donnerstags Development, freitags Consulting. Für samstags planen wir eventuelle Specials und am Monatsende gibt es, so wie heute, einen Rückblick, den Monthly Snap. Der Snap bietet die Gelegenheit, noch einmal zu rekapitulieren. Während ich bei meinem täglichen Blick in das Blog meinen Fokus ja eher auf den einzelnen Beitrag des Tages richte, fällt mir jetzt am Monatsende mal wieder die Bandbreite an Themen und die Vielzahl der Stimmen auf, die unseren Blog und damit NETWAYS ausmachen!
Im besten Falle findet ihr, genau wie Felix, das ein oder andere für euch spannende Thema und klickt euch durch die Links. Viel Spaß dabei!
CEO Bernd hat diesen Monat seine Vergleichsserie wieder aufgenommen und veröffentlicht Icinga, Nagios, Naemon, OMD, Check_MK, Op5, Centreon oder Shinken – Teil III. Außerdem verweist er auf das Bitkom Forum Open Source 2018.
Webinare – Aus der Asche
In NETWAYS Webinare – Aus der Asche erfahrt ihr von Christian mehr über ein kleines Hitze- und Performance-Problem und die Termine aller Webinare in der zweiten Jahreshälfte, während Silke vom Shop & Sales-Team euch darüber informiert: Die neuen STARFACE Pro V6 und STARFACE Compact V3 Anlagen sind da!
Und natürlich gibt es auch wieder eine bunte Kiste voller Tipps und Tricks von unseren Entwicklern, Administratoren und Consultants, die vielleicht auch euch das Leben erleichtern: Jennifer – Feu – verrät „How css-tricks improved my work life“. Thomas weiß, es gibt JSON in bequem. Noah stolpert durch Zufall darüber und ist ab sofort happy mit Postman – API development and testing made simple. Philipp setzt seine i-doit-Reihe fort mit i-doit API create, update, delete.
La La Lan & Molecule
Max zeigt euch in seiner La La Lan-IT Love Story wie man Linux Netzwerkschnittstellen mit check_nwc_health überwachen kann. Florians Thema: MySQL-Datenbanken verwalten mit Sequel Pro. Tim teilt sein Wissen über Adfree Internet with pi-hole.
Blerim stieß, als er an der Ansible Role für Icinga 2 arbeitete, auf ein hilfreiches Tool. Lest selbst: Testing Ansible Roles with Molecule. Ihr wollt mehr über Icinga 2 wissen, genauer, wie ihr mit Puppet eine dezentrale Icinga 2-Umgebung aufbaut und konfiguriert? Wir haben da einen neuen Workshop! Was euch erwartet, erfahrt ihr von mir in Ice, Ice – Icinga 2 / Puppet – Baby!
GitLab as a Service, Mutual SSL und OpenStack
Gitlab | self-hosted vs. Gitlab as a Service – Marius wagt den Vergleich! Die vergangenen Monate hat er außerdem genutzt, um eine neue Cloud aufzubauen und weiß nun allerhand über Bursting und Throtteling in OpenStack zu berichten.
Jean beschäftigt sich in The Walrus Has Landed mit Structured Logging in Go und Georg dank einer Kunden-Anfrage mit der Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache. Sein Motto: Gesagt, getan.
DevOpsDays, OSBConf, OSMC und OSCAMP
Eventmäßig ist der August selbst ein eher ruhiger Monat. Klar: Viele sind in Urlaub, in zahlreiche Länder verstreut. Dafür stehen im Herbst die Zeichen umso mehr auf Get-Together. DevOpsDays | Sep 12. – 13. // OSBConf | Sep 26 // OSMC | Nov 5. – 8. // OSCamp | Nov 8. Mehr erfahrt ihr hier von Keya und mir: Devs are from Venus, Ops are from Mars? – DevOpsDays Berlin Program Online!, Why you shouldn’t miss OSBConf 2018 – #1 und #2, OSMC program online: Check out who’s in! Und OSCAMP #2 on Puppet: Get on stage!
Und sonst so?
Wir haben Gunnar verabschiedet, ohne den wir Icinga heute so nicht hätten, und unseren ersten neuen Azubi willkommen geheißen, Henrik Triem im Development, und eine Woche Unterstützung von Nadine gehabt, die als Berufsschullehrerin mal Firmenluft schnuppern wollte.
Unser Schulungsraum Kesselhaus hat jetzt Jalousien und kann verdunkelt werden. Wir werden am 17. Dezember ein IcingaCamp in Tel-Aviv veranstalten und Icinga ist jetzt offizieller Partner im HashiCorp Technology Partner Program.
Viele Themen, viele Stimmen, viel Neues, viel Spannendes!
So much happend, more to come! Stay tuned!
SNMP Netzwerk Monitoring
Huhu!
Heute möchte ich euch ein wenig in die Welt von SNMP Monitoring mit Icinga 2 entführen. Da man leider nicht immer einen Switch mit SNMP zur Hand hat, verwende ich eine GNS3 Netzwerk Umgebung sowie eine CentOS 7 Maschine für Icinga 2.
Doch was ist den dieses SNMP überhaupt, was kann das? Zunächst SNMP steht für Simple Network Message Protocol (RFC 1157) und wurde mit dem Gedanken entwickelt Netzwerkgeräte wie Drucker, Router, Switche und vermutlich irgendwann auch Toaster per IoT von einem Zentralen Punkt im Netzwerk aus überwachen bzw. steuern zu können. SNMP an sich besitzt nicht wirklich viel Magie es beschreibt im Endeffekt wie Datenpakete aussehen können. Damit Icinga 2 (Managmentstation) den Switch (Agent) fragen kann, wie es ihm den heute so geht. Die eigentliche Magie ist die sogenannten Managment Information Base, umgangssprachlich auch MIB genannt.
Die MIB kann man sich wie einen großen Baum vorstellen, dessen Äste und Blätter mit Hilfe von eindeutigen OIDs gebildet werden. Die Blätter die an unseren Ästen hängen sind Objekte wie ein Lüfter, oder eine Festplatte und können als als OID so aussehen: 1.3.6.1.4.1.1.4.
Nach viel Techbabbel kommt nun wenig Kaboom (Practical Examples). An Hand des Beispiel möchte ich euch ein Grundgerüst an die Hand geben, wie man bequem und ohne Geräte spezifisches Plugin ein SNMP Monitoring unter Icinga 2 einfach realisieren kann.
Im ersten Schritt holen wir uns alle OIDs samt Beschreibung vom Gerät, in meinem Fall von einem VyOS Router:
snmpwalk -Os -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_desc snmpwalk -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_oid
Für das Beispiel wähle ich drei OIDs aus:
.1.3.6.1.2.1.2.2.1.2.1
.1.3.6.1.2.1.2.2.1.2.2
.1.3.6.1.2.1.2.2.1.2.3
Mit dem Director hab ich ein Template und Service angelegt, welches auf das Check_Plugin/Kommando check_snmp zurückgreift. Die ausgewälten OIDs werden Kommasepariert per Costume Attribut „snmp_oid“ mitgegeben:
template Service "snmp" { check_command = "snmp" max_check_attempts = "3" check_interval = 1m retry_interval = 20s }
object Service "Interfaces" { host_name = "vyos" import "snmp" vars.snmp_label = "Interfaces" vars.snmp_oid = ".1.3.6.1.2.1.2.2.1.2.1,.1.3.6.1.2.1.2.2.1.2.2,.1.3.6.1.2.1.2.2.1.2.3" }
Nach dem ausbringen der Konfiguration sollte das ganze folgendermaßen aussehen:
Tipp am Rande:
Falls euer Gerät nicht auf Öffentlichen MIBs aufbauen sollte, wie hier im Beispiel, bekommt ihr die im Regelfall vom Hersteller bereitgestellt. Die MIB wird einfach zu den bereits existierenden hinzugefügt und dann ist alles wie gehabt! 🙂
Damit verabschiede ich mich und wünsche wie immer viel Spass beim Implementieren!
MySQL-Datenbanken verwalten mit Sequel Pro
Eines meiner meist genutzten Apps am Mac ist Sequel Pro. Das kann man kennen, muss man aber nicht. Daher liest man – wenn man möchte – in den folgenden Zeilen eine kurze Vorstellung.
mehr lesen…

Einfaches verschlüsseltes Backup
Seit Inkrafttreten der DSVGO ist Datenschutz in aller Munde. Da wird es einmal Zeit auch den Datenschutz des Monitoring-Servers zu überdenken. Dabei denke ich in diesem Fall nicht an die diversen Härtungsmaßnamen wie SSL für Webserver und Datenbank. Auch Icinga2 erzwingt bei seinen API Verbindungen immer verschlüsselte Verbindungen.
Wo bleiben aber die Backup Dateien? Einmal erzeugt, verlassen sie den Server und liegen dann ‚woanders‘. Zum Glück ist es nicht unbedingt nötig, dass man dem File Server voll vertraut. Eventuell ist es günstig die Backup in irgendeine Cloud zu schieben, oder auf den semi public File Server der Unternehmens. Mit Hilfe von GPG kann man seine Daten einfach verschlüsseln und sicherstellen, dass alle Berechtigten sie auch wieder entschlüsseln können. Im folgenden wird erklärt wie man GPG benutzt um ein icinga2 Backup für eine Gruppe von Berechtigten zu verschlüsseln ohne das der private key einer Person den Monitoring Server oder den Backup Server berührt.
1.) gpg Schlüsselpaar erstellen
Am einfachsten benutzt man das CLI tool gpg um den key zu erzeugen. Das sollte man aber auf einem sicheren System machen, z.B. dem eigenen Laptop oder Arbeitsplatz PC. Anschließend wird der öffentliche Teil an einen Keyserver gesendet um den Schlüsselaustausch zu vereinfachen.
$ gpg --full-gen-key [...] Ihr Name ("Vorname Nachname"): Max Mustermann Email-Adresse: max.mustermann@example.org pub rsa2048 2018-05-31 [SC] [verfällt: 2023-05-30] XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0BA2D8D6 Max Mustermann <max.mustermann@example.org> $ gpg --keyserver pool.sks-keyservers.net --send-key 0BA2D8D6
2.) Monitoring Server mit Schlüsseln versorgen
Auf dem Server kann man mit Hilfe der gpg group Funktion die Daten mit den public keys einer ganzen Gruppe verschlüsseln. Hierfür muss man diese Gruppe in der ~/.gnupg/gpg.conf anlegen.
$ vim .gnupg/gpg.conf +80 group icingabackup = max.mustermann@example.org john.doe@example.org
Anschließend kann man die public keys vom keyserver laden und ihnen das Vertrauen aussprechen. Nur wenn man allen Schlüsseln „absolutes Vertrauen“ ausspricht läuft der encryption Prozess ohne weitere Rückmeldungen ab.
$ gpg --keyserver pool.sks-keyservers.net --search-keys max.mustermann@example.org gpg: suche nach "max.mustermann@example.org" auf hkp-Server pool.sks-keyservers.net (1) Max Mustermann (Test) <mustermann@example.org> 4096 bit RSA key 0BA2D8D6, erzeugt: 2013-11-18 $ gpg --keyserver pool.sks-keyservers.net --recv-keys 0BA2D8D6 $ gpg --edit 0BA2D8D6 trust 5 = Ich vertraue ihm absolut $ gpg --keyserver pool.sks-keyservers.net --search-keys johndoe@example.org gpg: suche nach "johndoe@example.org" auf hkp-Server pool.sks-keyservers.net (1) John Doe (Work email) johndoe@example.org 4096 bit RSA key 732D8994, erzeugt: 2018-04-20, verfällt: 2020-04-19 $ gpg --keyserver pool.sks-keyservers.net --recv-keys 732D8994 $ gpg --edit 732D8994 trust 5 = Ich vertraue ihm absolut
3.) Backup erzeugen und verschlüssen
Das kurze bash Script sammelt Dateien von icinga2 und icingaweb, erzeugt einen mysqldump, packt alles zusammen und verschlüsselt es zum Schluss. Alle Schritte sind im Script kommentiert. Bitte lesen sie unbedingt auch die Hinweise in der icinga2 Dokumentation zu diesem Thema.
#!/bin/bash DATE=`date +%Y%m%d%H%M` # Backup script for icinga2 and icingaweb2 # Choose which parts will be backed up. BACKUP_ICINGA2=true BACKUP_ICINGAWEB2=true BACKUP_MYSQL=true ENABLE_ENCRYPTION=true DELETE_OLD_FILES=true # Backup target dir BACKUPDIR=/data/icinga2_backup # Backup retention time. Files will be deleted after 14 days RETENTION_TIME=14 # Icinga2 settings ICINGA2FILES="/etc/icinga2 /var/lib/icinga2 /etc/default/icinga2" # Icingaweb2 settings ICINGAWEB2FILES="/etc/icingaweb2 /usr/share/icingaweb2" HTTPD_ETCDIR="/etc/apache2" # mysql settings MYSQL_DATABASES="mysql icinga icingaweb director" MYSQL_ETCDIR="/etc/mysql" MYSQL_DUMP="$BACKUPDIR/tmp/icingaMysqlDump.sql.gz" # encryption settings GPG_RECIPIENT=icingabackup # Ensure Backupdir exists [ ! -d $BACKUPDIR ] && mkdir -p $BACKUPDIR/tmp # Add icinga2 folders if [ $BACKUP_ICINGA2 = true ]; then BACKUPFILES+=" $ICINGA2FILES" fi # Add icingaweb2 folders if [ $BACKUP_ICINGAWEB2 = true ]; then BACKUPFILES+=" $ICINGAWEB2FILES" BACKUPFILES+=" $HTTPD_ETCDIR" fi # Add my folders and mysqldump if [ $BACKUP_MYSQL = true ]; then BACKUPFILES+=" $MYSQL_ETCDIR" if [ ! -z "$MYSQL_DATABASES" ]; then mysqldump --create-options --databases ${MYSQL_DATABASES} | gzip > $MYSQL_DUMP BACKUPFILES+=" $MYSQL_DUMP" fi fi # make archive TAR=$BACKUPDIR/icingaBackup_${DATE}.tar.gz if [ ! -z "$BACKUPFILES" ]; then # Archive all files and delete mysqldump tar -czf $TAR $BACKUPFILES 2> /dev/null && [ -e $MYSQL_DUMP ] && rm $MYSQL_DUMP fi # encrypt archive if [ $ENABLE_ENCRYPTION = true ]; then gpg --encrypt --recipient icingabackup $TAR && rm $TAR fi # delete everything older than 14 days if [ $DELETE_OLD_FILES = true ]; then find $BACKUPDIR -mtime +$RETENTION_TIME -exec rm \{\} \; fi
4.) Cron
Um das Backupscript jeden Tag auszuführen kopiert man es auf den Server und trägt es im crontab ein:
root@icingaMaster# crontab -e @daily /root/backup_icinga2.sh
5.) Decrypt
Da beim verschlüsseln alle User der Gruppe icingabackup berechtigt wurden kann jeder aus dieser Gruppe die Dateien wieder entschlüsseln.
gpg –output icinga2Backup.tar.gz –decrypt icinga2Backup.tar.gz.gpg
