Kategorien
Anwendungen

Virtualisierung unter Debian

Wird auf Windows-Clients oft VirtualBox als Desktop-Virtualisierungslösung eigesetzt, stellt man nach dem Wechsel auf Debian fest, daß VirtualBox seit Buster nicht mehr in den Paketquellen enthalten ist.

Das Debian-Wiki empfieht als Ersatzlösung das auf QEMU/KVM basierende Paket virt-manager, welches in den „normalen“ Paketquellen enthalten ist und somit einfach installiert werden kann:

$ sudo apt install virt-manager

Nach dem ersten Aufruf poppt erst einmal ein Fenster „System policy prevents management of local virtualized systems“ zur Eingabe des Kennwortes hoch. Wer dies vermeiden möchte, kann seinen Benutzer der Gruppe „libvirt“ hinzufügen:

$ sudo usermod -aG libvirt $(whoami)

Anschließend kann nun eine virtuelle Maschine aufgesetzt (und verwendet) werden.

Netzwerkbrücke

Je nach Anwendungsszenario stellt man sehr schnell fest, daß zwar die virtuelle Maschine ohne Probleme überall ins Netz kommunizieren kann, eine Kommunikation vom Host zur virtuellen Maschine hingegen nicht möglich ist.

Um dies zu ermöglichen, muß eine virtuelle Netzwerkbrücke eingerichtet werden. Hierzu schlagen die meisten per Suchmaschinen auffindbaren Lösungsmöglichkeiten vor, den Netzwork-Manager zu deaktivieren und die Konfiguration der Netzwerkinterfaces komplett von Hand zu übernehmen, aber es funktioniert auch mittels Network-Manager, und das sogar recht einfach und elegant.

Zuerst einmal gilt es, die aktuelle Netzwerkverbindung sowie das verwendete Interface auszulesen

$ sudo nmcli connection show
NAME                         UUID                                  TYPE      DEVICE 
Kabelgebundene Verbindung 1  4e405dd1-dc75-3990-bfd1-fdb013e95f18  ethernet  ens192

in diesem Fall sind es „Kabelgebundene Verbindung 1“ und „ens192“.

Nun wird dem System die Netzwerkbrücke hinzugefügt

$ sudo nmcli connection add type bridge ifname br0 stp no
Verbindung »bridge-br0« (e7a07a8f-beac-4ffe-adcf-47d406a82177) erfolgreich hinzugefügt.

$ sudo nmcli connection show
NAME                         UUID                                  TYPE      DEVICE 
Kabelgebundene Verbindung 1  4e405dd1-dc75-3990-bfd1-fdb013e95f18  ethernet  ens192 
bridge-br0                   e7a07a8f-beac-4ffe-adcf-47d406a82177  bridge    br0

und die Netzwerkschnittstelle als Slave der Brücke zugewiesen

$ sudo nmcli connection add type bridge-slave ifname ens192 master br0
Verbindung »bridge-slave-ens192« (e4a63a0d-4e1b-4a82-b1af-bdc9aecaf593) erfolgreich hinzugefügt.

$ sudo nmcli connection show
NAME                         UUID                                  TYPE      DEVICE 
Kabelgebundene Verbindung 1  4e405dd1-dc75-3990-bfd1-fdb013e95f18  ethernet  ens192 
bridge-br0                   e7a07a8f-beac-4ffe-adcf-47d406a82177  bridge    br0    
bridge-slave-ens192          e4a63a0d-4e1b-4a82-b1af-bdc9aecaf593  ethernet  -- 

Als letzter Schritt wird dann die Brücke aktiviert

$ sudo nmcli connection up bridge-br0
Verbindung wurde erfolgreich aktiviert (master waiting for slaves) (Aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/3)

sowie die bisher verwendete Verbindung deaktiviert

$ sudo nmcli connection down "Kabelgebundene Verbindung 1"
Verbindung »Kabelgebundene Verbindung 1« wurde erfolgreich deaktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/1)

Ein Blick in die Verbindungseinstellungen zeigt, daß der Wechsel erfolgreich war:

$ sudo nmcli connection show
NAME                         UUID                                  TYPE      DEVICE 
bridge-br0                   e7a07a8f-beac-4ffe-adcf-47d406a82177  bridge    br0    
bridge-slave-ens192          e4a63a0d-4e1b-4a82-b1af-bdc9aecaf593  ethernet  ens192 
Kabelgebundene Verbindung 1  4e405dd1-dc75-3990-bfd1-fdb013e95f18  ethernet  --    

