Artikel mit Tag lösung

[Lösung] Flameshot unter Ubuntu 22.04 LTS defekt

In der Vergangenheit hatte ich Flameshot als Screenshot Tool vorgestellt. Leider sorgt Flameshot, beziehungsweise Screenshottools im Allgemeinen für Verwirrungen bei Ubuntu 22.04 Nutzern.
Ubuntu 22.04.1 LTS (Jammy Jellyfish) wurde bereits im August 2022 veröffentlicht. Der neue Ubuntu Desktop auf Basis von Gnome Shell 42 sieht mit dem Yaru Theme zwar schick aus, mag aber nicht mehr so richtig mit Flameshot zusammenarbeiten.

Das Problem

Flameshot startet, bietet aber auf den ersten Blick keine Möglichkeit eine Auswahl für den Screenshot zu treffen, bzw. blendet überhaupt keine Auswahlliste ein.

Das Problem ist hier nicht Flameshot selbst, sondern Gnome ab Version 41. Dieses Verhalten betrifft alle dritten Screenshot Tools. Dieser neue Weg war eine aktive Entscheidung der Entwickler und wurde bereits vor einiger Zeit beschrieben, siehe:

  •     https://github.com/flameshot-org/flameshot/issues/2186
  •     https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970
  •     https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4895
  •     https://github.com/flatpak/xdg-desktop-portal/issues/649


Es gab bereits viel Diskussionen dazu, daher lest euch gerne die verlinkten Kommentare durch, sollte es euch interessieren.

Flameshot hat inzwischen eine eigene Hilfeseite dazu geschaltet, da relativ häufig Fragen dazu kommen.
 

gnome_share_permission_window

Die Lösung

Wie lässt sich Flameshot ab Ubuntu 22.4 LTS bzw. Gnome 41 weiterhin mit dem üblichen Auswahlmenü verwenden?

  1. Die simpelste Lösung ist, einfach auf den Share Button zu drücken (siehe Screenshot), danach öffnet sich das bekannte Auswahlmenü.
  2. Eine weitere Lösung wäre, in den Einstellungen Wayland zu deaktivieren. Passt dazu die Konfiguration an:
    sudo nano /etc/gdm3/custom.conf
    WaylandEnable=false
    sudo systemctl restart gdm3
  3. Nutzt das Gnome eigene Screenshot Programm, damit habt ihr leider nicht mehr so viel Funktionen, dafür aber auch weniger Klickarbeit.

Lösung: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead

Was ist apt-key?

Die Man Pages beschreiben apt-key wie folgt:

apt-key is used to manage the list of keys used by apt to authenticate packages. Packages which have been authenticated using these keys will be considered trusted.

apt-key wird verwendet, um die Liste der Schlüssel zu verwalten, die von apt zur Authentifizierung von Paketen verwendet werden. Pakete, die mit diesen Schlüsseln authentifiziert wurden, werden als vertrauenswürdig eingestuft.

Der Vollständigkeit halber hier der Punkt zur "deprecated" Meldung:

update (deprecated)
Update the local keyring with the archive keyring and remove from the local keyring the archive keys which are no longer valid. The archive keyring is shipped in the archive-keyring package of your distribution, e.g. the ubuntu-keyring package in Ubuntu.

Note that a distribution does not need to and in fact should not use this command any longer and instead ship keyring files in the /etc/apt/trusted.gpg.d/ directory directly as this avoids a dependency on gnupg and it is easier to manage keys by simply adding and removing files for maintainers and users alike.

Was bedeutet apt-key is deprecated?

In der Fehlermeldung "apt-key is deprecated. Manage keyring files in trusted.gpg.d" sind zwei Meldungen versteckt:

Bisher wurden Schlüssel in trusted.gpg verwaltet. In Zukunft sollten die Schlüssel einzeln unter trusted.gpg.d verwaltet werden. Der Grund für das Abschaffen des alten Vorgangs ist die schlicht die Sicherheit.

Zusätzlich wird apt-key als veraltet eingestuft. Da es sich hier nur um eine Warnung handelt, kann diese bis jetzt auch einfach ignoriert werden. Im Prinzip möchte sie den Nutzer weg von apt-key hin zu gpg schubsen und genau das möchte ich hier zeigen.

Bei einem apt update wirft ein Ubuntu beispielsweise folgenden Warnungen in Bezug auf nodejs und yarn Repositorys

reading package lists... Done
W: https://deb.nodesource.com/node_16.x/dists/jammy/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
W: https://dl.yarnpkg.com/debian/dists/stable/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

Lösung -  Schlüssel aus trusted.gpg in trusted.gpg.d umziehen

