Ein paar vim tricks

Ich benutze in meiner täglichen Arbeit vim als Editor. Im Laufe der Zeit habe ich dabei ein paar Dinge gelernt, die mir das Leben einfacher machen. Ein paar dieser “Tricks” möchte ich euch heute einmal zeigen.

Autovervollständigung

Mit vim kann man seine Texte und Scripte autovervollständigen lassen. Das funktoniert mit normalen Wörtern, die schon einmal im Text vorgekommen sind STRG + n, mit ganzen Zeilen STRG + x + l oder mit Dateien und Ordnern im Filesystem.

Einfügen auf mehreren Zeilen

Es ist zwar nicht intuitiv, aber man kann relativ einfach viel Text auf einmal einfügen. Man kann entweder vor der Curserposition, z.B. am Anfang der Zeile, oder am Ende der Zeile Zusätzliche Zeichen hinzufügen.

In jedem Fall muss man erstmal mit STRG + v die Zeilen markieren, die bearbeitet werden sollen.
Das # am Anfang der Zeilen fügt man jetzt mit SHIFT + i (instert mode), gefolgt von #, gefolgt von ESC ein.
Der . am Ende der Zeilen funktioniert ähnlich. Aber statt SHIFT + i kommt $A zum Einsatz. Wieder gefolgt von dem Zeichen . und einem ESC.

History im vim

Lange zeit dachte ich, wenn ich zweimal dd benutze ist dar erste Inhalt weg. Genauso wie bei Word’s “auschneiden/einfügen”. Das ist allerdings nicht wahr. mit :reg kommt man in die History vom vim. Möchte man z.B. den dritten eintrag einfügen, geht das mit “3p.

json, jq und vim

In vergangen Blogposts wurde ja schon über die Macht von API, json und jq geschrieben. Das lässt sich wunderbar auch im vim kombinieren. Wenn ich mir Beispielsweise die Services einer icinga2 API ausgeben lasse, schaut das erstmal im vim recht unleserlich aus.

curl -k -u root:icinga 'https://127.0.0.1:5665/v1/objects/services' |vim -

Erst durch ein :%!jq ‘.results[].attrs | select(.active==true) | {__name, display_name, enable_perfdata}’ wird daraus etwas schönes.
Jetzt wird nur noch Name, display_name und enable_perfdata angezeigt. Und das nur von Services, die “active” sind.

Christoph Niemann

Autor: Christoph Niemann

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Einfaches verschlüsseltes Backup

Seit In­kraft­tre­ten 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

 

Christoph Niemann

Autor: Christoph Niemann

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Samba Samba die ganze Nacht

samba.org logoWer in seinem Unternehmen heterogene Umgebungen vorfindet ist oftmals gezwungen Brücken zwischen der Linux/Unix Welt und Windows zu schlagen. Hierfür wird gerne der freie und quelloffene Samba Server eingesetzt. Dieser stellt per SMB Protokoll Freigaben bereit.
Nun ist es eine Sache die Windows Kollegen zu hetzen, alte Windows XP Maschinen abzustellen. Die andere Seite der Medaille ist die Absicherung der eigenen Serverdienste. Denn wenn der Linux Server immer noch SMBv1 spricht ist der nächsten WannaCrypt/WannaCry Attacke Tür und Tor geöffnet. Microsoft warnt z.B. im Technet Blog vor dieser Möglichkeit.

Die Abhilfe dagegen ist relativ einfach, man verbiete SMBv1. Die Änderung erfolgt in /etc/samba/smb.conf innerhalb der “global” section.

 [global]
 ...
 #min protocol = SMB2
 client min protocol = SMB2
 server min protocol = SMB2
 ...

 

Christoph Niemann

Autor: Christoph Niemann

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Ungewöhnliche Überwachungen

Kuh auf WieseBei meinen Einsätzen als Consultant bei Netways bin ich oft bei Kunden vor Ort und darf mich immer wieder von der Unterschiedlichkeit der Monitoring Installationen überzeugen. Dabei fallen mir immer wieder kreative und ungewöhnliche Methoden auf neue Dinge zu überwachen. Über den Sinn und Unsinn dieser Checks darf zwar gerne gestritten werden, dennoch wollte ich euch ein paar Ideen nicht vorenthalten.

Check boss / Schwiegermutter

