Manpages und die Hilfe

Manpages, die erste Anlaufstelle für Informationen zu allem, was auf einem Linuxsystem an Programmen,Strukturen und weiteren Infos zur Verfügung steht, kennt man eigentlich nur aus der Konsole. Dort werden sie mit dem Befehl „man“ abgerufen.“Man“ ist die Abkürzung für Manual, also Handbuch. Es ist sehr praktisch direkt in der Konsole nach Informationen zu suchen, weil man dazu nicht erst von Rechner weg, seinen Stapel mit Büchern durchsuchen muß und vor allem, weil die „manpages“ aka. Handbuchseiten, jederzeit auf dem aktuellen Stand sind.

Beispiel: „man ls

LS(1) Dienstprogramme für Benutzer LS(1)

BEZEICHNUNG
 ls - Verzeichnisinhalte auflisten

ÜBERSICHT
 ls [OPTION]… [DATEI]…

BESCHREIBUNG
 Auflistung von Informationen über die DATEIen (Standardvorgabe ist das aktuelle Verzeichnis). Die Einträge
 werden alphabetisch sortiert, falls weder -cftuvSUX noch --sort angegeben wurden.

Die obligatorischen Argumente für Optionen sind für deren Kurz- und Langform gleich.

-a, --all
 Einträge nicht ignorieren, die mit ».« beginnen
... usw. ...

Die Ausgabe des „man“ Befehls erfolgt bei direkt in die Konsole, wo man auch nach Begriffen suchen kann. Das es auch anders geht, zeigt folgendes Beispiel. Auf der Suche nach einem Problem vom Systemd kam folgende Ausgabe zustande:

Bild wie Manpages unter Linux verlinkt sind.

Manpagelink in der Konsole

Als weiterführende Dokumentation ist ein Manpage-Link angegeben, den man u.a. über das der Konsole anhaftende Contextmenü mit „Link öffnen“ lesen kann. Statt direkt in der Konsole die Informationen anzuzeigen, öffnet sich die GNOME-Hilfe App:

Manpage in der Hilfeapp

Manpage in der Hilfeapp

Die dort dargestellten Links sind wie in einer Webseite klickbar, aber leider existiert das Ziel nicht immer :

die Verlinkung in der Manpages-Datenbank ist nicht immer vollständig.

Was nicht geht

Trotzdem ist das Handbuch die erste Anlaufstelle, wenn man etwas wissen will. Es lohnt sich eigentlich immer da reinzuschauen. Es kann auch vorkommen, daß die Informationen eine wahre Flutwelle annehmen:

Beispiel: „man systemd.directives“

COLOPHON
 This index contains 2135 entries in 13 sections, referring to 228 individual manual pages.

Ja, das scrollen dauert eine Weile 😉

Nicht immer gibt es eine deutsche Übersetzung für die Informationen, ein bisschen Englisch aus der Schule kann also nicht schaden 🙂  Was es aber scheinbar nicht gibt, sind Witzbolde die Manpages schreiben. Einer kleinen Recherche nach, gibt es keine Hinweise auf lustige oder kuriose Handbuchseiten. Irgendwie schade . Dicht dran, das Ubuntu Handbuch .

Spaß in der Konsole geht aber trotzdem :

cowsay, ein Programm um lustige Hinweise in der Konsole auszugeben

Was die Kuh sagt…

Das kleine Programm heißt „cowsay“ und es gibt es auch für den Desktop. Ob und wo die Kuh zu Dir spricht, bestimmtst aber nicht Du 😉

Das Anastasia Botnetz

Spams gibt ja immer und meisten steckt heute ein Botnetz dahinter. Das Netzwerk, das unsere Mailserver derzeit am meisten nervt, ist das von mir so genannte Anastasia Botnetz.

Es ist allerdings leicht am Absender zu identifizieren, der immer das Wort Anastasia am Anfang hat:

