Category Archives: Linux

Wine: Die SSD schonen

Posted on by

Ihr wollt mit Wine Spiele spielen, aber Eure SSD nicht unnötig belasten? Da könnte man was machen.

Wine: Die SSD schonen

Wer auf Linux Windows Spiele zocken möchte, der kommt um Wine nicht herum. Egal in welcher Form, es ist immer irgendwie beteiligt. Leider bedeutet das auch, daß Eure SSD alleine durchs Loggen von Debuginfos belastet wird. So eine Runde WOW kann da die Lebenszeit der SSD richtig dezimieren:

# grep fixme /var/log/messages |grep „Jun 28“ | grep -c fixme
711541

meint, am 28.Juni wurden ins Logfile 711.541 Zeilen von Wine geschrieben, fast alle mit dem gleichen, leeren Inhalt:

Jun 28 10:08:21 xxx /usr/libexec/gdm-x-session[2227]: 009e:fixme:rawinput:GetRawInputBuffer data (nil), data_size 0x22f7b0, header_size 24 stub!

Von den 711k Logzeilen macht die obige Zeile 708k aus, ohne Mehrwert für den User. Rechnet Euch mal aus, wieviele das übers Jahr sind!

Wie bekommt man das jetzt weg?

Zum Glück ist das einfach in der .desktop Datei vom jeweiligen Wine-Spiel zu lösen(hier WOW):

Ändert die Exec Zeile von so:

Exec=env WINEPREFIX=“/home/<username>/.wine“ /opt/wine-staging/bin/wine64 C:\\\\windows\\\\command\\\\start.exe /Unix /home/<username>/.wine/dosdevices/c:/Program\\ Files\\ (x86)/World\\ of\\ Warcraft/_retail_/Wow.exe

in so um:

Exec=env WINEPREFIX=“/home/<username>/.wine“ WINEDEBUG=-all /opt/wine-staging/bin/wine64 C:\\\\windows\\\\command\\\\start.exe /Unix /home/<username>/.wine/dosdevices/c:/Program\\ Files\\ (x86)/World\\ of\\ Warcraft/_retail_/Wow.exe

Danach ist Ruhe im Logfile und rsyslogd bzw. journald werden Euch danken, denn:

Jun 28 16:38:51 XXXXXXX rsyslogd[1506]: imjournal: 180769 messages lost due to rate-limiting (20000 allowed within 600 seconds)
Jun 28 16:48:52 XXXXXXX rsyslogd[1506]: imjournal: 180635 messages lost due to rate-limiting (20000 allowed within 600 seconds)
Jun 28 16:58:58 XXXXXXX rsyslogd[1506]: imjournal: 103949 messages lost due to rate-limiting (20000 allowed within 600 seconds)

das, was grep da gezählt hat, ist nur das, was im Logfile auch angekommen ist. In Wirklichkeit sind da tonnenweise Logzeilen weg gefiltert worden und trotz dessen waren es am Ende noch 711k ! Das müssen mehrere Millionen Zeilen gewesen sein, an nur einem einzigen Tag!

„Warum ist das nicht die Defaulteinstellung?“ würde man zurecht fragen, aber solange nur beim Start mal kurz was wichtiges geloggt wird, ok, aber 708.010x das eine 3D-Routine gefixt werde müßte?? Also da könnte man auch mal über sinnvolleres Loggen nachdenken, oder?

Nvidia: 2 Sicherheitslücken im Linux-Treiber

Posted on by

Zwei Sicherheitslücken sind im NVIDIA GFX-Kartentreiber für Linux enthalten, wenn Ihr noch nicht die brandaktuellste Version haben solltet, was schwierig sein dürfte.

Nvidia: 2 Sicherheitslücken im Linux-Treiber

Laut der Bugbeschreibung bei Nvidia, handelt sich dabei bei einer Lücke um einen Bug in der IPC Communication API, was man braucht um Daten zwischen einzelnen Prozessen hin und her zu schicken. Dieser Fehler kann dazu genutzt werden um mit erweiterten Rechten eingeschleusten Code auszuführen.

CVE-IDs
Addressed		Software ProductOperating SystemDriver BranchAffected VersionsUpdated Versions
CVE‑2020‑5963
CVE‑2020‑5967		GeForceLinuxR450All versions prior to 450.51450.51
Quadro, NVSLinuxR450All versions prior to 450.51450.51
R440All versions prior to 440.100440.100
R390All versions prior to 390.138390.138
TeslaLinuxR450All R450 versionsAvailable the week of June 29, 2020
R440All versions prior to 440.95.01440.95.01
R418All versions prior to 418.152.00418.152.00

