Zahn der Zeit nagt am Linuxsupport von Brother

Das bislang vorbildliche Verhalten von Brother im Bezug auf Linux zeigt leider erste Schwachstellen. Kann man die Druckerfunktion über Netz noch ohne Brothertreiber realisieren, muß man für die Scannerfunktion der MFC Serien auf BRScan von Brother zurückgreifen.

Linuxsupport von Brother schwächelt zusehens

Von dem Umstand mal abgesehen, daß von Brother genutzte SAP wohl was gegen Kontaktformularanfragen hat 🙁 , sind die Webseiten von Brother was Handbücher und Treiber betrifft eigentlich ganz brauchbar. Leider kann man das von der Scansoftware nicht mehr sagen.

Die auf dem Stand 2017 kompilierte Scansoftware Brscan braucht dringend ein Update, da die verwendete libnsl u.a. von Fedora nur noch als Legacy angeboten wird und nicht mehr zum festen Systemumfang zählt. Das führt dann leider dazu, daß auch wenn man Brscan vorschriftsmäßig über das von Brother gelieferte Softwarepaket für redhatbasierte Systeme installiert, Xsane oder SimpleScan  die Scanner im Netzwerk (und vermutlich lokal auch) nicht finden.

Schuld daran ist ein „Ich hab Dir doch gesagt, ich brauche diese nsl Library“ Fehler in Brscan. Leider eskaliert das Programm den Fehler nicht an die Oberfläche, so daß der Otto-Normal-Tux keine Chance hat, da den Fehler zu finden. Dieser wird erst sichtbar, wenn ein Admin die passenden Programme von Brother direkt in der Konsole startet. Da diese Programme nicht für den Desktop geschrieben wurden, tauchen sie natürlich auch nicht im Desktop-Menü auf. Es besteht daher keine Chance, daß ein Endanwender das je findet.

Fix für Fedora u.ä.

Jetzt kann man das noch unter Fedora, und vermutlich allen anderen RH Systemen, mit dem folgenden Befehl als Rootuser leicht beheben:

dnf install -y libnsl

Es spielt dabei eine Rolle, ob Ihr Brscan vorher oder danach installiert, das Ergebnis ist das Gleiche.

Wichtig für Netzwerkdrucker ist nur, daß Ihr bei der Frage des Installationsscripts, welches auch als Root ausgeführt werden muß, die korrekte IP des Druckers/Scanners angebt. Ein Problem könnte sich dabei ergeben, wenn Euer DHCP Server im lokalen Netz dem Scanner IPs zufällig zuordnet, statt diese dauerhaft zu vergeben.

Sollte das der Fall sein, liegt eine Config Datei im /usr-Bereich der Brscan-Software, welche die IP Angabe enthält. Die müßte man dann anpassen.

CoronaChroniken: Sieht gut aus für Kinder

Liebe Kasernierte,

Spanien hat seine Coronatoten nach unter korrigieren können, da einige Tote doppelt gezählt wurden und in Anderen kein Virus nachgewiesen werden konnte. Da passen die aktuellen Grafiken gut ins Bild.

CoronaChroniken: Sieht gut aus für Kinder

Vor einigen Tagen kursierte im Netz die reißerische Schlagzeile „Todesfallen für Kinder„. Schon damals konnte man das leicht als Fakenews entlarven. Heute habe ich da eine schöne Grafik für Euch:

Sterbekurve der Kinder in Europa, mit dem Zeiger unter normalem Niveau \o/

(c) EuroMOMO.eu

Also wenn diese europaweite Untersterblichkeit bei schulpflichtigen Kinder die Eltern nicht überzeugt, dann wird es kein anderes Argument geben: Der blaue Bereich ist das Normalniveau. In den letzten drei Wochen starben unterdurchschnittlich wenige Schulkinder. Hoffen wir, daß sich der Trend auch nach Corona fortsetzt.

Aus anderen Bereichen haben wir auch gute Nachrichten zu erwarten:

(C) marius.bloggt-in-braunschweig.de 2020

Die Kurve flacht ab und ab und ist bald nicht mehr in diesem Maßstab sichtbar. Da fragt man sich, was da in Berlin eigentlich gemessen wird.

Kleine Anekdote zum R-Wert, wenn man den konsequent bis zu Ende durchrechnet, wird der immer mehr springen, weil die Zahlen immer kleiner werden, nur um dann am Ende auf 1 zugehen und dann direkt auf 0 😀 Das wäre dann das Ende der Neuinfektionen und auch das Ende von dem Virusausbruch in diesem Blog.

