Citrix WorkSpace app: Zertifikate unter Linux

Die proprietäre Citrix Workspace app for Linux krankt seit jeher daran, nur einige Zertifikate mitzubringen, meist nicht das benötigte. Eigentlich könnten sie’s auch ganz lassen und stattdessen die im System befindlichen verwenden. Das wäre saubere, konforme Arbeit.

Es existieren etliche Anleitungen im Netz. Folgend eine, die funktioniert (getestet in einer Debian-testing-VM und bereits mehrfach die Version aktualisiert – abgesehen von apt gilt dies im Prinzip auch für andere Distributionen).

  1. Installation des Pakets ca-certificates, falls nicht ohnehin installiert:
    sudo apt install ca-certificates
  2. Wechseln in das Directory mit dem icaclient-Paket (Direktlink ist nicht möglich, da dynamisch erzeugt).
  3. Installation von icaclient:
    sudo apt install ./icaclient*_amd64.deb
  4. Umbenennen des Citrix-eigenen cacerts-Directorys (für Vorsichtige, man könnte das auch gleich löschen):
    sudo mv /opt/Citrix/ICAClient/keystore/cacerts{,_orig}
  5. Erzeugen eines Softlinks:
    sudo ln -s /etc/ssl/certs /opt/Citrix/ICAClient/keystore/cacerts
  6. Zertifikatsspeicher aktualisieren:
    sudo /opt/Citrix/ICAClient/util/ctx_rehash

Anmerkung: Innerhalb der Installationsroutine des ICAClients gibt es eine Abfrage zu app protection component. Will man seine Entscheidung später revidieren, ist der ICAClient (wie auch unter Redmonds System) neu zu installieren.

User mißverstehen die Technologie oft, erwarten gleiches Funktionieren, als würde nicht auf einem Citrix-Server, sondern lokal ausgeführt werden. Für Video und dergleichen ist die Technologie nicht ausgelegt, entsprechend kann das bis zum Standbild ‘runtergehen (ich habe es erlebt, daß manche allen Ernstes yt-Videos über WSpApp haben sehen wollen…mit 1 Bild aller 2 Sekunden…).

Man kann es allerdings mit HDX RealTime Media Engine abmildern, insb. für MS Teams.

Chromium: fehlendes SSE3-Flag

Der Start eines aktuellen Chromiums oder dessen Code nutzender anderer Browser auf AMD Phenom II X6/4/3/2 ist nicht möglich, es kommt zu folgender Ausgabe:

The hardware on this system lacks support for the sse3 instruction set.
The upstream chromium project no longer supports this configuration.
For more information, please read and possibly provide input to their
bug tracking system at http://crbug.com/1123353

CPUs haben Befehlssätze, denen Befehlssatzerweiterungen hinzugefügt worden sind. Die wohl bekannteste dürfte MMX sein (was man eben 1997 unter Multimedia verstanden hat), die damals dem Pentium 1 auch im Produktnamen erkennbar als z.B. Pentium 166 MMX beigegeben worden ist.

Fragt man heute unter Linux mit

$ lscpu

oder gefiltert

$ lscpu | grep Flags

ab, wird eine ziemliche Menge solcher Befehlssatzerweiterungen gelistet. So gibt es bspw. SSE-Flags in Versionen. Genannte Phenoms haben zwar die Erweiterungen SSE1, SSE2, SSE3 und SSE4a (typische Mogelpackung AMDs, es liegt nicht SSE4 zugrunde, sondern es ist SSE3 plus 4 zusätzlicher Befehle), aber das Flag sse3 wird nicht ausgegeben, sondern bei diesen CPUs dessen alternative Bezeichnung pni.

D.h., Software kann SSE3 nutzen, wenn es allerdings deren Vorhandensein über Flag sse3 abfragt, fehlt für diese eben SSE3.

Das Ganze erinnert mich an Pentium M Banias und Dothan FSB100, denen das PAE-Flag fehlt (Ubuntu ab 12.04 ist damals 2 Jahre lang nicht ohne Tricks installierbar gewesen, ich habe hier diesbzgl. mehrere Posts geschrieben gehabt). Eine der Möglichkeiten ist das Hinzufügen des Flags in /proc/cpuinfo gewesen (ich habe es damals anders gelöst, die PAE-Abfrage aus dem jeweiligen Paket umgebogen). Dies können sich Phenom-User auch heute zu Nutze machen.

“/proc/cpuinfo” kann nicht direkt geändert werden. Daher kopieren wir deren Inhalt in eine neue Datei und fügen das Flag “sse3” hinzu (Kleinschreibung). Diese binden wir dann entsprechend ein.

