Fedora: Xen bootet endlich wieder aktuelle Kernel

Paravirtualisierte Virtuelle Maschinen eines XenServers booten endlich alle wieder die aktuellen Kernel, ein Grund zu feiern.

It’s Time to Party \o/

Die Einleitung mag dem Einen oder Anderen komisch vorkommen, aber auf den Tag habe ich lange warten müssen. Seit einiger Zeit booteten die Kernels von Fedora nicht auf Paravirtualsierten VMs vom XenServer. Zudem liefen die Kernel 4.16.x bis 5.0.0 echt instabil, so daß diese sich nach Stunden bereits reseteten. Richtig gelesen RESET, nicht Crash. Das ist so ziemlich die mieseste Art eines Kernelbugs, da man nicht mal sehen kann, was da wo gecrasht ist.

Unzählige Bugreports an RedHat und Citrix später ist nun endlich soweit, die aktuellen Kernel 5.0.16 laufen stabil und, das beste daran, booten überhaupt wieder auf allen XenServer-Versionen.

Damit bekommen die VMs auch die neueste Firmware für die CPUs mit und angesichts diverser neuer Intel-CPU Schwachstellen, eine wirklich beruhigende Angelegenheit. Daher 😀

 

Alternativ die Studioversion von Andrew W.K.’s Time to Party!

Ich finde ja den Live Sound trotz der Störgeräusche einfach besser. Das der als Band ein ganzes Stadion gefüllt hat, will man kaum glauben, oder? 😉

Runes of Magic, Linux und der Performance Bug

Ihr könnte Euch gaaaaaaaaaaaaaaanz sicher an die Intel CPU Bugs erinnern und wie die im Linux Kernel abgewehrt wurden, so in etwa. Der Nebeneffekt war, u.a., daß bspw. Runes of Magic als WineApp mit DX9 Teil auf meinem  Achtkerner von im Durchschnitt 150% CPU Last pro Instanz auf 250% hochgeschnellt war. Die Kernels 4.19.9+ > 4.20.latest waren allesamt davon betroffen.

66% mehr CPU Last

Das Phänomen war besonders nervig, weil zwar im Regelbetrieb nur eine leichte Erhöhung von 150% auf 180% vorhanden war, aber sporadisch brach die Lasthölle los, mit den erwähnten Peeks auf 250%, die dann für einige Minuten blieben um dann wieder zu verschwinden. Ein Spielen war so natürlich nicht mehr mit mehreren Instanzen möglich.

Seit Kernel 5.0.6 und vermutlich auch eher, ist die Last wieder zurück auf den Normalwert von 150% im normalen Spielbetrieb. Die Reaktion vom Kernel bzw. Wine Maintainer auf diesen Bugreport war übrigens „Damit können wir nichts anfangen“ mit anderen Worten, sie konnten nicht mal glauben, daß es den Effekt überhaupt gab.

top – 13:11:29 up 1 day, 3:52, 1 user, load average: 4,09, 4,31, 4,87
PID   USER   PR NI VIRT   RES    SHR   S %CPU %MEM TIME+ COMMAND
3542  marius 20 0 2240024 1,238g 76976 S 155,8 7,9 1159:15 H:\Programme\GameforgeLive\Games\DEU_deu\Runes Of Magic\Client.exe NoCheckVersion20398 marius 20 0 2378776 1,291g 78152 R 142,2 8,3 1369:03 H:\Programme\GameforgeLive\Games\DEU_deu\Runes Of Magic\Client.exe NoCheckVersion

Da die Last seit einiger Zeit wieder konstant im grünen Bereich ist, kann man das Problem wohl als gelöst betrachten. Falls jemand von Euch mit einem Programm unter Linux ähnliche Erfahrungen gemacht hat oder derzeit macht, wisst Ihr was die Lösung ist => Kernel Updaten.

Bevor Klagen von Lesern reinkommen: klar hatte ich überprüft, ob sich Wine oder die Grafikkartentreiber geändert hatten, hatten sie nicht.

Der Nachtrag: LPD in Braunschweig

Wenn man in Braunschweig einen LPD plant, dann muß man eine goldene Regel beachten. Nur diese !!eine!! Regel entscheidet darüber, ob Dein Event gut besucht wird, oder nicht, und diese !!eine!! Regel ist wirklich wichtig :

