Normale Ansicht

Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Ältere BeiträgeHaupt-Feeds

Proxmox VE 7.4 aktualisiert Unterbau

27. März 2023 um 07:28

Mit der Distribution Proxmox VE lässt sich schnell eine Umgebung für virtuelle Maschinen und Container aufsetzen. Die neue Version 7.4 offeriert ein neues dunkles Theme. Darüber hinaus liegen die Kernkomponenten QEMU, LXC und ZFS in frischen Versionen bei.

Als Basis dient weiterhin Debian 11.6 („Bullseye“), im Hintergrund arbeitet jedoch wahlweise der Kernel 5.15 oder 6.2. Mit an Bord sind QEMU 7.2, LXC 5.0.2 und ZFS 2.1.9. Beim verteilten Dateisystem Ceph kann man sich zwischen der Version Quincy 17.2.5 und Pacific 16.2.11 entscheiden. GUI und API bieten zudem detaillierte Ceph OSD-Informationen an.

Task Logs darf man ab sofort als Textdateien herunterladen. Der Resource Tree lässt sich zudem nach Name oder VMID sortieren. Der HA-Manager hat ein CRM-Kommando spendiert bekommen, über das man einen aktiven Knoten manuell und ohne Neustart in den Maintenance-Modus versetzen kann. CRS re-balanciert virtuelle Maschinen und Container automatisch beim Start. Sämtliche Neuerungen listen detailliert die offiziellen Release Notes auf.

Der Beitrag Proxmox VE 7.4 aktualisiert Unterbau erschien zuerst auf Linux-Magazin.

Hangover-Entwicklung nimmt wieder Fahrt auf

13. März 2023 um 08:48

Die Software Hangover erlaubt den Start von Windows-Software auf 64-bittigen Arm- und x86-Prozessoren sowie zukünftig auch PowerPC-Systemen. Nachdem das Projekt längere Zeit stillgestanden hat, scheint die Entwicklung jetzt wieder weiterzugehen.

Im Moment führt Hangover ausschließlich 32-Bit-Windows-Programme auf den genannten Prozessoren aus. Zukünftig soll sich auch 64-Bit-Windows-Software auf ARM- und PowerPC-Prozessoren ausführen lassen.

Hangover nutzt im Hintergrund vor allem die WoW64-Funktionen von Wine 8 sowie den Qemu-Emulator. Da die Lizenzen von Wine und Qemu nicht kompatibel sind, stellen die Entwickler derzeit nur den Quellcode bereit.

Das jetzt veröffentlichte Hangover 0.8.3 soll zwar vor allem stabiler laufen, es handelt sich jedoch weiterhin um eine Alpha-Version. Neu ist zudem die Bibliothek „wowarmhw.dll“ für die ARM32-Emulation.

Die Wine-Entwickler André Zwing und Stefan Dösinger hatten das Hangover-Projekt bereits 2016 gestartet. Vor rund zwei Jahren stoppte jedoch die Arbeit, weil die beiden zunächst die Implementierung des WoW64-Systems in Wine abwarten wollten. Dieses erlaubt die Ausführung von 32-Bit-Windows-Programmen auf einem 64-Bit-System.

Der Beitrag Hangover-Entwicklung nimmt wieder Fahrt auf erschien zuerst auf Linux-Magazin.

Docker Desktop für Linux

09. Juni 2022 um 13:17

Docker Desktop ist eine grafische Benutzeroberfläche zu Docker, die manche administrative Aufgaben erleichtert. Ursprünglich stand das Programm nur für Windows und macOS zur Verfügung. Seit Mai 2022 gibt es den Docker Desktop auch für Linux. Für diesen Blog-Artikel habe ich das Programm unter Ubuntu 22.04 kurz ausprobiert. Soviel vorweg: Aufgrund diverser Nachteile gibt es wenig zwingende Gründe, die für den Einsatz sprechen.

Docker Desktop unter Linux