Die Maskenpflicht – politischer Aktionismus

Kommen wir zu den Schwankungen seit dem Tag der Maskenpflicht: 24.4.2020

(C) marius.bloggt-in-braunschweig.de 2020

Nach dem 24.4. kann man eine Abnahme der Abnahme der Infektionszahlen sehen ( Verflachung der Neuinfektionskurve). Zu erwarten wäre aber eine steilere Abnahme gewesen, wenn die Masken einen Effekt gehabt hätten. Hatten Sie aber nicht. Wäre man gemein, würde man behaupten, daß die Masken es sogar noch schlimmer gemacht haben, haben sie aber auch nicht, denn sie hatten gar keinen messbaren Effekt.

Im Detail nochmal die Abweichungen in Prozent

Deutlicher wird das, wenn man sich das in Prozent ansieht. Da ist nämlich der absolute Wert egal (orangene Kurve):

Prozentual gesehen, war die Abnahme vor dem 24.4. auch schon so „stark“ und Schwankungen unterlegen. Ein Effekt würde sich auch erst nach Stichtag + Inkubationszeit für Corona zeigen, aber 4 Wochen, wie die Grafik oben nahe legen würde, ist natürlich Blödsinn. Die typische Inkubationszeit ist 5-14 Tage, im Mittel vermutlich um die 7-8 Tage, und in diesem Zeitraum ist wahrlich kein Rückgang zu sehen, außer dem Rückgang vom Rückgang 😉

Es bleibt dabei: Die Maskenpflicht ist politischer Aktionismus und sollte sofort beendet werden!

WordPress: die vergessene mShot DOS Attacke

Alle guten Geschichten beginnen mit „Es war einmal..“ so auch meine heutige Geschichte eines längst vergessenen Dienstes, der zu einem DOS Angriffs mutiert ist. Wer WP betreibt, wird in diesem Artikel einige Denkeanstöße für seine eigene Instanz bekommen.

WordPress: die vergessene mShot DOS Attacke

Es war einmal ein Dienst der Firma AUTOMATTIC, Inc. die Ihres Zeichens nach WordPress.com betreibt. Wir schreiben die Prä-Neulandzeit. Der Dienst konnte Screenshots von Webseiten erzeugen und irgendwo einbasteln. Im Jahre der Merkel 2012 postete jemand eine Anfrage im WordPressforum, wo denn all die komischen Anfragen in seinem Blog herkommen würden, die „WordPress.com mShots“ im Useragent stehen haben.

Es wurde ihm folgendes mitgeteilt:

mShots was a third party extra feature that has been removed > mShots have been deactivated on all WordPress.com blogs, says a Happiness Engineer:
https://en.forums.wordpress.com/topic/does-using-zemanta-disable-mshots?replies=2#post-517481

Damit Ihr wisst um was es geht, hier ein exemplarischer Auszug aus einem Logfiles eines Kundenservers heute morgen, womit wir uns nebenbei +8 Jahre nach „Einstellung des Dienstes“ befinden:

192.0.100.186 – – [20/May/2020:08:51:12 +0200] „GET /trainer/ HTTP/1.1″ 301 20 „-“ „Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/69.0.3494.0 Safari/537.36 WordPress.com mShots
LOCALHOST – – [20/May/2020:08:51:21 +0200] „POST /trainer/wp-cron.php?doing_wp_cron=1589957481.2505230903625488281250 HTTP/1.1″ 200 20 „http://eine.wordpress.seite/trainer/wp-cron.php?doing_wp_cron=1589957481.2505230903625488281250″ „WordPress/5.3.3; https://eine.wordpress.seite/trainer
192.0.100.186 – – [20/May/2020:08:51:22 +0200] „GET /trainer/ HTTP/2.0″ 200 – „-“ „Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/69.0.3494.0 Safari/537.36 WordPress.com mShots

Damit der Spannungsbogen Euch nicht umbringt, hier eine erste Auflösung: der Dienst wurde nicht abgeschaltet 😉

Was sehen wir oben?

Wir haben den Zugriff vom WP Servercluster 192.0.100.186, dann einen Cronjob der von der WP Installation selbst stammt, und danach wieder ein Zugriff vom WP Cluster. Damit haben wir 3x PHP im Spiel, pro Aufruf.

Der Angriff aus dem Nichts

Jetzt gab es um 8:51:xx nicht nur Zugriffe auf diese eine WordPressinstanz, sondern über 100 haben gleichzeitig diese mShots Anfrage bekommen, mit dem Resultat das (am Ende) gleichzeitig hunderte PHP Prozesse liefen.