Mach Deinen LPD niemals an einem Tag, an dem Eintracht Braunschweig um den Klassenerhalt spielt 🙂

Die Besucherzahlen waren besser als auf den letzten LPDs und damit setzt sich der positive Trend der letzten Jahre fort. Das Wetter war fantastisch, was natürlich für eine In-Raum Veranstaltung nicht gerade förderlich war. Natürlich gab es wieder Lecker zu Essen: Danke Horst!

Zu den Ergebnissen:

Wir haben einen neuen Anreiserekord aus Dessau \o/
Wir haben jetzt spontan einen neuen Linux-Tablet-Besitzer in Braunschweig, was dann fünf Sichtungen macht bislang 😉
Unsere Multi-Room-Audiolösung konnte das eine und andere Cool entlocken 🙂
Die Kanotix Maintainer konnten viele lange Gespräche über Linux führen.
Die Asterix Telefonanlage fand begeisterte Nerds, die lautstark gefachsimpelt haben 😀
und ein zwanzig Jahre (unbestätigt) altes Artpad konnte wieder belebt werden ( das es damals schon USB gab 🙂 )

Am Ende waren alle zufrieden mit dem Tag.

Die für uns weniger interessanten Fakten des Tages, Eintracht bleibt der Abstieg in das Vergessen erspart, und den Anwohnern wird auch weiterhin in den Vorgarten gepinkelt, was die Blase hergibt.

An dieser Stelle der Nerdhinweis für die kommenden Tage:

29.5.2019 ab 18:00 Uhr : Der OpenSteetMap Abend mit Dipl.-Ing. Annette Thurow

 

 

Wie man sich RPM Scripte ansieht

Heute geht es um RPMs und die Install und Uninstall Scripte die RPMs so mit sich rumschleppen.

Wie man RPM-Files genauer betrachtet

Zunächst schauen wir mal in ein RPM am Beispiel des Zoomclienten für Linux rein, was überhaupt drin ist:

# rpm -ql ./zoom_x86_64.rpm

Allerdings sieht man dabei nur die Dateien des RPM, aber nicht die Scripte oder die Info des RPM:

# less zoom_x86_64.rpm

Ja, genau, less 🙂 Wer hätte das gedacht, daß dies beides gleichzeitig anzeigt 🙂

Name : zoom
Version : 2.8.183302.0415
Release : 1
Architecture: x86_64
Install Date: (not installed)
Group : default
Size : 246299262
License : see https://www.zoom.us/
Signature : RSA/SHA1, Di 16 Apr 2019 09:02:21 CEST, Key ID b903bf1861a7c71d
Source RPM : zoom-2.8.183302.0415-1.src.rpm
Build Date : Di 16 Apr 2019 08:59:45 CEST
Build Host : localhost
Relocations : / 
Packager : Zoom Linux Team <linux-dev@zoom.us>
Vendor : Zoom Video Communications, Inc.
URL : https://www.zoom.us
Summary : Zoom, #1 Video Conferencing and Web Conferencing Service \nZoom, the cloud meeting company, unifies cloud video conferencing, simple online meetings, and group messaging into one easy-to-use platform. Our solution offers the best video, audio, and screen-sharing experience across Zoom Rooms, Windows, Mac, Linux, iOS, Android, and H.323/SIP room systems.
Description :
Zoom, #1 Video Conferencing and Web Conferencing Service \nZoom, the cloud meeting company, unifies cloud video conferencing, simple online meetings, and group messaging into one easy-to-use platform. Our solution offers the best video, audio, and screen-sharing experience across Zoom Rooms, Windows, Mac, Linux, iOS, Android, and H.323/SIP room systems.
-rw-rw-r-- 1 root root 513 Jul 26 2018 /opt/zoom/Droplet.pcm
-rw-rw-r-- 1 root root 140 Sep 13 2018 /opt/zoom/Qt/WebSockets/qmldir
-rw-rw-r-- 1 root root 2637 Sep 13 2018 /opt/zoom/Qt/labs/calendar/DayOfWeekRow.qml
-rw-rw-r-- 1 root root 7835 Sep 13 2018 /opt/zoom/Qt/labs/calendar/DayOfWeekRow.qmlc
-rw-rw-r-- 1 root root 2703 Sep 13 2018 /opt/zoom/Qt/labs/calendar/MonthGrid.qml
-rw-rw-r-- 1 root root 8747 Sep 13 2018 /opt/zoom/Qt/labs/calendar/MonthGrid.qmlc
-rw-rw-r-- 1 root root 2645 Sep 13 2018 /opt/zoom/Qt/labs/calendar/WeekNumberColumn.qml
-rw-rw-r-- 1 root root 7835 Sep 13 2018 /opt/zoom/Qt/labs/calendar/WeekNumberColumn.qmlc
-rwxrwxr-x 1 root root 117816 Sep 13 2018 /opt/zoom/Qt/labs/calendar/libqtlabscalendarplugin.so
-rw-rw-r-- 1 root root 4968 Sep 13 2018 /opt/zoom/Qt/labs/calendar/plugins.qmltypes
-rw-rw-r-- 1 root root 187 Sep 13 2018 /opt/zoom/Qt/labs/calendar/qmldir
-rwxrwxr-x 1 root root 64624 Sep 13 2018 /opt/zoom/Qt/labs/folderlistmodel/libqmlfolderlistmodelplugin.so
-rw-rw-r-- 1 root root 2341 Sep 13 2018 /opt/zoom/Qt/labs/folderlistmodel/plugins.qmltypes
-rw-rw-r-- 1 root root 124 Sep 13 2018 /opt/zoom/Qt/labs/folderlistmodel/qmldir