Die zweite Schwachstelle ist dann schon schwieriger auszunutzen, da eine RACE Condition ist, es kämpfen also zwei Prozesse um eine Ressource. Der Gewinn des RACE würde einen DOS erlauben. Was ein Angreifer auf einem DesktopPC davon haben würde die Grafikkarte zu crashen, naja. Ist trotzdem gut, daß es gefixt wurde.

Für Fedora lautet die Treiberversion für meine GFX-Karte 440.82 und muß daher aktualisiert werden. Da diese aus dem Repo von RPMFusion stammt, dürfte der Verbreitungsgrad und damit der Updatezwang unter Fedora/Centos/RHEL Benutzern entsprechend hoch sein. Wie das zu Problemen führen kann und was man das machen muß, lest Ihr hier: Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll.

Bei RPMFusion habe ich heute schon angeklopft, daß Updates benötigt werden.

Quelle: https://nvidia.custhelp.com/app/answers/detail/a_id/5031

Exim: TLS Protokollnamen haben sich geändert

Posted on by

Heute habe ich ein kleines exotisches Problem aus der Exim Welt für Euch, aus dem Ihr auch ohne Exim was lernen könnt.

Exim: TLS Protokollnamen haben sich geändert

Im Exim gibt es die Variable $tls_cipher. In dieser steht das TLS Protokoll drin,  auf welches sich die beteiligten Mailserver geeinigt haben. Rund eine Woche vor Exim 4.93 wurde „noch schnell“ ein Patch zur Standardisierung von SSL/TLS-Protokollnamen in das kommende Release (4.93) eingefügt. Leider war das eher unüberlegt, denn es wurde vergessen diesen Wechsel der Namen im ChangeLog von Exim 4.93 bekannt zu geben.

Nun setzten wir dies tatsächlich in einer ACL ein:

deny condition = ${if eq{${substr_0_7:$tls_cipher}}{TLSv1.2} {0}{1}}

Was dazu geführt hat, daß beim Wechsel auf Fedora 31 und in Folge auf Exim 4.94 die Config anpassen mußten:

deny condition = ${if eq{${substr_0_6:$tls_cipher}}{TLS1.2} {0}{1}}

Da diese Änderung nicht dokumentiert wurde, kam es nach dem Upgrade zu einer Störung des Mailverkehrs. Das möchte man natürlich vermeiden und deswegen liest ein Admin die Changelogs durch. Nutzte hier nur nichts.

Nehmt daher für Eure Projekte zwei Sachen mit:

1. Alles was zu Änderungen von Ausgaben und Variableninhalten führt, muß von Euch kommuniziert werden, sonst => Problem mit Nutzern.

2. „Testen! Testen! Testen!“

 

Vollversagen bei OpenSSH: Is a directory

Posted on by

Nehmt es mir nicht übel, aber anders als ein komplettes Versagen auf ganzer Linie kann man den Fall bei OpenSSH nicht bezeichnen, zumal es um einen kleinen, aber sinnvollen Bugfix geht.

Vollversagen bei OpenSSH: „Is a directory“

Damit Ihr versteht um was es geht, müssen wir zurückreisen ins Jahr 2010. Damals wurde ein Bugreport im Bugtracker von OpenSSH veröffentlicht: https://bugzilla.mindrot.org/show_bug.cgi?id=1768

Von dem wußte ich aber nichts, als ich 2015 über das Problem gestolpert bin. Das Problem sieht wie folgt aus:

scp testdatei user@servername:/topdir/subdir/

Wenn es „subdir“ als Directory gibt, dann wird testdatei dahin kopiert und alles ist gut. Wenn es „subdir“ aber nicht gibt, dann würde man ja wohl erwarten, eine Fehlermeldung zu bekommen, aus der genau das hervorgeht, oder? Tja, wie soll ich sagen, ähm…nein!

Actual results:

scp: /usr/doesnotexist/: Is a directory

Wow.. oder? Das komplette Gegenteil von dem was man annehmen würde 🙂 Diese Aussage bekommt jeder, der sich OpenSSH selbst aus den original Sourcen kompiliert, denn, obwohl der Fehler schon 2010 gemeldet wurde und 2015 Jakub Jelen von Red Hat einen kompletten Patch geschrieben hat und das seit Fedora 20 und RHEL8 an alle „Nutzer“ in einem „Feldtest“ ausgerollt wurde, sieht sich das Projekt hinter OpenSSH nicht dazu in der Lage.

