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.

VBox-Kernel-Module bauen nicht mit Linux 6.4.10

Mit dem aktuellem Linux-Kernel 6.4.10 (2023-08-11) im Host können keine VirtualBox-Kernel-Module gebaut werden (Bugreport). Das betrifft sowohl 7.0.10-158379 (2023-07-13) als auch Testbuild 7.0.11-158681 (2023-08-04). Den Development Snapshot 7.0.97-158691 habe ich nicht getestet, da nur 7 h neuer als der Testbuild und damit ebenso zu alt.

Einstweilen Zurückgehen auf Kernel 6.4.9 – hier besteht das Problem noch nicht – wäre zwar eine Möglichkeit (aber keine für mich, Kernel ist Grundlage, so wichtig mir Virtualisierung auch ist).

Erste Linux-Distributionen, die VBox ausliefern, haben einen Patch eingepflegt, ganz vorn wie immer Arch Linux in die in den Arch-Repositories befindliche VBox-Version 7.0.10-2.

Wo dies noch nicht geschehen ist, z.B. in den .run-Versionen, kann man mit root-Rechten selbst editieren:

# sed -i 's/#if RTLNX_VER_MIN(6,5,0)/#if RTLNX_VER_MIN(6,4,0)/g' /usr/src/vboxhost-7.0.10/vboxnetflt/linux/VBoxNetFlt-linux.c
# /sbin/vboxconfig

Btw., man kann natürlich auch libvirt/VMM nutzen.

·

Update 2023-08-16: Im heutigem Testbuild VirtualBox-7.0.11-158813-Linux_amd64.run ist das Problem gefixt.

Audio-Aussetzer beim Player-Start

Beim Doppelklick auf ein Audio- oder Video-File startet der entsprechend eingestellte Player, z.B. vlc, dieser lädt das A/V-File und spielt es ab. Seit geraumer Zeit gibt es jedoch gleich zu Beginn eine Art Aussetzer, es scheint, als würde der Player stolpern.

Ursache ist das schlafen Legen der SPU, die da offensichtlich nicht mit dem Aufwecken von jetzt auf gleich klar kommt. Für das jeweilige Sound-Modul kann man dies abfragen, hier für snd_hda_intel:

$ cat /sys/module/snd_hda_intel/parameters/power_save

Ergibt dies erwartbar 1, ist der Sleep Mode aktiv. Man kann ihn deaktivieren, hier wieder für Intel:

$ echo "options snd_hda_intel power_save=0" | sudo tee -a /etc/modprobe.d/alsa-base.conf

VirtualBox 7.0.0 final

Nach 3 Betas und diesmal keinem Release Candidate ist die Final von VirtualBox 7.0.0 (akt. 7.0.8) erschienen. Hinzugefügt worden sind u.a. virtuelles Secure Boot, virtuelles TPM 1.2/2.0, und virtuelle IOMMU. Mit UEFI, vSB und vTPM ist nun auch Windows 11 ohne weitere Tricks in VMs möglich, sofern die anderen willkürlichen Anforderungen (Core i gen 8, 64 GiB vSSD/vHDD, 4 GiB RAM) erfüllt sind. Zudem ist der Wizard zur Erstellung von VMs überarbeitet worden.

Die Schritt-für-Schritt-Anleitungen

sind entsprechend aktualisiert.

Wer das Repository hinzugefügt hat, muß VBox 6.x deinstallieren und explizit 7.x installieren:

$ sudo apt purge virtualbox*
$ sudo apt install virtualbox-7.0

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.

Font-Darstellung in Java-Programmen

Da hat man nun seit Ewigkeiten diverse Verbesserungen der Darstellung von Schrift wie Hinting und Antialiasing, daß das Ganze nicht aussieht wie Bitmap-Fonts auf dem Amiga, dennoch wirken sie sich in Java-Programmen nicht aus, selbst, wenn es in diesen zusätzlich aktiviert werden kann und worden ist.

Ein Beispiel ist der bekannte TV-Browser. Wenigstens betrifft es nicht das Innere des Hauptfensters, also den Programminhalt der Sender, wohl aber den Kopf und auch “about”:

ohne Hinting

Es gibt jedoch Möglichkeiten, auch in Java-Programmen ein halbwegs anständiges Font-Rendering zu erhalten. Direkt verglichen:

mit Hinting

