CoronaChroniken: Da hatten wir mal eine kräftige Abnahme

Liebe Kasernierte,

nichts neues an der Coronafront, außer, daß wir einen kräftigen Abfall an Neuinfiziertenhaben und das RKI Alarm schlägt, weil sein R mal wieder steigt. Ich weiß wirklich nicht, was die da so berechnen.

CoronaChroniken: Da hatten wir mal eine kräftige Abnahme

Macht Euch selbst ein Bild davon, hier sind die üblichen Grafiken:Wiedereinmal zeigt unser R einen Abfall an, wo das R von RKI angeblich über 1 liegt. Da es aber mittlerweile 3 Vorfälle gibt, wo nachgewiesen wurde, daß sich die Leute im RKI verrechnet haben, gehe ich mal Brust-Voraus auf den Balkon und behaupte: „Mein R stimmt“ 😉

Der Abfall am 31.5. ist in absoluten zahlen nicht weiter wild (blaue Linie oben und unten), aber im prozentualen Bereich, da hauts einem fast die Füße weg ( rote Linie unten ):

Das ist einer der stärksten Abfälle überhaupt seit beginn der Rechnung und er scheint anzuhalten. Ist das jetzt endlich das Ende vom Ende? Wir werden sehen.

In anderen „Nachrichten“ : Das Städtische Klinikum in Braunschweig hat unsere Redaktionsanfrage (ja, so etwas gibts hier bei Bedarf 😉 ) unbeantwortet gelassen. Habe ich fast befürchtet, daß es so kommen würde, dabei war das eine ergebnisoffene Anfrage.

Jitsi-Meet-Docker failed mit Cgroups2

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

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.

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!