#!/bin/sh
# 2022-09-05

$ sed 's/flags\t*:/& sse3/' /proc/cpuinfo > /tmp/cpuinfo_sse
$ mount -o bind /tmp/cpuinfo_sse /proc/cpuinfo
$ mount -o remount,ro,bind /proc/cpuinfo

exit

Man kann diese 3 Befehlszeilen (entnommen aus fake-pae.conf im Paket fake-pae von Bernd Kreuss und entsprechend angepaßt) einzeln über c&p ausführen (mount jeweils mit root-Rechten), man kann sinnvollerweise das Ganze als z.B. “/usr/local/bin/sse3flag.sh” speichern, mit

$ sudo chmod +x /usr/local/bin/sse3flag.sh

ausführbar machen und mit root-Rechten aufrufen. Letzteres bietet sich im Autostart an.

Dazu erstellt man eine Service Unit “/etc/systemd/system/sse3flag.service” mit folgendem Inhalt:

[Unit]
Description=add the SSE3 flag

[Service]
Type=simple
ExecStart=/usr/local/bin/sse3flag.sh

[Install]
WantedBy=multi-user.target

Mit

$ systemctl enable --now sse3flag.service

wird der Service permanent aktiviert (übersteht also Reboots) und gleich gestartet. Eine erneute lscpu-Abfrage gibt nun auch “sse3” aus. Da ich eine richtige ]:-) CPU habe, habe ich zum Test spaßeshalber “sse6” ;-) gesetzt – funktioniert.

Firefox snap durch deb ersetzen

Bekanntlich forciert Canonical deren Format snap, auch Firefox gibt es in Ubuntu 22.04 ausschließlich nur noch als snap-Image. Wie man das durch Firefox deb ersetzen kann, ist auf diversen Seiten beschrieben, aber auf keine würde ich verlinken (das geht schon mit “Ji m”s ewigem Kardinalfehler “sudo gedit” los).

  1. Erstelle eine Prioritätsdatei:
    • 1
      
      sudo nano /etc/apt/preferences.d/mozillateamppa.pref

      Füge über c&p ein:

      Package: firefox*
      Pin: release o=LP-PPA-mozillateam
      Pin-Priority: 501
    • Alternativ könnte man umgekehrt die Installation von Fx aus den Ubuntu-Repositories herunterstufen (das ist ein transitional .deb-Package, das in jedem Fall versionshöher ist, sich also drübersetzen und die snap-Version installieren würde)
      1
      
      sudo nano /etc/apt/preferences.d/firefox.pref

      Füge über c&p ein:

      Package: firefox*
      Pin: release o=ubuntu
      Pin-Priority: -1
  2. Füge das PPA Mozilla Team hinzu:
    1
    
    sudo apt-add-repository ppa:mozillateam/ppa
  3. Seit geraumer Zeit läßt apt-add-repository nach Hinzufügen automatisch “apt update” laufen – deswegen ist die Prioritätsdatei in dieser Liste an erste Stelle gesetzt worden (man muß ja nicht unnötige Schritte und Traffic erzeugen).

  4. Deinstalliere Fx snap (sollte man diese Anleitung damit abarbeiten, wäre ein temporäres Copypasten der Schritte in einen Editor von Vorteil, freilich ist’s nicht mehr viel):
    1
    2
    
    sudo snap remove firefox
    sudo apt purge firefox # fuer das transitional package
  5. Installiere
    • Firefox
      1
      
      sudo apt install firefox firefox-locale-de

    • oder Firefox-ESR
      1
      
      sudo apt install firefox-esr firefox-esr-locale-de

      Für Firefox-ESR brauchte es die Prioritätsdatei nicht, da keine solche Version in den Ubuntu-Repos angeboten wird, sie stört aber auch nicht.

Konfigurationsverzeichnisse liegen an unterschiedlichen Orten:

  • snap: “~/snap/firefox/”
  • deb: “~/.mozilla/”

Im übrigen kann ich nur jedem nahelegen, sich andere Linux-Distributionen anzusehen. Besser wird’s mit Canonical und Ubuntu nicht.

Firefox 98: Profile nicht abwaertskompatibel

Warnung: Firefox ändert mal wieder etwas an den Profilen, sprich mit Fx 98.0 candidate build 2 (die Final ist für 2022-03-08 avisiert) einmal gestartet, kann das Profil nicht wieder mit der derzeitigen Final 97.0.1 geladen werden.

Ein realistisches Szenario, da Fx 98.0cb2 Sites reproduzierbar crashen läßt, die aus einem Link in Thunderbird geladen werden.