Jeder der sich mit Hosting auskennt, weiß, daß hunderte von PHP Prozessen jede Menge an Speicher, CPU Last und IO erzeugen, besonders wenn PHP nicht als Modul, sondern im sicheren CGI-Modus läuft. Jetzt wäre auch das nicht das Problem, wenn auf dem nur einige dieser WP Instanzen wären, waren sie aber nicht. Ein einziger Server hat diese Wucht abbekommen und der hatte auch nur 4 Kerne zur Verfügung.

Zufälle gibts, die gibt es gar nicht.

Um dem Ganzen oben noch die Krone aufzusetzen, hatte ein Mitarbeiter der für die WP Instanzen zuständigem Werbeagentur, kurz vorher ein Backup einer Präsenz gestartet. Zu den hunderten von PHP Prozessen lief also auch noch ein TAR/GZ Backup eines nicht kleinen Webdienstes mit 100% Leistung auf einem der vier Kerne.

Jetzt könnte man glauben, daß wäre ja schon Zufall genug, aber da lege ich jetzt noch einen drauf 🙂 Ich war nämlich heute morgen auch zufällig auf dem Server und wollte einer Meldung von letzter Nacht nachgehen, als ich aus Routine, aber wiederum zufällig, in TOP geschaut hatte, ob alles rund läuft. Dabei habe ich dann die ganzen PHP Prozesse im Aufbau eines Totalausfalls bemerkt und konnte gerade noch rechtzeitig „killall php-cgi“ eingeben, bevor es zum Kaskadenversagen durch CPU/IO/SWAP kam. Die Load war bereits auf dem Weg gen 75 😉

Die Suche nach der Ursache

Gefahr gebannt, aber was konnte das ausgelöst haben? So einen ähnlichen Vorfall hatten wir vor einigen Jahren auch mal, als ein Möchtegern-Hacker parallel allen WP-Instanzen ein paar unsinnige Anfragen geschickt hatte und das WP diese nicht beantwortbare Anfrage auch fleißig allen WP Plugins anbot, nur um dann doch 404 Seiten auszugeben, die wiederum im WP gelandet sind ( fast wärs eine Endloss-404-Schleife geworden ). Weil auch die 404 Seiten wiederum durch PHP liefen, hatte sich die Load auch unfreiwillig verdoppelt. Das haben wir damals dann geändert, so das 404 jetzt nur noch statische Webseiten sind, was die Performance des Servers stark verbessert hat.

Kein Hacker…

Umso mehr hatte mich dann gewundert, daß es wieder zu so einer DOSartigen Situation kam. Also schaute ich in die Logs und wurde schnell mit einer Reihe von IPs aus dem gleichen Block belohnt: Denen von WordPress.com.

192.0.100.186 – – [20/May/2020:08:51:12 +0200] „GET /trainer/ HTTP/1.1″ 301 20 „-“ „Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/69.0.3494.0 Safari/537.36 WordPress.com mShots

Da dort merkwürdigerweise immer mShots stand habe ich dann Tante Google gefragt, aber die meinte ja, siehe oben, daß es das gar nicht mehr geben würde. Also habe ich vergleichende Forensik betrieben und danach auf anderen bekannten WP Instanzen in unserem Cluster gesucht. Fündig wurde ich aber nicht.

„Wie das gibt es doch nicht..“

Das Gespräch mit dem Kunden, der sein Server da gerade gedost worden war, war dann nach einer Weile des Rätselns doch von Erfolg gekrönt. Im Ausschlussverfahren haben wir dann ein Plugin identifiziert, daß dafür indirekt verantwortlich war: der Elementor!

Elementor ist ein Plugin-System mit dem man „schneller“ (haha) komplizierte Layouts in WordPress umsetzen kann, als wenn man an den Themes rumspielt. Es ist also eine Art Homepagebaukasten innerhalb von WordPress. Jetzt sind meine Ansprüche an eine Webseite nicht so hoch, daß ich da Elementor einsetzen würde, wenn ich schon WP habe, aber das sehen Werbeagenturen naturgemäß anders 😉

Die Auflösung