Die Lösung für die oben aufgeführte Problematik ist das bereits erwähnte Umschichten von trusted.gpg zu trusted.gpg.d.

Zunächst werden die betreffenden Schlüssel aufgelistet:

sudo apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg
--------------------
pub   rsa4096 2014-06-13 [SC]
      9FD3 B784 BC1C 6FC3 1A8A  0A1C 1655 A0AB 6857 6280
uid           [ unknown] NodeSource <gpg@nodesource.com>
sub   rsa4096 2014-06-13 [E]

pub   rsa4096 2016-10-05 [SC]
      72EC F46A 56B4 AD39 C907  BBB7 1646 B01B 86E5 0310
uid           [ unknown] Yarn Packaging <yarn@dan.cx>
sub   rsa4096 2016-10-05 [E]
sub   rsa4096 2019-01-02 [S] [expires: 2023-01-24]
sub   rsa4096 2019-01-11 [S] [expires: 2023-01-24]


Schlüssel in eine eigene Datei verschieben

Danach die letzten 8 Zeichen der zweiten Zeile unter pub kopieren. In diesem Fall ist das 6857 6280. Das Leerzeichen zwischen den Zahlen muss entfernt werden.
Der zukünftige Name kann beliebig gewählt werden, es liegt allerdings nahe, ihn nach dem installierten Paket bzw. Repository zu benennen:

sudo apt-key export 68576280 | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/nodejs-key.gpg
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

sudo apt-key export 86E50310 | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/yarn-key.gpg
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

sudo apt-get update

Nun sollten die Warnungen der Vergangenheit angehören.

Neue Schlüssel hinzufügen

Sollte ein neuer Schlüssel hinzugefügt werden, wird in Zukunft nicht mehr mit apt-key gearbeitet, sondern gpg verwendet werden.

Früher

curl -sS https://download.spotify.com/debian/pubkey_5E3C45D7B312C643.gpg | sudo apt-key add -


Heute

curl -sS https://download.spotify.com/debian/pubkey_7A3A762FAFD4A51F.gpg | sudo gpg --dearmor --yes -o /etc/apt/trusted.gpg.d/spotify.gpg

 

Was bedeutet: WARNING apt does not have a stable CLI interface. Use with caution in scripts?

Beim Ausführen von Skripten auf einer Linux Konsole, die apt install beinhalten, taucht folgende Meldung auf: 

WARNING : apt does not have a stable CLI interface. Use with caution in scripts.

Doch warum wird eine Warnung angezeigt? Die Lösung ist relativ simpel.

Vor Jahren hatte ich mal eine Übersicht von apt vs. apt-get veröffentlicht. Ich habe sie euch unten noch einmal eingebunden.
Im Artikel ist zu lesen, dass apt unter anderem einen grafischen Fortschrittsbalken ausgibt.

Genau das ist einer der Gründe, warum das Kommandozeilentool bei der Verwendung in Scripten ein WARNING meldet. Denn diese Fortschritts-Ausgabe kann von Scripten fehlerhaft interpretiert werden und ist im Prinzip nur für Endnutzer gemacht, aber nicht wirklich für Skripte. Darum sollte hier eher auf apt-get zurückgegriffen werden.

Gleiches gilt übrigens auch für apt show programm-name. Hier sollte besser apt-cache show programm-name verwendet werden.

apt vs. apt-get
apt Kommando apt-get Kommando Funktion
apt install apt-get install Pakete installieren
apt remove apt-get remove Pakete deinstallieren
apt list --upgradable -- Anstehende Updates anzeigen
apt list dpkg list Pakete auflisten
apt purge apt-get purge Pakete und Konfiguration entfernen
apt update apt-get update Repository aktualisieren
apt upgrade apt-get upgrade Anstehende Pakete aktualisieren
apt full-upgrade apt-get dist-upgrade Anstehende Pakete aktualisieren und deinstallieren
apt autoremove apt-get autoremove Nicht benötigte Pakete deinstallieren
apt search apt-cache search Pakete suchen
apt show apt-cache show Paketdetails anzeigen
apt edit-sources -- sources.list editieren

Kali Linux mit Desktop unter Windows über WSL2 installieren

WSL2, besser bekannt als Windows Subsystem Linux erlaubt es verschiedene Linux Distributionen unter Windows zu installieren. Normalerweise werden diese Installationen über die Kommandozeile bedient. Seit einiger Zeit unterstützt Kali Linux Win-KeX, was es erlaubt auf dem System wie auf einem Desktop zu arbeiten.
Win-Kex tut dies, indem es einen VNCServer mit der Xfce-Desktop-Umgebung innerhalb der Kali Linux WSL-Instanz startet. Danach startet ein TigerVNC-Windows-Client und übergibt automatisch die Befehle zur Verbindung mit dem VNC-Server.
Soweit so schön, bei der Installation gibt es dennoch einige Fallstricke.