Die so erzeugte Brücke kann dann in virt-manager für die Netzwerkverbindungen der virtuellen Maschinen verwendet werden.

Kategorien
Anwendungen

Adobe Photoshop CS5 unter Debian Buster

Auch wenn GIMP inzwischen zu einem brauchbaren Werkzeug geworden ist, ist Adobe Photoshop in vielen Disziplinen noch immer ungeschlagen. Leider ist keine native Linux-Version erhältlich und die Installation mittels Wine gestaltet sich mitunter zickig.

Der hier seit vielen Jahren im Einsatz befindliche Adobe Photoshop CS5 ließ sich aber – mit einigen Einschränkungen – trotzdem zu einer Installation überreden.

Kategorien
Betriebssysteme

dpkg und Status „deinstall“

Beim gelegentlichen Erstellen der Liste aller installierten Pakete mit „dpkg –get-selections“ ist mir aufgefallen, daß ein paar Pakete mit dem Status „deinstall“ angezeigt werden, z.B.

python3.7					install
python3.7-minimal				install
qemu-kvm					deinstall
qemu-system-common				deinstall
qemu-system-x86					deinstall
qt5-gtk-platformtheme:amd64			install

Diese waren zum größten Teil Überbleibsel von Experimenten mit virutellen Maschinen, in deren Verlauf ich „virt-manager“ installiert und anschließend mittels „apt purge …“ wieder vom System entfernt habe, inklusive anschließendem „apt autoremove“.

Warum sind die Pakete offensichtlich noch vorhanden und werden von einem „autoremove“ nicht entfernt? Ein Blick in die man-Page brachte leider nicht die erhoffte Erleuchtung:

deinstalliere
  Das Paket ist zur Deinstallation ausgewählt 
  (d.h. wir wollen alle Dateien außer den
  Konfigurationsdateien entfernen).

Im englischen Debian-Forum findet sich eine plausible Erklärung , zwar aus 2009, aber sie passt:

… this means that all package files have been selected for removal except the configuration files.

sowie

If there is no configuration, cache files or whatever to be removed, then the package will be completely removed and not left in ‚c‘ (deinstall) state.

Dependencies that were installed automatically are never purged by default (if not uninstalled manually, using the purge command).

Das erklärt, warum manche Pakete noch im Status „deinstall“ vorhanden waren:

Der „virt-manager“ war weg, weil mittels „apt purge …“ deinstalliert. Alle Depencencies ohne Konfigurationsdatei(en) waren ebenfalls weg, gelistet wurden noch die Reste, bei denen zwar die Pakete entfernt wurden, nicht aber die Konfigurationen.

Kategorien
Anwendungen

.desktop-Datei mit Wine-Prefix

Sofern ein Windowsprogramm mit Wine installiert wird, legt der Installer i.d.R. auch eine Verknüpfung im Startmenü an. Ohne Installationsprozess muß die Datei von Hand erzeugt werden. Sofern noch ein WINEPREFIX verwendet werden soll, muß auch dieser im Starter angegeben werden.

Der dafür zuständige Ordner ist „.local/share/applications/wine/Programs/“, in diesem wird eine Textdatei mit der Endung „.desktop“ angelegt. Das Beispiel richtet die Verknüpfung für die Windows-Variante von „Lemmings“ ein, welche normalerweise direkt von CD startet, aber auch in jeden beliebigen Ordner kopiert werden kann.

[Desktop Entry]
Encoding=UTF-8
Name=Lemmings
Comment=Lemmings for Windows
Type=Application
StartupNotify=true
Exec=env WINEPREFIX=/home/Benutzername/.winlemm wine "/home/Benutzername/.winlemm/drive_c/WINLEMM/LEMMINGS.EXE"
Icon=/home/Benutzername/.winlemm/drive_c/WINLEMM/LEMMING.ICO
Path=/home/Benutzername/.winlemm/drive_c/WINLEMM/
StartupWMClass=LEMMINGS.EXE

Während in der Exec-Zeile die Groß- bzw. Kleinschreibung nach „wine“ egal ist (Windows trifft hier keine Unterscheidung), ist in den Angaben für „Icon“ und „Path“ auf eine korrekte Groß- bzw. Kleinschreibung zu achten.

Weiterführende Informationen finden sich im Artikel „.desktop-Dateien“ des Ubuntuusers-Wikis.

Kategorien
Betriebssysteme

Internet-Zugriff für Sublime Text unter Debian unterbinden