Wer also diese Dev-Version testen will, vorher “~/.mozilla/” sichern!

Streams in vlc abspielen

Streams einer bekannten Videoplattform sind dafür vorgesehen, im Browser zu laufen. Um darüber hinausgehendes zu verhindern, werden ständig neue technische Rafinessen ersonnen (man denke nur an Fragmentierung des Videos, separate Audiospuren etc.).

vlc hat man bis vor geraumer Zeit durch Aufruf des Stream-URLs noch nutzen können. Derzeit stockt die Wiedergabe jedoch aller paar Sekunden – unbrauchbar. In Foren wird nach Lösungen gefragt. Tips, man solle doch smplayer nehmen (ohnehin nur ein Frontend für mplayer oder mpv), verkennen, daß dieser selbst derartige Streams gar nicht abrufen kann, sondern sich eines bekannten Zusatz-Tools bedient.

Ich betone, es soll ausschließlich um die Wiedergabe des temporär nur dafür im Cache gehaltenen Streams gehen. Also das, was ein Browser auch nur macht, aber ein Player technisch besser könnte, wenn ihm kein Bein gestellt wird (die Systembelastung ist merklich geringer, insbesondere unter Linux, dort haben Browser i.d.R. keine wirkliche Hardware-Beschleunigung).

vlc nutzt für Quellen entsprechende Playlists, eine Art Profile. Arch-based sind sie unter “/lib64/vlc/lua/playlist/” abgelegt, in debian-basierten Systemen unter “/usr/lib/x86_64-linux-gnu/vlc/lua/playlist/”. Default sind es .luac-Files. Es werden jedoch nicht nur Kompilate, also Binaries, erkannt, sondern auch .lua-Files.

Man benötigt keine neue vlc-Version (auch ein 4.0er nightly-snap soll nicht helfen), man kann das entsprechende .luac-File durch ein .lua-File (logscherweise raw) ersetzen.

In einer Arch-basierten Distribution ist das Problem damit behoben, ebenso in einer LFocal-VM (dort hat es bisher gar nicht abgespielt werden können), in einer Debian-testing-VM stockt es noch. Es sind unterschiedliche vlc-Versionen. Generell funktioniert es also – derzeit – wer es wirklich braucht (für mich ist es lediglich eine interessante technische Problemstellung gewesen), müßte in letzterem weitersuchen, bspw. Konfigurationen (VM, vlc,…) vergleichen.

LXQt: Shortcuts ohne Funktion

Wenn Tastenkombinationen keine Reaktion mehr zeigen, merkt man erstmal, wie sehr man selbst darauf baut. LXQt-Shortcuts funktionieren nicht mehr (wenn nicht mal über ctrl+alt+t ein Terminal gestartet werden kann, was ich hier ständig mache, ist das schon hart, hrr).

Sobald der Desktop aufgebaut ist, erscheint folgende Message:

lxqt-panel
Removable media/devices manager: Global shortcut 'X86Eject' cannot be registered

Ich untersuche das Problem seit Freitag (da ist es erstmals aufgetreten, testing ist in einer hier installierten arch-basierten Distribution prinzipiell aktiviert). Es ist irrelevant, welcher Window Manager genutzt wird (openbox, xfwm4). Zwischenzeitlich habe ich schon angenommen gehabt, ich hätte die Ursache gefunden bzw. zumindest einen Workaround.

lxqt-globalkeysd kann nicht gestartet werden. Dies kann man sehen unter:

LXQt Configuration Center → Session Settings → Basic Settings → Global Keyboard Shortcuts

An der Stelle kann man den Dienst starten, freilich überlebt dieser keinen Reboot oder Relogin.

Unter

LXQt Configuration Center → Autostart → Application Autostart → LXQt Autostart

habe ich “lxqt-globalkeysd” mit “Wait for system tray” als Workaround hinzugefügt. Hilft allerdings nicht zuverlässig. Im Moment funktioniert’s, was nicht daran liegen muß.

Zum Thema kann man fast nichts finden. Vor 5 Jahren ist das Fehlerbild schon mal aufgetreten (nicht bei mir, ich habe damals LXDE genutzt). Damals soll geholfen haben:

PCmanFM → Preferences → Volume → disable “Mount removable media automatically whe they are inserted” und disable “Show available options for removable media when they inserted”

Ist hier aber auch nicht einwandfrei reproduzierbar.

Thunderbird: Feeds ohne Zertifikat

Thunderbird in aktueller Version (derzeit 89.0b4) zieht keine RSS-Feeds von unsicheren URLs, also http ohne s, mehr. Möglicherweise kann man dies für eine Übergangszeit ähnlich wie in Fx über einen Eintrag in user.js rücksetzen, aber darum soll es hier nicht gehen (drin ist drin, gilt global und wird vergessen).

