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.

 

 

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.

Warum nur #youtube #unge ?

Vergeßt es, die Tweets gibt es nicht und das ist auch gut so. Heute gibt es mal keine Lebenshilfe, sondern eine Frage, die Ihr gern kommentieren dürft:

Wieso wird man von Nachrichten über Leute genervt, die andere Leute auf Youtube beim Spielen kommentieren oder gar Ihre eigenen Gamesessions kommentieren?

Wie man in den letzten 3 Tagen nicht verhindern konnte, wird man in diversen IT Newsseiten über die Probleme von Simon Unge genervt. Wie Golem in seinem Bericht geschrieben hat, ist das tatsächlich keine Meldung wert und trotzdem wird faktisch überall gehypt.

Ist jetzt endlich rausgekommen, daß es wiedermal nur um Kohle für die Jungs geht ? Das alleine kann es doch nicht sein, also wieso ist das eine Meldung wert, wenn jemand sein IMHO überflüssiges Videomaterial nicht mehr unters Volk bringen will ?

So ganz allein kann ich mit meiner Meinung nicht sein, denn letzte Woche ist Southpark sehr schön über diesen Youtube Schwachsinn hergezogen, es war Ihnen sogar eine Doppelfolge wert. Episode #Rehash

Ich habe übrigens nichts gegen Youtube Videos, aber wenn sollte man schon selbst mitspielen, als anderen beim Spielen zu zusehen.

Die Kommentare sind ab jetzt freigeschaltet…

TAR erfolgreich per SSH tunneln

Jeder Admin kennt das Problem, man muß irgendwann mal in seinem Leben ein System backupen, ohne das man Platz dafür hat oder die Platte ist nur noch lesbar.

Natürlich kommt einem dabei sofort die Idee, daß per SSH auf einen anderen Server zu übertragen. TAR muß aber irgendwo die Daten ausgeben, das geht nur in die PIPE. Mit den Daten kann man aber mit SSH als Ziel nicht viel anfangen, außer man schafft es den Datenstrom in die richtigen Bahnen zu lenken.

Genau das geht mit dieser Anweisung:

tar czv / | ssh user@backup.server.de "cat - > backup.tgz"

Cat leitet am Zielserver die Daten von Stdin in das File backup.tgz um.

Systemd: wenn set-default nicht funktioniert

Fedora empfiehlt auf den eigenen Seiten, daß man das Default.Target mit dem Befehl:

systemctl set-default graphical.target

setzen könnte. Das  graphical.target ist dabei die Desktopoberfläche. Mit dem multi-user.target bekommt man nur die auf Server übliche Textkonsole zusehen.

Leider stimmt das nicht für jede Fedoraversion und z.b. bei Fedora 19 muß man selbst Hand anlegen:

ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Man kann auch den direkten runlevel als Ziel angeben:

z.b.  /etc/systemd/system/default.target -> /lib/systemd/system/runlevel3.target

Im laufenden Betrieb kann man als Root mithilfe des isolate Befehls zwischen den Runleveln umschalten. Das ist zu Debugzwecken ganz praktisch.

systemctl isolate multi-user.target

LOLing

Ich hatte eigentlich gedacht, daß die Zeiten der Babelfische vorbei wären,
aber der dreiste Phisingversuch, der heute morgen in unserer Emailfalle aufschlug,
ist einfach zu schön 🙂

Und weil das so schön war, hier die ungekürzte Originalfassung. Die Highlites habe mal markiert, sehr schön auch die GoogleMail Adresse der UBS Bank 🙂

Ein dickes LOL an den unbekannten Verfasser !

Update:

Received: from 41.206.1.8 ([41.206.1.8])
        (SquirrelMail authenticated user bonsain)
        by 166.78.148.43 with HTTP;
        Thu, 4 Dec 2014 01:42:18 -0000

Wie sich rausgestellt hat, ist das tatsächlich aus Nigeria gekommen:

inetnum:        41.206.1.0 - 41.206.1.255
netname:        MTNNG-0007-MTNCORP-LAGREGION-WIMAX
descr:          WIMAX CLIENTS DYNAMIC POOL
country:        NG
admin-c:        MA56-AFRINIC
tech-c:         MA56-AFRINIC
status:         ASSIGNED PA
mnt-by:         MTNNIGERA1-MNT
source:         AFRINIC # Filtered
parent:         41.206.0.0 - 41.206.31.255