Installation

Ich habe meine Tests unter Ubuntu 22.04 durchgeführt. Auf dem Rechner waren bisher keine Docker-Pakete installiert. Beachten Sie, dass der Docker Desktop keine Erweiterung zu einer vorhandenen Docker-Installation ist. Vielmehr sollten Sie diese vollständig entfernen, bevor Sie mit der Installation beginnen!

Bevor Sie den Docker Desktop installieren können, müssen Sie die Docker-eigene Paketquelle einrichten (Quelle):

sudo apt update

sudo apt install ca-certificates curl gnupg lsb-release

sudo mkdir -p /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Absurderweise enthält diese Paketquelle zwar diverse Docker-Pakete, nicht aber den Docker Desktop. Den müssen Sie manuell als DEB-Paket von der folgenden Seite herunterladen. (Der Grund für diese umständliche Vorgehensweise sind vermutlich die abweichenden Lizenzen. Der Docker Desktop steht zwar Privatanwendern kostenlos zur Verfügung. Es handelt sich aber nicht um Open-Source-Code. Für den kommerziellen Einsatz sind je nach Unternehmensgröße Lizenzgebühren erforderlich.)

https://docs.docker.com/desktop/release-notes

Das lokal heruntergeladene Paket samt aller Abhängigkeiten installieren Sie nun so:

sudo apt update

sudo apt install Downloads/docker-desktop-4.9.0-amd64.deb

Zum Ende der Installation wird eine Warnung angezeigt, die Sie aber ignorieren können:

N: Der Download wird als root und nicht Sandbox-geschützt durchgeführt, 
da auf die Datei »/home/kofler/Downloads/docker-desktop-4.9.0-amd64.deb« 
durch den Benutzer »_apt« nicht zugegriffen werden kann. 
pkgAcquire::Run (13: Keine Berechtigung)

Betrieb

Im Startmenü bzw. unter Gnome mittels Aktivitäten führen Sie den Docker Desktop nun aus. Der Startvorgang dauert eine Weile. Anschließend können die Kommandos docker und docker compose wie üblich in einem Terminalfenster ausgeführt werden. Docker wurde so eingerichtet, dass das Kommando ohne sudo funktioniert. Den Containern wird standardmäßig eine Netzwerkverbindung in einem privaten Netzwerk in 172.*.*.* zugewiesen.

docker run -it --rm alpine

<alpine># ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
3: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN qlen 1000
    link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
16: eth0@if17: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

Nachdem die Hürden der Installation einmal überwunden waren, hat Docker ausgezeichnet funktioniert. Im Vergleich zur reinen Verwendung des Kommandos docker hilft der Docker Desktop beim Einstieg in die Container-Welt sowie bei der Verwaltung aller jemals ausgeführten Container, aller heruntergeladenen Images sowie der von den Container genutzten Volumes. Wirklich essentiell ist keine dieser Funktionen, aber natürlich erleichtern sie die ersten Schritte.

Interna

Hinter den Kulissen ist für die Ausführung der Docker-Container eine virtuelle Maschine zuständig, die vom Docker Desktop automatisch gestartet wird. Auf meinem Rechner mit 16 GByte RAM und einer CPU mit 4 Cores hat der Docker Desktop für sich knapp 4 GByte RAM und 2 Cores reserviert. Für das Disk Image der Maschine sind 64 GByte vorgesehen. (Anfänglich ist die Datei aber zum Glück wesentlich kleiner.) QEMU-Experten können sich in der Prozessliste die Optionen ansehen, die für die Ausführung der virtuellen Maschine verwendet werden.

ps axu | grep qemu