In erster Linie dürfte das Feeds betreffen, die man seit Jubeljahren bezieht. D.h., hier prüft man, ob Feeds nicht längst über https ziehbar sind. Das “s” im URL dazuschreiben, funktioniert nicht. Man entfernt den Feed (die Nachrichten bleiben erhalten) und fügt den Feed mit nun https hinzu.

Feeds ohne secure sollte es nun so langsam nicht mehr geben. Stimmt bei https aber das Zertifikat nicht, zieht Tb auch nichts.

feed subscriptions

Das Beispiel rglinuxtech.com ist nur über http erreichbar, aber Feeds gibt’s so eben nicht mehr. Über https funktioniert es nicht, da das eingebundene Zertifikat nicht darauf, sondern auf dessen Hoster pipeten.co.uk ausgestellt worden ist.

Über “Add Exception” gelangt man auf folgenden Requester:

Read more “Thunderbird: Feeds ohne Zertifikat”

VBox: stuttering in yt

VMs in VBox eignen sich für wirklich vieles, aber nicht gerade für yt. In Firefox (und wohl auch Chromium) starten Videos nicht wirklich, es wird scheinbar ewig gebuffert. Man muß mehrfach stoppen und starten, bis es weiter geht…ein wenig.

(Nicht nur) in diesen Browsern gibt es unter Linux keine Hardware-Unterstützung durch die GPU, geplant ist bislang auch nichts (nicht mal im closed source Chrome). D.h., das Rendering hat die CPU in Software zu übernehmen. In nativen Linux-Installationen macht sich das nicht bis kaum bemerkbar, so man nicht gerade eine Schippe Sand als CPU hat. In VBox-VMs allerdings eben schon, zumal die GPU-Treiber VBoxSVGA und VMSVGA dahingehend auch nicht die stärksten sind.

In altägyptischen Flash-Zeiten hat es mal den Workaround gegeben, per Rechtsklick (oder auch kleiner Konfigurationsdatei) im Video HW-Unterstützung zu deaktivieren, also das, was eh nicht da ist. Flash, ohnehin nie für Videos gedacht, ist aber tot (und nein, solchen Dreck installieren wir auch nicht, User ohne Plan aus einem bestimmtem Forum), mithin auch diese Einstellmöglichkeit.

Das problematische OpenGL in Hardware ausknipsen hilft bei diesem Fehlerbild auch nicht. Auch nicht, den Original-Firefox zu verwenden statt des Kompilats der jeweiligen Linux-Distribution (in debian gibt es gerade mal ein Problem, was so umgehbar ist). Alles bereits ausprobiert.

In Fx’ “about:config” gibt es mehrere Probanden, die zu testen wären. Ohne die Ursache zu kennen, ist das aber eher ein trial & error. Defaults eines frischen Profils bringen auch nichts.

Nun hat das Ganze früher mal ohne zu stottern funktioniert. Da es für mich aber keine Priorität hat (ja, das gibt es, User ohne Plan aus einem bestimmtem Forum), bin ich dem bislang nicht nachgegangen.

Um zum Punkt zu kommen, yt streamt in VP8/VP9. Eine Hardware-Unterstützung gibt es dafür bisher kaum, wohl aber für H.264. Als Linux- und OSS-Verfechter würde man natürlich lieber ein freies Format verwenden, an der Stelle muß man abwägen.

Allein Codecs installiert zu haben, genügt nicht. Dem Browser muß gesagt werden, daß er H.264 verwenden, d.h. von yt anfordern soll. Gibt’s sicherlich auch eine Möglichkeit unter “about:config”, denn etwas anderes wird das Fx-Add-on h264ify auch nicht verändern. Als Quickfix mag es genügen – und es funktioniert einwandfrei.

Btw., wenn man ein Add-on zum Ändern des User Agents installiert hat, kann man auch eine brauchbare Kombination aus OS und Browser ermitteln, dann wird H.264/mp4 gestreamt und man braucht nichts extra.

Firefox: Add-ons deaktiviert

Es ist mal wieder ein Weltuntergang. Jedenfalls, schenkt man manchen Usern Glauben, die da behaupten, ohne Add-ons sei Firefox nicht zu gebrauchen, also denen, die Fx mit ach so wichtigen Add-ons zukleistern. Seit heute Nacht werden in Fx automatisch Add-ons deaktiviert, weil bei mozilla.org Verantwortliche den Ablauf des entsprechenden Zertifikats verpennt haben.