Jetzt hatten wir einen Verdacht, also gruben wir noch etwas tiefer und schauten uns die Zeiten an, als den Server die mShots in der Vergangenheit getroffen hatten. Dabei stellte sich ein unregelmäßiges Muster ein, anhand dessen der Kunden dann eingrenzen konnte, daß wann immer er selbst in der Elementor-Zentralinstanz bei Elementor eingeloggt war, so ein DOS Angriff statt gefunden hatte. Das hat er selbst nicht gemerkt, weil er ja anderswo beschäftigt gewesen war. Meistens gab es da auch keine laufenden Backupprozesse, so das die mShot Anfragen bislang unbemerkt geblieben waren. Elementor fragt nämlich beim Login WordPress.com:mShots von allen verbundenen Webseiten (>100 Stück) einen aktuellen Screenshot zu besorgen.

Fazit: Der Kunde hatte sich mit dem Login bei Elementor,  und dem laufenden Backup unwissentlich selbst gedost. Das erlebt man auch nicht alle Tage 🙂

Die Empfehlung

Jetzt meine Empfehlung an Euch:

Auch wenn etwas bei der Anzahl 1, 2 oder 3 zügig reagiert, ist das bei 100+ nicht mehr der Fall.

Wenn Ihr also irgendein Programm baut, geht nicht davon aus, daß es ja nur die paar Testfälle verkraften muß, die Ihr hattet, sondern überlegt immer, was passieren kann, wenn hundert, tausend oder gar Millionen Abfragen involviert sind 🙂

Unser Kunde fragt derzeit bei Elementor an, ob man die Screenshots abschalten kann, das solltet Ihr auch abschalten, wenn Ihr so viele Instanzen auf einem einzigen Server habt. Glücklicherweise kam das Plugin nur bei den knapp über 100 WP Instanzen zum Einsatz, auf dem Server sind aber noch hunderte andere Instanzen untergebracht 😉

Wie wichtig das mit dem Einplanen nur „Millionen“ Anfragen sein kann, würde Euch ein anderer Feuerwehr-Fall zeigen, aber leider reden wir nicht über Kundenfälle, außer wir haben die Erlaubnis dazu, was aber hier der Fall ist.

 

CoronaChroniken: Alles beim Alten

Liebe Kasernierte,

außer einem Ende der Maskenpflicht in Thüringen Anfang Juni, gibt es leider nichts bewegendes zu berichten.

CoronaChroniken: Alles beim Alten

Daher hier nur die Updates der Woche für Euch in Bildern:

Trotz Maskenpflicht will dieser Virus einfach nicht weniger Leute anstecken, wer hätte das von den Null-Effekt-Masken auch anders erwartet. Ich fordere hiermit ein Ende der unsinnigen Community-Maskenpflicht in ganz Deutschland.

Wie die Kurve oben zu interpretieren ist, findet Ihr hier:  CoronaChroniken: Der negative Maskeneffekt

In anderen Nachrichten: „Pathologen finden schwere Lungenschäden in … Toten, die an Lungenentzündung mit/durch Covid-19 gestorben sind“. Was bitte hatten die da sonst erwartet?  Aber man kann ja schon froh sein, daß überhaupt mal wer nachschaut.

CoronaChroniken: Zahlen lügen nicht – Teil 3

Liebe Kasernierte,

heute gab es einen Pressevorfall, der schon an Fakenews grenzt. Es geht um die angebliche Übersterblichkeit in Deutschland. (Alle die wegen IT hier sind, scrollt mal runter zum nächsten Artikel)

CoronaChroniken: Zahlen lügen nicht – die Nicht-Übersterblichkeit

Die Webseite Spektrum.de des Spektrum-Verlags präsentierte jüngst folgende These: „Übersterblichkeit »vergleichsweise gering«“

Der ganze Artikel ist hier erreichbar, aber absichtlich nicht verlinkt, um die nicht auch noch zu belohnen:  https://www.spektrum.de/news/uebersterblichkeit-vergleichsweise-gering/1735480 )

Die Grundaussage ist: Es gab im April eine leichte Übersterblichkeit und im Vergleich z.B. zu Frankreich wäre das ja nur vergleichsweise gering ausgefallen.

Da sich der Artikel auf das Bundesamt für Statistik beruft, sollten wir doch mal deren Meinung im Originalbild und „Ton“ vergleichen:

(C) Bundesamt für Statistik Stand 22.5.2020

Erklärung: die rote Linie ist der Sterbeverlauf 2020, die blau gestrichelte Linie ist der Durchschnitt 2016-2019 und die grauen Linien sind die beiden letzten Jahre.

Was sehen wir da?