Geht natürlich auch direkt mit rpm :

# rpm -qi foo.rpm

und wer auch die Changelogs sehen will:

# rpm -qi –changelog foo.rpm

Jetzt ging es aber um die Installationsscripte, die ausgeführt werden, wenn man Pakete installiert oder eben deinstalliert:

# rpm -qp –scripts foo.rpm

Wenn man das beim Beispiel Zoom macht, kommt das raus:

# rpm -qp –scripts zoom_x86_64.rpm

Warnung: zoom_x86_64.rpm: Header V4 RSA/SHA1 Signature, Schlüssel-ID 61a7c71d: NOKEY
postinstall scriptlet (using /bin/sh):
#!/bin/bash
# Program:
# script to be run after package installation

echo "run post install script, action is $1..."

#ln -s -f /opt/zoom/ZoomLauncher /usr/bin/zoom

#$1 folder path
function remove_folder
{
if [ -d $1 ]; then
rm -rf $1
fi
}

echo current home is $HOME
remove_folder "$HOME/.cache/zoom"

update-mime-database /usr/share/mime || true
#update-desktop-database || true
if [ -x "/usr/bin/update-desktop-database" ]; then 
update-desktop-database || true
fi
postuninstall scriptlet (using /bin/sh):
#!/bin/bash
# Program:
# script to be run after package removal

echo "run post uninstall script, action is $1 ..."

[ "$1" == "0" ] || exit 0

echo current home is $HOME

if [ -L "/usr/bin/zoom" ]; then 
rm /usr/bin/zoom 
fi

#$1 folder path
function remove_folder
{
if [ -d $1 ]; then
rm -rf $1
fi
}

#$1 file path
function remove_file
{
if [ -f $1 ]; then
rm -f $1
fi
}

remove_folder "/opt/zoom"
remove_folder "$HOME/.zoom/logs"
remove_folder "$HOME/.cache/zoom"
#remove_file "$HOME/.config/zoomus.conf"

#logged_in_users=$(who -q | head -n 1)
#sorted_users=$(echo "$logged_in_users"|tr " " "\n"|sort|uniq|tr "\n" " ")
#for user in $sorted_users;do
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom..."
# remove_folder "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom"
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf..."
# remove_file "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf"
#done

Orange ist das Installscript, Grün ist das Uninstallscript

Denn Sie wissen nicht, was Sie tun

Ok, was fällt uns daran auf?

echo current home is $HOME
...
remove_folder "/opt/zoom"
remove_folder "$HOME/.zoom/logs"
remove_folder "$HOME/.cache/zoom"

Es soll also im Home des Users etwas gelöscht werden ? Jetzt zeige ich Euch mal was das Script ausgegeben hat :

# dnf erase zoom
Abhängigkeiten sind aufgelöst.
================================================================================================================================================================================================================================================================================
Paket Arch Version Paketquelle Größe
================================================================================================================================================================================================================================================================================
Entfernen:
zoom x86_64 2.8.183302.0415-1 @@commandline 235 M