Interessanterweise werden nicht sämtliche disabled, bspw. NoScriptdas ist ein unverzichtbares Add-on – läuft weiter. Wer also nicht sonstige installiert und aktiviert hat, merkt davon nichts. Installieren, auch manuell, wird freilich mit dem falschen Hinweis abgelehnt, das .xpi sei corrupt (auch NoScript).

Der Vorgang zeigt aber nicht nur die Verschlafenheit bzgl. Zertifikaten, sondern vor allem die Unfähigkeit und den Unwillen von Usern zur Recherche. Seit ~3:00 (!) gibt es einen Bugreport auf bugzilla.mozilla.org und seitdem bis jetzt, Nachmittag, 41 (!) Duplicates, also weitere (nunmehr geschlossene) Bugreports desselben Problems.

Bei mozilla.org hat man sich ob der Zahl fortwährender Postings leicht genervt gezeigt (discourse.mozilla.org ist offensichtlich seit Stunden permanent überlastet), aber zumindest gg. Mittag eine Interimlösung mit einem Zwischenzertifikat bereitgestellt.

Zum Zeitpunkt des Schreibens dieses Postings ist Fx 66.0.4 Candidate Build 1 angeboten, dann aber wieder entfernt worden, freilich ohnehin bloß für Redmond OS. Mittlerweile ist Directory Listing für download-installer.cdn.mozilla.net/pub/firefox/candidates/ disabled.

Solange hotfix-update-xpi-intermediate@mozilla.com-1.0.2-signed.xpi ziehbar ist (manuell in Fx zu installieren, allerdings nicht in den ESR-Versionen), ist das jedoch völlig ausreichend. Auch nur ein .xpi-File, das funktioniert aber. Und danach auch wieder installierte Add-ons sowie das Installieren von Add-ons.

Update 2019-05-05, 19:30: Mozilla hat Fx 66.0.4 mit einem Fix bereitgestellt (bei Erststart wird automatisch der eventuell zuvor im User-Profil unter extensions abgelegte intermediate-Fix gelöscht). Gefixte 60er ESR- und 67.0b-Versionen fehlen allerdings noch.

Update 2019-05-05, 21:00: Mittlerweile liegt auch 60.6.2esr vor.

Ubuntu: vaapi unter chromium entfernen

Man sollte wissen, was man installiert hat, erst recht als Linux-User.

Jener weiß es offensichtlich nicht. Er spricht von “google-chrome” in Version 71.0.3578.98 (schon der Zusatz 64 bit wäre überflüssig, da es Google Chrome für Linux seit langem nur noch für x86_64, also nicht x86_32, gibt).

Google Chrome ist längst weiter, schon die Abfrage unter siduction ergibt für chromium, die OSS-Variante, 72.0.3626.53-1. Dagegen ist genannte 71er derzeit genau die für chromium unter Ubuntu Xenial bis Disco.

Wir halten also fest, er hat chromium und nicht google-chrome installiert. Und jetzt müßte man sich auch mal richtig informieren, vor allem, wenn man Support geben will. pro-linux.de berichtet, daß ein längst bereitstehender, jedoch wegen möglicher Probleme bislang nicht freigeschalteter, Patch in chromium übernommen worden ist – in Fedora und Ubuntu. In letzterem ist es ein unsägliches Snap-Paket. In den chromium-Settings Hardware-Unterstützung deaktiviert zu haben, genügt dabei offenbar nicht.

Den proprietären Treiber nvidia (technisch besser als der freie nouveau, Kunststück bei Infos unter Verschluß, aber ständig inkompatibel zu bestimmten Kernel- und VBox-Versionen) nicht installieren, stattdessen nouveau nutzen wollen, kann ich verstehen (ich fahre auch nur noch nouveau nach ehedem langjährigem Support meinerseits für nvidia auf diesem Portal). Am besten, man kickt dieses unsägliche Snap und damit eben auch dieses Paket.

1
2
sudo apt purge snapd
sudo apt autoremove

Zudem kann man chromium mit Variablen starten.

2019-01-24, Nachtrag: Besagter Threadstarter, seit 11 Jahren dabei, sieht noch nicht mal, was er falsch macht, daß er unsauber arbeitet. Er schafft es auch nicht selbst aus diesem Chaos heraus. Aber Lamento gegen nvidia. Installationen und Reparaturen selbst verkorkster nvidia-Installationen habe ich hunderte Male erklärt (Suchmaschine → Hilfe zur Selbsthilfe). Das ist der Hauptgrund, weshalb ich mich dort nach langjährigem Support ausgeklinkt habe.