Dieser Check ist perfekt wenn du nicht von einem plötzlichen Besuch deines Chefs im Büro oder der Schwiegermutter zu Hause überrascht werden willst. Da heutzutage ja alle ein Smartphone mit sich herumtragen kann man einfach checken, ob bzw. auf welchem Accesspoint jemand eingeloggt ist um Frühzeitig über sein erscheinen informiert zu sein. Wie ich aus zuverlässiger Quelle gehört habe geht das zu Hause bequem mit einem Raspberry und einem Check, der den arp table überwacht. Im Unternehmen hat man häufig bessere Accesspoints, die per snmp auf angemeldete devices geprüft werden können. Hier kann man die Daten auch noch mit Geo Koordinaten versehen und anzeigen wo der Boss sich auf dem Betriebsgelände versteckt 😉

Check bitcoin/pool

In einem Unternehmen mit bitcoin affiner IT-Abteilung haben mehrere Admin’s zu Hause ein paar mining Server stehen. Hier hat es sich angeboten, die mining Rate mit check_btcpool zu überwachen und bei einem Abfall zu informieren.
Da hier sowieso schon gebastelt wurde haben die Herren gleich noch eine flotte Überwachung der bitcoin Kurse auf Basis der bitcoin.de API hinzugefügt. Bei Ausbruch aus einem bestimmten Korridor wird auch hier informiert.

Check bot

Überraschenderweise kann man sogar Pflanzen monitoren. Ein Botanik-Check überwacht EC, PH und Feuchtigkeit im Boden und setzt im Eventfall 5 Sekunden lang eine Pumpe in Gang die das Beet bewässert. Auf Grund der Langzeitdaten über EC und PH Wert kann man das Gießwasser mit Dünger und anderen Stoffen vorbehandeln und hat so eine perfekte Nährlösung. Allerdings ist die Ausrüstung hierfür wohl nicht ganz günstig. Das Ganze bietet sich also wohl nur für den professionellen Gemüsebauer an.

Check meat

In der Landwirtschaft geht es weiter. Der moderne Bauer hat schon einiges an IT bei sich herumstehen. Das Rind ist überwacht, der Biogastank blubbert. Doch wer überwacht die Überwacher dieser Prozesse? Natürlich Icinga. Neben der Überwachung der eigentlichen IT sowie der Melk und Futtersysteme bin ich hier auf die Idee gestoßen die Rinder mit Hilfe des maps moduls für icinga2 zu lokalisieren. Hierfür war es natürlich nützlich, dass alle Rinder ein RFID Halsband tragen und sich an den Trinkstellen selbst “anmelden”. Einer interessanter Einsatz des Netways Monitors war hier die Temperaturüberwachung der Ställe. Dabei ging es vor allem um ein Überschreiten der Temperatur im Sommer.

Wenn ihr noch ungewöhnliche Checks kennt oder eine irre Idee habt schreibt es gerne in die Kommentare.

Christoph Niemann

Autor: Christoph Niemann

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Was macht eigentlich . . .

This entry is part 13 of 13 in the series NSClient++

. . . NSClient++ ? Länger haben wir hier im Blog nichts mehr zum Thema NSClient geschrieben. Grund genug um mal wieder den aktuellen Entwicklungsstand zu überprüfen.

Aktuell wird der Monitoring Agent in 2 Strängen weiterentwickelt. Die Version 0.4.4 ist als stable markiert und bekommt nur noch bugfixes und kleinere Erweiterungen. In Version 0.5.0 wurden einzelne Module komplett neu geschrieben. Mit der aktuellen 0.5.0.59 wurde weiter an der Stabilität und einzelnen Checks gearbeitet.

nsclient-logoBesonders hervorzuheben sind im 0.5er Release der Webserver, der ssl gesichert und REST-apifiziert Kommandos entgegen nimmt und Informationen zurückliefert, Auch ist es in der aktuellen Version möglich Performancedaten direkt an graphite zu schreiben, was besonders in Großen Umgebungen zu einer starken Entlastung des monitoring servers (egal ob icinga 1 oder 2) führen kann. Um den überwachten Server besser zu schützen beendet NSClient jetzt alle von ihm angestoßenen Skripte wenn es selbst beendet wird, damit keine Langläufer mehr verloren gehen.

Bei allen Verbesserungen in 0.5 sollte man aber nicht vergessen, dass diese Version noch beta ist und nur mit der nötigen Vorsicht verwendet werden sollte.

Christoph Niemann

Autor: Christoph Niemann

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.