2017-08-02 01:44:59 H=(ip-38-239.tricom.net) [186.150.38.239] rejected MAIL <Anastasiabj@tricom.net>: identified as Anatasia Botnet
2017-08-02 01:45:43 H=(ocit-41.189.55.239.aviso.ci) [41.207.201.171] rejected MAIL <Anastasiafab@aviso.ci>: identified as Anatasia Botnet
2017-08-02 01:45:46 H=([115.164.85.255]) [115.164.85.255] rejected MAIL <Anastasiabcbr@puretechnutrition.com>: identified as Anatasia Botnet
2017-08-02 01:47:05 H=([51.36.222.115]) [51.36.222.115] rejected MAIL <Anastasiacoe@incco.com.gt>: identified as Anatasia Botnet
2017-08-02 01:47:27 H=(131-108-125-254.infortek.net.br) [131.108.125.254] rejected MAIL <Anastasiarcae@infortek.net.br>: identified as Anatasia Botnet
2017-08-02 01:47:32 H=160.red-81-39-134.dynamicip.rima-tde.net [81.39.134.160] rejected MAIL <Anastasiaxte@woburnapartments.co.nz>: identified as Anatasia Botnet
2017-08-02 01:47:54 H=([161.132.100.51]) [161.132.100.51] rejected MAIL <Anastasiamm@rhinohandyman.com>: identified as Anatasia Botnet
2017-08-02 01:48:56 H=([186.235.188.234]) [186.235.188.234] rejected MAIL <Anastasiacljgf@pedicur.ru>: identified as Anatasia Botnet
2017-08-02 01:49:06 H=([202.90.136.58]) [202.90.136.58] rejected MAIL <Anastasiaxw@directiva.com.br>: identified as Anatasia Botnet
2017-08-02 01:49:44 H=([175.101.251.27]) [175.101.251.27] rejected MAIL <Anastasiadihu@it-is-it.com>: identified as Anatasia Botnet
2017-08-02 01:50:25 H=(host-177-232-80-119.static.metrored.net.mx) [177.232.80.119] rejected MAIL <Anastasiaazy@metrored.net.mx>: identified as Anatasia Botnet
2017-08-02 01:50:31 H=([27.123.171.127]) [27.123.171.127] rejected MAIL <Anastasiabviyu@hrcbmdfw.org>: identified as Anatasia Botnet
2017-08-02 01:50:32 H=85.233.11.37.dynamic.jazztel.es [37.11.233.85] rejected MAIL <Anastasiayurg@jazztel.es>: identified as Anatasia Botnet
2017-08-02 01:51:18 H=(static.vnpt.vn) [113.161.8.21] rejected MAIL <Anastasiafir@static.vnpt.vn>: identified as Anatasia Botnet
2017-08-02 01:52:20 H=fixed-187-189-92-55.totalplay.net [187.189.92.55] rejected MAIL <Anastasiahw@fixed-187-189-92-55.totalplay.net>: identified as Anatasia Botnet
2017-08-02 01:52:26 H=(static.vnpt.vn) [14.183.242.229] rejected MAIL <Anastasiaud@static.vnpt.vn>: identified as Anatasia Botnet
2017-08-02 01:52:34 H=(static-ip-cr18152012787.cable.net.co) [181.52.127.87] rejected MAIL <Anastasiaxcs@cable.net.co>: identified as Anatasia Botnet
2017-08-02 01:53:09 H=(host-177-232-87-110.static.metrored.net.mx) [177.232.87.110] rejected MAIL <Anastasiarclg@metrored.net.mx>: identified as Anatasia Botnet
2017-08-02 01:53:20 H=red.connectbd.com [202.79.16.10] rejected MAIL <Anastasiavpuup@red.connectbd.com>: identified as Anatasia Botnet
2017-08-02 01:53:42 H=([161.132.100.51]) [161.132.100.51] rejected MAIL <Anastasiaualik@grouptower.com>: identified as Anatasia Botnet
2017-08-02 01:54:30 H=([123.23.241.122]) [123.23.241.122] rejected MAIL <Anastasianwz@ubsystems.com>: identified as Anatasia Botnet
2017-08-02 01:55:05 H=(187.253.122.253.cable.dyn.cableonline.com.mx) [187.253.122.253] rejected MAIL <Anastasiadabgp@cableonline.com.mx>: identified as Anatasia Botnet
2017-08-02 01:57:59 H=(static.vdc.com.vn) [113.190.40.226] rejected MAIL <Anastasiailk@vdc.com.vn>: identified as Anatasia Botnet
2017-08-02 01:58:21 H=([191.99.126.26]) [191.99.126.26] rejected MAIL <Anastasiafsg@zarlock.com>: identified as Anatasia Botnet
2017-08-02 01:59:32 H=([41.216.32.42]) [41.216.32.42] rejected MAIL <Anastasiaecous@vertexconsultancy.co.in>: identified as Anatasia Botnet
2017-08-02 01:59:42 H=(181-174-59-224.telebucaramanga.net.co) [181.174.59.224] rejected MAIL <Anastasiajinv@simtecno.com.br>: identified as Anatasia Botnet
2017-08-02 02:00:19 H=([31.145.75.194]) [31.145.75.194] rejected MAIL <Anastasiaonl@juste.com.tw>: identified as Anatasia Botnet

Das dies nur ein kleiner Ausschnitt von nur einer einzigen Maschine ist, deutet das Ausmaß des Botnetzes an.

Für alle die einen EXIM Mailserver betreiben, hier die Regel um die Spams gezielt auszufiltern:

acl_check_mail:

# Hosts are required to say HELO (or EHLO) before sending mail.
...
drop message = identified as Anastasia Botnet
     condition = ${if match{$sender_address}{\N^Anastasia.*\N}{1}{0}}

Natürlich ist die Regel sehr grob, auch eine echte Anastasia.Kulikovwa@mail.ru würde ausgefiltert werden, aber im Gegensatz zu zum Botnetz, könnte die Dame zum Telefon greifen und einfach anrufen, daß die Mails nicht ankommen. Davon abgesehen sind 0.01% falsche Treffer eine echt gute Quote, mit der ich persönlich leben kann 🙂