Eingeführt wurde der Bug übrigens um das Jahr 2005 herum. Damit sind es streng genommen schon 15 Jahre, die der Bug da vor sich hin dümpelt. Da ich Fedora nutze, habe  ich das Problem nicht mehr und viele andere Distros haben den RH Patch übernommen, aber traurig ist das schon, oder?

Leider mußte ich gerade feststellen, daß die neue Fehlermeldung auch nicht gerade viel besser als die alte ist:

scp: /tmp/ugdjkfh/: Not a directory

Das stimmt zwar inhaltlich, gibt aber den wahren Ursprung meiner Meinung nach nur unzureichend wieder 😉 Daher war ich mal so frei, Jakub darauf hinzuweisen, zumal ich den Bug da auch bei RH reportet hatte, vielleicht bekommt man nach 10 Jahren dann doch nochmal ein „Does not exist“ 😀 Wobei man als Server ja unterscheiden können muß zwischen „directory gibts nicht“ und „Du User, darfst da nicht reinschreiben“ unterscheiden wenn so eine Anfrage kommt, sonst könnte ein User niedriger Privilegierung die Verzeichnisstruktur einfach durchtesten. Ok, er könnte das viel einfach, wenn er eingeloggt wäre, aber ggf. hat der Account nur SFTP Zugang, ohne Interaktiven Shellzugang zu haben. Wäre ja denkbar.

Wie man sieht, doch nicht ganz trivial so eine saubere Fehlermeldung 😉

Wenn Ihr jemanden im OpenSSH Team kennt, könnt Ihr Ihn ja mal auf dieses Problem ansprechen. Übrigens erinnert mich das ganz stark an meinen Bugreport an ProFTP, weil deren 20 Jahre alte CHROOT Anweisung den Fall, daß da einer das Ziel per Symlink umgeleitet hat, nicht abgedeckt hatte. Das wurde auch Jahrelang geblockt bis es dann doch wer geschafft hatte, die Entwickler umzustimmen. Leider durfte ich mit dem 20 Jahre Bug-Jubiläumsvortrag nicht auf dem CCC sprechen. Dabei wollte ich nur son 15 Minuten Vortragsfenster im Nebenraum haben. Ich hatte denen sogar einen Patch für das Problem geschickt. Das wäre bestimmt lustig geworden, wenn die ProFTP Devs sich auf der Vortragsliste gesehen hätten 😀 Vielleicht packe ich Euch den Vortrag als PDF mal auf die Seite.

Ein Args für netstat

Posted on by

Wenn Dinge nicht so funktionieren, wie sie sollten, dann liegt das oft daran, daß falsche Entscheidungen getroffen wurden. Bei dieser Entscheidung geht es um netstat und IPv6.

Ein „Args!“ für netstat

netstat zeigt einem die Verbindungen, Sockets und Ports an, die auf einem Linux PC verfügbar sind. Solange es dabei um TCP und IPv4 Adressen geht, ist alles ok. Wenn man aber ein Problem mit einer IPv6 Adresse hat, dann sollte man sich informieren, weil netstat dummerweise IPv6 Adressen unvollständig anzeigt… ohne Warnung übrigens.

Nun würde man ja annehmen, daß ein „man netstat“ alles wissenswerte zu den Optionen von netstat anzeigt, oder? Tja, Pech gehabt liebe deutschsprechende Gemeinde, Ihr seid leider am Allerwertesten 🙂

BESCHREIBUNG
Netstat zeigt Informationen des Linux Netzwerkssystems an.

Bitte beachten Sie, dass der Inhalt der deutschen man-page nicht vollständig ist,im Moment.

„nicht vollständig“ ist eine leichte Untertreibung und dieser „Moment“ hält auch schon seit 2007 an 🙁 Tief durchatmen. Es gibt ja noch eine englische Originalversion. Aber wie kommt man da ran? Fragen wir doch mal „man man“ dazu …

Handbuchseiten finden
-L Locale, –locale=Locale
man wird in der Regel Ihre aktuelle Locale durch einen Aufruf der C-Funktion setlocale(3) bestimmen, welche verschiedene Umgebungsvariablen auswertet (darunter sind eventuell auch $LC_MESSAGES und $LANG). Um den ermittelten Wert vorübergehend außer
Kraft zu setzen, können Sie man mit dieser Option eine Locale vorgeben. Beachten Sie, dass dieser Wert erst wirksam wird, wenn die Suche tatsächlich beginnt. Programm-Meldungen wie Hilfe-Nachrichten werden immer in der zu Anfang ermittelten Locale
angezeigt werden.

