Ich wünsche allen Lesern einen guten Rutsch ins Jahr 2015 !
Monthly Archives: Dezember 2014
Munin unter Fedora 21 zum Laufen bringen
Munin hat speziell mich die letzten zwei Wochen auf Trab gehalten, seitdem unsere Testserver für die neuen Softwarekomponenten auf Fedora 21 umgestellt wurden. Jeden Tag haben wir hunderte Emails von Munin bekommen, daß alles auf dem Server ok wäre. Eine Konsultation mit den Entwicklern von Munin brachte nur ein „Kann ich nicht reproduzieren“ hervor, ja.. also.. kann passieren 😉
Da mir das nun langsam auf die Nerven gegangen ist, habe ich mich dann selbst an Munin versucht.
Das Problem
Das DiskFree Modul und die DiskFree-Inodes Modul von Munin ( kurz df und df_inode) gehen die Liste von Filesystemen eines Servers durch und prüfen, ob diese voll oder fast voll sind. Dabei wird scheinbar alles geprüft, was irgendwie ein Filesystem ist, selbst romfs, ramfs und debugfs, die ja nun keine echten Filesysteme mit möglichen Belegungsproblemen sind. Komischerweise schickte uns Munin immer nur OK Meldungen, aber keine Warnmeldungen zu df und df_inode zu. Die Filesysteme auf den Servern hatten zudem auch gar keine Belegungsprobleme, trotzdem haben wir alle 15 bis 30 Minuten so eine Email bekommen.
testdomain.de :: testdomain.de :: Inode usage in percent OKs: /run/user/0 is 0.00, /sys/fs/cgroup is 0.01, /opt/root/dev/shm is 0.00, /run is 0.88, / is 3.78, /run/user/496 is 0.00, /dev/shm is 0.00, /dev is 0.24.
Die Analyse
Munin bietet zwar von Haus aus Debugfunktionen an, aber keine führte zum Ziel. Damit man Munin debuggen kann, muß man zunächst zum Munin User werden, der „normalerweise“ keine Shell hat, damit man sich nicht einloggen kann:
# su munin -s /bin/bash
Dann gibt mal als erstes mal munin-limits ein, um sich einen Überblick zuverschaffen.
# /usr/share/munin/munin-limits --debug
pre>2014/12/22 15:41:19 [DEBUG] processing critical: _dev_xvda1 -> : 98
2014/12/22 15:41:19 [DEBUG] processing warning: _dev_xvda1 -> : 92
2014/12/22 15:41:19 [DEBUG] processing unknown_limit: _dev_xvda1 -> 3
2014/12/22 15:41:19 [DEBUG] processing field: localhost::localhost::df::_dev_xvda1
2014/12/22 15:41:19 [DEBUG] field: $VAR1 = {
‚#%#name‘ => ‚_dev_xvda1‘,
‚critical‘ => ’98‘,
‚graph_data_size‘ => ’normal‘,
‚label‘ => ‚/‘,
‚update_rate‘ => ‚300‘,
‚warning‘ => ’92‘
};
2014/12/22 15:41:19 [DEBUG] value: localhost::localhost::df::_dev_xvda1: 22.62 (crit: :98) (warn: :92)
2014/12/22 15:41:19 [DEBUG] generating service message: localhost::localhost::df
2014/12/22 15:41:19 [DEBUG] Contact list for localhost::localhost::df:
2014/12/22 15:41:19 [DEBUG] processing service: fw_conntrack
2014/12/22 15:41:19 [DEBUG] state_file: /var/lib/munin/state-localhost-localhost.storable
Das obige Beispiel ist natürlich nur ein Ausschnitt, im Normalfall kommen dort Dutzende verschiedene Werte zur Ausgabe. Interessant ist diese Zeile:
value: localhost::localhost::df::_dev_xvda1: 22.62 (crit: :98) (warn: :92)
Der Wert des Feldes „df“ war 22.62 % für /dev/xvda1 ( unsere Rootpartition ). Eine Warnung gibt es bei 92 % Belegung und einen Critical ab 98%. In diesem Beispielfall kommt also keine Email zustande, weil alles im Toleranzbereich ist.
Munin schickt laut Sourcecode nur dann noch Emails, wenn sich der Zustand geändert hat, also z.b. vorher Critical war und dann bei nächsten Check wieder OK ist. Genauso in die andere Richtung ( ok -> fail ).
d.h., wenn Munin keinen anderen tieferen Bug hat, muß es so einen Wechsel festgestellt haben und da die Platte als Quelle ausschied, weil dich dort nicht geändert hat, mußte die Warnung für ein anderes Filesystem gekommen sein, auch wenn man das nicht gesehen hat. Allzuviele kommen da nicht in Frage:
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf /dev/xvda1 78G 17G 58G 23% / devtmpfs 490M 0 490M 0% /dev tmpfs 500M 0 500M 0% /dev/shm tmpfs 500M 3,1M 497M 1% /run tmpfs 500M 0 500M 0% /sys/fs/cgroup tmpfs 500M 4,0K 500M 1% /opt/root/dev/shm tmpfs 100M 0 100M 0% /run/user/0
Scheinbar hatten sich die Ausgaben für tempfs und devtempfs von Fedora 20 zu Fedora 21 verändert,
was Munin verwirrt hat.
Die Lösung
Nach einigen Tests gelang es mir dann, Munin zur Aufgabe zu bewegen.
Dazu muß man in der plugin-conf für df das devtempfs und das tempfs excluden. Es macht sowieso kaum Sinn ein Ramlaufwerk zu checken, da Ramlaufwerke i.d.R. immer zu 100% voll sind, außer man hat ein fixed Ram-Drive gewählt.
# cat /etc/munin/plugin-conf.d/df [df*] env.exclude none unknown iso9660 squashfs udf romfs ramfs debugfs binfmt_misc rpc_pipefs fuse.gvfs-fuse-daemon tmpfs devtmpfs
Das alleine half aber nur bei dem Wert für df, df_inode sendete fleißig weiter OK Meldungen. Wie sich dann herausstellte, kann man auch für das df_inode eine eigene Configdatei ablegen. Dazu braucht man nur die df Datei zu kopieren „cp df df_inode“ und dann das System neustarten : systemctl restart munin-node . Den letzten Schritt sollte man nicht vergessen, denn auch wenn Munin alle 5 Minuten vom Cron gestartet wird, heißt das nicht, daß die Limits dann eingelesen werden, da die Node als eigener Prozess läuft.
pünktlich zum Fest WordPress 4.1
WordPress 4.1 ist erschienen und steht nun allen Braunschweig-Bloggern zur Verfügung.
Bankraub im 21. Jahrhundert
Einen schönen Artikel darüber, wie man erfolgreich eine Bank ausräumt, findet sich heute bei heise.de .
Aus Securitysicht ein wahrer Albtraum, da wieder mal die einfachsten Regeln nicht beachtet wurden und das in einer Bank. Wer jetzt glaubt, daß wäre auf Russland beschränkt, der irrt und damit zitiere ich nicht den Artikelinhalt 😉 Das Problem mit IT-Sicherheit ist, daß Menschen in den Computern noch arbeiten müssen und genau dann, wenn es unbequem wird, ist es mit der IT-Sicherheit vorbei. Da wird dann doch mal die alte Version benutzt, statt der gebugfixten neuen Version nur weil damit etwas nicht mehr so einfach geht, wie in der vorherigen Version. Der Klassiker ist der Emailtrojaner, der dann von dem ratlosen Mitarbeiter an alle gemailt wird, weil er mit der Email nichts anfangen kann. Das ist alles Alltag in deutschen Firmen. Zum Artikel bei heise.de
UDP Traffic per SSH tunneln
SSH Tunnel sind eine gängige Methode um Traffic sicher von einer Maschine auf die andere umzuleiten, aber SSH kann nur TCP Traffic tunneln. Wie bekommt man jetzt UDP über SSH getunnelt ?
Die Antwort lautet : gar nicht! Man muß TCP Traffic draus machen 🙂
Als ersten Schritt öffnen wir mal den Tunnel: (alle Befehle als Root ausführen versteht sich)
root# ssh -L 8080:localhost:8080 username@zielserver.de „sleep 10000“
Dies schiebt alle Daten die auf Port 8080 ankommen, an den Port 8080 des Zielserver. Der Einfachheit halber, belassen wir die Port auf Quell- und Zielsystem bei der gleichen Nummer, aber das kann man auch nach Bedarf anpassen.
Als erstes brauchen wir einen FIFO ( First In – First Out ) Speicher auf dem Zielserver. Damit kann man die Daten lesen und schreiben, was bei einer PIPE nicht geht.
root@Ziel# mkfifo /tmp/fifo
Nun leiten wir den UDP Traffic per nc von Port 8080 um :
root@Ziel# nc -l -p 8080 < /tmp/fifo | nc -u ip.des.dns.servers 53 > /tmp/fifo
Alles was wir auf Port 8080 lesen, geht über die PIP an den NC Befehl, der es an den DNS Server schickt. Seine Antwort geht über das FIFO File zurück zum „Server nc Befehl“ .
Das Gleiche, nur anders rum, brauchen wir auf dem lokalen Server:
root@local# mkfifo /tmp/fifo root@local# nc -l -u -p 53 < /tmp/fifo | nc localhost 8080 > /tmp/fifo
Auf unserem lokalen Server binden wir uns an den Port 53 und schicken alles, was in dem FIFO File steht an den, der sich auf Port 53 verbunden hat, also z.b. der Befehl dig . Alles was von dig an den Port 53 gesendet wird, geht über die PIPE zum zweiten nc und der leitet das an den Startpunkt unseres Tunnels.
Entweder, man trägt jetzt 127.0.0.1 in die /etc/resolv.conf ein :
nameserver 127.0.0.1
oder man fragt mit dig 127.0.0.1 direkt ab:
dig @127.0.0.1 marius.bloggt-in-braunschweig.de
Das wars schon.