Installation WSL2

Zunächst wird eine WSL2 Installation unter Windows benötigt.

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
wsl --set-default-version 2

Installation und Update von Kali Linux via WSL

wsl –-install -d kali-linux

Nach der Vergabe des Benutzernamens und eines Passworts sollte das System stehen.

Nun tauchen allerdings die ersten Probleme auf. Denn eine apt update zeigt zunächst einen Keyring Fehler an, dieser kann einfach nachinstalliert werden.

wget --no-check-certificate -O kali-archive-keyring_2022.1_all.deb https://http.kali.org/pool/main/k/kali-archive-keyring/kali-archive-keyring_2022.1_all.deb

dpkg -i  kali-archive-keyring_2022.1_all.deb

sudo apt update

Beim kommenden Upgrade Vorgang (sudo apt upgrade) treten die nächsten Probleme auf.

Setting up libc6:amd64  ...
Checking for services that may need to be restarted...
Checking init scripts...
Nothing to restart.
sleep: cannot read realtime clock: Invalid argument
dpkg: error processing package libc6:amd64 (--configure):
 installed libc6:amd64 package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 libc6:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Dieses Problem führt dazu, dass der Upgrade-Vorgang abbricht und ein sudo mit dem zuvor eingerichteten User ab sofort scheitert.

Sorry, try again.
Sorry, try again.
sudo: 3 incorrect password attempts

Die Lösung für dieses Problem ist ein manuelles Installieren von libcrypt1.

apt -y download libcrypt1
dpkg-deb -x libcrypt1_1%3a4.4.28-2_amd64.deb .
cp -av lib/x86_64-linux-gnu/* /lib/x86_64-linux-gnu/
apt -y --fix-broken install
apt upgrade

Nun sollte das System aktuell sein und stabil laufen. Im letzten Schritt wird jetzt Win-Kex installiert.

kali

Win-Kex installieren

Dieser Schritt ist denkbar einfach.

sudo apt install -y kali-win-kex

Jetzt kann Win-Kex gestartet werden, achtet darauf, dass es mit sudo Rechten gestartet wird.

sudo kex --win

#Session wiederaufnehmen

sudo kex --win --start-client

Die wichtigste Taste dürfte F8 sein. Damit kann das Kontextmenü nach dem Start geladen werden, um zum Beispiel zwischen Vollbild und Fenstermodus zu wechseln.
Sollte es zu Verbindungsproblemen beim Start und Verbinden des VNC Servers kommen, kontrolliert eure Firewall Einstellungen.

Seit Kali 2022.2 wird Kin-Kex unterstützt, welches das Ausführen von Anwendungen mit sudo Rechten erlaubt.

vnc

Fazit


Es ist möglich, Kali unter Windows mit WSL2 zu installieren. Der Weg dahin ist aber weiterhin etwas steinig und wird Windows Nutzern sicher nicht leicht von der Hand gehen. Da bietet sich wohl weiterhin ein VirtualBox Image an, denn damit ist die Installation um einiges flüssiger.

 

Nagios - Icinga: Debian Bullseye check_interfaces schlägt fehl

icinga-logo

Ein kurzer Tipp fürs Interface Monitoring mit Icinga oder Nagios unter Debian.

Nach einem Update auf Debian Bullseye kann es vorkommen, dass einige Check Plugins fehlschlagen. So geschehen mit check_interfaces.

Das Plugin bringt nur noch folgende Ausgabe:

Plugin-Ausgabe
/usr/lib/nagios/plugins/check_interfaces: error while loading shared libraries: libnetsnmp.so.30: cannot open shared object file: No such file or directory

Zunächst kann man natürlich versuchen, die nötigen Dateien auf anderen Systemen zu suchen oder das Paket libsnmp40 zu installieren, leider bringt dies unnötige Arbeit, bzw. keine Abhilfe.

Die Lösung ist ein einfaches neu builden des Plugins:

debian_bullseye

apt-get update
apt-get -y install git build-essential libsnmp-dev

wget https://github.com/NETWAYS/check_interfaces/archive/refs/tags/v1.4.tar.gz

tar xvf v1.4.tar.gz

cd check_interfaces-1.4/

./configure --libexecdir=/usr/lib/nagios/plugins

make
make install

Der Zielpfad kann natürlich je nach Check Plugin Verzeichnis angepasst werden. Nach dem erneuten Builden unter Debian Bullseye sollte das Plugin wieder ohne Probleme funktionieren.