Also tun mir mal, was da exemplarisch nicht steht: „man -L EN_en.UTF8 netstat“ und plötzlich haben wir Zugriff auf alle Infos zu allen Optionen, die in der deutschen Version nicht mal angedeutet wurden. Wer auch immer das übersetzt und dann auf die Deutschen losgelassen hat, mochte uns wohl nicht.

Zurück zum Problem: Die IPv6 Adressen werden abgeschnitten

Lösung:

–wide, -W
Do not truncate IP addresses by using output as wide as needed. This is optional for now to not break existing scripts.

Nun, die Begründung verschlägt einem ja praktisch die Sprache. Da IPv4 Adressen nicht verkürzt werden müssen, sieht man den Bug selten, bis man mal IPv6 braucht. Wer sein Script aber ohne IPv6 Support gebaut hat, der kann mit der Ausgabezeile eh nichts anfangen, weil da dann zu viele „:“und zu wenige „.“ in den IPs drin sind. Vorhandene Scripts stolpern also vermutlich sowieso über IPv6, da hätte man die IPs auch komplett ausgeben können.

Noch cleverer wärs gewesen, die Ausgabe wie „less“ oder „vim“ erzeugen zu lassen, die scrollen einfach nach rechts, wenn man die Cursorsteuertaste „->“ benutzt. Wenn man also keinen Platz mehr in einem 80-Spalten Terminal hat, dann macht man sich halt welchen, aber verkürzt sicher nicht wichtige Informationen.

Warum man nicht ss benutzt?

„ss“ ist der „Nachfolger“ von netstat, aber IMHO, und mit der stehe ich wohl nicht ganz alleine dar, ist die Ausgabe von ss unverhältnismäßig unübersichtlich :

Beispiel:

$ ss -6 -t -p

ESTAB 0 0 [::ffff:127.0.0.1]:58772 [::ffff:127.0.0.1]:mysql users:((„java“,pid=1525,fd=59))

$ netstat -lnapW

tcp6 0 0 127.0.0.1:58772 127.0.0.1:3306 VERBUNDEN 1525/java

Was ist jetzt einfacher zu lesen? Es steht zwar das gleiche an Information zur Verfügung, aber es ist einfacher zu erfassen finde ich.

Es war einmal ein Sambashare …

Posted on by

und dann kam Fedora 31 daher. Ich habe Zuhause diverse Geräte, die sich von meinem PC Videos in die Küche, ins Bad, ins hiesige Bett oder ins Hotelbett nach Paris ziehen können, falls NetFlix ausfällt 🙂

Es war einmal ein Sambashare …

Nun ist da ein älteres AOS4 Gerät dabei, welches außer Emails eigentlich nur als Unterhaltungsquelle für NetFlix oder meine eigene Videothek dient. Das liegt daran, daß es praktisch nichts wiegt und der Akku trotz des Alters lange hält. Die Rechenleistung reicht auch genau noch dafür aus, bei FHD wirds schon schwierig bis geht gar nicht mehr.

Jetzt stand der Wechsel auf Fedora 31 wegen Fedora 30 EOL sowieso an, also habe ich das 7.000 Schritte Update gestern mal gemacht. Das lief technisch gut, aber sehr lange und das trotz SSD. Nach dem Reboot gabs dann das von Windows schon bekannte Durchbooten ohne Bildschirm zucken. Wers mag, bitte. Bis auf ein VNC Problem in Python, das sich durch rustikales Nachinstallieren mit Gewaltandrohung von alten Paketen lösen lies, gab es keine nennenswerten Probleme.

Heute wollte ich dann in der Küche beim Mittag mal etwas laufen lassen, aber das bislang genutzt Programm meinte nur so, daß kein Server da wäre. Also habe ich nachgesehen, aber der Server war da. Das gleiche Programm, aber mit AOS5 als Basis, konnte den Sambaserver auch finden und nutzen, aber die AOS4 Version davon nicht. Das finde ich jetzt schon so komisch, daß ich dem Dev da mal eine Email geschrieben habe. Leider gabs noch keine Reaktion, falls die jemals kommen wird.