person:         Muideen Aruna
address:        MTN Nigeria

Die Erfinder werden auch immer schlechter 🙂

Von Dr. William Parrett
Global Equity Research
London-Regionalbüro
UBS Investment Bank London.

1 flossen begraben Avenue, London EC2M 2PP


Mein lieber Freund,


Mein Name ist Dr. William Parrett aus Harlesden North West London. Ich
arbeite mit UBS Investment Bank Vereinigtes

Königreich. Ich wollen Sie kurz Diskus über ein Angebot, das einen
immensen Vorteil für uns beide werden. In meiner

Abteilung wird die Leiter Aktienanalyse, entdeckte ich eine verlassene
Summe von £ 19,7 Millionen große britische

Pfund Sterling (Nineteen Millionen sieben hundert tausend britische
Pfunde) in einem Konto, das gehört zu einem der

unseren ausländischen Kunden/Stephen Richard, der vor vielen Jahren bei
einem Flugzeugabsturz mit seiner Frau und

einzige Tochter starb.

Die Wahl der Kontaktaufnahme mit Ihnen ist aus der geographischen Natur wo
Sie leben, vor allem wegen zu erregt die

Empfindlichkeit dieser Transaktion, die Bank gewartet hat für keine der
Verwandten zu kommen-Up für die Behauptung

aber Niemand hat getan, dass ich persönlich bei der Suche nach den
verwandten seit 3 Jahren erfolglos geblieben.

Ich Suche Ihre Zustimmung an Sie als die nächsten Angehörigen zu
präsentieren / Will Beneficiary an den

verstorbenen, so dass die Erlöse aus Dieses Konto bei £ 19,7 Millionen
Pfund geschätzt wird als die nächsten

Angehörigen zu Ihrem nominierten Bank-Konto übertragen werden Verstorbene
Stephen Richard.

Dies wird ausgezahlt oder geteilt in diese Prozentsätze, 60 % für mich und
40 % für Sie. Alles was ich brauche ist

zum Hochladen Ihrer Details in unserer Bank-Datenbanksystem wie die
nächsten Angehörigen zu spät Stephen Richard.

Was ich im Grunde jetzt benötigen, ist Ihre ehrliche Zusammenarbeit,
Vertraulichkeit und Vertrauen zu mir und Sie

können den Erfolg in dieser Transaktion sehen. Bitte haben Sie um diese
Transaktion 100 % Geheimnis wegen meine

Position hier in meiner Bank und die Gesellschaft zu halten.

Ich habe Ihr Ansprechpartner aus Ihrem Auslandsgeschäft
Länderinformationen; Ich beschloss, Sie hofft, dass

kontaktieren Sie Diese interessant finden. Bitte wird auf Ihrer
Bestätigung dieser Nachricht und Ihr Interesse ich

Sie liefern mit weiteren Informationen.

Geben Sie mir Ihre volle Details unten, so dass mir Ihre Daten in unsere
Bank-Datenbank entsprechend hochladen

können in der Bank-Netzwerk-System, das Sie den benannten Angehörigen /
Empfänger dieses Fonds werden und da führt

Sie auf wie man offene Kommunikation mit der Bank und stellen Ihnen die
Anträge auf Weiterleitung des Fonds. Als

insider und meine langjährige Erfahrung im Bankensektor habe Struktur alle
Modalität sehen den Erfolg dieser

Transaktion alle ich wünsche von euch ist Sie Zusammenarbeit. Ich will
dich nicht zum Verrat nachdem die Mittel

wurden Kontaktieren Sie auf Ihr Bankkonto überwiesen werden, wenn Sie
nicht geradlinig und würdig Vertrauen bitte

nicht mich.

1. vollständiger Name:
2. Ihr Wohnsitz-Adresse:
3. Ihre direkte Handynummer:
4. Ihre Fax-Nummer:
5. Geschlecht:
6. Alter:

Geben Sie mir bitte mit Ihren vollständigen Angaben oben, damit wir
fortfahren und den Fonds-Transfer zu Ihrer

nominierten Bank bekommen können Konto.

Bitte kontaktieren Sie mich auf meine private e-Mail:
dr.williamparrettt@gmail.com

Grüße,
Von Dr. William Parrett
Global Equity Research
London-Regionalbüro
UBS Investment Bank London.
www.UBS.com