Das im Jahr 2018 in Kalenderwoche 10 ( KW10 ) ~7.000 Menschen mehr gestorben sind als in 2020. In 2020 sind sogar unterdurchschnittlich wenige Menschen gestorben, erkennt man daran, daß die Kurve unter dem gepunkteten Verlauf entlang zieht. In ca. KW 15 fällt der Durchschnitt dann stark ab (Ende der Grippewelle 2-3 Wochen vorher) und die Sterberate in Deutschland steigt in 2020 dagegen leicht an.

Da sind dann ca. 900 Menschen in einer ganzen Woche mehr gestorben, als im Vergleich zu letzten großen Grippewelle 2018. (Kleiner Tip: https://www.destatis.de/ besuchen, die Grafik ist interaktiv und zeigt bei jedem Punkt die nativen Zahlen direkt an.) Am Tag sind das 128 Menschen, oder 5,12% mehr als „normal“. Das sind pro Tag 0,00015418% der Bevölkerung (83Mio).

Was schreibt das Bundesamt dazu?

Um die Frage zu beantworten, ob COVID-19 zu einer Übersterblichkeit führt, beobachten wir anhand einer Sonderauswertung die vorläufigen Sterbefallzahlen in Deutschland. Im Moment sind die Zahlen bis zum 19. April 2020 darstellbar. Im März 2020 mit insgesamt mindestens 86 400 Sterbefällen ist bei einer monatsweisen Betrachtung kein auffälliger Anstieg der Sterbefallzahlen im Vergleich zu den Vorjahren erkennbar. Seit der letzten Märzwoche liegen die Zahlen allerdings über dem Durchschnitt der Jahre 2016 bis 2019.

Quelle: https://www.destatis.de

Es liegt leicht über dem Durchschnitt der letzten 3 Jahre, aber noch im Toleranzbereich der Normalkurve (95% Regel). Diese Kurven haben zwar ein relativ ähnlichen Verlauf jedes Jahr, aber das am Tag 2500 Menschen Sterben, ist natürlich auch nur wieder ein Mittelwert/Durchschnitt. Hätte es einen Flugzeugabsturz gegeben, wären an einem Tag eben auch mal deutlich mehr als 2500 gestorben, die Kurve hätte einen Ausreißer gehabt und das wärs dann auch schon gewesen. Es sterben eben doch nicht jeden Tag gleich viele Menschen.

Argumentieren wir mal wie die Gegenseite

„Die Kurve liegt über dem Durchschnitt, also hatten wir eine Übersterblichkeit“ Stimmt technisch natürlich, aber was war eigentlich in KW 8 – KW 13 los? Da lag doch unsere 2020 Kurve deutlich unter dem Durchschnitt oder? War das nicht eine Untersterblichkeit? Ja, war es, wenn man das mit zwei extrem Grippejahren vergleicht sowieso.

Fakt ist, daß aufgrund der erhöhten Vorsicht, der Mahnungen im Fernsehen, der Isolation der Risikogruppen, sprich der Angst des Individuums am „Killervirus“ zu versterben,  weniger Menschen Kontakt hatten und damit natürlich weniger Neuinfektion mit allen anderen Viren da draußen stattgefunden haben, was zu weniger Sterbefällen bei den Risikogruppen geführt hat. Da sich die Natur von uns nicht verarschen lässt, starben diese geschützten Menschen dann halt etwas später, an ihren Resterkrankungen.

Schauen wir uns mal Frankreich an, da kann man das derzeit hervorragend sehen:

(C) Euromomo.eu Woche 19

Es mag uns nicht gefallen, aber der Virus macht seinen Job und rafft gehäuft die Alten und Schwachen dahin. Die sind ab Woche 17 in Frankreich nicht nochmal gestorben, ergo sterben jetzt weniger als „Normal“. Auf Frankreich bezogen sogar „deutlich“ weniger als normal wäre.

Die Auflösung ist ganz einfach:

Der Virus hat die Sterberaten von Menschen in Frankreich, die ohne den Virusinfekt nicht gleich gestorben wären, im Datum nach vorn verlegt. Wir in Deutschland haben das Sterbedatum von Menschen durch die Isolation für viele Menschen nach hinten verlegt. Als Folge werden wir im ganzen Jahr eine leichte Erhöhung des Sterbeschnitts sehen, bis alle die verstorben sind, die bereits an der Viruswelle hätten versterben sollen.

Können wir jetzt bitte endlich zurück zum Alltag übergehen, dieser Virus ist in seiner Auswirkung auf die Gesellschaft nicht anders als andere Viren auch. Er mag ja andere schwere Verläufe hervorrufen als bislang bekannte Viren, aber ansonsten ist an dem Virus nichts besonderes, außer wir machen was besonderes daraus.