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.

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.

CUPS: Drucker nicht mehr angezeigt

Wenn seit etwa einer Woche (in Abhängigkeit, welche Distribution installiert ist, ob man in arch testing aktiviert und wann geupdatet hat) keine Drucker mehr als installiert angezeigt werden, fängt man nicht unlogisch an, die neu installieren zu wollen, auch cups nicht.

Mit CUPS als solchem liegt man jedoch nicht falsch, man checkt, ob der Service läuft:

1
2
3
4
5
6
$ systemctl status cups
● cups.service - CUPS Scheduler
     Loaded: loaded (/usr/lib/systemd/system/cups.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
TriggeredBy: ● cups.socket
       Docs: man:cupsd(8)

Also nicht, richtig vermutet. Kann man den Daemon mit

1
# systemctl start cups

starten, sprich funktioniert das Drucken wieder (aber nur für diese eine Session), weiß man schon mal, alles ist richtig installiert. Bis auf die Kleinigkeit, daß eben der Daemon nicht automatisch gestartet wird. Sieht man selbstverständlich bei Updates hin, sollte aufgefallen sein, daß sich kürzlich bzgl. cups etwas geändert hat. Man prüft in den Changes. Ab Zeile 190 “# rename the systems service files” wird man bestätigt, daß 5 Files “org.cups.cups*.*” in “/usr/lib/systemd/system/” umbenannt worden sind. Nun sollte man wissen, daß auf diese über Softlinks zugegriffen wird. Die zeigen aber auf nicht mehr existente Files.

Man sollte den Daemon nochmal stoppen, auch, um hernach gleich zu sehen, ob’s funktioniert hat:

1
# systemctl stop cups

Da man sauber arbeitet, löscht man zuerst die toten Links:

1
# systemctl disable org.cups.cupsd

Nun legt man die neuen Softlinks an:

1
# systemctl enable --now cups

Mit der Option “now” wird erreicht, daß das Gewünschte sofort aktiv ist, kein Reboot oder extra Start nötig.

Status-Check:

1
2
3
4
5
6
7
8
9
10
$ systemctl status cups
● cups.service - CUPS Scheduler
     Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2020-11-23 18:10:42 CET; 31s ago
TriggeredBy: ● cups.path
             ● cups.socket
       Docs: man:cupsd(8)
   Main PID: 859 (cupsd)
     Status: "Scheduler is running..."
(...)

Done.

VirtualBox: Installation ueber .run

Altägyptisch oder bleeding edge. Aktuelles Beispiel: In siduction wird anders als in sid Kernel 4.20 installiert (towo ist da glücklicherweise agil). Wer VirtualBox aus den debian-Repositories nutzt, bekommt bislang nur 5.2.22, das jedoch inkompatibel zu Kernel 4.20 ist.

VBox 6.0.0 ist kompatibel zu Kernel 4.20. Man kann zwar das VBox-Repo einbinden, daraus aber nur für debian stable und oldstable installieren, was im Normalfall unter sid(uction) wegen Dependencies fehlschlägt. Für Ubuntu gebaute Pakete in debian installieren ist auch nicht die gescheiteste Idee (auch wenn die für Bionic momentan laufen sollen).

Dann sollte man so flexibel sein und die .run-Files nutzen, statt wie ein User im siduction-Forum zu jammern, er wolle nur installieren, was “über apt oder dpkg” geht, und deshalb bei der letzten 4.19 bleiben (von der Paketverwaltung abgesehen, was er meint und womit er natürlich Recht hat, erntet er meinerseits dennoch Unverständnis, man fährt doch keine bleeding-edge-RRD, um ausgerechnet beim Kernel stehenzubleiben bzw. zurückzugehen). Fremdpakete aus Sicht der Distribution sind es so und so, aber in diesem Fall bzw. aus Sicht VBox’ sind sie das Original.

Das Ganze ist auch nicht schwieriger, mehr noch, man kann das so unter diversen Distributionen durchführen, bspw. unter siduction und antergos die jeweils selben .run-Files (braucht sie also auch nur 1x ziehen) und bis auf sudo vs. root-Terminal gleich. Zudem kann man Testbuilds nutzen, die ihrerseits ggf. Fixes ggü. dem letzten Release enthalten. Der einzige Nachteil ist lediglich, daß man sich selbst um neue Versionen kümmern muß (und das Interesse für derlei setze ich bei Usern, die bewußt brandaktuelle Distributionen fahren, voraus).

Ich selbst nutze seit längerem VirtualBox*.run unter (bis vor einiger Zeit noch Lubuntu,) siduction, antergos (die gemischte Groß-/Kleinschreibung für solche Namen ist übrigens kein ständiger Fehler meinerseits, falls das jemand annimmt, sondern jeweilige Eigenschreibweise). Insbesondere durch die nicht aufhörenden Probleme mit dem Lubuntu-Host seit Kernel 4.15 (nur dort, nicht in siduction und antergos, reproduzierbare Freezes unterschiedlicher VMs und das Suchen nach den Ursachen) haben mich das jeweils aktuelle Testbuild installieren lassen, mittlerweile mache ich das standardmäßig (nur nicht, wenn das Release gerade mal neuer ist) und fahre damit sehr gut. Natürlich weiß ich, was das bedeutet und kann damit umgehen.

.

Installation VirtualBox 7.0.14 über .run

  1. Ein ggf. installiertes Extension Pack deinstallieren:
    1
    
    sudo VBoxManage extpack uninstall "Oracle VM VirtualBox Extension Pack"
  2. Eine ggf. installierte VBox-deb-Version deinstallieren:
    1
    2
    
    killall -9 virtualbox 
    sudo apt purge virtualbox*
  3. Zum Kompilieren der Kernel-Module nötige Pakete installieren:
    1
    
    sudo apt install build-essential dkms linux-headers-$(uname -r)
  4. VirtualBox*.run ziehen:
    1
    2
    
    cd ~/Downloads/
    wget https://download.virtualbox.org/virtualbox/7.0.14/Oracle_VM_VirtualBox_Extension_Pack-7.0.14.vbox-extpack
  5. Aktuelle VBox-Version installieren:
    1
    
    sudo sh Virt*
  6. Weiter geht es in meinem Tutorial VirtualBox: Repository in Ubuntu hinzufügen mit Punkt 8, “Entsprechende Version des Extension Packs ziehen”.

Soll ein so installiertes VBox wieder deinstalliert werden, sollte zuerst wie oben geschrieben das Extension Pack deinstalliert werden, danach VBox selbst (das EP bliebe anderenfalls erhalten, aber nicht nutzbar):

1
sudo sh Virt* uninstall

.

Update 2024-01-16: Aktualisiert auf v7.0.14.
Update 2023-10-17: Aktualisiert auf v7.0.12.
Update 2023-07-18: Aktualisiert auf v7.0.10.
Update 2023-04-17: Aktualisiert auf v7.0.8.
Update 2023-01-17: Aktualisiert auf v7.0.6.
Update 2022-11-18: Aktualisiert auf v7.0.4.
Update 2022-10-19: Aktualisiert auf v7.0.2.
Update 2022-10-10: Aktualisiert auf v7.0.0, VBox-6.x-Schiene entfernt.
Update 2022-09-29: VBox-7.0-Schiene hinzugefügt.
Update 2022-09-01: Aktualisiert auf v6.1.38.
Update 2022-07-20: Aktualisiert auf v6.1.36.
Update 2022-04-19: Aktualisiert auf v6.1.34.
Update 2022-01-18: Aktualisiert auf v6.1.32.
Update 2021-11-22: Aktualisiert auf v6.1.30.
Update 2021-10-19: Aktualisiert auf v6.1.28.
Update 2021-07-28: Aktualisiert auf v6.1.26.
Update 2021-07-20: Aktualisiert auf v6.1.24.
Update 2021-04-29: Aktualisiert auf v6.1.22.
Update 2021-04-20: Aktualisiert auf v6.1.20.
Update 2021-01-19: Aktualisiert auf v6.1.18.
Update 2020-10-20: Aktualisiert auf v6.1.16.
Update 2020-09-04: Aktualisiert auf v6.1.14.
Update 2020-07-14: Aktualisiert auf v6.1.12.
Update 2020-06-05: Aktualisiert auf v6.1.10.
Update 2020-05-14: Aktualisiert auf v6.1.8.
Update 2020-04-09: Aktualisiert auf v6.1.6.
Update 2020-02-20: Aktualisiert auf v6.1.4.
Update 2020-01-15: Aktualisiert auf v6.1.2.
Update 2019-12-11: Aktualisiert auf v6.1.0.
Update 2019-10-15: Aktualisiert auf v6.0.14.
Update 2019-09-03: Aktualisiert auf v6.0.12.
Update 2019-07-16: Aktualisiert auf v6.0.10.
Update 2019-05-14: Aktualisiert auf v6.0.8.
Update 2019-04-16: Aktualisiert auf v6.0.6.
Update 2019-01-28: Aktualisiert auf v6.0.4.
Update 2019-01-15: Aktualisiert auf v6.0.2.

Lubuntu 17.10: 80 % Blackscreen mit Intel-IGP

Auf Rechnern mit altägyptischen Intel-IGPs wie GMA 945/950 in Netbooks mit Atom 270/280 gibt es unter Lubuntu Artful, logischerweise 32 bit, seit geraumer Zeit das Problem, daß nur ein vertikaler Streifen am rechten Rand Bild zeigt, 80 % dagegen sind schlicht schwarz. Da man zur Ursachenfindung offenbar noch Zeit braucht, hier der als funktionierend allgemein bestätigte Workaround. Um ihn durchführen zu können, kann man beispielsweise das System kurz in Standby schicken und wiederholen (an sich schon ein halber, jedoch unschöner Workaround).

  1. Starte den Editor mit root-Rechten:
    1
    
    sudo -H leafpad /etc/default/grub
  2. Füge folgende Zeile hinzu bzw. ersetze die möglicherweise vorhandene:
    GRUB_GFXPAYLOAD_LINUX=text
  3. Aktualisiere grub:
    1
    
    sudo update-grub
  4. Reboote:
    1
    
    sudo reboot

Mit der Option text wird auf Werte aus einer Blacklist für problematische GPUs zugegriffen.

Artful-Kernel in Zesty und Xenial

Man kann sich’s zwar auch selbst aus meinen früheren Blogposts (6, 5, 4, 3, 2, 1) schmieden, aber der Einfachheit halber und zum direkten Verlinken als aktualisierter Post:

Artful-Kernels können in Zesty (und Xenial) installiert werden.

Führe über copy & paste in einem Terminal aus (Achtung, erst bis zum Schluß lesen):

1
2
3
4
sudo bash -c "echo 'deb http://archive.ubuntu.com/ubuntu/ artful main' >> /etc/apt/sources.list.d/artful.list"
sudo bash -c "echo -e 'Package: *\nPin: release a=artful\nPin-Priority: 100\n' >> /etc/apt/preferences.d/artful.pref"
sudo apt-get update
sudo apt-get install -t artful linux-image-generic linux-generic linux-headers-generic linux-libc-dev

Direkt vor dem Distupgrade auf Artful (Final Release 2017-10-19) führe aus:

1
2
sudo rm /etc/apt/sources.list.d/artful.list
sudo rm /etc/apt/preferences.d/artful.pref

Die freien GPU-Treiber intel, nouveau und radeon sowie vboxvideo (VBox 5.1.26, VBox 5.2.0b2) kommen mit derzeit Kernel 4.12 klar (Vanilla- und Ubuntu-Mainline-Kernel 4.13 Final werden für 2017-09-03 erwartet, in Artful soll letztendlich 4.13 einfließen), nicht jedoch der proprietäre Treiber aus den Ubuntu-Paketquellen nvidia für bis inkl. Zesty. Daher ist zuerst der jeweils aktuelle nvidia-304 (GF 6 und 7), nvidia-340 (GF 8 – GF 300) bzw. nvidia-375 (GF 400 und höher) für Artful aus den Ubuntu-Repositories zu installieren.

Login ohne grafische Oberflaeche

Hat man ein System mit XServer, Desktop Environment und Display Manager installiert, will man jedoch default oder temporär ohne GUI starten, hat man früher die nichtdokumentierte Bootoption “text” setzen können. Seit Umstellung auf systemd zeigt diese (dafür) jedoch keine Wirkung mehr. Hier kann man das über eine systemd.unit erreichen, zumindest permanent.

Status-Abfrage:

1
systemctl status multi-user.target

Falls nicht aktiviert:

1
sudo systemctl enable multi-user.target

Setzen als Standard:

1
sudo systemctl set-default multi-user.target

Von hier aus kann man nun, falls gewünscht, den DM starten mit beispielsweise:

1
sudo service lightdm start

Soll wieder default grafisch eingeloggt werden:

1
sudo systemctl set-default graphical.target

Installation Samsung Unified Linux Driver

Starte mit [ctrl] + [alt] + [t] ein Terminal und führe Zeile für Zeile über copy & paste komplett aus:

  1. Starte die Printerconfig:
    1
    
    system-config-printer
  2. Entferne den möglicherweise bereits falsch installierten Samsung!
  3. Schließe die Printerconfig!
  4. Ziehe den Samsung über USB/LAN ab!
  5. Erstelle das Downloadverzeichnis und wechsele dorthin:
    1
    
    mkdir -p ~/Downloads/samsung/uld/ && cd ~/Downloads/samsung/uld/
  6. Ziehe das Treiberarchiv:
    1
    
    wget https://ftp.hp.com/pub/softlib/software13/printers/MFP170/uld-hp_V1.00.39.12_00.15.tar.gz -O uld-hp_V1.00.39.12_00.15.tar.gz

    Hinweis: 2017-11 hat HP Inc. Samsungs Druckersparte übernommen, daher sind Treiber unter deren Domain zu finden.

  7. Entpacke das Treiberarchiv:
    1
    
    tar -xzvf uld-hp_V1.00.39.12_00.15.tar.gz
  8. Installiere die Treiber:
    1
    
    sudo uld/install.sh
  9. Schließe den Samsung über USB oder (W)LAN an!
  10. Starte die Printerconfig:
    1
    
    system-config-printer
  11. Laß den Samsung-Drucker an USB bzw. als Netzwerkdrucker erkennen und wähle den eben installierten Treiber aus!
  12. Gehe die Konfiguration durch! Möglich ist auch die Konfiguration über Browser http://localhost:631/printers (localhost temporär in NoScript zulassen, falls installiert).

Soll(en) der/die ULD wieder deinstalliert werden:

1
sudo uld/uninstall.sh

Die Treiber, nicht Drucker entfernt, versteht sich.

Installation Dell Unified Linux Driver

(Modelle: 1130, 1130n, 1133, 1135n, 1815, 2145cn, 2335dn, 2355dn, 5330, B1160, B1160w, B1165nfw, B1260dn, B1265dfw, B1265dnf, B2365dnf)

Starte mit [ctrl] + [alt] + [t] ein Terminal und führe Zeile für Zeile über copy & paste komplett aus:

  1. Starte die Printerconfig:
    1
    
    system-config-printer
  2. Entferne den möglicherweise bereits falsch installierten Dell!
  3. Schließe die Printerkonfig!
  4. Erstelle das Downloadverzeichnis und wechsele dorthin:
    1
    2
    
    mkdir -p ~/Downloads/dell_unidrv/
    cd ~/Downloads/dell_unidrv/
  5. Ziehe das Treiberarchiv:
    1
    
    wget http://downloads.dell.com/FOLDER01513124M/1/B1160w_Linux_v1.04_Driver.tar.gz -O B1160w_Linux_v1.04_Driver.tar.gz
  6. Entpacke das Treiberarchiv:
    1
    
    tar -xzvf B1160w_Linux_v1.04_Driver.tar.gz
  7. Installiere die Treiber:
    1
    
    cdroot/autorun
  8. Innerhalb der folgenden grafischen Installation kann der Drucker bzw. dessen Anschluß gewählt werden. Über den “Unified Driver Configurator” (recht unverschämt in einer eigenen Menu-Gruppe “DELL Unified Driver”) kann dies auch später durchgegangen oder geändert werden.

Alternativ zur nicht paketverwaltungskonformen Installation kann man sich das jeweilige .ppd-File auch aus dem entpackten Archiv unter “cdroot/Linux/noarch/at_opt/share/ppd/” holen und über

1
system-config-printer

installieren.

kernel-remover in Ubuntu

siduction kernel-remover

Ältere bzw. nicht mehr benötigte Kernels werden unter Ubuntu nicht automatisch deinstalliert (was seine Richtigkeit hat). Ewig und 3 Tage hat es gedauert, bis durch ein “apt-get autoremove” dies (für Linux-Beginners, denen sonst /boot auf separater Partition vollläuft) mit berücksichtigt worden ist, wobei nur “alles oder nichts” möglich ist (selbstverständlich kann man das immer in einem Terminal oder in Synaptic bewerkstelligen).

Andere Distributionen können das besser. In siduction kann man das kleine Tool kernel-remover laufen lassen. Der Aufbau der Kernel-Pakete von debian sid und Ubuntu unterscheidet sich, weshalb es interessant gewesen ist, kernel-remover einfach mal in einer Lubuntu-Trusty-VM auszuprobieren (für derlei hat man sowas ja). Dazu habe ich extra unterschiedliche Kernels wie einen Mainline-Kernel (die ich sonst nicht verwende) und unterschiedliche Dev-Versions aus Wily installiert.

Read more “kernel-remover in Ubuntu”