Category: arch_based

Citrix WorkSpace app: Zertifikate unter Linux

axt

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

axt

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.

Erste Arch- und EndeavourOS-Images nach der Migration auf Gitlab

axt

Nach der für User reibungslosen Migration der Arch-Linux-Repositories auf Gitlab vor zwei Wochen sind wie üblich zu jedem Monatsbeginn ein aktualisiertes Arch-Linux-Image und heute (Server-Date 2023-06-03) EndeavourOS Cassini Nova 03-2023 R2 mit den veränderten Paketquellen in “/etc/pacman.conf” erschienen.

Wer also z.B. eines neuen Rechners wegen jetzt neu installieren muß, hat genau das passende Image. :^)

Audio-Aussetzer beim Player-Start

axt

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

axt

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

axt

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

axt

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.

EndeavourOS: verwaistes Paket pcurses

axt

Beim Update in EndeavourOS und ggf. weiteren arch-basierten Distributionen erscheint folgende Ausgabe:

:: Searching AUR for updates...
 -> Orphaned AUR Packages:  pcurses

Bedeutet, das Paket pcurses ist verwaist. Es ist installiert, aber es ist nicht mehr im AUR enthalten. Es funktioniert, kann aber natürlich keine Updates mehr erhalten, mehr noch, das nicht mehr Vorhandensein kann sogar Installationen verhindern (EndeavourOS, wenn man die online-Installation aus dem Image heraus wählt, dort ist das Paket explizit im EndeavourOS-Teil unter “base packages” abzuwählen – es gibt bereits einen Fix des Scripts).

Klingt schlimmer, als es ist, zum Einen sind die Sources auf github.com das letzte Mal vor 4 Jahren angefaßt worden, da kommt eh nichts mehr (weshalb es dann wohl eben auch entfernt worden ist). Zum Anderen braucht man es nicht wirklich (sonst wäre es ja auch in den offiziellen Repositories und nicht im AUR gewesen). Also einfach deinstallieren:

1

yay -R pcurses

Hintergrund, was pcurses überhaupt ist, im Readme ist zu lesen:

“A curses frontend to libalpm.”

libalpm ist eine Package Management Library, die in erster Linie von pacman und damit auch dem Helper yay genutzt wird. pcurses ist eine textbasierte pseudografische Oberfläche im Terminal oder tty dazu (TUI, Text-based User Interface).

Wer ncurses kennt (pcurses ist ursprünglich ein Clone dessen), weiß, was das ist. Dem, der unter Ubuntu(-Flavours) oder Debian MS-TrueTypeFonts installiert hat, ist dies in simpler Form bei der altertümlich daherkommenden Lizenzabfrage begegnet (wo die Smartphone-Generation dann nicht weiß, daß es mit Tab weitergeht, und mit Click auf Close die Paketverwaltung aus dem Tritt bringt). Oder auch, wenn man eine Linux-Distribution nichtgrafisch installiert. Wie das früher normal gewesen ist. mc (midnight commander) nutzt ncurses ebenfalls.

Firefox 98: Profile nicht abwaertskompatibel

axt

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

axt

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 oder das aktuelle EndeavourOS booten 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.