Als Texteditor ist hier Sublime Text in der lizenzierten Version im Einsatz.

Es ist aus meiner Sicht vollkommen legitim, daß ein Lizenzinhaber gelegentlich überprüft, ob die zugewiesene Lizenz noch gültig ist. Sublime Text führt diese Online-Überprüfung aber nach jedem Start durch, was im Hinblick auf die Privatsphäre suboptimal ist – letzendlich geht es im Rahmen der erworbenen Lizenz die Entwickler nichts an, ob der Editor fünfzig mal am Tag oder um drei Uhr nachts gestartet wird.

Eine Diskussion mit dem Thema „Sublime Text calling home to license.sublimehq.com on every start?“ im offiziellen Sublime Text-Forum hat leider zu keinem greifbaren Ergebnis geführt. Da auch die Sales FAQ nicht verlangt, daß das Programm nach Hause telefonieren darf / kann / soll / muss, ist eine anwendungsbezogene Sperrung des Netzwerk-Zugriffs eine naheliegende Option.

Unter Windows konnte der Internet-Zugriff für ein beliebiges Programm mit Hilfe der bordeigenen Firewall mit wenigen Klicks blockiert werden, unter Linux ist dies etwas komplizierter. Unter Linux blockiert die Firewall Internetzugriffe von außen basierend auf IP-Adresse und Port und eben nicht wie im aktuellen Fall gewünscht unabhängig  von IP und Port den Zugriff einer Anwendung nach aussen.

Zur Realisierung bietet sich AppArmor an, das unter Debian 10 standardmäßig installiert und aktiviert ist, so daß keine zusätzliche Software benötigt wird. AppArmor verfügt über weitreichende Konfigurationsmöglichkeiten, wer aber einen kurzen Blick in die unter „/etc/apparmor.d“ gespeicherten Profile wirft, wird davon ohne Vorkenntnisse regelrecht erschlagen.

Glücklicherweise gibt es mit den AppArmor Utils die Möglichkeit, ein Profil für eine Anwendung interaktiv zu erstellen.

An der Kommandozeile wird als erster Schritt die Erstellung eines neuen Profils gestartet:

$ sudo aa-genprof /opt/sublime_text/sublime_text

Anschließend wird Sublime Text gestartet und nach Möglichkeit alle darin benötigten Aktionen ausgeführt.

Nach dem Beenden von Sublime Text wird mit Druch auf „S“ im ursprünglichen Fenster die interaktive Generierung gestartet. „aa-genprof“ untersucht nun die anwendungsbezogenen Einträge im Syslog und stellt zu jedem Eintrag die Frage, ob eine Aktion erlaubt sein soll oder nicht.

Das Ergebnis ist ein Profil, das in der Datei „/etc/apparmor.d/opt.sublime_text.sublime_text“ erzeugt wird und nur recht wenige Zeilen enthält.

Um den Netzwerkzugriff zu blockieren, muß – falls vorhanden – die Zeile

#include <abstractions/nameservice>

entfernt werden, denn diese schaltet den Netzwerkzugriff frei, so daß ein anschließend eingefügtes

deny network

keinerlei Wirkung mehr zeigt.

Das fertige Minimal-Profil für Sublime Text sieht dann wie folgt aus:

# Last Modified: Mon May 11 20:28:54 2020
#include <tunables/global>

/opt/sublime_text/sublime_text {
  #include <abstractions/X>
  #include <abstractions/base>
  #include <abstractions/dbus-session-strict>
  #include <abstractions/evince>

  deny network,

  /opt/sublime_text/ r,
  /opt/sublime_text/** r,
  /opt/sublime_text/plugin_host mrix,
  /opt/sublime_text/sublime_text mr,
  /proc/filesystems r,
  owner /dev/shm/* rwl,
  owner /home/** rw,

}

Direkt nach Erzeugung startet AppArmor das Profil im „Enforce“-Modus, d.h. alles, was nicht explizit erlaubt ist, wird verboten. Sofern Build-Systeme o.ä. eingesetzt werden, sind noch Nachabeiten notwendig.

Diese können entweder manuell erfolgen oder durch das Wechseln des Profils in den „Complain“-Modus, dessen Aufzeichnungen anschließend wieder interaktiv ausgewertet werden können.

Zum Start von Perl als Build-System reicht z.B. das Hinzufügen von

/usr/bin/perl mrix,

welches das Starten des Perl-Internpreters mit den geerbten Berechtigungen von Sublime Text erlaubt.