Category: clients

Citrix Workspace app mit webkit2gtk-4.1

axt 
$ yay -Q icaclient  webkit2gtk-4.1  webkit2gtk
icaclient 26.04.0.73-1
webkit2gtk-4.1 2.52.4-1
error: package 'webkit2gtk' was not found
$

Na, endlich!

Das kann man mit Fug und Recht sagen, zählt doch Citrix Systems Inc. zu den IT-Firmen, die extrem lange brauchen, um Veränderungen um sie herum wahrzunehmen. Ihre Citrix-Clients sind bekanntlich ein einziges Trauerspiel, nicht nur, aber besonders unter Linux. So hat man lange, sehr lange, in .deb-Pakete ein rudimentäres wine und Windows-Software gepackt (wie damals auch die Teamviewer AG mit deren Client). Dann hat man etliche Jahre nicht mitbekommen, daß es nicht nur x64 gibt, sondern Standard von Linux-Distributionen geworden ist (z.B. bei Ubuntu mit 12.10). Man hat also noch eine rudimentäre 32-bit-Umgebung mitinstallieren oder basteln müssen. Alles etliche Jahre her.

Geändert am Gesamtbild hat sich aber nichts. So verspricht Citrix Systems seit langem, die CWSpA für Linux auf GCC 11 basieren zu lassen. Hint: aktuell ist 16.1.

Dieses Aufschieben ist aber nicht das Schlimmste. icaclient (die Pakete heißen weiter so, obwohl es nicht diese Software vor einem reichlichem Jahrzehnt ist) hat als Abhängigkeit nach wie vor das längst abgelöste webkit2gtk. Nur in Debian oldstable und oldoldstable (!) und Ubuntu 22.04 sind das Paket und dessen Abhängigkeiten noch zu finden. Sowas setzt auf dem Desktop doch keiner mit klarem Verstand ein.

webkit2gtk ist eine harte Abhängigkeit, irgendwas zu tricksen, hilft nicht, Softlinks vom aktuellen webkit2gtk-4.1, z.B. Bei Closed Source kann man da auch nichts machen. Man kann nur die “Lightversion” (Citrix scheint das absichtlich äußerst unscheinbar auf der Auswahlseite bei Erstaufruf zu schreiben) nutzen, also im Browser (immerhin funktioniert da seit geraumer Zeit Vollbild, man hat also keine Einbußen mehr durch den Browser-Rand).

Derzeit aktuell ist CWSpA 2601 for Linux, es gibt die 2604 Technology Preview. Es sieht nicht danach aus, als würde sich fundamental etwas ändern. Gleicher Trott…doch, halt:

Citrix Workspace app for Linux 2604 with GCC 11 – Technical Preview liegt zusätzlich zum Testen bereit. Aufgeblähte Citrix-Software läßt schon genug graue Haare wachsen, als daß jemand noch deren Betatester spielen wollte. Aber vielleicht hat man doch mitbekommen, daß sich da vor Jahren etwas bei webkit2gtk getan hat…

Das Subject verrät’s bereits, ja, mit dieser Preview ist Citrix Workspace App auf webkit2gtk-4.1 gewechselt.

Ich habe wie üblich ein bestimmtes pkgbuild aus dem AUR und das .tar.gz-Archiv gezogen. Das pkgbuild habe ich mit Trial & Error angepaßt (wie gesagt, CS, kann man nur raten) und ein funktionierendes .zst für Arch Linux erstellt. Installation, Programm, Connect. Selbstredend alles in einer eigens dafür vorgehaltenen VM (solches CS-Zeug kommt mir keinesfalls in meinen Arch-Host).

Ich gehe davon aus, in den ziehbaren .deb- und .rpm-Versionen für entsprechende Distributionen hat man ebenfalls gewechselt (die Arbeit wird man sich sicher nicht einzeln machen wollen).

Nun bleibt nur noch zu hoffen, daß man diesen Zweig zum Standard erklärt. Wieso man erst noch eine Preview für den alten zusammenzimmert, weiß man wohl nur in Fort Lauderdale.

·

Zu beachten weiterhin:

Citrix WorkSpace app: Zertifikate unter Linux

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.

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.

Firefox snap durch deb ersetzen

axt

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).

  3. 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
  4. 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

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!

Streams in vlc abspielen

axt

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

axt

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

axt

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

axt

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

axt

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. NoScript – das 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.