Also habe ich etwas geforscht und der Unterschied zu Fedora 30 war bei Samba, daß es dort noch Version 4.10.15 war und jetzt 4.11 ist. Mit 4.11 wurde per default NT1 aka Samba 1 deaktiviert. Nach sehr viel rumraten, weil Lösungen aus dem Netz dafür verliefen alle samt im Sande, hatte ich dann doch einen Weg gefunden:

[global]

…
client min protocol = NT1
server min protocol = NT1
security = user
ntlm auth = ntlmv1-permitted
…

Wenn man obiges in die /etc/samba/smb.conf einträgt und neustartet, dann geht auch wieder mit AOS4 Programmen 😉

Wenn Ihr das mal selbst testen müßt: smbclient -L //IP.ADDR/

Wenn da was angezeigt wird und in eurem Programm nicht, dann liegts an Eurem Programm 😉

 

Jitsi-Meet-Docker failed mit Cgroups2

Posted on by

Ich habe es bei FlatPak gesagt, ich habe es bei Snap gesagt, und ich sags bei Docker: Container sind Scheisse!

Jitsi-Meet-Docker failed mit Cgroups2

Die Jitsi-Meet-Docker Instanz hatte ja bereits am Anfang leichte Probleme: Das erste Update ging gründlich schief, weil es mit der selbst erstellten Laufzeitconfig nicht mehr zurecht kam. Ein komplettes „rm -rf“ war die Folge. Zum Glück lies es sich dann recht einfach reinstallieren. Die Folge war allerdings, daß es nachts abstürzte und per Cron restartet werden mußte.

Der Wechsel von Fedora 30 ( CGroups V1 ) auf Fedora 31 ( CGroups V2 ) hat dem Dockerimage dann den Rest gegeben. zwei der vier Server starten halt nicht mehr.

# ./update.sh
Removing docker-jitsi-meet_web_1 … done
Removing docker-jitsi-meet_prosody_1 … done
Removing network docker-jitsi-meet_meet.jitsi
Bereits aktuell.
Creating network „docker-jitsi-meet_meet.jitsi“ with the default driver
Creating docker-jitsi-meet_web_1 …
Creating docker-jitsi-meet_prosody_1 … error
Creating docker-jitsi-meet_web_1 … error
ERROR: for docker-jitsi-meet_prosody_1 Cannot start service prosody: OCI runtime create failed: this version of runc doesn’t work on cgroups v2: unknown

ERROR: for docker-jitsi-meet_web_1 Cannot start service web: OCI runtime create failed: this version of runc doesn’t work on cgroups v2: unknown

ERROR: for prosody Cannot start service prosody: OCI runtime create failed: this version of runc doesn’t work on cgroups v2: unknown

ERROR: for web Cannot start service web: OCI runtime create failed: this version of runc doesn’t work on cgroups v2: unknown
ERROR: Encountered errors while bringing up the project.

Der resultierende Bugreport im GitHub wird seit dem ignoriert.

Die mangelnden Updates am den Basisimages, bzw. die Vorherschaft von Debianimages in den Containern führt wegen dem lahmen Updatezyklus von Debian und dem mangelnden Druck zu Updates durch die Containerhersteller, dann unweigerlich ins Nirvana.

Fazit: Man kann eben doch nicht einfach Container von A nach B und zwischen Osen verschieben wie man will.

Schweres Defizit im Dockersystem

Wie ich gerade feststellen muß, ist es nicht möglich in einen nicht laufenden Container zuwechseln. Das macht das Debuggen natürlich extrem toll, wenn man nicht mal die Logfiles auslesen kann!

# docker-compose ps
Name Command State Ports
——————————————————–
docker-jitsi-meet_prosody_1 /init Exit 128
docker-jitsi-meet_web_1 /init Exit 128
# docker-compose logs web
Attaching to docker-jitsi-meet_web_1

Ich hab jetzt keine große Lust das Filesystem umständlich zu mounten und da so reinzusehen 🙁

So lustige Sachen wie : „docker export CONTAINER|tar -t“ gehen auch nicht.

Meine Meinung: wer Docker produktiv einsetzt, sollte aus dem Zirkel der ITler exkommuniziert werden.

UPDATE – LÖSUNG

Es gibt noch Leute, die da durchblicken, „{hier ihre Gottheit einsetzen} sei Dank“!

Seit ner Weile gibt es im Kernel die neuen Control Groups 2. Fedora hat mit 31 auf cgroups2 umgestellt, aber Docker kann das nicht, weswegen die Container sauber wegcrashen.

Die Lösung des Problems ist zwar einfach, aber sollte echt nicht nötig sein:

# cat /etc/default/grub
…
GRUB_CMDLINE_LINUX=“rhgb quiet audit=0 systemd.unified_cgroup_hierarchy=0“
…

Dann die grub Config neu erzeugen, oder einfach die /boot/grub/grub.cfg (Legacy)  kurz anpassen und rebooten. (Mehr Hinweise dazu in: Wenn sich Grub und Grubby uneins sind )

Danach starten die Container wieder, außer der Container hat beim Update was anderes verbrochen, was Jitsi tatsächlich hinbekommen hat:

Die JICOFO Komponente prüft doch jetzt tatsächlich, ob das Passwort nicht das Defaultpasswort ist. Das finde ich ja prinzipielle richtig gut, wäre da nicht der Umstand, daß das gar nicht eingeschaltet ist 😀

2. UPDATE:

Kleines Sicherheitsloch bei Jitsi-Meet:

Die Passwörter für die Instanzen werden in ENV variablen übergeben und nie gelöscht. Sobald jemand, wie auch immer, Zugang zur Prozessenviron bekommt, kann man das auslesen. Da potentiell noch andere priviligierte Prozesse im System laufen, ist generell eine dumme Idee.

Infos aus ENV variablen, die man nicht mehr braucht, gehören getilgt, in dem die Variable entfernt wird. Passwörter gehören übrigens GAR NICHT in ENV Variablen.

 

Zahn der Zeit nagt am Linuxsupport von Brother

Posted on by

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

WordPress: die vergessene mShot DOS Attacke

Posted on by

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.

 

Xenserver: VDI löschen geht nicht – was tun?

Posted on by

Moin,

heute widmen wir uns eines kleinen Problems, daß auftreten kann, wenn beim Xenserver was richtig schlief läuft:

Beim Transfer einer VM von einem Server zum Anderen ( Stichwort: vm-import ) brach der Transfer zusammen und die importierte VM war defekt. Zu dem Zeitpunkt lies sich weder der Import abbrechen, noch störte das den zweiten Versuch. Erst beim Aufräumen der VM und Festplatten, die beim Import automatisch angelegt werden, kam es zum Problem:

Error: „This Operation Cannot be Performed Because a VDI is in Use by Some Other Operation“

Ja, ok. Und nu? Die zu löschende VM ( vm-destroy ) lies sich noch löschen, aber die daran angehängten Festplatten ( VDI ) nicht mehr. Diese wurden noch vom hängenden Import Prozess blockiert, der an der Dom0 hängt.

Hinweis: Die UUID hier sind die von meinem Server, Ihr habt andere! Die Befehle einfach so in die Konsole hauen, wird schlimmstenfalls Sachen löschen, die Ihr nicht löschen wolltet oder es passiert gar nichts 😀

Da muß man jetzt die Zähne zusammenbeißen und ein paar unfreundliche Anweisungen manuell in die Konsole hauen:

1. Damit wird der hängende Importtask endgültig terminiert:

xe-toolstack-restart

Für sich betrachtet ist der Befehl allerdings harmlos, damit geht noch nichts kaputt 😉

2. Damit sucht man sich die UUID der Festplatte raus, die man löschen will.

xe vdi-list

3. Jetzt müssen wir die VBD ( Virtual Block Device ) zu der VDI finden:

xe vbd-list vdi-uuid=bc83886b-5723-4dfe-9d5b-feebb2917d0f

Da kommt in etwa sowas raus:

uuid ( RO) : d16248e4-2c24-fa3a-1364-dcb43f5f6858
vm-uuid ( RO): 253c1fde-78d4-3719-ede6-8d0bd223b873
vm-name-label ( RO): Control domain on host: xen1
vdi-uuid ( RO): bc83886b-5723-4dfe-9d5b-feebb2917d0f
empty ( RO): false

4. Jetzt die Augen zu und durch: die VBD abziehen und löschen

xe vbd-unplug uuid=d16248e4-2c24-fa3a-1364-dcb43f5f6858
xe vbd-destroy uuid=d16248e4-2c24-fa3a-1364-dcb43f5f6858

5. und jetzt weg mit der VDI:

xe vdi-destory uuid=611441f9-20c7-6775-716a-37c78b6d672e

6. Jetzt empfehle ich noch das Storage Repository ( SR ) neu zu scannen:

xe sr-list
xe sr-scan uuid=655e2297-b012-d722-1c5f-c2814226a942

Damit wird die Liste der virtuellen Festplatten aktualisiert.