Transaktionsübersicht
================================================================================================================================================================================================================================================================================
Entfernen 1 Paket

Freigegebener Speicherplatz: 235 M
Ist dies in Ordnung? [j/N]:j
Transaktionsüberprüfung wird ausgeführt
Transaktionsprüfung war erfolgreich.
Transaktion wird getestet
Transaktionstest war erfolgreich.
Transaktion wird ausgeführt
Vorbereitung läuft : 1/1 
Löschen : zoom-2.8.183302.0415-1.x86_64 1/1 
Ausgeführtes Scriptlet: zoom-2.8.183302.0415-1.x86_64 1/1 
run post uninstall script, action is 0 ...
current home is /root
Überprüfung läuft : zoom-2.8.183302.0415-1.x86_64 1/1

Entfernt:
zoom.x86_64 2.8.183302.0415-1

Fertig.

Na? Wer hats gesehen?  … Richtig: „current home is /root“  wie sinnvoll dort Configs u.ä. zu löschen oder gar anzulegen, wo Root doch gar nicht der User ist, des es ausgeführt hat. Um das zu beheben, war der Code hier mal gedacht:

#logged_in_users=$(who -q | head -n 1)
#sorted_users=$(echo "$logged_in_users"|tr " " "\n"|sort|uniq|tr "\n" " ")
#for user in $sorted_users;do
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom..."
# remove_folder "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom"
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf..."
# remove_file "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf"
#done

Selbst wenn das einkommentiert gewesen wäre, wäre das wenig hilfreich gewesen, weil was wenn der User gar nicht eingeloggt ist, wenn das Uninstallscript läuft? Genau, dann würden die Files auch nicht gelöscht werden 😀  Da haben sie es dann gleich gelassen 😉

Einmal mit Profis und so..

Wieso habe ich das eigentlich nach Benutzung gelöscht? Ach ja, wegen der sechs CVE Sicherheitslücken allein in den statisch gelinkten QT5 Libraries seit September 2018 😀

#CVE IDCWE ID# of ExploitsVulnerability Type(s)Publish DateUpdate DateScoreGained Access LevelAccessComplexityAuthenticationConf.Integ.Avail.
1CVE-2018-19873119Overflow2018-12-262019-01-08
7.5
NoneRemoteLowNot requiredPartialPartialPartial
An issue was discovered in Qt before 5.11.3. QBmpHandler has a buffer overflow via BMP data.
2CVE-2018-198723692019-03-212019-04-24
4.3
NoneRemoteMediumNot requiredNoneNonePartial
An issue was discovered in Qt 5.11. A malformed PPM image causes a division by zero and a crash in qppmhandler.cpp.
3CVE-2018-198714002018-12-262019-04-25
4.3
NoneRemoteMediumNot requiredNoneNonePartial
An issue was discovered in Qt before 5.11.3. There is QTgaFile Uncontrolled Resource Consumption.
4CVE-2018-198704762018-12-262019-04-25
6.8
NoneRemoteMediumNot requiredPartialPartialPartial
An issue was discovered in Qt before 5.11.3. A malformed GIF image causes a NULL pointer dereference in QGifHandler resulting in a segmentation fault.
5CVE-2018-19869202018-12-262019-04-25
4.3
NoneRemoteMediumNot requiredNoneNonePartial
An issue was discovered in Qt before 5.11.3. A malformed SVG image causes a segmentation fault in qsvghandler.cpp.
6CVE-2018-198655322018-12-052019-05-10
5.0
NoneRemoteLowNot requiredPartialNoneNone
A keystroke logging issue was discovered in Virtual Keyboard in Qt 5.7.x, 5.8.x, 5.9.x, 5.10.x, and 5.11.x before 5.11.3.

Den Rest der App zu analysieren habe ich mir dann gleich erspart 😉

Beworben wurde das RPM übrigens mit „ab Fedora 21“ .. das ist ja auch nur schon 4 Jahre her. Daher hat ich dann das Filedatum der Libs verwundert, denn die stammen von 2018. Ob das damit wirklich noch „ab Fedora 21“ läuft, hmm, wer weiß, ich probier es jedenfalls nicht aus 😉