kofler     40338  3.5 26.0 6470936 4223024 ?     Sl   13:13   0:54 qemu-system-x86_64 -accel kvm -cpu host -machine q35 -m 3962 -smp 2 -kernel /opt/docker-desktop/linuxkit/kernel -append page_poison=1 vsyscall=emulate panic=1 nospec_store_bypass_disable noibrs noibpb no_stf_barrier mitigations=off linuxkit.unified_cgroup_hierarchy=1 vpnkit.connect=tcp+bootstrap+client://gateway.docker.internal:42021/974498b84e0cf777fec14624fda4ca7bb07343ae3bbed05f397d28bbf707b784 vpnkit.disable=osxfs-data console=ttyS0 -initrd /opt/docker-desktop/linuxkit/initrd.img -serial pipe:/tmp/qemu-console1100778794/fifo -drive if=none,file=/home/kofler/.docker/desktop/vms/0/data/Docker.raw,format=raw,id=hd0 -device virtio-blk-pci,drive=hd0,serial=dummyserial -netdev user,id=net0,ipv6=off,net=192.168.65.0/24,dhcpstart=192.168.65.9 -device virtio-net-pci,netdev=net0 -vga none -nographic -monitor none -object memory-backend-memfd,id=mem,size=3962M,share=on -numa node,memdev=mem -chardev socket,id=char0,path=/home/kofler/.docker/desktop/virtiofs.sock0 -device vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=virtiofs0

Der Docker Desktop samt seiner virtuellen Maschine läuft ohne root-Rechte als Prozess des lokalen Benutzers.

