Linux am Dienstag.. bis in den Mittwoch :)

Ganz kleine Nachlese zum Linux am Dienstag, das diesmal erst Mittwoch endete .. malwieder 😉

Linux am Dienstag.. bis in den Mittwoch 🙂

Kleine Jitsi-Statistik:

mit BildschirmĂŒbertragung haben wir : 10 Mb/s
ohne BildschirmĂŒbertragung haben wir : 2 Mb/s

Und das sehr konstant ĂŒber den ganzen Abend. Nicht ganz so viel ist vom Server empfangen worden: Spitze 1,62 Mb/s

Da es ja um USBPowercontrol fĂŒr Linux ging, hier ein kleiner Auszug wie man das macht:

Hinweis: nicht alle USB-Hubs können das und das klappt auch nur als root.

1) so findet man GerÀte:

[root ] $ uhubctl
Current status for hub 4-2 [174c:3074 Asmedia ASM107x, USB 3.00, 4 ports, ppps]
Port 1: 02a0 power 5gbps Rx.Detect
Port 2: 02a0 power 5gbps Rx.Detect
Port 3: 02a0 power 5gbps Rx.Detect
Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 3-2 [174c:2074 Asmedia ASM107x, USB 2.10, 4 ports, ppps]
Port 1: 0303 power
Port 2: 0507 power highspeed suspend enable connect [046d:085b Logitech Webcam C765F F4C01DCF]
Port 3: 0100 power
Port 4: 0100 power
Current status for hub 1-7 [05e3:0610 USB2.0 Hub, USB 2.00, 4 ports, ppps]
Port 1: 0100 power
Port 2: 0100 power
Port 3: 0100 power
Port 4: 0100 power

-l LOCATION 3-1 fĂŒr Hub#2
-p PORT 2 fĂŒr die WebCam

2) So schaltet man den Strom aus:

[root ] $ uhubctl -a off -p 2 -l 3-2
Current status for hub 4-2 [174c:3074 Asmedia ASM107x, USB 3.00, 4 ports, ppps]
Port 2: 02a0 power 5gbps Rx.Detect
Sent power off request
New status for hub 4-2 [174c:3074 Asmedia ASM107x, USB 3.00, 4 ports, ppps]
Port 2: 00a0 off
Current status for hub 3-2 [174c:2074 Asmedia ASM107x, USB 2.10, 4 ports, ppps]
Port 2: 0503 power highspeed enable connect [046d:085b Logitech Webcam C925e F4C01DCF]
Sent power off request
New status for hub 3-2 [174c:2074 Asmedia ASM107x, USB 2.10, 4 ports, ppps]
Port 2: 0000 off

3) So schaltet man den Strom wieder an:

[root ] $ uhubctl -a on -p 2 -l 3-2
Current status for hub 4-2 [174c:3074 Asmedia ASM107x, USB 3.00, 4 ports, ppps]
Port 2: 00a0 off
Sent power on request
New status for hub 4-2 [174c:3074 Asmedia ASM107x, USB 3.00, 4 ports, ppps]
Port 2: 02a0 power 5gbps Rx.Detect
Current status for hub 3-2 [174c:2074 Asmedia ASM107x, USB 2.10, 4 ports, ppps]
Port 2: 0000 off
Sent power on request
New status for hub 3-2 [174c:2074 Asmedia ASM107x, USB 2.10, 4 ports, ppps]
Port 2: 0101 power connect [046d:085b]

Hinweis: Wenn man wĂ€hrend einer LivevorfĂŒhrung dem Browser die Webcam abschaltet, reagiert dieser relativ ungehalten darauf, auch wenn er nur deren Ton nutzen wollte 😉

Außerdem war noch dies Thema:

Internetzensur fĂŒr NeulĂ€nder in Deutschland umgehen

Fedora: wie man Jitsi wieder starten kann

Auch Jitsi ist in die Jahre gekommen und braucht beim Start jetzt unsere Hilfe 😉

Fedora: wie man Jitsi wieder starten kann

Im Gegensatz zum Truecryptproblem, ist das Jitsi Problem recht einfach in den Griff zu bekommen.

Die Ursache ist ein Wechsel des Default-Javas auf Java 11. Jitsi braucht aber Java 1.8 zum Starten, sonst findet es eine Klasse nicht. Ingo Bauersachs, der derzeitige alleinige Autor vom Desktop Jitsi, arbeitet an solchen Problemen, aber aufgrund der geringen Zeit die er da investieren kann, kommt das alles nur langsam voran.

Wer also bei Jitsi mithelfen will, weil das u.a. auch das einzig gut funktionierende SIP-Phone auf dem Desktop ist, kann sich gern bei Ingo melden.

Nun zur Lösung

Werdet mal root auf Eurem Linux und geht das ein:

alternatives –config java

kommt so etwas:

# alternatives –config java

Es gibt 3 Programme, welche »java« zur VerfĂŒgung stellen.

Auswahl Befehl
———————————————–
+ 1 java-1.8.0-openjdk.x86_64 (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.292.b10-3.fc33.x86_64/jre/bin/java)
2 java-9-openjdk.x86_64 (/usr/lib/jvm/java-9-openjdk-9.0.4.11-6.fc28.x86_64/bin/java)
* 3 java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.11.0.9-2.fc33.x86_64/bin/java)

Eingabe um die vorgegebene Auswahl[+] zu behalten, oder geben Sie die Nummer an:

Ich habe mein Java natĂŒrlich schon so umgestellt, deswegen zeigt er bei mir das „+“ beim Java 1.8 an. Wenn das bei Euch nicht der Fall, sonst wĂ€rt Ihr vermutlich auch nicht hier, dann gebt „1“ oder die bei Euch angezeigte Zahl an. Danach startet Ihr Jitsi neu und geht wieder.

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.