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.
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