(Btw., falls jemand auf die Idee kommen sollte, nein, das hat absolut nichts mit beta zu tun.)

  • Möglichkeit auf Userebene:
    1
    
    $ nano ~/.xprofile

    Hinzufügen:

    Xft/Hinting 1
    Xft/HintStyle "hintslight"
    Xft/Antialias 1
    Xft/RGBA "rgb"
  • Möglichkeit auf Systemebene mit einem xsettings-Daemon:
    1
    
    # nano /etc/environment

    Hinzufügen:

    _JAVA_OPTIONS='-Dawt.useSystemAAFontSettings=setting'

    Für “setting” trägt man einen der folgenden Werte ein:

    off, false, defaultkein Antialiasing
    onvolles Antialiasing
    gaspin TTF integriertes Hinting
    lcd, lcd_hrgbAntialiasing für viele gebräuchliche LCDs
    lcd_hbgr, lcd_vrgb, lcd_vbgralternatives AA-Setting für LCDs

Relogin ist nötig. Ich selbst habe sowohl User als auch System getestet (kein Unterschied in der Ausgabe) und mich für den systemweiten Eintrag und gasp entschieden.

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!

Arch Linux 2022.01.01, Image in VBox nicht UEFI-faehig

Um in einer VBox-VM statt im CSM-Mode (Compatibility Support Module, das UEFI verhält sich, als sei es ein BIOS) im UEFI-Mode zu booten, ist lediglich im “VM VirtualBox Manager” unter System → Motherboard → Extended Features “Enable EFI (special OSes only)” zu aktivieren. Alternativ in einem Terminal:

1
vboxmanage modifyvm "VM name" --firmware efi

Selbstverständlich muß das zu bootende Image so oder hybrid erstellt worden sein (ein installiertes System sowieso). Das einfache Bootmenu von Arch Linux erscheint dann wie folgt:

Nicht so beim aktuellen Image archlinux-2022.01.01-x86_64.iso. Die Arch-Einträge fehlen, schlicht da das Image in VBox-VMs im UEFI-Mode nicht boot-fähig ist. Nativ soll es OK sein.

Man kommt nur in die EFI Shell oder das rudimentäre UEFI-Menu. Änderungstests in letzterem oder im VM-Manager sind erfolglos. Andere UEFI-fähige Distributions-Images, bspw. ein mit isorespin.sh angepaßtes Lubuntu bootet anstandslos, ebenso Arch-Images davor.

Ursächlich soll systemd 250.1-1 sein, es gibt einen Bugreport dazu bei archlinux.org. So es so ist, müßte dann, da Upstream, jedoch einer bei systemd erstellt werden.

Erhärtet wird es, da ein User ein Image mit systemd 249.x erstellt hat, das entsprechend boot-fähig ist. Jener bietet es zwar zum Download an, ein OS-Image von irgendjemandem verändert, so nett es gemeint ist, würde ich jedoch nicht verwenden.

Ebensogut könnte es ein Zusammenspiel mehrerer Faktoren, d.h. mit VBox sein, würde also (auch) dorthin gehören. Freilich nutze ich prinzipiell die jeweils aktuelle Version, sprich Testbuilds, derzeit 6.1.31 (das letzte ist knapp 4 Wochen alt, jetzt könnte so langsam mal wieder was kommen, manchmal gibt’s 3 Versionen pro Woche). In besagten Threads wird 6.1.30 final verwendet.

Wer jetzt Arch Linux in einer VBox-VM mit UEFI installieren will (mit CSM gibt es kein Problem), kann 2021.12.01 heranziehen – hat dann natürlich erheblich zu aktualisieren, was bei arch durch permanente Updates aber ohnehin der Fall ist – oder mit 2022.01.01 in der EFI Shell folgendes aufrufen:

1
FS1:\EFI\BOOT\BOOTx64.EFI

Das installierte System scheint keine UEFI-Boot-Probleme mit aktuellem systemd in VBox-VMs zu haben.

Update 1: Zwischenzeitlich ist upstream ein Bugreport für systemd erstellt worden.

Update 2: Der Commit boot: Fix readdir_harder() on VirtualBox für systemd ist 2022-01-10 Spätabend hinzugefügt worden, Arch Linux liefert systemd 250.2-2 damit in testing bereits aus. Das Februar-Image sollte dann dahingehend problemlos boot-fähig sein.

Update 2022-01-18: Die heutige (eigentlich vom 13.) Final VBox 6.1.32 löst zwar das Problem, Arch Linux 2022.01.01 zeigt im UEFI-Mode das vollständige Menu und kann folgerichtig booten. Jedoch bringt VBox 6.1.33-149396 das Problem zurück.

Update 2022-02-01: archlinux-2022.02.01-x86_64.iso funktioniert dahingehend korrekt.
FYI: Das wenige Stunden zuvor von testing nach extra gewanderte archinstall 2.3.1 ist enthalten.

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.