Selbstverständlich könnte man die Regeln entsprechend verfeinern:

 condition = ${if match{$sender_address}{\N^Anastasia.{2,5}@.*\N}{1}{0}}

Diese Anpassung entspricht dem Muster, daß nach Anastasia noch bis zu 5 zufällige Zeichen kommen vor dem @.

Da es ähnliche Regelsätze für andere Mailserver gibt, könnt Ihr da natürlich jetzt Eure eigenen Anpassungen machen.

Jitsi kann keine SIP Anrufe mehr annehmen

Wer kennt das nicht, in der Firma läuft es ruhig. Kunden melden sich nur per Email, aber das Telefon schweigt seit Tagen. Das alljährliche Sommerloch, wegen dessen wir alle in den Urlaub fahren …, oder ?

Paranoide Menschen würden jetzt per Telefon sich selbst anrufen und entsetzt feststellen, daß die Telefone nicht klingeln, weil .. ja .. scheisse, wieso klingeln die nicht ????!!!!!!

Ab jetzt herrscht Panik in der IT-Abteilung:  Was ist passiert ?

Ist der SIP Provider pleite gegangen ?
Haben Mäuse die Glasfaserkabel geknackt ?
Oder liegt es etwa an uns ?
Gab es ein Update der Telefonsoftware ?
Gab es überhaupt irgend ein Update ?

Also prüfen wir zunächst mal, ob alle betroffen sind und stellen fest : Alle Jitsi SIP Softphones sind quasi tod, aber normale Telefone für SIP nicht. Jitsi kann zwar noch raustelefonieren, sonst wäre das ja auch eher aufgefallen, aber ankommende Anrufe gehen nicht mehr. Komischerweise geht Jitsi auf den Handies noch.

Das schliesst per se ein DSL Router und Netzwerkproblem aus, außer die lokale Firewall wäre im Spiel:

TEST:
systemctl stop firewalld
Anruf => kein Klingeln
systemctl start firewalld

Das wars nicht. Hatte Jitsi ein Update ? Seit Monaten nicht mehr.  Fällt somit als Ursache auch weg.  Hmm…

2 Tage und eine systematische Suche später ..

Das Problem, das  Jitsi keine SIP Calls mehr annehmen konnte, ist behoben worden.

Es lag NICHT an Jitsi, Sipgate, den Mäusen, dem DSL Router, den Kabeln, der Firewall sondern an :  JAVA.

Die Ursache

Fedora hat vor zwei Tagen ein neues openjdk 1.8.0.141_b16 eingespielt, das hat Jitsi und vermutlich andere Apps beeinträchtigt. Das Update war als Security Update markiert, es ist also potentiell gefährlich, die App weiter zu betreiben. Ist es in dem Fall nicht, da das Update pauschal als Security Update eingestuft wurde, weil 4 Security Tests beim Build nicht liefen. Dazu noch eine Menge normaler Updates, von denen vermutlich eins die Ursache ist.

Der Workaround

Der schnellste Workaround ist natürlich, Java zu downgraden auf die letzte funktionierende Version:

java-1.8.0-openjdk-1.8.0.131-5.b12.fc25.x86_64.rpm
java-1.8.0-openjdk-devel-1.8.0.131-5.b12.fc25.x86_64.rpm
java-1.8.0-openjdk-headless-1.8.0.131-5.b12.fc25.x86_64.rpm
java-1.8.0-openjdk-javadoc-1.8.0.131-5.b12.fc25.noarch.rpm

Wenn man das jetzt mit „dnf downgrade java-*“ macht, landet man bei einer uralten Version, was Securitymäßig keine gute Idee ist. Also lädt man die Pakete hier runter:

https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/noarch/java-1.8.0-openjdk-javadoc-1.8.0.131-5.b12.fc25.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/x86_64/java-1.8.0-openjdk-headless-1.8.0.131-5.b12.fc25.x86_64.rpm
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/x86_64/java-1.8.0-openjdk-devel-1.8.0.131-5.b12.fc25.x86_64.rpm
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/x86_64/java-1.8.0-openjdk-1.8.0.131-5.b12.fc25.x86_64.rpm

Aber natürlich nur passenderweise für Fedora 25, andere Versionen bitte selbst bei koji suchen.

Nicht vergessen: /etc/dnf/dnf.conf editieren und java auf die Sperrliste setzen, sonst kommt das Update gleich wieder rein.

Warum ist jetzt der Downgrade auf b12 akzeptable und der auf die Fedora Downgrade Version nicht ?

Weil Jitsi nur Verbindungen zu bestimmten, vertrauenswürdigen Servern aufnimmt. Es ist daher kaum möglich etwaige SecBugs in Java über diesen Channel auszunutzen, zumal in der ML von OpenJAVA keine Hinweise zu Securitybugs enthalten waren. 4 Tests beim Build failten, das kann alles sein. in nächster Zeit wird es sicher Updates von Jitsi geben, damit es auch mit der aktuellen Java Version läuft, denn es steht zu befürchten, daß Openjdk, den „Bug“ nicht fixt.