systemctl --user status docker-desktop

  docker-desktop.service - Docker Desktop
     Loaded: loaded (/usr/lib/systemd/user/docker-desktop.service; disabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-06-09 13:13:50 CEST; 9min ago
   Main PID: 40088 (com.docker.back)
      Tasks: 157 (limit: 18937)
     Memory: 5.8G


docker version

Client: Docker Engine - Community
 Cloud integration: v1.0.25
 Version:           20.10.17
 API version:       1.41
 ...
 Context:           desktop-linux
 Experimental:      true

Server: Docker Desktop 4.9.0 (80466)
 Engine:
  Version:          20.10.16
  API version:      1.41 (minimum version 1.12)
  ...
 containerd:
  Version:          1.6.4
  GitCommit:        212e8b6fa2f44b9c21b2798135fc6fb7c53efc16
 runc:
  Version:          1.1.1
  GitCommit:        v1.1.1-0-g52de29d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Die Eckdaten der virtuellen Maschine können in der Oberfläche des Docker Desktops verändert werden.

Einstellungen für die virtuelle Maschine, in der die Docker-Container ausgeführt werden

Zukunftsvisionen: »Development Environments« versus »Development Containers«

Spannend ist eine neue Funktion, die aktuell aber erst im Preview-Stadium vorliegt: Development Environments (Link zur Dokumentation) sollen es im Zusammenspiel mit git noch einfacher machen, Testversionen bzw. Entwicklungszweige (git-Branches) im Team auszuprobieren — und das, ohne jedesmal alle möglichen Voraussetzungen manuell einzurichten. Möglicherweise führt das die Idee von gewöhnlichen Containern noch einen Schritt weiter.

Das VSCode-Plugin Remote Containers verfolgt mit Development Containern eine ganz ähnliche Idee (Link). Ob sich eines dieser Konzepte durchsetzen kann, ist aktuell noch nicht absehbar.

Fazit

Die grafische Oberfläche des Docker Desktops bietet Linux-Anwendern den gleichen Komfort wie Entwicklern, die Docker unter macOS oder Windows ausführen. Das ist an sich sehr erfreulich.

Der Docker Desktop enthält allerdings keine wirklich relevanten Funktionen, die nicht schon bisher auf Kommandoebene zur Verfügung standen. Gegen den Einsatz von Docker Desktop sprechen diverse Gründe:

  • Die Installation ist verblüffend umständlich. (Die Docker-Installation war schon immer relativ umständlich, weil nur wenige Distributionen aktuelle Docker-Pakete zur Verfügung stellen. Aber dass Docker Desktop die Sache noch komplizierter macht, ist absurd.)

  • Docker Desktop ist ein Komplettpaket inklusive aller Docker-Tools. Es ersetzt die bisherigen Pakete. Eine Installation des Docker Desktop parallel zu einem schon vorhandenen Docker-Setup ist nicht möglich.

  • Der Docker Desktop verwendet eine virtuelle Maschine zur Ausführung von Containern. Dadurch ergibt sich eine bessere Trennung zwischen dem Host-Rechner und den Docker-Container. Allerdings geht ein wesentlicher Vorteil von Docker unter Linux verloren, nämlich die nahtlose Integration von Docker-Containern in die Prozess- und Speicherverwaltung des Hosts. Der für die virtuelle Maschine reservierte Speicher wird zur Gänze Docker zugeteilt, ganz egal, wie viele oder wenige Container gerade ausgeführt werden. Auf Entwicklungsrechnern mag dieser Ansatz eine gewisse Berechtigung haben. Für das Deployment am Server ist der Docker Desktop definitiv ungeeignet (und auch gar nicht vorgesehen).

  • Weil der Docker Desktop eine virtuelle Maschine benötigt, kann der Docker Desktop nur bei nativen Linux-Installationen genutzt werden — nicht aber, wenn Linux selbst in einer virtuellen Maschine läuft. Vermutlich ist das ein Grund, warum bisher so wenig Testberichte zum Docker Desktop erschienen sind …

  • Der Docker Desktop steht Privatanwendern zwar kostenlos zur Verfügung, es handelt sich aber nicht um ein ein Open-Source-Programm. Der kommerziellen Einsatz ist in großen Unternehmen (>250 Mitarbeiter oder >10 Millionen $ Jahresumsatz) kostenpflichtig.

Quellen/Links

Kali Linux als virtuelle Maschine unter macOS mit UTM ausführen

08. Juni 2022 um 19:30

Der Einsatz von Kali Linux auf einem »alten« Apple-Rechner ist einfach: Sie installieren zuerst VirtualBox und dann in einer virtuellen Maschine die x86-Version von Kali Linux. Die Vorgehensweise ist im Internet vielfach dokumentiert.

Schon etwas komplizierter wird die Sache, wenn Sie einen M1- oder demnächst einen M2-Mac besitzen. VirtualBox steht für diese CPU-Architektur nicht zur Verfügung. Sie haben die Wahl zwischen den beiden kommerziellen und relativ teuren Virtualisierungssystemen Parallels und VMware Fusion sowie dem Programm UTM, das auf der unter Linux beliebten Virtualisierungs-Software QEMU basiert. Dieser Blog-Beitrag zeigt, wie Sie die ARM-Variante von Kali Linux unter UTM installieren.

Die ARM-Variante von Kali Linux läuft in einem Fenster unter macOS (getestet auf einem Mac Mini M1)

UTM

Sie können UTM wahlweise für nur 10 € im Apple Store kaufen und so die Entwickler ein wenig unterstützen oder die App kostenlos von der folgenden Seite herunterladen:

https://mac.getutm.app

UTM ist eine einfache, aber funktionelle Oberfläche für das unter Linux etablierte Programm QEMU. Sie können damit Linux-Distributionen installieren, die als ARM64-Image vorliegen.

Die Virtualisierungsoberfläche »UTM« unter macOS, hier mit zwei virtuellen Maschinen, Ubuntu und Kali Linux

Kali-Installation

Als Basis für die Kali-Installation wählen Sie auf der Kali-Download-Seite die Variante Bare Metal / Apple M1 / Installer aus. Die ISO-Datei ist ca. 2,5 GByte groß:

https://www.kali.org/get-kali/#kali-bare-metal

Nun richten Sie in UTM eine neue virtuelle Maschine ein. Im ersten Dialog des Assistenten wählen Sie die Option Virtualize, im zweiten Dialog geben Sie an, dass Sie eine Linux-Distribution ausführen möchten. Im dritten Dialog wählen Sie mit Browse das zuvor heruntergeladene Kali-Installations-Image aus. Die Optionen Use Apple Virtualization und Boot from kernel image bleiben deaktiviert.

In den nächsten zwei Dialogen geht es um die Hardware-Ausstattung der virtuellen Maschine. Je nachdem, wie üppig Ihr Mac ausgestattet ist, sollten Sie der virtuellen Maschine 2 bis 4 GByte RAM sowie zwei CPU-Cores zuweisen. Kali benötigt einen virtuellen Datenträger von zumindet 15 GByte. Mit 20 bis 25 GByte haben Sie ein wenig Platzreserve.

Im folgenden Dialog Shared Directory können Sie ein macOS-Verzeichnis zum Datenaustausch mit Kali Linux auswählen. Da die Nutzung dieses geteilten Verzeichnisses unter Kali Linux nicht vorgesehen ist, können Sie diesen Punkt überspringen.

Im abschließenden Dialog Summary sollten Sie die Option Open VM Settings aktivieren. Das gibt Ihnen in der Folge die Möglichkeit, zwischen mehreren Netzwerkmodi zu wählen. Für den Einsatz von Kali Linux ist zumeist Bridged empfehlenswert: Damit erhält Kali Linux eine IP-Adresse im lokalen Netzwerk und kann mit diesem kommunizieren. (Diese Einstellung können Sie aber auch nachträglich vornehmen. Dazu stoppen Sie die virtuelle Maschine und öffnen dann im UTM-Hauptfenster den Konfigurationsdialog der virtuellen Maschine.)

Bridged Networking integriert die virtuelle Maschine in das lokale Netzwerk

Nach dem Start der virtuellen Maschine gelangen Sie in das Kali-Boot-Menü. Bei meinen Tests erwies sich das Kommando Graphical Install als nicht zielführend: Das UTM-Fenster wird dann nach wenigen Sekunden vollständig schwarz und verhindert so die Bedienung des Installationsprogramms. (Das Problem ist anscheinend relativ neu. Es gibt hier einen Fehlerbericht.)

Entscheiden Sie sich daher mit Install für eine Installation im Textmodus. Der Ablauf ist exakt gleich wie bei einer Installation im Grafikmodus, die Dialoge sehen nur weniger schön aus; zur Navigation zwischen den Eingabefeldern verwenden Sie die Tabulatortaste.

Beim Kali-Bootmenü müssen Sie »Install« auswählen. »Graphical Install« führt nach wenigen Sekunden in ein schwarzes, nicht mehr bedienbares Fenster.
Software-Auswahl während der Installation

Erster Start und Betrieb

Nach dem Abschluss der Installation wird die virtuelle Maschine neu gestartet. Statt des frisch installierten Systems erscheint allerdings wieder das Installationsprogramm. Das liegt daran, dass die virtuelle Maschine noch immer das ISO-Image als Boot-Medium verwendet. Stoppen Sie die virtuelle Maschine mit dem Button Shut down, klicken Sie dann in der auf das CD/DVD-Symbol rechts in der Fenstertitelleiste und führen Sie CD/DVD (ISO) Image / Eject aus. Beim nächsten Neustart bootet Kali Linux von der virtuellen Disk und läuft dann erfreulicherweise auch im Grafikmodus. Die gewünschte Desktop-Auflösung (und damit auch die Fenstergröße) legen Sie innerhalb von Kali Linux mit Einstellungen / Anzeige fest.

Bei meinen Tests hat Kali Linux innerhalb von UTM ausgezeichnet funktioniert. Allerdings kommt es bei der Bildschirmdarstellung aufgrund der automatisch durchgeführten Skalierung zwischen dem Grafiksystem der virtuellen Maschine und dem Monitor des Macs zu unschönen Farbverschiebungen, vor allem bei der Darstellung von Texten.

Quellen/Links

❌
❌