Seit Ende Oktober 2021 ist die Raspberry-Pi-Familie um ein weiteres Mitglied gewachsen: Der Raspberry Pi Zero 2 löst die vorangegangenen Zero-Modelle ab. Das wichtigste Unterscheidungsmerkmal ist die wesentlich schnellere CPU im System-on-a-Chip (SoC) mit der Bezeichnung BCM2710A1. Dahinter versteckt sich eine Variante des SoC aus dem Raspberry Pi 3. Der Zero 2 glänzt jetzt mit 4 Cores und einer Taktfrequenz von 1 GHz. Damit ist die Rechenleistung um ein Vielfaches höher als bisher.
Persönlich war meine größte Befürchtung, dass sich die höhere Geschwindigkeit auch in einer spürbar höheren Leistungsaufnahme widerspiegeln würde. Tatsächlich ist dies aber laut Messungen von hackaday.com nur teilweise der Fall. Zwar fließen unter Volllast knapp 450 mA Strom (entspricht einer Leistungsaufnahme von 2,2 W). Die Leistungsaufnahme ist damit fast 2,5 mal höher als bei den bisherigen Zero-Modellen. Errechnet man allerdings die CPU-Leistung pro Watt, dann ist der Zero 2 der effizienteste Minicomputer, den die Raspberry Pi Foundation bisher produziert hat. Im Leerlauf sind Zero und Zero 2 fast genauso sparsam (rund 0,4 W beim Zero, rund 0,5 W beim Zero 2).
Der Raspberry Pi Zero 2
Wenn Ihnen die maximale Leistungsaufnahme des Zero 2 zu hoch ist, können Sie durch einen Kernel-Option drei der vier Cores sperren. Damit sinkt die Leistungsaufnahme unter Volllast auf die Hälfte, die Geschwindigkeit allerdings auf ein Viertel. Details dazu können Sie im Blog nachlesen.
Eigener Test
Ich habe den Zero 2 mit Raspberry Pi OS Lite (Bullseye) ausprobiert. Eigentlich wollte ich Hostnamen, WLAN und SSH-Zugang vorweg im Raspberry Pi Imager konfigurieren; beim ersten Versuch hat dies überhaupt nicht funktioniert. Beim zweiten Versuch wurden immerhin der Hostname und das Passwort korrekt gesetzt, aber die WLAN-Verbindung funktionierte wieder nicht. Es ist mir nichts anderes übrig geblieben, als den Zero 2 an einen Monitor und eine Tastatur anzuschließen und die Konfiguration manuell in raspi-config vorzunehmen. Das ist ärgerlich, weil gerade der Zero 2 mit seinen wenigen und exotischen Anschlüssen für eine Headless-Installation prädestiniert ist.
Nachdem diese Hürden gemeistert waren, verhielt sich der Zero 2 unauffällig. Gemessen daran, dass es sich um ein Zero-Modell handelt, läuft der Mini-Computer verblüffend schnell und (z.B. während Updates) ohne unangenehm heiß zu werden.
Eckdaten
Größe: 65 mm x 30 mm
SoC: BCM2710A1, 4 Cortex-A53-Cores
RAM: 512 MByte
Anschlüsse: 2 x Micro-USB (1 x Stromversorgung, 1 x Daten), Mini-HDMI, Mini-Kameraanschluss (erfordert Adapter)
WLAN 2,4 GHz 802.11b/g/n
Bluetooth 4.1
Leistungsaufnahme: 0,4 W (Leerlauf) bis 2,2 W (alle 4 Cores unter Volllast)
40 GPIOs (Lötkontakte, keine Steckerleiste!)
Beachten Sie, dass sämtliche Zero-Modelle, also auch der neue Zero 2, mit einem Mini-HDMI-Anschluss ausgestattet sind. Der Raspberry Pi 4B verwendet dagegen Micro-HDMI. Sie brauchen also für den Zero 2 ein eigenes Kabel oder einen Adapter.
Preis
Das ursprüngliche Zero-Modell wurde ursprünglich als Raspberry Pi für nur fünf Euro beworben. Tatsächlich war er aber nur schwer zu diesem Preis erhältlich (und wenn, dann nur bei der Abnahme hoher Stückzahlen). Beim Zero 2 sieht es aktuell noch schlimmer aus: Laut geizhals ist das Gerät aktuell (Dez. 2021) generell schwer erhältlich und kostet beachtliche 30 Euro — Schnäppchen ist das keines! Der hohe Preis hat mit Corona, dem allgemeinem Chip-Mangel, dem Brexit etc. zu tun, ist also nicht unbedingt die Schuld der Raspberry Pi Foundation. Trotzdem: Wer den Zero 2 kauft, tut dies sicher nicht wegen des günstigen Preises, sondern weil er/sie einen winzigen, leistungseffizienten, Pi-kompatiblen Mini-Computer sucht.
Fazit
tolle Hardware, aber mit 512 MB RAM nicht Desktop-tauglich
Asahi Linux ist ein Projekt, um Linux nativ auf Apple-Rechnern mit M1-CPU auszuführen. Seit einigen Tagen gibt es eine Alpha-Version eines Installers für Arch Linux. Ich konnte natürlich nicht widerstehen und habe das Programm auf meinem Mac Mini ausprobiert.
Bevor Sie »Hurra!« rufen, kurz eine Zusammenfassung der wichtigsten Einschränkungen, die aktuell gelten:
Die Installation muss auf eine interne SSD erfolgen. (Externe USB-Disks sind leider nicht geeignet.)
Es gibt keine GPU-Unterstützung. Die Geschwindigkeit der Grafik ist trotzdem OK, aber natürlich nicht überragend.
Beim Mac Mini muss der Monitor per HDMI angeschlossen werden. (USB-C funktioniert nicht.) Die max. Auflösung ist Full HD (kein 4k!).
Kein DisplayPort, kein Thunderbolt, kein HDMI bei den MacBooks, keine Kamera-Unterstützung
Kein Bluetooth
Kein Schlafmodus oder CPU deep idle, d.h. die CPU braucht im Leerlauf mehr Strom als notwendig. Bei den MacBooks ist die Akku-Laufzeit entsprechend eingeschränkt.
Asahi Linux verwendet 16k-Speicherseiten. Einige Programme (Google Chrome, Emacs, alle Programme auf Electron-Basis etc.) sind dazu inkompatibel und laufen daher nicht. Für manche Programme gibt es bereits Bugfixes, d.h. es ist zu hoffen, dass dieses Inkompatibilitäten im Laufe der nächsten Monate verschwinden.
Installation (Phase 1, unter macOS)
Grundsätzlich ist die Installation nicht schwierig: Zuerst stellen Sie sicher, dass macOS zumindest in Version 12.3 vorliegt, und lösen die Verbindung zu evt. vorhandenen Backup-Datenträgern. (Wenn Sie das nicht machen, vergeudet der Installer Stunden, um die Korrektheit der TimeMachine-Backups auf externen Datenträgern zu überprüfen.)
Dann führen Sie in einem Terminal führen Sie das folgende Kommando aus:
curl https://alx.sh | sh
Nun folgen Sie den Anweisungen. Im Wesentlichen müssen Sie mehrfach Ihr Passwort eingeben, die gewünschte Größe für die SSD-Partitionierung festlegen, und einen von drei Installationsmodi auswählen:
Installation von Arch Linux mit KDE-Desktop
Installation eines minimalen Arch-Systems (Textmodus)
Installation eines UEFI-Umgebung als Ausgangspunkt für die Installation anderer Distributionen
Ich habe mich für die zweite Variante entschieden und kann zu den anderen Optionen nichts sagen. Die folgenden Screenshots dokumentieren den Verlauf des Setup-Prozesses.
Start der Installation im TerminalAnzeige von SysteminfosPartitionierung der internen SSD, um Platz für Linux zu machenSinnlose (stundenlange) Überprüfung der TimeMachine-Snapshots eines externen (!) Datenträgers, bevor dann der interne Datenträger verändert wirdAuswahl der InstallationsvarianteVorbereitung für den ersten BootvorgangLetzte Anweisungen und Warnungen vor dem Reboot
Installation (Phase 2, nach Reboot)
Bevor das Setup-Script den Rechner herunterfährt, gibt es klare Anweisungen: Der Rechner muss ca. 15 Sekunden komplett ausgeschalten bleiben, bevor er neu gestartet wird (warum auch immer). Beim Neustarten muss der Power-Knopf für ca. 10 Sekunden dauerhaft gedrückt bleiben, bis am Bildschirm ein Auswahlmenü zwischen macOS und Asahi-Linux erscheint. Sie wählen Asahi-Linux aus.
Das Boot-Menü erscheint nur, wenn beim Einschalten mind. 10 Sekunden der Power-Knopf dauerhaft gedrückt wird
Allerdings wird noch nicht das fertige Linux gestartet. Vielmehr muss die Installation abgeschlossen werden. Sie müssen sich dabei zweimal authentifizieren (also das Passwort des primären macOS-Benutzers angeben), damit Linux als »sicheres« Betriebssystem in den Tiefen des verschachtelten macOS-Bootprozesses verankert werden können. Ich habe versucht, den Verlauf von Phase 2 so gut wie möglich durch Fotos zu dokumentieren.
Start der Installationsphase 2Letzte Warnungen …Viele Details, die nochmals bestätigt werden müssen.Ankündigung eines weiteren Reboots
Arch Linux einrichten
Asahi Linux sollte jetzt das Default-Betriebssystem sein. Wenn alles gut geht, startet nach dem neuerlichen Reboot Arch Linux. Da ich mich für die Minimalinstallation von Arch Linux entschieden habe, erscheint eine Textkonsole. Es gibt zwei vorkonfigurierte Logins, root (Passwort root) und alarm (Passwort alarm). Die ersten Schritte sollten sein, die Passwörter dieser beiden Benutzer sofort zu ändern und dann den SSH-Server zu aktivieren.
Erste Arbeiten in der Konsole von Arch Linux
In den nächsten Schritten geht es darum, eine Minimalkonfiguration von Arch Linux durchzuführen und Xorg sowie Gnome zu installieren. Das setzt Arch-Grundkenntnisse voraus. Nach einem Login als root habe ich die folgenden Kommandos ausgeführt:
# Passwort von root und alarm ändern
passwd
passwd alarm
# SSH-Dämon starten
systemctl enable --now sshd
# Spracheinstellungen
cat <<EOF > /etc/locale.gen
de_DE.UTF-8 UTF-8
en_US.UTF-8 UTF-8
EOF
locale-gen
echo "LANG=de_DE.UTF-8" > /etc/locale.conf
echo "KEYMAP=de-latin1" > /etc/vconsole.conf
# sudo installieren, Benutzer 'kofler' mit sudo-Rechten anlegen
pacman -Syu sudo
useradd -m kofler
usermod -a -G wheel kofler
passwd kofler
# in /etc/sudoers die Zeile mit '%wheel' auskommentieren!
# xorg und Gnome installieren. Beim Audio-System habe ich mich
# für die Pakete pipewire-jack und wireplumber entschieden.
pacman -Syu xorg gnome
all xorg packages
all gnome packages
pipewire-jack
wireplumber
# Grafiksystem samt Gnome-Login starten
systemctl enable --now gdm
# im Terminal von Gnome: Firefox installieren
pacman -S firefox firefox-i18n-de
Ich hoffe, ich habe nichts Wesentliches vergessen. Denken Sie daran, dass Sie bei der ersten Verwendung von pacman die Option -y angeben. Einfach pacman -S scheitert, weil die Informationen zu den Paketquellen nicht aktuell sind. pacman muss zuerst das Inhaltsverzeichnis der Paketquellen herunterladen (Option -y).
Gnome läuft sehr flüssig, wenn auch enttäuschenderweise auf meinem 4k-Monitor nur mit Full HD. Die von mir verwendete uralte USB-Apple-Tastatur wird ausgezeichnet unterstützt, nachdem ich unter Gnome die Tastatur Deutsch (Macintosh) eingestellt habe.
Gnome 41 läuft nativ auf einem Mac M1 Mini!
Default-Betriebssystem einstellen
Linux gilt nun als Default-Betriebssystem. Um macOS zu booten, müssen Sie beim Einschalten wieder gut 10 Sekunden den Einschaltknopf drücken. Damit gelangen Sie in das Boot-Menü und können dort macOS auswählen.
Das Default-Betriebssystem können Sie unkompliziert in den macOS-Systemeinstellungen festlegen. Leider gibt es keine Möglichkeit (bzw. ich habe keine gefunden), dass das Boot-Menü automatisch erscheint. Für den wechselweisen Betrieb von Linux und macOS wäre das sehr praktisch.
Einstellung des Default-Betriebssystem unter macOS
Probleme (aktualisiert 28.3.2022)
Neben den in der Einleitung bereits aufgezählten technischen Einschränkungen traten bei meinen Tests wiederholt Boot-Probleme auf. Das Boot-System für Linux findet eine Datei (oder das Root-Dateisystem?) nicht, zeigt für ein paar Sekunden kryptische Fehlermeldungen an, und startet dann neu (Boot-Loop). Früher oder später hat es dann meistens funktioniert.
Der Linux-Bootprozess funktioniert (zumindest auf meinem System) unzuverlässig
Der Fehler tritt spürbar häufiger auf, wenn ich meine externe USB-3-SSD angeschlossen habe. (Diese SSD dient unter macOS als TimeMachine-Backup-Volume und hat keine andere Aufgabe. Ich brauche sie unter Linux nicht, aber es wäre natürlich fein, wenn ich sie einfach angeschlossen lassen könnte. Davon habe ich mittlerweile abgesehen.)
Es gibt noch ein Problem, das mir anfänglich nicht aufgefallen ist: Manchmal bleibt der Monitor nach dem Start einfach schwarz. Dieses Problem tritt nur auf, wenn Linux automatisch bootet (also als Default-Betriebssystem ohne die vorherige Anzeige der Boot-Auswahl durch das lange Drücken des Einschaltknopfs). Der Rechner startet ganz normal, nach ca. 10 bis 15 Sekunden kann ich mich via SSH anmelden, ps zeigt, dass gdm läuft, aber der Monitor erhält kein Signal, bleibt schwarz und aktiviert nach ein paar Sekunden den Energiesparmodus.
Abhilfe: Booten über das Menü mit langem Drücken des Einschaltknopfs. Siehe auch diesen theregister-Kommentar von Marcan zu diversen Monitorproblemen, die anscheinend demnächst gelöst werden sollen.
Fazit
Es ist faszinierend, wie viel bereits funktioniert. Dessen ungeachtet ist Asahi Linux natürlich noch nicht praxistauglich (bzw. nur für ganz schmale Anwendungsnischen). Auf meinem Mac Mini stört aktuell die HDMI-Einschränkung auf 1920×1080. Für den Einsatz auf einem Notebook fehlen Bluetooth, eine ordentliche Unterstützung externer Schnittstellen (Thunderbolt, HDMI etc.) sowie ein besseres Energiemanagement. Der Installationsprozess ist zwar für Profis OK, aber für Einsteiger ungeeignet.
Viel wichtiger ist für mich die Perspektive: MacBooks sind aus technischer Sicht enorm attraktive Geräte (wenn auch teuer): Großartige Rechenleistung, großartige Displays, endlich wieder ein gutes Keyboard, und, für mich fast am wichtigsten: praktisch lautlos!
Aus meiner Linux-Sichtweise stört halt macOS :-) Ich streite nicht ab, dass macOS ein gutes Betriebssystem ist, aber für mich als Entwickler, Admin und Autor ist es nicht perfekt. (Größtes Hindernis: Die unkomplizierte Möglichkeit, Linux-Distributionen in virtuellen Maschinen zu testen. Das geht aktuell allerdings auch unter Asahi Linux nicht ohne Weiteres …)
Sofern das Asahi-Projekt die noch fehlenden Treiber-Lücken demnächst ebenfalls schließen kann, wäre es möglich, dass in zwei, drei Jahren ein MacBook Pro meinen Lenovo P1 ablöst.
Seit ca. einem Jahr tritt Arch Linux immer stärker in meinen Linux-Fokus. Dieser Beitrag beschreibt die Installation von Arch Linux auf einem Notebook. Das neue System soll folgende Merkmale aufweisen:
Vollverschlüsselung (Betriebssystem + Daten)
LVM
systemd-boot (kein GRUB)
Ich gehe davon aus, dass es keine weiteren Betriebssysteme gibt und die gesamte SSD genutzt werden soll. Ich gehe auch davon aus, dass Sie nicht an UEFI Secure Boot interessiert sind. (Bei mir scheidet Secure Boot aus, weil ich auf meinem Notebook auf die NVIDIA-Treiber angewiesen bin.) Falls Sie Secure Boot verwenden wollen, müssen Sie zum Booten GRUB anstelle von systemd-boot verwenden.
Partitionierung
Die Installation beginnt im Live-System des Arch Linux Images (Download, das vorher auf einen USB-Stick übertragen werden muss. Den Umgang mit dem Live System habe ich zuletzt in diesem Blog-Beitrag beschrieben, weswegen ich hier auf Wiederholungen verzichte. Beachten Sie insbesondere die Möglichkeit, im Live-System einen SSH-Server zu starten und die weitere Installation dann auf einem anderen Rechner via SSH durchzuführen.
Die Grundidee der Arch-Linux-Installation besteht darin, dass Sie alle erforderlichen Dateisysteme manuell einrichten und unter /mnt einbinden. Erst dann startet der eigentliche Installationsprozess.
Die Partitionierung erfolgt mit parted. Beachten Sie, dass nur zwei Partitionen erforderlich sind:
Die erste Partition dient gleichzeitig EFI- und Boot-Partition. Sie wird später unter dem Pfad /boot genutzt und sowohl die für EFI erforderlichen Dateien (/boot/EFI) als auch die Boot-Dateien (initramfs-xxx und vmlinux-xxx direkt in /boot) enthalten. Die reservierten 2 GByte sind mehr als großzügig. Aktuell (ein Monat nach der Installation) werden nur 76 MByte genutzt. Aber ein wenig Reserve — gegebenenfalls für die Installation weiterer Distributionen — kann nicht schaden.
Die zweite Partition dient als LUKS-Container, wird also verschlüsselt. mkpart ... -1mib bedeutet, dass die gesamte Disk bis knapp an deren Ende genutzt werden soll.
parted /dev/nvme1n1
(parted) mklabel gpt
(parted) mkpart esp 1mib 2000mib
(parted) mkpart crypt 2001mib -1mib
(parted) set 1 boot on
(parted) set 1 esp on
(parted) unit mib
(parted) print
Modell: Samsung SSD 970 EVO Plus 2TB (nvme)
Festplatte /dev/nvme1n1: 1907729MiB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags:
Nummer Anfang Ende Größe Dateisystem Name Flags
1 1,00MiB 2000MiB 1999MiB fat32 esp boot, esp
2 2001MiB 1907629MiB 1905628MiB crypt
Dateisysteme, LUKS und LVM einrichten
Für die erste Partition reicht ein simples FAT32-Dateisystem:
mkfs.fat -F 32 /dev/nvme1n1p1
In der zweiten Partition wird mit cryptsetup luksFormat ein verschlüsselter Container eingerichtet. cryptsetup luksOpen aktiviert den Container. Natürlich muss bei beiden Kommandos das gewünschte Passwort angegeben werden:
Der gesamte Container soll als Physical Volume (PV) für LVM verwendet werden:
pvcreate /dev/mapper/mycrypt
Das PV ist vorerst das einzige Element für den LVM-Datenpool, also für die Volume Group (VG):
vgcreate vgcrypt /dev/mapper/mycrypt
Innerhalb der Volume Group habe ich zwei Logical Volumes (LVs) angelegt, eine mit 200 GByte für Arch Linux und eine weitere mit 600 GByte für /home. In beiden LVs habe ich ein ext4-Dateisystem erstellt.
Bevor die eigentliche Installation losgeht, müssen die neuen Dateisysteme unter /mnt in den Verzeichnisbaum des Live-Systems integriert werden:
mount /dev/mapper/vgcrypt-archroot /mnt
mkdir /mnt/boot
mkdir /mnt/home
mount /dev/nvme1n1p1 /mnt/boot
mount /dev/mapper/vgcrypt-archhome /mnt/home
Installation und Konfiguration des Minimalsystems
pacstrap installiert ein Minimalsystem nach /mnt. genfstab erzeugt die zum Setup passende Datei /etc/fstab. arch-chroot wechselt in das neue Minimalsystem. pacman installiert einige Basispakete.
pacstrap /mnt base linux linux-firmware
genfstab -U /mnt >> /mnt/etc/fstab
arch-chroot /mnt
pacman -S lvm2 nano man zile dhclient networkmanager
Ein symbolischer Link kümmert sich um die Einstellung der richtigen Zeitzone:
Damit der Boot-Vorgang funktioniert, muss die Initramfs-Datei Treiber für LVM und die Entschlüsselung des LUKS-Containers enthalten. Deswegen muss mit einem Editor die Variable HOOKS in der Datei /etc/mkinitcpio.conf angepasst werden. Achtung: Die Reihenfolge der Hooks ist wichtig!
# diese Zeile in der Datei /etc/mkinitcpio.conf anpassen
HOOKS=(base udev autodetect keyboard modconf block encrypt lvm2 filesystems fsck)
Mit mkinitcpio erzeugen Sie nun die Initramfs-Datei.
mkinitcpio -p linux
bootctl richtet systemd-boot ein. Das Kommando setzt voraus, dass /boot die EFI System Partition (ESP) ist. Am Beginn der Installation ist diese Partition mit parted entsprechend markiert worden (set 1 boot on und set 1 esp on).
bootctl --path=/boot/ install
Nun muss noch der Bootloader konfiguriert werden. Dazu ermitteln Sie zuerst mit blkid den UUID der verschlüsselten Partition:
Das erste cat-Kommando erzeugt die Datei /boot/loader/loader.conf. Diese Datei besagt, dass systemd-boot standardmäßig nach 3 Sekunden die Booteinstellungen aus /boot/loader/entries/arch.conf berücksichtigen soll:
Das zweite cat-Kommando erzeugt den Menüeintrag für Arch-Linux.
cat << EOF > /boot/loader/entries/arch.conf
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options cryptdevice=UUID=todo:cryptlvm root=/dev/vgcrypt/archroot quiet rw
EOF
In diese Datei müssen Sie nun mit einem Editor die zuvor ermittelte UUID eintragen. In meinem Fall (vergleichen Sie das Ergebnis von blkid oben) sieht die Datei dann so aus:
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options cryptdevice=UUID=44fbbcd5-8d8e-4978-9c32-ffcaa646554f:cryptlvm root=/dev/vgcrypt/archroot quiet rw
Zur Kontrolle können Sie bootctl ohne Parameter ausführen. Das Ergebnis sollte in etwa wie folgt aussehen:
bootctl
System:
Firmware: UEFI 2.60 (Lenovo 0.4992)
Secure Boot: disabled (setup)
TPM2 Support: yes
Boot into FW: active
Current Boot Loader:
Product: systemd-boot 250.3-2-arch
Features: ✓ Boot counting
✓ Menu timeout control
✓ One-shot menu timeout control
✓ Default entry control
✓ One-shot entry control
✓ Support for XBOOTLDR partition
✓ Support for passing random seed to OS
✓ Load drop-in drivers
✗ Boot loader sets ESP information
ESP: n/a
File: └─/EFI/BOOT/BOOTX64.EFI
Random Seed:
Passed to OS: no
System Token: set
Exists: yes
Available Boot Loaders on ESP:
ESP: /boot (/dev/disk/by-partuuid/84bd0fe5-be18-4f5a-991c-b28c2a8899ef)
File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 250.3-4-arch)
File: └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 250.3-4-arch)
Boot Loaders Listed in EFI Variables:
...
Boot Loader Entries:
$BOOT: /boot (/dev/disk/by-partuuid/84bd0fe5-be18-4f5a-991c-b28c2a8899ef)
Default Boot Loader Entry:
title: Arch Linux
id: arch.conf
source: /boot/loader/entries/arch.conf
linux: /vmlinuz-linux
initrd: /initramfs-linux.img
options: cryptdevice=UUID=44fbbcd5-8d8e-4978-9c32-ffcaa646554f:cryptlvm root=/dev/vgcrypt...
Reboot, Gnome-Installation
Mit Strg+D verlassen Sie nun die chroot-Umgebung. reboot startet den Rechner neu. Wenn alles gut geht, erscheint das minimalistische Boot-Menü von systemd-boot. Wenige Sekunden später landen Sie in einer Textkonsole mit dem ebenso minimalistischen Arch Linux.
Da mein Notebook mit einem Ethernet-Kabel an das lokale Netzwerk verbunden ist, kann die Netzwerkverbindung unkompliziert durch die Aktivierung des NetworkManagers hergestellt werden.
systemctl enable --now NetworkManager
Danach habe ich den SSH-Server installiert:
pacman -Syu openssh
Für einen Verbindungsaufbau als root mit Passwort muss /etc/ssh/sshd_config geändert werden (PasswordAuthentication yes und PermitRootLogin yes). Danach aktivieren Sie den SSH-Server und können alle weiteren Arbeiten via SSH durchführen.
systemctl enable --now sshd
Im nächsten Schritt ist es zweckmäßig, einen Benutzer (hier kofler) sowie sudo einzurichten:
Jetzt ist es an der Zeit, eine grafische Benutzeroberfläche zu installieren. Ich habe mich für Gnome entschieden:
pacman -S xorg gnome
pacman stellt nun eine Menge Detailfragen. Ich habe alle xorg- und Gnome-Pakete installiert und mich für wireplumber als Pipewire-Session-Manager entschieden. Das Grafiksystem starten Sie wie folgt:
systemctl enable --now gdm
Gnome 41 unter Arch Linux
Überraschend problemlos verläuft die Installation der NVIDIA-Treiber:
pacman -S nvidia
reboot
Aktuell läuft Gnome 41 unter Xorg absolut zufriedenstellend. Mit Gnome 42 werde ich später testen, ob die Kombination aus NVIDIA + Wayland + Gnome mittlerweile praxistauglich ist.
Update 7.4.2022: Getestet mit Gnome 42 und NVIDIA-Treiber (Version 510). Um das Modesetting zu aktivieren, habe ich einen neuen systemd-boot-Loader-Eintrag mit nvidia-drm.modeset=1 erstellt. Das System samt Gnome + Wayland lässt sich problemlos hochfahren, aber der externe Monitor bleibt schwarz. (Der Monitor wird in den Gnome-Einstellungen erkannt, ich kann ihn konfigurieren, aber egal was ich mache: Der Monitor bleibt im Energiesparmodus.) Ich weiß, dass xorg veraltet ist, aber es funktioniert wenigstens :-)
Erfahrungen und Anmerkungen
Die fertige Anleitung liest sich so, als könnte man nicht viel falsch machen. Das täuscht. Ich habe den Prozess zuerst in einer virtuellen Maschine samt EFI »geübt«, und es waren mehrere Versuche notwendig, bis es wirklich funktioniert hat. Natürlich gibt es im Internet Dutzende Arch-Linux-Installationsanleitungen — aber jede bezieht sich auf einen anderen Sonderfall, manche sind veraltet etc. Insofern trifft zu, was ich schon früher geschrieben habe: Arch Linux richtet sich an fortgeschrittene Anwender.
Ich habe mein Glück auch mit archinstall versucht, bin aber gescheitert. Ich bin mir nicht sicher, ob meine Setup-Wünsche für archinstall zu spezifisch waren oder ob ich einfach zu blöd bin, um archinstall korrekt zu verwenden.
Auf grafische Installer (Manjaro etc.) habe ich verzichtet, weil ich ein originales Arch-Linux-System haben wollte.
Meine Arch-Linux-Installation ist ein Experiment mit dem Ziel, Ubuntu als Haupt-Desktop-OS zu verlassen. Ob das glückt, kann ich noch nicht sagen, aber ich werde im Blog weiter darüber berichten. Aktuell habe ich Arch Linux und Ubuntu 21.10 parallel im Betrieb. Ich warte jetzt das Update auf Ubuntu 22.04 ab, aber die Tendenz geht Richtung Arch Linux :-)
Post Scriptum: PCIe-SSDs, LUKS, 4k-Blöcke und Benchmark-Tests
Es gibt im Internet Berichte, wonach LUKS deutlich schneller ist, wenn es 4k-Blöcke verwendet (siehe die Links am Ende des Artikels). Meine SSD, eine Samsung 970 EVO Plus, unterstützt aber nativ keine 4k-Blöcke, sondern meldet wie eine Uraltfestplatte 512-Byte-Blöcke. Manchmal hat man ernsthafte Zweifel am Zustand der IT-Industrie: 512-Byte-Blöcke bei einer SSD mit 2 TByte!
Meine SSD lässt sich, im Gegensatz zu stärker Pro-orientierten SSDs von Samsung, auch nicht mit nvme format auf 4k-Blöcke umstellen. Es ist aber möglich, mit cryptsetup luksFormat --type luks2 --sector-size 4096 LUKS-intern 4k-Blöcke zu erzwingen. Ich habe vor der eigentlichen Installation einige Stunden lang recherchiert und diverse Benchmark-Tests durchgeführt. Die Ergebnisse waren nicht schlüssig; manche Tests waren mit LUKS-4k schneller als bei einem Standard-LUKS-Setup, andere aber langsamer. (Ideal wäre offensichtlich eine SSD, die 4k-Blöcke nativ unterstützt. Dann verwendet auch LUKS standardmäßig 4k und alles passt zusammen. Mangels passender Hardware kann ich aber nicht sagen, wie viel Performance das gebracht hätte.)
Letztenendes habe ich dieses Nebenthema nicht mehr weiter verfolgt und bin bei den Defaulteinstellungen von cryptsetup geblieben, somit bei meiner SSD also bei 512-Byte-Blöcken. Sollten Sie vor dem Kauf einer SSD stehen und vor haben, LUKS zu verwenden, lohnt sich aber eine kurze Recherche, ob die SSD 4k-Blöcke unterstützt oder nicht.
Und noch eines: Ja, die Verschlüsselung durch LUKS kostet bei PCIe-SSDs messbar I/O-Performance. Ein ext4-Dateisystem in einer simplen Partition ist bei synthetischen Tests ca. 10 bis 25 % schneller als eines in einem LUKS-Container.
Davon losgelöst ist es selten sinnvoll, sich von synthetischen Benchmark-Tests verrückt machen zu lassen. Diese Tests haben eingeschränkte Relevanz auf den alltäglichen Desktop-Betrieb — selbst wenn man wie ich viel mit virtuellen Maschinen, deren Images sowie mit Docker hantiert. Anders sieht es aus, wenn Sie einen stark I/O-lastigen Server optimieren möchten — aber in diesem Fall werden Sie vermutlich auf die Verschlüsselung ganz verzichten.
Mit Ubuntu 22.04 »Jammy Jellyfish« hat Canonical die neueste LTS-Version von Ubuntu fertiggestellt. Aktuelle Software kombiniert mit einem Update-Versprechen über fünf Jahre sind die Hauptargumente für die Distribution — und zwar gleichermaßen im Desktop- wie im Server-Segment. Fundamentale technische Neuerungen gibt es keine, einige richtungsweisende Entscheidungen aber sehr wohl: Wayland gilt nun als Default-Grafiksystem, und Firefox wird als Snap-Paket ausgeliefert. Letztere Entscheidung wird nicht nur auf Zustimmung treffen …
Anmerkung: Dieser Blog-Beitrag berücksichtigt ausschließlich das »originale« Ubuntu für den Desktop, nicht die diversen Derivate bzw. die Server-Version.
Installation
Eigentlich wollte Canonical Ubuntu einen neuen, mit der Bibliothek Flutter entwickelten Installer verpassen. Daraus ist nichts geworden, das Programm wurde nicht rechtzeitig fertig. Der Installer ist somit im Vergleich zu den Vorversionen unverändert, was aus meiner Sicht kein Nachteil ist: Das Programm ist einfach zu bedienen und funktioniert gut.
Der Platzbedarf für eine Standardinstallation beträgt ohne /swapfile ca. 6,4 GByte. Wie viel Platz der Installer für die Swap-Datei vorsieht, hängt von der Hardware des Rechners ab, auf dem Sie Ubuntu installieren.
Gut 6 GByte sind zwar angesichts des breiten Software-Angebots akzeptabel, das Attribut »schlank« trifft auf Ubuntu aber schon lange nicht mehr zu. Die Snap-Pakete sind daran nicht alleine Schuld, leisten aber natürlich auch einen Beitrag: Der Platzbedarf für /var/lib/snapd/snaps beträgt anfänglich ca. 640 MByte. Selbst wenn Sie keine weiteren Snap-Pakete installieren, verdoppelt sich der Umfang des Snap-Verzeichnisses früher oder später, weil bei Updates immer auch die vorige Version aller Snap-Pakete erhalten bleibt.
Desktop-Neuerungen
Relativ viele Änderungen bzw. neue Einstellmöglichkeiten gibt es im Gnome-Desktop. Zum Teil handelt es sich dabei einfach um neue Features von Gnome 42, zum Teil um Erweiterungen, die Canonical in den Gnome-Desktop integriert hat:
In den Einstellungen kann zwischen der normalen Darstellung der Fenster und dem »Dark Mode« gewechselt werden.
Es stehen zehn Kontrastfarben für ausgewählte Elemente zur Auswahl.
Auf dem Desktop können unkompliziert Icons abgelegt werden. Dazu ziehen Sie Dateien oder Verzeichnisse per Drag&Drop aus dem Dateimanager auf den Desktop. Intern werden die Dateien dadurch in das Verzeichnis Schreibtisch verschoben.
Bei Notebooks kann im Systemmenü einer von mehreren Energiemodis aktiviert werden.
Die Tools zur Aufnahme von Screenshots bzw. Screencasts wurden modernisiert.
Die Ubuntu-Variante der Gnome-Einstellungen bietet mehr Optionen als das OriginalDer Gnome-Desktop im Dark Mode und mit einer grünen Kontrastfarbe
Beachten Sie, dass die Verwaltung der Gnome Shell Extensions im Snap-Firefox nicht funktioniert. Sie müssen stattdessen das Paket gnome-shell-extensions installieren und ausführen.
Unter Ubuntu sind drei Gnome Shell Extensions vorinstalliert. Die Konfiguration kann bei Bedarf über das Programm »gnome-extensions« erfolgen.
Software-Versionen
Wie üblich wurden fast alle Software-Versionen auf den aktuellen Stand gebracht. Erfreulicherweise trifft dies auch für Gnome zu, das in der aktuellen Version ausgeliefert wird. Ausgenommen sind lediglich vereinzelte Gnome-Anwendungen: In Gnome 42 wurden einige Apps auf die neue Bibliothek GTK4 aktualisiert. Ubuntu geht solchen Programmen aus dem Weg und verwendet gegebenenfalls die ältere Version. Das betrifft z.B. die Kalender-App (gnome-calendar).
Wie bereits in Version 21.10 wird Firefox nicht mehr als »gewöhnliches« Paket, sondern in Kooperation mit der Mozilla-Organisation als Snap-Paket ausgeliefert. Für Canonical erleichtert das die Wartung. Für den Anwender ergeben sich daraus aber drei Nachteile:
Der Platzbedarf auf dem Datenträger und im RAM ist wesentlich höher.
Der erstmalige Start des Programms spürbar langsamer. Selbst die Ubuntu-freundliche Website omgubuntu macht sich darüber in einem Video lustig (siehe ab 3:40). Der lahme Start hat damit zu tun, dass nicht nur Firefox an sich geladen wird, sondern auch ein riesiges Paket von (vollkommen redundanten) Bibliotheken.
Es gibt Kompatibilitätsprobleme, z.B. im Zusammenspiel mit der Verwaltung der Gnome-Shell-Erweiterungen oder mit dem Passwort-Tool KeePass.
Wenn Sie das Firefox-Snap-Paket durch ein traditionelles Paket ersetzen möchten, gehen Sie so vor:
Vorsicht: Einfach sudo apt install firefox funktioniert nicht, weil dadurch neuerlich das Snap-Paket installiert wird! Damit das nächste apt update nicht wieder die Snap-Version von Firefox installiert, müssen Sie außerdem die Priority-Einstellungen für apt verändern:
Alternativ können Sie natürlich auch Chrome (von der Google-Website) oder Chromium (Paket chromium-browser) installieren.
Wayland per Default
Wie alle gängigen Distributionen werden auch bei Ubuntu der herkömmliche Grafik-Server Xorg und das neue System Wayland parallel installiert. Nach Möglichkeit kommt in Ubuntu 22.04 standardmäßig Wayland zum Einsatz. Im Idealfall soll das sogar bei Grafikkarten mit NVIDIA-Treiber funktionieren. Auf meinem Notebook (Lenovo P1, Quadro P1000 Mobile), ist das aber nicht der Fall: Beim Login gibt es keine Wahl zwischen den unterschiedlichen Grafikbibliotheken, Gnome verwendet wie in älteren Ubuntu-Versionen Xorg (X11) als Grafiksystem. Vermutlich liegt das daran, dass Hybridsysteme (Intel + NVIDIA GPU) noch nicht unterstützt werden.
Zusammenfassung der Eckdaten in den Gnome-Einstellungen
Dafür hat Wayland bei meinen Tests anstandslos in virtuellen Maschinen funktioniert. Auch das Zusammenspiel auf Computern mit Intel- oder ADM-Grafik sollte klappen.
Distributions-Update mit »do-release-upgrade«
Auf meinem Arbeits-Notebook habe ich zwei Tage vor dem offiziellen Release ein Update von Version 21.10 auf die aktuelle Version durchgeführt. Der Prozess hat zwar ca. eine Stunde gedauert, ist aber komplett problemlos verlaufen.
sudo apt update
sudo apt dist-upgrade
sudo reboot
sudo do-release-upgrade -d --allow-third-party
...
11 packages are going to be removed. 174 new packages
are going to be installed. 2198 packages are going to
be upgraded.
You have to download a total of 2,857 M. This download
will take about 7 minutes with your connection.
Installing the upgrade can take several hours. Once the
download has finished, the process cannot be canceled.
...
Fazit
Für Linux-Einsteiger bzw. Leute, die Linux als Desktop-Betriebssystem anwenden möchten, ohne sich Gedanken über technische Hintergründe zu machen, ist Ubuntu weiterhin eine gute Wahl:
In aller Regel funktioniert Ubuntu ganz einfach.
Das Aussehen und Verhalten des Desktops ist (aus meiner Sicht) besser als bei Distributionen mit dem originalen Gnome.
Ubuntu bietet inklusive PPAs und Snaps das wohl beste Software-Angebot in der Linux-Welt.
Dank der großen Verbreitung ist es einfach, im Freundeskreis oder im Internet Hilfe zu finden.
Ich kann für diese Zielgruppe unter den aktuellen Distributionen keine bessere Alternative zu Ubuntu erkennen. Am ehesten ist wohl Linux Mint geeignet (das aber selbst von Ubuntu abgeleitet ist).
Persönlich spricht mich Ubuntu allerdings immer weniger an. Ich halte Snap-Pakete für einen Irrweg (und die von Red Hat favorisierte Alternative FlatPak auch nicht nennenswert besser). Der LTS-Vorteil einer langen Lebenszeit ist für mich angesichts des über den Verlauf der Jahre zunehmend veralteten Software-Stacks für meine Desktop-Anwendung als Entwickler/Admin uninteressant.
Warum muss ich ein Distributions-Update machen, damit ich die neueste Version von git verwenden kann? Oder von LibreOffice? Damit ich in einer aktuellen Version von Python programmieren kann? Die Zeiten, in denen sich Linux mit jedem Distributions-Update grundlegend verändert, sind seit etlichen Jahren vorbei. Die Zeit ist reif für Rolling-Release-Distributionen, bei denen eine einmalige Installation und in der Folge »kleine« Updates ausreichen.
Wer heute ein neues Notebook kauft und darauf Linux installiert, sollte dieses während der Lebenszeit des Geräts (vielleicht fünf bis sieben Jahre?) mit simplen Updates nutzen können.
In den vergangenen drei Jahren habe ich auf meinem Notebook alle halbe Jahr ein Release-Update von Ubuntu n auf Ubuntu n+1 durchgeführt. Grundsätzlich sind diese Updates keine Hexerei, aber sie dauern relativ lange und durchbrechen die »normale« Nutzung. Nicht selten gibt es während des Updates oder danach Probleme.
Die Verwendung einer LTS-Version, wie ich dies auf meinen Servern handhabe und »Normalanwendern« empfehle, kommt für mich privat nicht in Frage: Als IT-Autor muss ich die gerade neuesten Versionen diverser Programme ausprobieren und will dabei nicht (nur) in virtuellen Maschinen bzw. mit Docker arbeiten.
Natürlich könnte ich statt Ubuntu auch Debian, Fedora oder openSUSE verwenden — aber das Grundproblem ändert sich nicht. Regelmäßig sind, losgelöst von »normalen« Paket-Updates, disruptive Distributions-Updates erforderlich.
In der fernen Vergangenheit waren derartige Distributions-Updates oder gar Neuinstallationen unumgänglich, weil es fundamentale Neuerungen gab: Der Wechsel des Init-Systems von Init-V über Upstart zu systemd, der Wechsel des Dateisystems von ext2 zu ext3, reiserfs, btrfs, xfs oder ext4 (je nach Vorliebe), neue Verfahren, um das Internet per Modem, ISDN, ADSL und WLAN zu nutzen etc. Wann gab es zuletzt derart weitreichende Strukturänderungen in einer Linux-Distribution?
Linux ändert sich aktuell nur inkrementell. Das ist nichts Negatives, sondern ein Zeichen dafür, wie sehr sich Linux im Verlauf von drei Jahrzehnten stabilisiert hat.
Man kann über Extra-Paketformate wie Snap oder Flatpak streiten, über die Segnungen der neuesten Gnome-Version diskutieren, aber letztlich sind die so eingeführten Neuerungen kein zwingender Grund für einen Komplettumbau der ganzen Distribution, weder durch eine Neuinstallation, noch durch ein Distributions-Update.
Was für Firefox, Google Chrome und Thunderbird nun schon seit Jahren selbstverständlich ist, nämlich ein sofortiges Update zur nächsten Version sobald diese fertig ist, genau das will ich auch für andere Werkzeuge des täglichen Bedarfs: git, ssh, zsh, Python, Emacs, vi, Gimp, LibreOffice usw.
Rolling-Release-Distributionen
Die Lösung sind Rolling-Release-Distributionen: Nach einer einmaligen Installation werden je nach Gusto und Sicherheitslage täglich, wöchentlich oder monatlich Paket-Updates installiert. Damit bleibt die ganze Distribution auf dem aktuellen Stand — über viele Jahre hinweg (im Idealfall über die ganze Lebensdauer des Computers).
Natürlich gibt es derartige Distributionen seit Jahren, ja Jahrzehnten (!), wie der folgende Überblick ohne Anspruch auf Vollständigkeit zeigt:
Arch Linux (verfügbar seit 2001) richtet sich schon bei der Installation dezidiert an Experten. In seiner eng umrissenen Zielgruppe ist Arch Linux seit Jahren sehr populär und gewinnt immer mehr Zulauf, zuletzt auch vom Autor dieser Zeilen …
EndeavourOS und Manjaro sind benutzerfreundlichere Varianten von Arch Linux. Das reicht immerhin für die Plätze 2 und 4 im distrowatch-Ranking. Auch wenn dieses Ranking umstritten ist, ist es ein Indiz dafür, dass das Rolling-Release-Modell im Mainstream angekommen ist. (Arch Linux, also das Original, lag im April 2022 übrigens nur auf Platz 22.)
Mit openSUSE Tumbleweed beweist auch SUSE seit 2014, dass das Rolling-Release-Modell funktioniert. Dennoch fliegt Tumbleweed weitgehend unter dem Radar der IT-Berichterstattung. Es ist schwer zu sagen, ob das am mangelnden Marketing oder an den YaST-Eigenheiten liegt. Persönlich hat meine Begeisterung für SUSE-Distributionen jeder Art in den letzten 10 Jahren stark nachgelassen, wobei ich nicht konkret festmachen kann, weshalb: Vielleicht ist es die Kombination von vielen distributionsspezifischen Sonderwegen kombiniert mit zu wenig aktueller Dokumentation?
Der Rolling Rhino Remix versucht, Ubuntu zu einer Rolling-Release-Distribution macht. Im Wesentlichen ersetzt es die regulären Paketquellen durch devel-Quellen. Um die Updates kümmert sich dann das Script rhino-update. Dieser Ansatz ist zwar simpel, richtet sich aber an sehr experimentierfreudige Linux-User. (So gesehen kann man den Debian-Unstable-Zweig sid auch als Rolling-Release-Distribution bezeichnen.)
Rolling Release für die Massen?
Bei aller Begeisterung für die verfügbaren Rolling-Release-Distributionen fristen diese doch ein Nischendasein. Linux-Einsteiger starten typischerweise mit Ubuntu, Mint oder einer ähnlichen Distribution. Um das Rolling-Release-Modell massentauglich zu machen, müsste einer der Big Player, also z.B. Red Hat (IBM) oder Canonical, auf diesen Zug aufspringen. Das ist unwahrscheinlich: Das Rolling-Release-Modell entfaltet seine Attraktivität eher auf dem Desktop als auf dem Server. Red Hat, SUSE, Canonical & Co. verdienen Ihr Geld aber mit Server-Kunden.
Außerdem gibt es für technisch nicht versierte Desktop-Nutzer noch ein Hindernis: Gnome! Mit wirklich jedem Update funktioniert irgendeine der von mir genutzten Extensions nicht mehr (und ich bin schon dankbar, wenn es nur eine ist). Und leider sind viele Gnome-Konzepte einfach inkompatibel zu meinen persönlichen Vorlieben: Ohne Dash-to-Dock mag ich Gnome ganz einfach nicht verwenden.
Fazit
Meine Wünsche werden wohl Träume bleiben. Für mich persönlich heißt die Lösung aktuell Arch Linux. Nach zwei Monaten im Dauereinsatz bin ich auf keine unüberwindlichen Hindernisse gestoßen. Ob meine Begeisterung ausreicht, dass ich mein Notebook bis zu seiner Ablöse ohne Linux-Neuinstallation nutzen kann, muss sich aber erst zeigen.
Dessen ungeachtet kann ich mir nicht vorstellen, dass sich Arch Linux außerhalb der Freak- und Experten-Liga durchsetzt. Das Rolling-Release-Linux, das ich guten Gewissens auf den Rechner eines technisch nicht versierten Freunds oder einer Verwandten installieren würde, habe ich noch nicht gefunden.
Vergleichsweise kurze drei Jahre dauerte es von RHEL 8 bis RHEL 9: Vor ca. zwei Wochen präsentierte Red Hat die neueste Version von Red Hat Enterprise Linux. Diese Linux-Distribution wird in den nächsten Jahren als Referenz für den kommerziellen Linux-Einsatz gelten.
Das Rennen, wer als erster einen RHEL9-Klon fertigstellen kann, hat AlmaLinux gewonnen. AlmaLinux zählt neben Rocky Linux und Oracle Linux zu den drei wichtigsten CentOS-Nachfolgern. (Zur Erinnerung: CentOS, der in der Vergangenheit populärste RHEL-Klon, wurde von Red Hat Ende 2021 eingestellt. CentOS Stream, ein neues Angebot von Red Hat, hat eine andere Zielgruppe als das originale CentOS.)
Nur 9 Tage nach dem RHEL-Release steht AlmaLinux 9 für dieselben vier CPU-Architekturen wie das Original zur Auswahl: x86_64, aarch64, ppc64le und s390. Zusätzlich zu den »gewöhnlichen« Installations-ISO-Images gibt es Live-Images, die neben Gnome auch die (von Red Hat nicht offiziell unterstützten) Desktop-Systeme KDE und Xfce enthalten. AlmaLinux gibt es auch in Form von Docker-Images, zur Installation für den Raspberry Pi, zur Installation im Windows Subsystem for Linux (WSL) sowie für diverse Cloud-Plattformen. Dass AlmaLinux diese riesige Software-Palette wenige Tage nach dem RHEL-Release anbieten kann, ist beeindruckend.
Dieser Blog-Beitrag wirft einen ersten Blick auf AlmaLinux 9 für x86-64-CPUs.
AlmaLinux 9 verwendet Gnome 40 als Desktop
Installation und Betrieb
An der Installation von RHEL bzw. AlmaLinux hat sich im Vergleich zu Version 8 praktisch nichts verändert. Das Installationsprogramm funktioniert unverändert. Unübersichtlich wie eh und je ist die Partitionierung der Datenträger (falls erforderlich). Alle anderen Schritte sind schnell und intuitiv erledigt.
Installation von AlmaLinux 9
Für die Konfiguration von RHEL bzw. AlmaLinux gewinnt Cockpit weiterhin an Bedeutung. Die Webkonsole muss mit systemctl enable --now cockpit.socket aktiviert werden und kann dann über Port 9090 im Webbrowser verwendet werden.
Konfiguration von AlmaLinux durch Cockpit
Für nicht offizielle Zusatzpakete ist EPEL weiterhin die erste Wahl. Die Paketquelle wird unter AlmaLinux einfach mit dnf install epel-release aktiviert.
Versionsnummern
Wie üblich steht bei RHEL 9 und damit auch bei allen Klonen Stabilität vor Aktualität. Im Vergleich zu Version 8 ist der Software-Stack aber doch deutlich aktueller. Das AppStream-Konzept wird von wichtigen Programmiersprachen und Server-Paketen in Zukunft auch neuere Versionen zur Auswahl stellen.
Abseits der Versions-Updates gibt es in RHEL9 verblüffend wenig »echte« Neuerungen.
Firewall: Die Firewall-Funktionen verwenden nun nft als neues Fundament. In der Praxis ändert das vorerst wenig, iptables steht als kompatibles Kommando weiterhin zur Verfügung. Die Release Notes warnen allerdings davor, die in iptables-nft enthaltenen Kommandos einzusetzen. Die Kompatibilitätsschicht wird nicht weiterentwickelt, neue Firewall-Scripts sollen nativ nft verwenden.
Netzwerkkonfiguration: Das traditionsreiche Verzeichnis /etc/sysconfig/network-scripts ist jetzt leer. Standardmäßig erfolgt die Konfiguration der Schnittstellen nun direkt durch Dateien im Verzeichnis /etc/NetworkManager/system-connections. (Das NetworkManager-Plugin ifcfg-rh zur Verarbeitung von Konfigurationsdateien in network-scripts steht aber weiterhin zur Verfügung und funktioniert unverändert. Es befindet sich im Paket NetworkManager. Details siehe man nm-settings-ifcfg-rh sowie man NetworkManager.conf.)
Core Scheduling: Mit Core Scheduling besteht die Möglichkeit, einer Gruppe von Prozessen eine CPU-Core zuzuweisen. Das kann aus Sicherheits- oder Performance-Gründen zweckmäßig sein. Mehr Details sind hier beschrieben.
Grafiksystem: Schon RHEL 8 setzte standardmäßig auf Wayland. Neu ist, dass X.org in den Release Notes nun als deprecated bezeichnet wird. Offensichtlich sollen die X.org-Pakete in zukünftigen RHEL-Versionen entfernt werden. Für die X-Kompatibilität ist Xwayland zuständig.
Virtualisierung: Wie schon in RHEL 8 ist virt-manager als deprecated markiert. Das Paket steht aber weiterhin zur Verfügung. Längerfristig soll virt-manager durch Cockpit ersetzt werden.
Podman: Red Hat setzt anstelle von Docker weiter auf die Eigenentwicklung Podman. RHEL/AlmaLinux 9 enthält die erst im Februar 2022 vorgestellte Version 4.0 von Podman.
Fazit
RHEL 9 ist, was die technischen Neuerungen betrifft, ein eher unspektakuläres RHEL-Release.
Erfreulich entwickelt hat sich das Angebot der RHEL-Klone: Vor zwei Jahren hatte ich befürchtet, ohne CentOS würde ein riesiges Loch in der RHEL-Welt entstehen. Stattdessen gibt es nun mit Rocky Linux und AlmaLinux zwei neue, sehr aktive und offenbar gut finanzierte Angebote. Zusammen mit Oracle Linux und einigen weiteren Anbietern ist das Klon-Angebot breiter denn je.
Es ist schwer, unter den Klonen einen eindeutigen Favoriten zu erkennen. Seit 18 Monaten sticht Alma Linux aber durch besonders schnelle Reaktionszeiten hervor — d.h. die Wartezeiten nach offiziellen RHEL-Releases beträgt jeweils nur wenige Tage. Insgesamt ist es beruhigend zu sehen, dass es nicht ein Angebot gibt, sondern eine gesunde Konkurrenz zwischen mehreren Anbietern (samt Scripts, die einen unkomplizierten Wechsel ermöglichen).
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:
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ß:
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.
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):
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.)
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.
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.
Multipass ist eine von Canonical entwickelte Software, um Ubuntu als virtuelle Maschine unter Linux, Windows oder macOS auszuführen. Ich bin über Multipass gestolpert, weil ich eine unkomplizierte Möglichkeit suchte, Ubuntu unter macOS mit M1/M2-CPU auszuführen. Dieser Artikel stellt zuerst Multipass kurz vor. Es folgt eine persönliche (= subjektive) Wertung.
Linux: Für Linux steht leider nur ein Snap-Paket zur Verfügung: sudo snap install multipass
Arch Linux stellt Multipass als AUR-Paket zur Verfügung: https://aur.archlinux.org/packages/canonical-multipass (Paket wird lokal kompiliert, das dauert > 15 Minuten; bei mir gab es zuletzt einen Fehler, dem ich nicht auf den Grund gegangen bin)
Multipass Command Line Interface (CLI)
Multipass wird über Kommandos in der Konsole genutzt. Um zu überprüfen, dass die Installation geklappt hat, führen Sie multipass version aus:
multipass version
multipass 1.10.1+mac
multipassd 1.10.1+mac
Die zur Auswahl stehenden Multipass-Images ermittelt multipass find:
Um eine neue Instanz zu starten, führen Sie multipass launch aus. Beim ersten Start muss das betreffende Image heruntergeladen werden, hier für Ubuntu 22.04. Der Start weiterer Instanzen erfolgt wesentlich schneller.
Das folgende Kommando erzeugt eine Instanz von Ubuntu 22.04 und gibt dieser den Namen myinstance.
multipass launch -n myinstance 22.04
Standardmäßig erhält die neue VM eine CPU, 1 GB RAM und eine Disk mit 5 GB und NAT-Networking. Andere Eckdaten können Sie mit Parametern festlegen:
-c <n>: Anzahl der CPU-Cores
-d <n>G: Disk-Größe, -d 15G für 15 GB Disk
-m <n>M oder -m <n>G: RAM, z.B. -m 4G für 4 GB RAM
-n <name> oder -n primary: gibt der VM einen Namen bzw. macht sie zur primären Instanz
multipass launch startet die VM, führt sie aber im Hintergrund aus. Um die VM zu bedienen, führen Sie multipass shell <name> aus:
Als Standard-User ist ubuntu aktiv. Dieser Benutzer ist nicht mit einem Passwort abgesichert und hat sudo-Rechte. Auch wenn Multipass-VMs normalerweise nur in einem privaten Netzwerk zugänglich sind (192.168.*.*), sollten Sie den ubuntu-Account mit einem Passwort absichern: sudo passwd ubuntu.
multipass list listet die aktuell eingerichteten Instanzen auf und gibt an, welche IP-Adresse der Instanz zugeordnet ist.
multipass list
Name State IPv4 Image
primary Running 192.168.64.7 Ubuntu 22.04 LTS
myinstance Running 192.168.64.8 Ubuntu 22.04 LTS
Mit multipass info <name> können Sie mehr Details zu einer VM ermitteln.
multipass info myinstance
Name: myinstance
State: Running
IPv4: 192.168.64.8
Release: Ubuntu 22.04.1 LTS
Image hash: 9620f479bd5a (Ubuntu 22.04 LTS)
Load: 0.28 0.25 0.10
Disk usage: 1.4G out of 4.7G
Memory usage: 153.5M out of 961.9M
multipass start <name> oder multipass stop <name> startet bzw. beendet die Ausführung einer VM.
multipass delete <name> löscht die VM vorläufig. Der Vorgang kann mit multipass revover rückgängig gemacht werden.
Erst multipass purge entfernt die zuvor gelöschten VMs endgültig und gibt den Speicher frei.
Eine VM kann als »primär« gekennzeichnet werden (launch -n primary ...). Das hat zwei Konsequenzen:
An einige multipass-Kommando braucht kein Name als Parameter übergeben werden. Beispielsweise bezieht sich multipass shell automatisch auf die primäre Instanz.
Innerhalb der VM steht das lokale Heimatverzeichnis (also das des Host-Computers) unter /home/ubuntu/Home zur Verfügung. Das ermöglicht einen unkomplizierten, nahtlosen Zugriff auf Host-Dateien durch die VM.
Bridged Networking
Wenn Sie VMs in das lokale Netzwerk integrieren möchten, ermitteln Sie zuerst mit multipass networks die zur Auswahl stehenden Netzwerkschnittstellen und aktivieren dann eine davon für die Netzwerkbrücke:
multipass networks
Name Type Description
bridge0 bridge Network bridge with en2, en3
en0 ethernet Ethernet
en1 wifi Wi-Fi
en2 thunderbolt Thunderbolt 1
...
multipass set local.bridged-network=en1
In der Folge können Sie an multipass launch die Option --bridged übergeben.
Ubuntu samt Desktop installieren
Um Ubuntu samt Desktop zu installieren, müssen Sie die VM ausreichend groß dimensionieren:
Sie müssen wissen, welche IP-Adresse Ihre VM hat. Dazu führen Sie innerhalb der VM hostname -I aus, oder außerhalb multipass list.
ubuntu@primary:~$ hostname -I
192.168.64.10
Jetzt brauchen Sie einen RDP-Client. Unter Linux funktionieren die meisten VNC-Viewer. Unter macOS installieren Sie am einfachsten im App Store Microsoft Remote Desktop. Dort richten Sie eine neue Verbindung ein und verwenden die zuvor ermittelte IP-Adresse. In der Regel ist es sinnvoll, die Option Start session in full screen zu deaktivieren. Hingegen ist die Optionen Update the session resultion on resize zweckmäßig. Die Anpassung der virtuellen Bildschirmauflösung hat bei meinen Tests (macOS als Host-System) ausgezeichnet funktioniert. Außerdem sollten Sie als User accountubuntu angeben.
Beim ersten Start erscheint der Ubuntu-Setup-Assistent. Dort können Sie das deutsche Tastaturlayout hinzufügen. (Standardmäßig ist nur das englische Layout installiert.)
Der Desktop erscheint in englischer Sprache. Die Umstellung auf Deutsch können Sie im Programm Settings durchführen. Die Änderung wird nur wirksam, wenn Sie sich aus- und neu einloggen.
Grundsätzlich hat der Ubuntu-Desktop bei meinen Tests ausgezeichnet funktioniert — allerdings mit »Vanilla Gnome«, d.h. ohne die Ubuntu-spezifischen Erweiterungen wie dem verschiebbaren Dock. Auch die entsprechenden Optionen im Programm Einstellungen fehlen. (Die Optionen tauchen auf, wenn das Einstellungsprogramm mit XDG_CURRENT_DESKTOP=ubuntu:GNOME gnome-control-center gestartet wird. Aber die Ubuntu-spezifischen Einstellungen bleiben wirkungslos.)
Ubuntu wird auf einem Mac mit M1-CPU ausgeführt und über ein RDP-Fenster bedient.
Multipass versus herkömmliche Virtualisierungssysteme versus Container
Eigentlich möchte man meinen, es gäbe bereits genug Software zur Ausführung von virtuellen Maschinen und Containern. Was kann Multipass also bieten, was andere Programme nicht können? Und wo sind die Grenzen von Multipass?
Im Gegensatz zu Docker oder Podman findet bei Multipass eine echte Virtualisierung statt. Der Overhead einer Installation ist deswegen vergleichsweise groß. Andererseits steht Ubuntu »komplett« zur Verfügung, d.h. mit systemd, mit verschiedenen Benutzern etc.
Standardmäßig werden keine Desktop-Pakete installiert. Diese können nachinstalliert werden. Das setzt aber voraus, dass die VM ausreichend groß dimensioniert ist (RAM, Speicherplatz).
Im Vergleich zu Virtualisierungsprogrammen wie VirtualBox, VMware & Co. hat Multipass keine grafische Oberfläche. Für Profis ist das kein Nachteil, für Einsteiger schon. Es gibt auch keine Grafiktreiber etc. Die Desktop-Nutzung erfolgt über RDP (ein Netzwerkprotokoll) und ist vergleichsweise langsam. Ausreichend schnell für Entwickleraufgaben, aber nicht ideal, um Videos abzuspielen oder Spiele zu spielen.
Der größte Nachteil von Multipass im Vergleich zu Virtualisierungs- und Container-Software besteht darin, dass nur Ubuntu ausgeführt werden kann. Multipass ist also keine universelle Lösung, sondern ein Admin- und Developer-Tool für die Ubuntu-Gemeinde.
Positiv: Multipass ist Open-Source-Software, die Quellen sind auf GitHub zu finden.
Persönliche Bewertung
Meine Beweggründe, mich überhaupt mit Multipass auseinanderzusetzen, ist der Linux-Unterricht. 2/3 der Studentinnen arbeiten mit einem Windows-Notebook, 1/3 mit MacBooks, vielleicht halb/halb mit Intel/Apple-CPU. Jetzt sollen alle eine VM mit Ubuntu installieren. Früher war das einfach: Alle verwenden VirtualBox und richten damit eine VM mit Ubuntu ein (oder Fedora, oder Debian, egal, solange es für alle einheitlich ist).
Heute geht das nicht mehr:
Unter Windows zickt VirtualBox in einen unerträglichen Ausmaß. Ob Microsoft daran Schuld ist (ständige Änderungen an Hyper-V) oder Virtualbox (weil es Hyper-V nicht korrekt nutzt), kann ich nicht beurteile — es ist eigentlich egal. Fakt ist, dass in einer Gruppe von 20 Studierenden VirtualBox bei mindestens zwei nicht funktioniert und die Probleme sich nicht trivial lösen lassen.
Unter macOS läuft VirtualBox nur auf alten Geräten mit Intel-CPU. Auf modernen Geräten mit Apple Silicon (M1, M2 usw.) ist Virtualisierung zwar auch möglich, aber das ist entweder teuer (Parallels, VMware) oder wenig intuitiv (UTM, siehe https://mac.getutm.app/).
Unter Windows kann ich auf WSL ausweichen. Das funktioniert verblüffend gut, aber ist für den Unterricht kein vollwertiger Ersatz. Kein cron, kein systemd etc. Grafische Desktop-Oberflächen laufen auch nur über Umwegen.
Auf allen OS kann ich Docker verwenden. Aber ein Ubuntu-Container ist halt auch kein vollwertiger Ersatz, selbst wenn man vom fehlenden Desktop absieht. Docker hat eine ganz andere Zielsetzung (und da brilliert es).
Zurück zu Multipass: Der Charme besteht darin, dass es OS-übergreifend einen einheitlichen Weg bietet, um Ubuntu in einer virtuellen Maschine auszuführen. Der Desktop-Zugriff erfolgt über RDP, was für den Unterricht gut genug ist. Multipass greift auf das Virtualisierungsframework des jeweiligen Betriebssystem zurück, erfindet diesbezüglich das Rad also nicht neu.
Aber:
Das Einrichten einer Ubuntu-VM in Multipass ist nicht trivial. Für meinen spezifischen Einsatzzweck ist es jedenfalls ungeeignet. Multipass richtet sich an Profis, nicht an Einsteiger.
Ubuntu-only ist auch irgendwie sinnlos. Aus meiner Sicht ist Ubuntu für den Linux-Unterricht gut genug, aber vielleicht will ich Server-Administration unterrichten. Da wäre mir dann Rocky oder Alma Linux lieber. Oder ich bin mit Debian vertrauter als mit Ubuntu, will Snap aus dem Weg gehen usw.
Linux-hostseitig wird Multipass auch nur als Snap-Paket angeboten. In der engen Canonical-Welt mag das OK sein, aber nicht jeder ist ein Fan von Snap.
Langer Rede kurzer Sinn: Multipass richtet sich in erster Linie an Entwickler und Admins, die ausschließlich mit Ubuntu arbeiten. Für diese Zielgruppe ist Multipass durchaus interessant.
Multipass ist auch ein relativ einfacher Weg, um Ubuntu (samt Desktop) auf einem Mac mit M1/M2-CPU auszuführen.
Darüberhinaus ist es aber wohl doch nur eine weitere Insellösung/Eigenentwicklung von Canonical mit ungewisser Zukunft. Die Zielgruppe ist so eng, dass ein Durchbruch aus der Nische nicht zu erwarten ist. Das ist schade, weil Multipass durchaus vielversprechende Ansätze zeigt.
Wer Linux ausprobieren oder samt Desktop anwenden möchte, unter Windows arbeitet und keine physische Installation durchführen will, für den/die ist das Virtualisierungssystem VirtualBox eine attraktive Wahl. Dieser Artikel fasst die wichtigsten Schritte einer Installation von Ubuntu 22.04 zusammen und erklärt auch die Nutzung der Gasterweiterungen und die Konfiguration für eine SSH-Verbindung zwischen Host (=Windows) und der Virtuellen Maschine (VM).
Testumgebung: Windows-PC mit Intel-CPU, Windows 11 Pro mit 22H2-Update (Hyper-V und WSL aktiviert), VirtualBox 7.0
VirtualBox 7 unter Windows 11 mit einer virtuellen Maschine mit Ubuntu 22.04
Der erste Schritt ist die Installation von VirtualBox. Dieses Virtualisierungssystem von Oracle kann von der folgenden Seite kostenlos heruntergeladen werden:
Beachten Sie, dass das Grundprodukt VirtualBox zwar kostenlos genutzt werden darf, das diese Regel aber nicht für das optionale VirtualBox Extension Pack gilt! Dessen Nutzung ist nur Privatnutzern bzw. zur Evaluation erlaubt, erfordert beim Einsatz in Firmen aber eine Lizenz! Die im Extension Pack enthaltenen Funktionen (RDP, Disk Image Verschlüsselung, NVMe und PXE Boot für Intel Systeme) werden normalerweise nicht benötigt. Wenn Sie unsicher sind, installieren Sie das Extension Pack nicht!
Virtuelle Maschine (VM) einrichten
Als Grundlage für die Installation müssen Sie von der Ubuntu-Website ein ISO-Image für Ubuntu 22.04 (64 Bit) herunterladen.
Mit dem Button Neu starten Sie die Installation einer neuen VM. Im ersten Dialog müssen Sie der VM einen Namen geben, einen Speicherort am Hostsystem (in unserem Fall ist das Windows) angeben, ein ISO-Image auswählen sowie Linux-Typ und -Versionsnummer auswählen.
Neue virtuelle Maschine einrichten
Ubuntu 22.04 wird von VirtualBox besonders gut unterstützt. Standardmäßig wird eine Unattended Installation durchgeführt. Damit kommen Sie mit dem Installationsprogramm von Ubuntu gar nicht in Berührung. Stattdessen geben Sie den Hostnamen, den Benutzernamen und das Passwort für die Ubuntu-VM vorweg in einem VirtualBox-Dialog an. In der virtuellen Maschine werden die sogenannten »Gasterweiterungen« automatisch installiert. Das ermöglicht eine bessere Integration zwischen Hostsystem (Windows) und Gast (Ubuntu), z.B. zum Austausch von Text über die Zwischenablage oder zum Austausch von Dateien über ein gemeinsames Verzeichnis (Shared Folder).
Tipp: Verwenden Sie ein Passwort ohne Sonderzeichen und ohne die Buchstaben Y und Z. Nach der Installation gilt für den Ubuntu-Login das US-Tastaturlayout.
Einstellungen für die »Unattended Installation«
Bevor es richtig losgeht, müssen Sie noch die Eckdaten der VM einstellen. Meine Empfehlung:
unbedingt 4 GByte Hauptspeicher/RAM (nicht nur 2 GByte, wie der VirtualBox-Assistent empfieht)
2 CPU-Cores
25 GByte Disk Size (außer, Sie haben vor, in der VM viele große Dateien zu speichern — dann brauchen Sie mehr)
Den Arbeitsspeicher und das RAM können Sie bei Bedarf später unkompliziert verändern. Die Disk-Größe kann hingegen nur sehr umständlich vergrößert werden, eine Verkleinerung ist nahezu unmöglich. Vergleichsweise einfach ist es, später eine zweite Disk hinzuzufügen. Allerdings müssen Sie schon etwas Linux-Erfahrung haben, um die zweite Disk dann auch innerhalb von Ubuntu sinnvoll nützen zu können.
RAM-Größe und CPU-Anzahl einstellenGröße der virtuellen Disk konfigurierenZusammenfassung aller Einstellungen
Nach dem Zusammenfassungsdialog startet VirtualBox die virtuelle Maschine und führt darin — wie von Zauberhand — die gesamte Installation durch. Das dauert einige Minuten, während der Sie nur zusehen können (oder sich einer anderen Aufgabe zuwenden).
Erste Schritte in Ubuntu
Nach Abschluss der Installation wird die virtuelle Maschine neu gestartet. Sie können sich jetzt einloggen, wobei Sie den im Dialog »Unattended Installation« Namen und das dort gewählte Passwort angeben. Das VirtualBox-Fenster ist anfänglich ziemlich klein. Sie können es einfach vergrößern, die Auflösung des Desktops der virtuellen Maschine passt sich automatisch an.
Ein Nachteil der Unattended Installation besteht darin, dass Ubuntu beim ersten Start Englisch als Sprache verwendet und ein US-Tastaturlayout vorsieht. Um die Einstellungen zu ändern, starten Sie das Programm Settings, am einfachsten im Systemmenü, das Sie rechts oben im Panel öffnen.
Die Spracheinstellungen finden Sie im Modul Region & Lanugage. Mit Manage Installed Languages und Install/Remove Language fügen Sie German hinzu. (Dabei müssen diverse Pakete installiert werden, weswegen dieser Vorgang ca. eine Minute dauert.) Schließlich können Sie die Präferenz der Sprachen einstellen, in dem Sie Deutsch in der Liste der installierten Sprachen ganz nach oben verschieben. Die geänderte Sprache ist noch nicht aktiv — dazu müssen Sie sich aus- und neu einloggen.
Vorher sollten Sie gleich noch das Tastaturlayout ändern. Dazu wechseln Sie im Einstellungsprogramm in den Dialog Keyboard, fügen zuerst das neue Layout German hinzu und entfernen dann das Layout English (US).
Damit diese Einstellungen wirksam werden, müssen Sie sich aus- und neu einloggen. Im Systemmenü, das Sie rechts oben im Panel öffnen, klicken Sie zuerst auf Power Off/Log Out und im nun erscheinenden Untermenü auf Log Out.
Normalerweise hat der erste in Ubuntu eingerichtete Benutzer sudo-Rechte. Dafür gibt es unter Ubuntu kein Passwort für den Benutzer root.
Wenn Sie in VirtualBox die Unattended Installation durchgeführt haben, gelten andere Regeln: Der eingerichtete Benutzer gehört nicht zur sudo-Gruppe und hat entsprechend keine administrativen Rechte. Dafür hat der Benutzer root das gleiche Passwort, das Sie dem Standardbenutzer zugewiesen haben.
Damit sich Ubuntu auch in VirtualBox so verhält wie immer, öffnen Sie über Aktivitäten ein Terminal-Fenster und führen dann die folgenden Kommandos aus, mit denen Sie den Standardbenutzer der Gruppe sudo hinzufügen:
username$ su -l
Passwort: ******** (das Passwort, das Sie in VirtualBox
vor der Installation angegeben haben)
root# usermod -a -G sudo <username>
Anstelle von <username> geben Sie den Namen Ihres Accounts an.
Die Änderung wird wiederum erst wirksam, wenn Sie sich in Ubuntu aus- und neu einloggen.
Nachdem Sie sudo repariert haben, können Sie — wenn Sie möchten — noch das Tastaturlayout für den Ubuntu-Login auf Deutsch umstellen. Dazu öffnen Sie ein Terminal-Fenster und führen dort sudo dpkg-reconfigure keyboard-configuration aus. Als Tastaturmodell wählen Sie Generic 105-key PC, als Sprache German. Alle weiteren Optionen bestätigen Sie einfach mit Return.
Zwischenablage aktivieren
Damit Sie unkompliziert Text zwischen dem Host-Rechner (Windows) und der virtuellen Maschine (Ubuntu) über die Zwischenablage austauschen können, führen Sie im Menü des VirtualBox-Fensters Geräte / Gemeinsame Zwischenablage / Bidirektional aus. (Diese Funktion setzt voraus, dass in der virtuellen Maschine die VirtualBox-Gasterweiterungen installiert sind. Das ist bei der Unattached Installation automatisch der Fall. Wenn Sie eine manuelle Installation von Ubuntu durchgeführt haben, müssen Sie die Pakete virtualbox-guest-utils und virtualbox-guest-x11 installieren und außerdem den Ubuntu-Standardbenutzer der zusätzlichen Gruppe vboxsf zuordnen.)
Aktivierung der gemeinsamen Zwischenablage
Gemeinsames Verzeichnis zum Dateiaustausch einrichten
Über Geräte / Gemeinsame Ordner gelangen Sie in einen Dialog, in dem Sie ein Windows-Verzeichnis (in der folgenden Abbildung: Dokumente) mit einem Verzeichnis innerhalb der virtuellen Maschine (hier: /mnt/win-documents) verbinden können. Damit können Sie innerhalb der virtuellen Maschine unkompliziert auf Windows-Dateien zugreifen. (Auch diese Funktion setzt voraus, dass zuvor die VirtualBox-Gasterweiterungen installiert wurden.)
Verzeichnis zum Austausch von Dateien zwischen Host (hier: Windows) und virtueller Maschine (hier: Ubuntu) einrichten
SSH-Zugriff aktivieren
Wenn ich auf Kommandoebene arbeite, bediene ich meine virtuellen Maschinen gerne über SSH. Unter Ubuntu muss dazu der SSH-Server installiert werden, was mit sudo apt install openssh-server rasch gelingt.
Das reicht aber noch nicht: VirtualBox gibt der virtuellen Maschine standardmäßig mittels Network Address Translation Zugriff auf die Netzwerkverbindung des Host-Computers. Die virtuelle Maschine ist aber im Netzwerk des Hosts unsichtbar, eine SSH-Verbindung ist unmöglich.
Die einfachste Lösung ist eine Port-Weiterleitung. Dazu führen Sie im VirtualBox-Fenster Geräte / Netzwerk / Einstellungen aus, klappen bei Adapter 1 den Bereich Erweitert aus und klicken auf Port-Weiterleitung. Nun richten Sie eine neue Regel ein, die Port 2222 des Hosts (127.0.0.1) mit Port 22 der virtuellen Maschine (10.0.2.15) verbindet.
Eine Port-Weiterleitung in der Netzwerkkonfiguration ermöglicht eine SSH-Verbindung zwischen Host (Windows) und Gast (Ubuntu)
Nachdem Sie die Einstellungen gespeichert haben (ein Neustart der virtuellen Maschine ist nicht notwendig), können Sie in cmd.exe oder in der PowerShell von Windows mit dem folgenden Kommando eine SSH-Verbindung in die virtuelle Maschine herstellen:
ssh -p 2222 name@localhost
Wichtig ist dabei die Option -p 2222. ssh soll nicht wie üblich Port 22 verwenden, sondern eben Port 2222. Wichtig ist auch, dass Sie als Zieladresse localhost angeben. Aufgrund der Port-Weiterleitung landen Sie wunschgemäß in der virtuellen Maschine. Anstelle von name geben Sie Ihren Ubuntu-Account-Namen an.
Fazit: VirtualBox 7 für Windows ist wieder OK
Die Windows-Variante von VirtualBox 7 hat mich mit dem Programm ein wenig versöhnt. In den letzten Jahren hatte ich unter Windows nämlich derart häufig Stabilitätsprobleme (ausgelöst vermutlich durch das schlechte Zusammenspiel mit Hyper-V), dass ich den Einsatz von VirtualBox für Windows nicht mehr empfohlen habe und diesen auch im Linux-Unterricht — so gut wie möglich — vermieden habe. Mit Version 7 hatte ich diesbezüglich (bisher) keine Probleme — gut so.
Ein wenig irritierend ist der bunte Mix von deutschen und englischen Texten in den Dialogen. Aus meiner Sicht wäre English Only die beste Option. Aber wenn eine deutschsprachige GUI erwünscht ist, wäre es gut, die Lokalisierung konsequent fertigzustellen. So wirkt das halbfertig.
Die Unattended Installation überzeugt mich nicht: Was ich an Zeit während der Installation gespart habe, musste ich später wieder investieren, um Sprach- und Tastatureinstellungen zu ändern und die sudo-Konfiguration zu reparieren. Da ist mir eine manuelle Installation lieber, das weiß ich wenigstens, was ich bekomme. Als einziger Vorteil bleibt die automatische Installation der VirtualBox-Gasterweiterungen, deren manuelle Durchführung mühsam ist.
Nachwort: VirtualBox 7 für Macs mit M1/M2
VirtualBox 7 unterstützt erstmals auch Apple Rechner mit Apple Silicon (M1, M2 …). Oracle weist explizit darauf hin, dass diese Funktionen noch experimentell und langsam sind. Ich habe VirtualBox 7 auf einem Mac Mini mit M1-CPU dennoch ausprobiert, und war etwas konsterniert: Die virtuellen Maschinen müssen eine 32-Bit x86-CPU verwenden (kein 64-Bit x86, auch nicht ARM).
Ganz egal, wie die Performance ist, engt das die Auswahl doch sehr stark ein. Viele Desktop-Distributionen für x86 sind 64-Bit-only. Ich hätte eigentlich erwartet, dass VirtualBox wie UTM auf virtuelle Maschinen für die ARM-Plattform setzt, aber meine diesbezüglichen Experimente sind ins Leere gegangen.
Gescheitert bin ich selbst mit dem Versuch, eine 32-Bit-Version (i386) von Debian zu installieren — selbst hier die Nachricht unsupported CPU. Diese Beta ist wirklich noch sehr experimentell :-(
Wie berichtet, habe ich mein Arbeits-Notebook im Frühjahr 2022 auf Arch Linux umgestellt. Bisher für mich eine Erfolgsgeschichte, alles läuft, wie es soll, und ich habe stets aktuelle Software. Mein Interesse an anderen Distributionen hat seither spürbar nachgelassen.
Mit dem letzten Update, das ich gestern durchgeführt habe, begann allerdings das Grafiksystem zu spinnen. Während sich der Maus-Cursor weiterhin flüssig bewegt, sinkt die Framerate beim Verschieben eines Fensters auf deutlich unter 1 fps (d.h. vernünftiges Arbeiten ist undenkbar).
Die Umstände des Fehlers sind merkwürdig: Der Totaleinbruch der Grafikgeschwindigkeit kommt nur zustande, wenn mein Notebook mit einem externen 4k-Monitor verbunden ist UND der Notebook-Deckel geschlossen ist.
Interessanterweise wird die Grafikgeschwindigkeit wieder normal, sobald ich den Notebook-Deckel öffne und somit BEIDE Bildschirme aktiv sind. Und, wie gesagt: das Setup hat jetzt über sieben Monate wunderbar funktioniert, ich habe nichts geändert. Irgendein Update (ich kann nicht sagen, welcher Komponente: Kernel, NVIDIA-Treiber, Xorg?) hat das fragile Gleichgewicht gestört.
Die Lösung: optimus-manager
Kurzes googlen führt zu diesem Forumbeitrag von 2021, der exakt mein Problem beschreibt:
Die dort beschriebene Lösung: optimus-manager installieren.
Der optimus-manager ist ein kleines Script, um den Grafiktreiber explizit zwischen einer integrierter CPU-Grafik und der externer GPU umzuschalten. Unter Ubuntu hatte ich in der Vergangenheit schon Erfahrungen mit prime-select gemacht. optimus-manager greift offenbar die gleiche Idee und (zumindest was gdm betrifft) den gleichen Code auf.
Die Aktivierung des optimus-manager verlangt die Installation von zwei AUR-Paketen, eben optimus-manager sowie gdm-prime, eine minimal veränderte Variante von gdm. Ich verwende yay zur Installation:
yay -Sy optimus-manager gdm-prime
Optimus ist anscheinend nicht Wayland-kompatibel. Bei mir ist Wayland sowieso deaktiviert (sonst funktioniert der externe Monitor gar nicht), aber gegebenenfalls müssen Sie eine Zeile in /etc/gdb/custom.conf ändern:
# Datei /etc/gdm/custom.conf
[daemon]
# Uncomment the line below to force the login screen to use Xorg
WaylandEnable=false
Nach einem Rechner-Neustart wird nur die integrierte Intel-GPU verwendet. Abhilfe schafft:
optimus-manager --switch nvidia
Und danach funktioniert mein Rechner wieder wie in den letzten sieben Monate …
Zwei Stunden wertvolle Lebenszeit vergeudet :-(
Fazit
Nie wieder ein Notebook mit NVIDIA. (Ich wiederhole mich, ich weiß …)
Das Windows Subsystem for Linux ist erwachsen geworden. Es ist nur für Windows 10 und Windows 11 im Microsoft Store erhältlich und gilt nicht mehr als »experimentell«. Der größte Vorteil der neuen Bezugsquelle: WSL-Updates werden in Zukunft unabhängig von Windows-Updates viel einfacher und schneller erfolgen.
Die Umstellung auf die Microsoft-Store-Variante ist denkbar einfach: Entweder installieren Sie WSL einfach aus dem Microsoft Store neu (vorhandene WSL-Distributionen bleiben dabei erhalten), oder Sie führen wsl --update aus (das setzt aber voraus, dass Ihre Windows-Version über alle aktuellen Updates verfügt).
Endlich systemd!
Aus meiner persönlichen Perspektive viel interessanter ist der Umstand, dass WSL nun endlich systemd unterstützt. Die Aktivierung erfolgt ganz einfach, in dem Sie in der WSL-Distribution die Datei /etc/wsl.conf verändern und dort zwei Zeilen hinzufügen:
# in /etc/wsl.conf (innerhalb der WSL-Distribution)
[boot]
systemd=true
Die Änderung wird erst aktiv, wenn Sie die Distribution beenden, WSL herunterfahren (wsl --shutdown) und die Distribution dann neuerlich starten. Bei meinen Tests hat die systemd-Aktivierung erstaunlicherweise auch bei WSL-Distributionen funktioniert, die schon recht alt waren (z.B. Ubuntu 21.04).
Ubuntu 22.04 unter WSL 2 mit systemd und cron
Der entscheidende Fortschritt im Vergleich zu älteren WSL-Versionen ohne systemd besteht darin, dass es nun endlich unkompliziert möglich ist, Server-Dienste (SSH, Apache, MySQL usw.) so einzurichten, dass Sie mit dem Start der WSL-Distribution automatisch mitaktiviert werden. Auch Cron-Jobs funktionieren jetzt ohne Verrenkungen.
Beachten Sie, dass Server-Dienste nur zur Verfügung stehen, solange die betreffende WSL-Distribution aktiv ist, also ein WSL-Fenster geöffnet ist.
SSH-Ärger
Noch zwei Tipps zum Betrieb eines SSH-Servers unter WSL mit Ubuntu 22.04. Der initiale Start scheitert, weil es keine SSH-Host-Keys gibt, und weil die sonst übliche automatischer Erzeugung beim ersten Start aus mir nicht nachvollziehbaren scheitert. Abhilfe schafft einmalig ssh-keygen -A. Danach führt systemctl enable --now ssh zum Erfolg. Der Versuch, sich von Windows aus mit ssh <name>@172.30.xxx.yyy anzumelden, führt zum Fehler permission denied: publickey. Schuld ist die Einstellung PasswordAuthentication no in /etc/ssh/sshd_config innerhalb von Ubuntu. Stellen Sie die Option auf yes und starten Sie den SSH-Server neu, dann klappt es.
Alles in allem ist die Verwendung von SSH im Zusammenspiel mit WSL + Ubuntu 22.04 weiterhin mühsam.
WSL 1 und WSL 2
WSL liegt in zwei grundlegenden Varianten/Architekturen vor, die (noch) beide gepflegt werden.
WSL 2 greift auf einen »echten« Linux-Kernel zurück, der via Hyper-V in einer virtuellen Maschine ausgeführt wird. In den meisten Fällen ist diese Variante vorzuziehen. Sie ist schneller und funktioniert bei Hardware- oder Kernel-nahen Funktionen besser.
WSL 1 bildet dagegen Linux-Funktionen nach (und ist aus technischer Sicht viel bemerkenswerter). Die Integration der WSL-Distributionen in das lokale Netzwerk ist anders als bei WSL 2 (manchmal vorteilhafter). Der Hauptunterschied: WSL 1 erfordert keine Virtualisierung, läuft also auch dann, wenn sich Windows selbst in einer virtuellen Maschine befindet!
Standardmäßig wird bei einer WSL-Installation aus dem Microsoft Store nur WSL 2 aktiviert. Die für WSL 1 erforderlichen Features können aber problemlos mit wsl --install --enable-wsl1 nachinstalliert werden.
Losgelöst von der WLS-Architektur 1 und 2 gibt es auch eine WSL-Versionsnummer, die nichts mit der Architektur zu tun hat. wsl --version liefert aktuell 1.0.0.0 und zeigt, dass WSL dem Beta-Stadium entwachsen ist.
Nachwort
Aus meiner Linux-Perspektive ist es immer wieder erstaunlich, wie viele »offizielle« Wege es gibt, um Windows-Komponenten zu installieren:
Für WSL oder das neue Terminal verwenden Sie den Microsoft Store.
Andere Komponenten wie der SSH-Client und -Server sind tief in den Einstellungen versteckt (Apps / Optionale Features, das muss man wirklich erst mal finden …).
Wieder andere Komponenten wie Hyper-V & Co. gelten als Windows Features und werden über das gleichnamige Programm aktiviert.
Da soll noch einer sagen, Linux wäre schwer verständlich ;-)
Bereits seit einigen Jahren bietet Canonical »Ubuntu Pro« an. Anfänglich war Ubuntu Pro auf AWS-Kunden beschränkt, denen Ubuntu Pro Updates über einen Zeitraum von 10 Jahren garantiert (statt der üblichen fünf Jahre für Ubuntu LTS). Später wurde Ubuntu Pro auf andere Clound-Anbieter ausgedehnt, und seit ein paar Wochen ist Ubuntu Pro als kostenpflichtiges Update-Service auch für »gewöhnliche« Installationen verfügbar. Privat- bzw. Kleinanwender dürfen Ubuntu Pro für fünf Installationen kostenlos nutzen.
Canonical bewirbt Ubuntu Pro beim Login sowie bei der Ausführung des apt-Kommandos. Das hat zu Unmut bei manchen Benutzern gestört. Ich kann das nicht ganz nachvollziehen. Es wird ja niemand gezwungen, Ubuntu Pro zu verwenden. Für manche Anwender bzw. Server-Administratoren ist die 10-jährige Update-Garantie durchaus ein attraktives Angebot. In diesem Beitrag versuche ich das Angebot im Kontext anderer Distributionen (Red Hat Enterprise, kostenlose Klone) einzuordnen.
Update 19.4.2023: Canonical erlaubt im Rahmen von Ubuntu Pro zwar die kostenlose Verwendung der Kernel-Livepatches, allerdings erhalten Sie dann Patches früher als zahlende Kunden. Sie sind quasi ein Beta-Tester für die Kernel-Patches. Wenn keine Probleme auftreten, werden die gleichen Patches mit einer gewissen Verzögerung auch an zahlende Kunden ausgeliefert.
Varianten
Ubuntu Pro gibt es aktuell in vier Ausprägungen:
Cloud: Die Cloud-Anbieter AWS, Azure und Google bieten virtuelle Maschinen (Cloud-Instanzen) mit Ubuntu Pro an. Die monatliche Gebühr ist höher als bei Ubuntu-LTS-Instanzen, dafür beträgt der Update-Zeitraum zehn statt fünf Jahre. Über diese Form des Ubuntu-Pro-Angebots habe ich schon vor Jahren in meinem Blog geschrieben.
Physische Desktop/Workstation-Installation: 25 $ / Jahr, 10 Jahre Updates für die Paketquellen main und universe
Physische Server-Installation, »Infra-only«: 225 $ / Jahr, 10 Jahre Updates nur für die main-Paketquelle. Das Angebot richtet sich insbesondere an Server, die als Virtualisierungs-Host verwendet werden.
Physische Server-Installation: 500 $ / Jahr, 10 Jahre Updates für die Paketquellen main und universe
Alle vier Angebote umfassen auch Live Kernel Patches, die bisher als eigenes Produkt verkauft wurden. Zu diesen Grundangeboten gibt es diverse Support-Erweiterungen, die die Sache natürlich teurer machen:
Die technische Voraussetzung für Ubuntu Pro ist das Kommando pro, das sich im Paket ubuntu-advantage-tools befindet. Es sollte standardmäßig installiert sein. pro security-status gibt einen Überblick über die installierten Pakete (hier auf einem Server mit Ubuntu 20.04 OHNE Ubuntu Pro).
$ pro security-status
1090 packages installed:
854 packages from Ubuntu Main/Restricted repository
228 packages from Ubuntu Universe/Multiverse repository
3 packages from third parties
5 packages no longer available for download
To get more information about the packages, run
pro security-status --help
for a list of available options.
This machine is receiving security patching for Ubuntu Main/Restricted
repository until 2025.
This machine is NOT attached to an Ubuntu Pro subscription.
Ubuntu Pro with 'esm-infra' enabled provides security updates for
Main/Restricted packages until 2030.
Ubuntu Pro with 'esm-apps' enabled provides security updates for
Universe/Multiverse packages until 2030 and has 19 pending security updates.
Die Ausgabe macht auch gleich Werbung für den Abschluss eines Ubuntu-Pro-Upgrades und verspricht Updates für 19 Universe-Pakete, zu denen es ohne Ubuntu Pro eben keinen Schutz gibt. Welche Pakete das sind, können Sie mit pro security-status --esm-apps herausfinden (siehe den folgenden Screenshot).
Ubuntu Pro verspricht Sicherheits-Updates für die fett hervorgehobenen universe-Pakete
Wenn Sie dieser Wink mit dem Zaunpfahl überzeugt, entschließen Sie sich dazu, Ubuntu Pro auszuprobieren. Dazu brauchen Sie ein Konto bei Ubuntu One. Damit können Sie sich beim Ubuntu Pro Dashboard anmelden. Dort erhalten Sie fünf kostenlose Tokens für Ubuntu Pro. Wenn Sie mehr brauchen, müssen Sie dafür bezahlen.
Das Ubuntu-Pro-Dashboard
Die Aktivierung von Ubuntu Pro für eine Ubuntu-Installation ist denkbar einfach. Sie führen pro attach <token> aus, fertig!
$ sudo pro attach <token>
Enabling default service esm-apps
Updating package lists
Ubuntu Pro: ESM Apps enabled
Enabling default service esm-infra
Updating package lists
Ubuntu Pro: ESM Infra enabled
Enabling default service livepatch
Installing snapd
Updating package lists
Installing canonical-livepatch snap
Canonical livepatch enabled.
Unable to determine current instance-id
This machine is now attached to 'Ubuntu Pro - free personal subscription'
SERVICE ENTITLED STATUS DESCRIPTION
esm-apps yes enabled Expanded Security Maintenance for Applications
esm-infra yes enabled Expanded Security Maintenance for Infrastructure
fips yes disabled NIST-certified core packages
fips-updates yes disabled NIST-certified core packages with priority security updates
livepatch yes enabled Canonical Livepatch service
usg yes disabled Security compliance and audit tools
NOTICES
Operation in progress: pro attach
Enable services with: pro enable <service>
Account: <account-name>
Subscription: Ubuntu Pro - free personal subscription
Anschließend können Sie mit apt full-upgrade alle Pakete aktualisieren. Dabei kommen nun die Ubuntu-Pro-Paketquellen zum Einsatz:
$ sudo apt full-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Die folgenden NEUEN Pakete werden installiert:
python3-defusedxml
Die folgenden Pakete werden aktualisiert (Upgrade):
ant ant-optional composer fail2ban glances libjs-jquery-ui libopenexr24 libpython2.7
libpython2.7-minimal libpython2.7-stdlib lynx lynx-common ntpdate php-symfony-console
php-symfony-filesystem php-symfony-finder php-symfony-process python2.7 python2.7-minimal
19 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
19 esm-apps security updates
Möchten Sie fortfahren? [J/n] y
...
Hinter den Kulissen hat pro attach zwei neue Paketquellen eingerichtet:
$ ls /etc/apt/sources.list.d/ubuntu-esm*
/etc/apt/sources.list.d/ubuntu-esm-apps.list
/etc/apt/sources.list.d/ubuntu-esm-infra.list
Außerdem hat pro attach die Kernel-Live-Patch-Funktion aktiviert. Beachten Sie, dass dafür ein Snap-Paket verantwortlich ist. Snap ist also eine zwingende Voraussetzung für diese Funktion. Den Status können Sie so überprüfen:
$ sudo canonical-livepatch status
last check: 6 minutes ago
kernel: 5.4.0-139.156-generic
server check-in: succeeded
patch state: ✓ no livepatches needed for this kernel yet
tier: updates (Free usage; This machine beta tests new patches.)
machine id: <id>
Im Prinzip war’s das. Ubuntu Pro läuft jetzt selbstständig, Sie müssen sich nur noch darum kümmern, regelmäßig Updates zu installieren. pro security-status verspricht jetzt Updates bis 2030 :-)
$ pro security-status
1093 packages installed:
857 packages from Ubuntu Main/Restricted repository
228 packages from Ubuntu Universe/Multiverse repository
3 packages from third parties
5 packages no longer available for download
To get more information about the packages, run
pro security-status --help
for a list of available options.
This machine is attached to an Ubuntu Pro subscription.
Main/Restricted packages are receiving security updates from
Ubuntu Pro with 'esm-infra' enabled until 2030.
Universe/Multiverse packages are receiving security updates from
Ubuntu Pro with 'esm-apps' enabled until 2030. You have received 19 security
updates.
Ich habe das kostenlose Angebot von Ubuntu Pro aktuell auf zwei Server laufen, bisher ohne irgendwelche Probleme. Langzeiterfahrungen kann ich allerdings noch keine bieten, dafür ist das Angebot zu jung.
Kernel-Patches: »Free usage; This machine beta tests new patches.«
Ein Leser dieses Beitrags hat mich auf eine Ergebniszeile von sudo canonical-livepatch status hingewiesen:
tier: updates (Free usage; This machine beta tests new patches.)
Es ist offensichtlich so, dass für zahlende Kunden tier: stable gilt, während an nicht zahlende Kunden Kernel-Updates aus tier: updates verteilt werden. Mit anderen Worten: Wenn Sie Kernel-Patches aktivieren, ohne dafür zu zahlen, sind Sie quasi ein Beta-Tester für die zahlenden Kunden. Wenn keine Probleme auftreten, erhalten zahlende Kunden etwas später die gleichen Updates. (Ein ähnliches Schema gilt übrigens für CentOS Stream, dort für alle Update-Pakete.)
An sich ist diese Vorgehensweise nachvollziehbar. Sie hat bei mir bisher auch keine Probleme verursacht. ABER: Die Informationspolitik von Canonical ist diesbezüglich extrem intransparent. Obwohl ich eine Weile danach gesucht habe, bin ich auf kein offizielles Dokument gestoßen, dass auf diesen Umstand deutlich hinweist oder die Hintergründe erklärt. Ein paar Lese-Tipps:
Einerseits garantiert Ubuntu Pro Sicherheits-Updates für zehn Jahre statt für fünf. Der Nutzen ist leicht zu begründen. Aus der Sicht von Canonical ist das Problem aber, dass viele Admins Ihrer Server ohnedies nicht so lange laufen lassen — oder nur wenig länger. Also macht es wirtschaftlich Sinn, die ersten fünf Jahre die kostenlosen LTS-Updates zu genießen und erst für die Folgejahre Ubuntu Pro zu zahlen. Aus Anwendersicht kosteneffizient, aber für Canonical ein schlechtes Geschäftsmodell.
Andererseits verspricht Ubuntu Pro recht vollmundig auch Updates für die ca. 23.000 Universe-Pakete. Mit diesem Argument versucht Canonical seine Kunden davon zu überzeugen, Ubuntu Pro auch in den ersten Jahre zu bezahlen. Ubuntu Pro hat also einen Zusatznutzen, weil Canonical den Support für die universe-Paketquelle übernimmt; bisher kümmerte sich nur die etwas diffuse »Community« darum.
Ich bin allerdings sehr skeptisch, wie weit das universe-Update-Versprechen reicht. Auf https://ubuntu.com/pricing/pro steht wörtlich: »Support for over 23,000 packages in the Ubuntu Universe repository«. Aber was heißt das? Ich habe nirgendwo das Kleingedruckte gefunden, das eine Abgrenzung vornimmt, für welche Pakete das Versprechen gilt, wie groß das Sicherheitsproblem ist, damit sich Canonical um die Behebung kümmert etc.
Ein Punkt ist klar: Selbst wenn Canonical hoch motiviert ist und ein riesiges Budget für ein großes Security- und Maintenance-Team aufbringt — 23.000 Pakete parallel für fünf LTS-Releases zu warten ist schlicht unmöglich. (Aktuell gibt es nur universe-Updates für die Versionen 18.04, 20.04 und 22.04, weil die universe-Wartungszusage für ältere Releases nicht gilt; aber in drei Jahren müssten die universe-Quellen für Ubuntu 18.04, 20.04, 22.04, 24.04 und 26.04 gleichzeitig gewartet werden! Das sind dann über 100.000 Pakete von Programmen und Bibliotheken in unterschiedlichen Versionen. Man könnte jetzt weiter rechnen, wie viele Zeilen Code das sind, mit wie vielen Maintainer Kontakt gepflegt wird etc.)
Red Hat (IBM) verspricht RHEL-Updates für ein viel kleineres Paketangebot und für weniger Releases zugleich (weil RHEL-Major-Versionen in der Regel drei bis vier Jahre auseinander liegen) — aus gutem Grund! Die restlichen Pakete befinden sich in der EPEL-Paketquelle oder anderen externen Paketquellen, dafür übernimmt Red Hat keine Verantwortung.
Es fällt schwer zu glauben, dass Canonical ein Kunststück gelingt, das Red Hat (mit sicher mehr Einnahmen) nicht einmal anstrebt.
Bei aller Kritik: Ubuntu Pro ist ein attraktives Angebot. Es erlaubt den Einsatz von Ubuntu gerade im Server-Bereich für längere Zeiträume als bisher, zu vertretbaren Kosten (und für fünf Server sogar kostenlos, extrem fair!). Ein kurzer Vergleich zu anderern Distributionen:
Red Hat Enterprise Linux: 10 Jahre (mit Einschränkungen sogar 13 Jahre), kostenpflichtig
RHEL-Klone (Rocky, AlmaLinux etc.): 10 Jahre, kostenlos, aber ohne Garantien
SUSE Linux Enterprise: 10 Jahre (mit Einschränkungen sogar 13 Jahre), kostenpflichtig
Ubuntu LTS: 5 Jahre kostenlos
Ubuntu Pro: 10 Jahre kostenpflichtig (wobei es möglich ist, Ubuntu LTS die ersten fünf Jahre kostenfrei zu nutzen und erst dann auf Ubuntu Pro umzusteigen)
Ich bin gespannt, in welchem Ausmaß Canonical liefern kann, was es aktuell verspricht. Und wie viele zahlende Ubuntu-Pro-Kunden Canonical finden kann. Für das Linux-Universum wäre es auf jeden Fall gut, wenn Canonical erfolgreich ist. Je mehr Firmen es gibt, die mit Linux Geld verdienen, desto besser ist das für alle Linux-Anwender, zahlende wie nicht zahlende!
Kürzlich bin ich beim Klonen von virtuellen Maschinen mit AlmaLinux 9 unter KVM/libvirt als Virtualisierungs-Host auf Netzwerk-Probleme gestoßen: Obwohl ich sämtlichen VMs per Script Netzwerkadapter mit eigenen MACs, IPv4- und IPv6-Adressen zugewiesen haben, traten IPv6-Netzwerkkonflikte auf — und zwar nicht für die reguläre Adressen, sondern für die Link-Local-Unicast-Adressen (fe80-xxx).
Eine kurze Google-Suche führt zur Ursache des Problems: Der NetworkManager wertet offenbar /etc/machine-id aus, um »eindeutige« fe80-Adressen zu generieren. Bei den geklonten VMs war /etc/machine-id aber immer identisch. Die resultierenden IPv6-fe80-Adressen waren daher ebenfalls identisch und führten zu Adresskonflikten (IPv6 Duplicate Address Detected) und letztlich zur Deaktivierung des betreffenden Netzwerkadapters.
Abhilfe ist zum Glück einfach: /etc/machine-id muss gelöscht und neu erzeugt werden:
rm /etc/machine-id
systemd-machine-id-setup
In meinen Setup gibt es ein Script, das beim ersten Start in jeder VM ausgeführt wird. Es führt zuerst die statische Konfiguration der Netzwerkschnittstellen durch, dann die beiden obigen Kommandos und zuletzt einen reboot. Damit gelingt der Parallelbetrieb diverser geklonter VMs wieder problemlos.
Der Frühlingsreigen neuer Distributionen hat begonnen, überraschenderweise mit Fedora statt wie sonst mit Ubuntu. (Ubuntu 23.04 ist diese Woche auch noch an der Reihe.) Heute habe ich einen ersten Blick auf Fedora 38 geworfen. Mein letzter derartiger »Minitest« liegt schon eineinhalb Jahre zurück (siehe Fedora 35).
Um es kurz zu machen: Abseits neuer Versionsnummern gibt es wenig Neuerungen — sowohl an der Oberfläche als auch hinter den Kulissen. Dass es überhaupt optische Änderungen gibt, ist dem neuen Hintergrundbild sowie Gnome 44 geschuldet. Selbst die Release Notes, sonst ein Konglomerat technischer Details, sind diesmal verblüffend leer.
Fedora 38 mit Gnome 44
Software-Versionen
Wie üblich konzentriere ich in dieser Kurzvorstellung auf die Workstation-Variante von Fedora. Die wichtigsten Versionsnummern des Software-Stacks sehen so aus:
Auf die Angabe der Versionsnummern von Thunderbird, Firefox und Chromium verzichte ist — diese Pakete werden ohnedies regelmäßig aktualisiert.
Technische Neuerungen
Fedora arbeitet an einem Unified Kernel Support. Das Ziel ist es, von am Rechner erzeugten Initramfs-Dateien wegzukommen und stattdessen den Kernel und die Initramfs-Datei als ein Paket auszuliefern. Das soll langfristig die Sicherheit verbessern. Details zu diesem Projekt können Sie auf der folgenden Seite nachlesen. Aktuell steckt das Projekt allerdings noch in den Kinderschuhen. Fedora 38 soll lediglich das Fundament für weitere Tests schaffen.
Wenige Tage nach Fedora hat Ubuntu nachgezogen. Spannend an der Version »Lunar Lobster« ist der komplett neu implementierte Installer.
Ubuntu verwendet als Desktop Gnome 44, angereichert mit ein paar Erweiterungen
Update 28.4. und 6.5.: Massive Installer-Problem (siehe unten)
Installation
Über die Installation von Standarddistributionen lohnt es sich kaum mehr, etwas zu schreiben. Das Prozedere verläuft in festen Bahnen, Neuerungen gab es in den vergangenen Jahren nur ganz selten. Wozu etwas ändern, wenn alle zufrieden sind?
Canonical sah das anders und hat das Installationsprogramm für Ubuntu rundumerneuert. Interessanterweise kam dabei die plattformunabhängige GUI-Bibliothek Flutter zum Einsatz. Wer sich nun spektakuläre neue Features erwartet, wird aber enttäuscht sein. Auch wenn das Layout ein wenig anders aussieht als bisher, weisen die Dialoge exakt dieselben Optionen auf wie bisher. Bei meinen Tests hat sich der Installer auch wie gewohnt verhalten, wobei ich zugeben muss, dass ich bisher nur einfache Setups ausprobiert habe. Die einzig echte Neuerung ist eine Auswahlmöglichkeit zwischen einem hellen und einem dunklen Desktop-Layout — eine Einstellung, die bei Bedarf auch später einfach geändert werden kann.
Auch wenn die optischen Unterschiede gering sind: Das Installationsprogramm wurde komplett neu implementiert
Canonicals Fehde gegen Flatpak
Wie schon in den vergangenen Versionen setzt Canonical als zweites Paketformat auf die Eigenentwicklung Snap. Neben diversen Bibliotheken sind standardmäßig nur zwei echte Snap-Pakete installiert: Firefox und eine modifizierte Version des Software-Managers. Immerhin wurde ein großer Kritikpunkt an Firefox ausgemerzt: Der Browser startet nun nahezu gleich schnell wie bei einer herkömmlichen Installation. Der Preis für die wenigen Snap-Pakete ist hoch: du /snap liefert einen Installationsumfang von 2,6 GByte (!). Die Images sind zwar komprimiert und brauchen tatsächlich weniger Platz auf der Disk. Aber für die Ausführung von Snap-Paketen ist eine Menge RAM erforderlich.
Andreas Proschofsky weist in seinem ausführlichen Ubuntu-Test auf die bestürzend schlampige Integration von Snap-Paketen im Software-Manager hin. Selbst wäre mir das vermutlich entgangen, weil ich dem Software-Manager (also »Ubuntu Software«) normalerweise aus dem Weg gehe, ganz egal, unter welcher Distribution ich gerade arbeite.
In der Vergangenheit hat Ubuntu das alternative Zweitformat Flatpak aus der Red-Hat-Schmiede nahezu gleichwertig unterstützt. Das gilt nun nicht mehr ganz: Das Paket flatpak ist standardmäßig nicht installiert. Das Paket wird aber weiter mitgeliefert und kann mit apt install flatpak im Handumdrehen installiert werden.
Schon interessanter ist eine andere Regel: »Offizielle« Ubuntu-Derivate müssen Snap verwenden und dürfen nicht auf Flatpak setzen (Quelle). Ob das Snap beliebter macht?
Ein Blick in die Tiling-Zukunft
Ubuntu denkt darüber nach, in Zukunft Tiling-Funktionen in Form einer zusätzlichen Gnome-Erweiterung standardmäßig auszuliefern. »Tiling« gibt vor allem Nutzern von großen Monitoren bessere Möglichkeiten, mehrere Fenster nebeneinander zu platzieren. Wie gut das funktionieren kann, hat (ausgerechnet!) Microsoft in Windows 11 gezeigt.
Wenn Sie die neue Funktion schon jetzt ausprobieren möchten, installieren Sie das entsprechende Paket, das sich bereits in den Paketquellen befindet:
(Ein kürzerer Paketnamen war wohl nicht möglich.) Die Installation lohnt sich alleine schon deswegen, weil Fenster nun endlich in einem Monitorviertel platziert werden können (während Gnome findet, Halbe-Halbe muss reichen). Wird die Größe der Fenster dann verändert, passen sich die anderen Fenster auch gleich an. Nach der Installation der Tiling-Erweiterung tauchen in den Systemeinstellungen zwei neue Optionen auf, mit denen sich das Tiling-Verhalten ein wenig adaptieren lässt.
Die Systemeinstellungen enthalten zwei versteckte Tiling-Optionen, die erst erscheinen, sobald das entsprechende Paket installiert ist
Heute habe ich versucht, Ubuntu 23.04 auf einen weiteren Rechner zu installieren. Es handelt sich um einen recht gewöhnlichen, schon etwas in die Jahre gekommenen PC. Zwei SATA-SSDs, eine mit Windows 11, die andere mit einer bunten Sammlung von Linux-Distributionen. LAN-Integration über Ethernet-Kabel. Intel-CPU, 16 GB RAM.
Auf diesem Rechner bleibt der Installer im ersten Dialog einfach hängen. (Ich habe über 10 Minuten gewartet. Keine CPU-Aktivität, nichts …) Die Logging-Datei bleibt bis auf eine Zeile leer, und auch die Bildschirmausgaben beim Start des Installers aus einem Terminal heraus sind dürftig:
Der neue Installer von Ubuntu 23.04 bleibt auf einem meiner Testrechner einfach hängen
Im Internet habe ich nur wenige vergleichbare Fehlerberichte gefunden:
Weiterer Versuch mit den neuen Installer, diesmal auf einem Notebook. Bei der manuellen Installation war es mir nicht möglich, eine EFI-Partition zu erstellen. Ich habe das manuell im Terminal mit parted erledigt. Die Fenstergröße des Installers ist relativ klein; es kann nicht vergrößert werden, und ein horizontales Scrolling ist nicht vorgesehen.
Das Installer-Fenster ist zu klein. Es kann weder vergrößert werden noch kann sein Inhalt horizontal gescrollt werden.
Bis zu Version 24.04 ist ja noch fast ein Jahr Zeit. Aber bis dahin gibt es für Canonical noch viel zu tun …
Ich bin ein leidenschaftlicher Fan der mittlerweile schon recht alten Apple-Aluminium-Tastatur. Ich habe vier Geräte mit USB-Kabel gehortet und verwende diese auf fast allen meinen Rechnern: diverse Linux-Notebooks und -PCs, Windows-PC, Mac Mini, Raspberry Pi etc. Schwer zu sagen, wie viele tausend Buchseiten ich mit diesen Tastaturen schon verfasst habe! Die Tastaturen scheinen unverwüstlich zu sein.
Schon 2011 habe ich auf dieser Website über die Verwendung dieser Tastatur unter Ubuntu Linux einen Blog-Artikel geschrieben. Mittlerweile hat sich die Konfiguration ein wenig geändert. Zeit also für ein Update!
Alt und dreckig, aber von unvergleichlicher Qualität. Und platzsparend!
Grundsätzlich funktioniert die Tastatur natürlich wie jede andere Tastatur auf Anhieb. Unter Gnome gibt es sogar einen eigenen Eintrag für das Apple-spezifische Layout.
Auf meinem Notebook habe ich zwei Tastatur-Layouts eingerichtet: Eines für die Apple-Tastatur für den stationären Betrieb zuhause und eines für die »gewöhnliche« Notebook-Tastatur für unterwegs.
Allerdings gibt es zwei Probleme:
Standardmäßig werden die Funktionstasten für Steuerungsfunktionen verwendet (Lautstärke lauter/leiser usw.). Ich will die Funktionstasten aber wirklich als Funktionstasten verwenden. Ich habe diese im Emacs mit diversen Aktionen verbunden, die ich häufig ausführe.
Linux hat bei einigen internationalen Modellen der Apple-Tastatur Probleme damit, die Tasten ^/° und </> richtig zuzuordnen. Die Wirkung der Tasten ist vertauscht.
Sie haben nicht zufällig eine solche Tastatur im Keller liegen? Deutsches Modell, klein (also ohne Ziffernblock), mit USB-Kabel. Ein, zwei Tastaturen hätte ich gerne noch, sozusagen für Notfälle :-) Melden Sie sich bei mir!
Sie wollen WordPress auf einem Server mit RHEL 9 oder einem Klon installieren? Diese Anleitung fasst alle erforderlichen Schritte zusammen. Dabei gehe ich davon aus, dass Sie über eine minimale Installation auf einem Root-Server oder in einer virtuellen Maschine verfügen. Ich habe meine Tests mit AlmaLinux 9 in einer Hetzner-Cloud-Instanz durchgeführt.
DNS-Einträge
Nachdem Sie Ihren Server in Betrieb genommen und sich mit SSH eingeloggt haben, ermitteln Sie die IP-Adressen, unter denen der Server nach außen hin erreichbar ist. Beachten Sie, dass das an sich nützliche Kommando hostname -I nicht in jedem Fall zielführend ist. Wenn Ihre virtuelle Maschine als EC2-Instanz in der Amazon Cloud (AWS) läuft, liefert das Kommando eine Adresse in einem privaten Netzwerk. Diese Adresse gilt aber nur AWS-intern! Sie müssen in der AWS-Konsole ergründen, welche IP-Adresse nach außen gilt.
Ich gehe hier davon aus, dass Ihre WordPress-Installation unter den Adressen example.com und www.example.com zugänglich sein soll und dass Sie IPv4 und IPv6 unterstützen. Dann müssen Sie für Ihre Domain example.com vier DNS-Einträge definieren. Naturgemäß müssen Sie die Beispiel-IP-Adressen durch Ihre echten IP-Adressen ersetzen. Normalerweise dauert es eine Weile (fünf Minuten bis hin zu mehreren Stunden), bis diese DNS-Änderungen wirksam werden.
Typ Name Zieladresse
----- ------- -------------------
A @ 1.2.3.4
A www 1.2.3.4
AAAA @ 2345:1234:1234::1
AAAA www 2345:1234:1234::1
Software-Installation
Auf Ihrem Server müssen Sie nun einen Webserver, einen Datenbank-Server sowie PHP installieren. Ich gehe hier davon aus, dass Sie Apache und MySQL verwenden. Statt Apache wäre natürlich auch NGINX denkbar, statt MySQL auch MariaDB. (Beachten Sie aber, dass die mit RHEL 9 uralte MariaDB-Versionen ausgeliefert werden. Wenn Sie MariaDB einsetzen möchten, sollten Sie den Datenbank-Server aus dem Repository von MariaDB installieren, siehe https://mariadb.org/download/?t=repo-config.)
Bei Cloud-Instanzen entfällt dieser Schritt normalerweise: Die meisten Cloud-Anbieter haben in ihren Instanzen die RHEL-interne Firewall deaktiviert und verwenden stattdessen Firewalls auf Cloud-Ebene, die über die Web-Oberfläche des Cloud-Systems konfiguriert werden muss.
Apache ausprobieren
Um zu testen, dass Ihre Website im Internet zugänglich ist, schreiben Sie »Hello World« in eine Datei im Webverzeichnis /var/www/html:
echo "Hello World" > /var/www/html/index.html
Nun öffnen Sie im Webbrowser auf Ihrem Notebook die Adresse www.example.com oder example.com. Statt »Hello World« wird der Webbrowser eine Sicherheitswarnung anzeigen, weil Ihr Server noch über kein richtiges Zertifikat verfügt. Das ist ein gutes Zeichen: Der Web-Server an sich funktioniert. Ihr Webbrowser erkennt, dass Ihr Server HTTPS unterstützt und will dieses verwenden.
Let’s-Encrypt-Zertifikat für HTTPS einrichten
Es gibt verschiedene Tools, um Zertifikate von Let’s Encrypt zu installieren. Meiner Ansicht nach funktioniert acme.sh am besten. Zur Installation führen Sie die folgenden Kommandos aus:
dnf install tar socat
curl https://get.acme.sh -o acme-setup
less acme-setup (kurze Kontrolle)
sh acme-setup email=admin@example.com
An die E-Mail-Adresse werden Warnungen verschickt, sollte in Zukunft die automatische Erneuerung von Zertifikaten nicht funktionieren. Damit Sie das frisch installierte Script verwenden können, müssen Sie sich aus- und neu einloggen. Jetzt fordern Sie das gewünschte Zertifikat an, wobei Sie natürlich example.com wieder durch Ihren tatsächlichen Hostnamen ersetzen:
acme.sh --issue -d --server letsencrypt example.com -d www.example.com -w /var/www/html
Your cert is in
/root/.acme.sh/example.com/example.com.cer
...
acme.sh speichert das Zertifikat also vorerst in Ihrem Heimatverzeichnis. Sie könnten die Zertifikatsdateien einfach in das /etc-Verzeichnis kopieren, aber das wäre keine gute Idee: Das Zertifikat muss regelmäßig erneuert werden, und acme.sh muss wissen, wohin die neuen Zertifikate dann kopiert werden müssen. Daher weisen Sie acme.sh an, die Zertifikate in das Verzeichnis /etc/mycert zu kopieren:
acme.sh merkt sich den Installationsort und berücksichtigt ihn in Zukunft automatisch bei Updates der Zertifikate. Für diese Updates ist das Kommando acme.sh --cron zuständig, das automatisch einmal täglich durch /var/spool/cron/root ausgeführt wird.
Die Zertifikatsdateien sind nun im /etc-Verzeichnis, aber Apache weiß noch nichts davon. Sie müssen also in der Webserver-Konfiguration angeben, wo sich die Verzeichnisse befinden. Dazu verändern Sie zwei Zeilen in ssl.conf:
# in /etc/httpd./conf.d/ssl.conf zwei Zeilen ändern
SSLCertificateFile /etc/mycert/example.com.fullchain
SSLCertificateKeyFile /etc/mycert/example.com.key
Jetzt starten Sie Apache neu:
systemctl restart httpd
Danach versuchen Sie nochmals, die Seite example.com im Webbrowser zu öffnen. Jetzt sollte alles klappen, d.h. »Hello World« wird verschlüsselt vom Webserver zum Webbrowser übertragen und der Webbrowser ist mit dem Zertifikat zufrieden.
MySQL absichern
Unbegreiflicherweise ist die MySQL-Installation von RHEL 9 und all seinen Klonen offen wie ein Scheunentor. Jeder Benutzer, der sich auf dem Linux-System anmelden kann, erhält mit mysql -u root ohne Passwort Root-Rechte für MySQL. Abhilfe schafft das Kommando mysql_secure_installation. Die folgenden Zeilen fassen stark gekürzt die wichtigsten Eingaben zusammen:
mysql_secure_installation
Would you like to setup VALIDATE PASSWORD component? n
New password: xxxxxx
Re-enter new password: xxxxxx
Remove anonymous users? y
Disallow root login remotely? y
Remove test database and access to it? y
Reload privilege tables now? y
MySQL-Datenbank einrichten
WordPress braucht eine Datenbank, in der Ihre Einstellungen, den HTML-Code Ihrer Blog-Beiträge, die Kommentare anderer Benutzer usw. speichern kann. Diese Datenbank sowie ein Datenbank-Nutzer, der darauf zugreifen darf, wird jetzt eingerichtet. Ich habe für die Datenbank und den Benutzer jeweils den Namen wp verwendet, aber natürlich sind Sie bei der Namenswahl frei.
mysql -u root -p
Password: xxxxxxx (gleiches Passwort wie bei mysql_secure_installation)
mysql> CREATE DATABASE wp;
mysql> CREATE USER wp@localhost IDENTIFIED BY 'strengGeheim';
mysql> GRANT ALL ON wp.* TO wp@localhost;
mysql> exit
WordPress-Dateien installieren
WordPress steht nicht als Paket zur Verfügung, sondern muss manuell installiert werden. Dazu laden Sie die Dateien herunter, packen Sie aus und weisen Ihnen die richtigen Zugriffsrechte samt SELinux-Kontext zu.
cd /var/www/html
rm index.html
wget https://de.wordpress.org/latest-de_DE.tar.gz
tar xzf latest-de_DE.tar.gz
chown -R apache wordpress
chcon -R system_u:object_r:httpd_sys_content_rw_t:s0 wordpress
rm latest-de_DE.tar.gz
Mit der Installation der WordPress-Dateien in /var/www/html/wordpress soll dieses Verzeichnis der Startpunkt für die Dateien in Apache sein. Daher mussdie Variable DocumentRoot von /var/www/html auf /var/www/html/wordpress umgestellt werden. Bei der Gelegenheit können Sie auch gleich den Server-Namen einstellen:
# in /etc/httpd/conf/httpd.conf zwei Zeilen ändern
DocumentRoot "/var/www/html/wordpress"
ServerName example.com
Damit die Einstellungen wirksam werden, ist das folgende Kommando notwendig:
systemctl reload httpd
WordPress konfigurieren
Damit ist es endlich soweit. Sie können nun mit der WordPress-Konfiguration beginnen. Dazu öffnen Sie die Seite example.com/wp-admin/setup-config.php. Im ersten Schritt müssen Sie den Namen der Datenbank, den Datenbank-User sowie dessen Passwort angeben.
Konfiguration des Datenbankzugriffs für WordPress
Im nächsten Schritt legen Sie den Namen Ihrer Website sowie einen Benutzernamen und ein Passwort für die WordPress-Administration fest. Mit diesen Daten können Sie sich danach bei Ihrer neuen Seite anmelden und die mit Inhalten füllen.
Fine Tuning
Wenn alles funktioniert, sollten Sie sich noch um die folgenden Details kümmern:
openSUSE Leap 15.5 ist ein weiteres Minor-Release, das auf SUSE Linux Enterprise Server 15 (SLES 15) basiert. Nach längerer Pause (zuletzt habe ich mir in diesem Blog openSUSE 15.1 angesehen) ist es wieder einmal Zeit, einen Blick in die openSUSE-Welt zu werfen.
openSUSE 15.5 mit KDE/Plasma-Desktop
Aktualisiert am 3.8.2023: NVIDIA-Treiberinstallation
Versionsnummern
openSUSE zeichnet sich durch einen seltsamen Mix aus alter und aktueller Software aus. Vollkommen unbegreiflich ist die uralte Python-Version (aktuell wäre 3.11).
Sie können bei der Installation zwischen mehreren Desktop-Systemen wählen. Viele openSUSE-Anwender entscheiden sich für KDE. Gnome steht nur in der ziemlich alten Version 41 zur Verfügung.
Wenn Sie openSUSE in Kombination mit aktueller Software einsetzen möchten, sollten Sie sich die Rolling-Release-Variante Tumbleweed ansehen. Persönlich bin ich der Meinung, dass Tumbleweed das »bessere« openSUSE ist.
Installation und Administration
Die Installation von openSUSE funktioniert gut wie eh‘ und je. Das Installationsprogramm brilliert vor allem bei komplizierten Setups mit RAID und LVM. Standardmäßig kommt das Dateisystem btrfs zum Einsatz, wobei diverse Subvolumes für /var, /tmp usw. eingerichtet werden. Außerdem werden bei jeder Paket-Installation und bei jedem Update Snapshots erstellt. Diese Snapshots ermöglichen es, eine fehlgeschlagene Paketoperation rückgängig zu machen. (Allzu oft tritt dieser Fall in der Praxis nicht auf. Ich hatte dazu in den letzten Jahren nie die Notwendigkeit, egal, unter welcher Distribution ich gerade gearbeitet habe.)
Das Systemadministrations-Tool YaST war über lange Zeit das Unterscheidungsmerkmal zwischen SUSE und anderen Distributionen. Mittlerweile wirkt YaST aber definitiv angestaubt. Beispielsweise sind die Module zur Software-Verwaltung aus heutiger Sicht unübersichtlich und verwirrend organisiert. Das Firewall-Modul findet außer ‚docker‘ keine Netzwerkschnittstellen. Das AppArmor-Modul eignet sich gerade noch dazu, AppArmor zu deaktivieren bzw. wieder zu aktivieren.
Probleme bei der NVIDIA-Treiberinstallation
Bei vergangenen openSUSE-Versionen gestaltete sich die Installation des proprietären NVIDIA-Treibers sehr einfach: NVIDIA-Paketquelle aktivieren, dann im YaST-Modul Online-Aktualisierung das Menükommando Extras/Alle
passenden empfohlenen Pakete installieren ausführen.
Aktuell scheitert allerdings die Aktivierung der NVIDIA-Paketquelle. Abhilfe: Richten Sie die Paketquelle
manuell mit Hinzufügen/URL angeben ein und verwenden Sie dabei die Adresse `http://download.nvidia.com/opensuse/leap/15.5` (mit HTTP, nicht HTTPS!). Siehe auch diesen Beitrag im NVIDIA-Forum.
Warum openSUSE?
Ich habe mich in den letzten Jahren immer wieder gefragt: Was macht die Attraktivität von openSUSE aus? Laut metrics.opensuse.org sind die Nutzerzahlen in den letzten zwei Jahren stark gestiegen. Auch auf distrowatch.com hält sich openSUSE in den Top-10. (Ich war vor 20 Jahren selbst großer SUSE-Fan, aber das hat sich gelegt.)
openSUSE ist großartig, wenn Sie beruflich oder für den Unterricht eine kostenlose Trainingsumgebung für SLES brauchen.
openSUSE konzentriert sich für die Desktop-Anwendung auf KDE. Wer KDE bevorzugt, hat im Linux-Mainstream wenig Auswahl. openSUSE ist dann durchaus eine sinnvolle Option.
openSUSE verzichtet in der Grundausstattung auf Snap- oder Flatpak-Pakete. Gerade im Vergleich zu Ubuntu kann man das als Pluspunkt sehen.
Ausblick
Für seine Enterprise-Version arbeitet SUSE momentan an einem Komplettumbau. SLES 15 soll durch die Adaptable Linux Platform (ALP) abgelöst werden. ALP basiert auf Micro OS, einer neuartigen immutable Distribution, bei der Updates in Form von atomaren Transaktionen (und nicht durch die Aktualisierung von Paketen) erfolgen. SUSE ALP ist allerdings nur das Kern-Betriebssystem. Die darin installierten Anwendungen sollen ähnlich wie Container (denken Sie an Docker oder Podman) laufen. Red Hat und Canonical experimentieren mit Silverblue bzw. mit Ubuntu Core und Snaps und in eine ähnliche Richtung.
openSUSE ALP soll diesen Paradigmen-Wechsel nachvollziehen. Bis es soweit ist, wird wohl noch einige Zeit vergehen — denn vorher soll es mit openSUSE 15.6 noch ein Minor Release geben (siehe news.opensuse.org).
Update 13.6.2023: Das in SUSE-Frage stets gut informierte Blog MerCurius weist darauf hin, dass ALP vermutlich eine reine Server-Plattform sein wird und keine Desktop-Pakete enthält. Damit openSUSE ALP als Desktop-System funktionieren kann, sucht openSUSE nach Unterstützung durch die Community.
Quellen/Links
Download, Release Informationen und sonstige Dokumentation
Debian 12 »Bookworm« vervollständigt den Distributionsreigen der letzten Monate. Debian wird ca. alle zwei Jahre aktualisiert. Die nun präsentierte Version zeichnet sich vor allem durch Software-Updates und ein paar technische Neuerungen aus. Erfreulich ist, dass die für den Betrieb von Netzwerk-Adaptern und anderen Hardware-Komponenten erforderliche Firmware-Dateien nun gleich mitgeliefert wird. Diese pragmatische Entscheidung des Debian-Entwicklerteams erleichtert die Installation von Debian auf aktuellen Notebooks. Davon abgesehen hat sich am Installations-Programm nur wenig geändert. Wenn man die Logik der Dialoge einmal kennt bzw. verstanden hat, lässt sich das Programm aber sehr effizient bedienen. Selbst komplexe Setups inklusive LVM, RAID und Verschlüsselung sind kein Problem.
Das Debian-Installationsprogramm ist optisch keine Glanzleistung, funktioniert dafür aber ausgezeichnet
Während der Installation haben Sie die Wahl zwischen mehreren Desktop-Systemen (Gnome, KDE, XFCE etc.). Ich habe meine Tests mit Gnome durchgeführt.
Generell ist festzustellen, dass die Versionsnummern — eigentlich untypisch für Debian — erfreulich aktuell sind. Insbesondere gilt dies für MariaDB und PHP. Gerade bei MariaDB liefern die meisten anderen Distributionen Uralt-Versionen aus. Debian macht es hier besser! (MySQL fehlt dafür.)
Plattformen (Architekturen)
Debian 12 steht (unverändert im Vergleich zu Debian 11) für die folgenden Plattformen zur Verfügung:
Standard-PCs: i386 und amd64
ARM: arm64, armhf, armel
MIPS: mipsel, mips64el
PowerPC: ppc64el
S390X: s390x
Weitere Details zur Hardware-Unterstützung können Sie hier nachlesen:
Firmware-Dateien: Ich habe in der Einleitung darauf hingewiesen, dass die offiziellen Installationsmedien nun auch Firmware-Dateien enthalten. Hinter den Kulissen wurde für diese Dateien die neue Paketquelle non-free-firmware geschaffen, die automatisch aktiv ist.
Logging: Der traditionelle Syslog-Dämon rsyslogd wird standardmäßig nicht mehr installiert. Stattdessen erfolgt das Logging nun über das Journal (eine systemd-Komponente). Die Logging-Daten werden dauerhaft in binärer Form gespeichert (Verzeichnis /var/log/journal) und können mit journalctl ausgewertet werden. Der wichtigste Unterschied im Vergleich zu früher besteht darin, dass diverse Logging-Dateien (z.B. /var/log/mail*) nicht mehr zur Verfügung stehen. Abhilfe schafft gegebenenfalls die Installation von rsyslog. Das Paket befindet sich weiter in den Paketquellen.
Keys für externe Paketquellen:apt-key ist veraltet. Beim Einrichten von neuen Paketquellen muss nun ein Schlüssel in /etc/apt/trusted.gpg.d hinterlegt werden. Auf diesen Schlüssel muss in /apt/sources.list.d/*.conf Bezug genommen werden. Das neue Prozedere ist sicherer, aber leider auch wesentlich umständlicher. Hintergründen können Sie z.B. in der Debian-Dokumentation oder auf syslog.me nachlesen.
Keine anderen Betriebssysteme im GRUB-Menü: Während der Installation verzichtet Debian so wie aktuelle Ubuntu-Versionen darauf, das Script os-prober auszuführen und alle anderen auf den SSDs/Festplatten gefundenen Betriebssysteme in das GRUB-Menü einzubauen. Dieser Schritt ist nicht nur zeitaufwändig, sondern auch überflüssig, weil Sie das zu startende Betriebssystem ja auch über ein EFI-Menü auswählen können. Sollte dabei etwas schief gehen, ist es ganz einfach, den os-prober zu reaktivieren. Dazu fügen Sie die folgende Zeile am Ende von /etc/default/grub ein:
# in /etc/default/grub
GRUB_DISABLE_OS_PROBER=false
Es geht nichts über eine doppelte Verneinung ;-)
Anschließend erzeugen Sie grub.cfg mit einem Aufruf von update-grub neu.
Wartungszeitraum
Anders als bei Ubuntu sind die Angaben zum Wartungszeitraum von Debian ein wenig vage. Grundsätzlich gibt es bei Debian ca. alle zwei Jahre ein neues Release. Das jeweils vorige Release wird dann noch ca. ein Jahr mit Updates versorgt, womit sich ein offizieller Wartungszeitraum von ca. drei Jahren ergibt.
Ein Team von Freiwilligen versucht Debian für die Plattformen i386, amd64, arm64 und armhf über den offiziellen Wartungszeitraum hinaus insgesamt fünf Jahre mit kritischen Sicherheits-Updates zu versorgen (Projekt Debian LTS).
»Bitte legen Sie das Medium mit dem Namen ‚Debian GNU/Linux‘ ein«
Der Standardinstaller hinterlässt in /etc/apt/sources.list eine Zeile mit dem Installationsmedium (USB-Stick oder DVD). Wenn Sie nach der Installation ein Paket installieren wollen (apt install <name>), will apt, dass Sie das Installationsmedium wieder einlegen, anstatt das betreffende Paket einfach herunterzuladen. Das ist (schon seit vielen Jahren) nicht mehr zeitgemäß.
Abhilfe: Öffnen Sie /etc/apt/sources.list mit einem Editor und entfernen Sie die Zeile, die mit deb cdrom beginnt.
Fazit
Debian ist mit »Bookworm« ein grundsolides, überdurchschnittlich modernes Release gelungen. Snaps und Flatpaks sind optional möglich, aber nicht erforderlich. Vielleicht ist das altmodisch, aber ich sehe es als Pluspunkt.
Gerade in Zeiten, wo dem Linux-Desktop ein rauer Wind entgegen weht (Red Hat will keine LibreOffice-Pakete mehr erstellen, SUSE überhaupt keine kommerzielle Desktop-Distribution mehr anbieten usw.) ist es großartig, dass Debian nicht nur am Server brilliert, sondern auch ein gutes Angebot für Desktop-User darstellt.
Ich habe es in meinen früheren Debian-Artikel schon erwähnt, aber man kann es nicht oft genug sagen: Debian ist das Fundament für eine große Palette weiterer Distributionen: Ubuntu und all seine Varianten, Kali Linux, Raspberry Pi OS usw. Die Linux-Community kann dem Debian-Team gar nicht dankbar genug sein, dass es dieses Fundament immer wieder neu zusammenstellt!
Red Hat Enterprise Linux (RHEL) besteht aus Open-Source-Code, der öffentlich zugänglich ist. Diesen Umstand nutzen AlmaLinux, Oracle Linux, Rocky Linux und einige weitere Distributionen, um zu RHEL kompatible Distributionen anzubieten. Es ist verständlich, dass dies Red Hat (oder noch mehr IBM?) ein Dorn im Auge ist. Die Klons funktionieren so gut wie das Original, und wer keinen Support braucht oder mit externen Support-Angeboten das Auslangen findet, kann sich viel Geld für Lizenzen sparen.
Nachdem Red Hat schon 2020 das CentOS-Projekt (quasi einen Red-Hat-eigener RHEL-Klon) beendet hat und durch das für den Produktivbetrieb weniger attraktive CentOS Stream ersetzt hat, hat die Firma Ende Juni verkündet, den öffentlichen Zugang auf die RHEL-Quellen unter https://git.centos.org zu beenden. Den RHEL-Quellcode erhalten dann möglicherweise nur noch zahlende Kunden. Das Ganze wurde in bestem Marketing-Sprech als Aufwertung des CentOS-Stream-Projekts verkündet. Die zentrale Aussage lautet: CentOS Stream will now be the sole repository for public RHEL-related source code releases.
Aktuell ist noch unklar, was das für AlmaLinux, Rocky Linux & Co. bedeutet. Grundsätzlich könnten die hinter den Projekt stehenden Organisationen einfach ein RHEL-Abo abschließen. Die Frage ist aber, in welcher Form der Zugang auf den Quellcode dann erfolgt (über SRPM-Pakete?), und wie flott diese Pakete aktualisiert werden. Letztlich könnte die ganze Aktion darauf hinauslaufen, die natürlich weitgehend automatisierten Build-Prozesse der Klone zu behindern oder zu verzögern.
Eine weitere Frage ist, ob irgendwelche EULA-Regeln die Verwendung dieses Codes zum Nachbau anderer Distributionen verbieten können. Das erscheint mir — ohne juristisches Wissen — eher unwahrscheinlich. Es galt immer und es gilt weiterhin die GNU Public License.
Es bleibt also spannend. AlmaLinux verkündet auf Twitter: Don’t panic. Wahrscheinlich eine gute Idee.
Die Einstellung des Git-Repos mit den RHEL-Quellen (siehe auch Ärger für Red-Hat-Klone) hat im Netz erwartungsgemäß für hitzige Diskussionen gesorgt. Ein wenig irritiert haben mich die Kommentare auf lwn.net, eigentlich der seriösesten Linux-News-Quelle: Dort wurden AlmaLinux, Rocky Linux und speziell Oracle von manchen Autoren als »Parasiten« bezeichnet.
Nun ist es unbestritten, dass die Zusammenstellung einer Distribution wie RHEL mit richtig viel Arbeit verbunden ist. Noch viel mehr Mühe bereitet es, das Software-Angebot über 10 Jahre zu warten und auch bei veralteter Software Sicherheits-Patches rückzuportieren. (Python 2.7 ist ein klassisches Beispiel.)
Wenn nun die RHEL-Klone die Quellen einfach kopieren und daraus ein kostenloses Produkt machen (oder, wie im Falle von Oracle, wahlweise kostenlos oder kostenpflichtig mit Support), ist das noch fair? Ist die Bezeichnung »Parasiten« womöglich zutreffend?
Anmerkung: Dieser Artikel wurde zwischen 23.6. und 24.6.2023 mehrfach aktualisiert.
Open Source ist keine Einbahnstrasse
ABER: Linux ist Open-Source-Software. Und das gilt nicht nur für den Kernel, das gilt auch für alle weitere Komponenten: Apache, NGINX, PHP, PostgreSQL, Samba, Postfix, Java, die Bash, der C-Compiler, Python, GRUB usw. Ich könnte hier vermutlich 1000 Open-Source-Komponenten aufzählen, die in RHEL zum Einsatz kommen. Ja, Red Hat arbeitet intensiv an manchen Open-Source-Projekten mit (dem Kernel, systemd, Gnome usw.) und unterstützt viele weitere finanziell. Von anderen Projekten profitiert es, ohne etwas zurückzugeben.
Dazu noch eine Anmerkung aus meiner beruflichen Praxis: Red Hat hat mit Podman ein Konkurrenzprodukt zu Docker geschaffen. Beide Programme stehen unter Open-Source-Lizenzen, beide halten sich an den öffentlichen OCI-Standard und beide funktionieren großartig. In der Presse genießt Docker aber einen zweifelhaften Ruf, weil es versucht, Geld zu verdienen. (Gerade c’t und iX bzw. einige Heise-Autoren sind sehr Docker-kritisch eingestellt.) Übersehen wird dabei: Die Firma Docker betreibt — mit beträchtlichem finanziellem Aufwand — den Docker Hub, die weltweit größte Quelle von Container-Images. Red Hat betreibt zwar auch Registries für ein paar eigene Software-Projekte, aber davon abgesehen gilt: Wer Podman anwendet, bezieht in aller Regel die Images vom Docker Hub (also von docker.io) und verursacht so weitere Kosten für Docker. Red Hat und Podman sind hier also Nutznießer einer Infrastruktur, die von einer anderen Firma geschaffen wurde. (Und ja, das ist Open Source. Das bessere Angebot wird sich langfristig durchsetzen.)
Das Open-Source-Modell funktioniert dann am besten, wenn Einsatz/Aufwand und Nutzen einigermaßen fair verteilt sind. Das Linux-Ökosystem als Ganzes profitiert von erfolgreichen Open-Source-Firmen, und Red Hat war ohne Zweifel die erfolgreichste. (Seit 2018 ist Red Hat Teil von IBM.) Red Hat wiederum profitiert vom riesigen Angebot exzellent gewarteter Open-Source-Software.
Wenn nun umgekehrt kleine Entwickler, Organisationen ohne riesige Finanzmittel, Schulen usw. RHEL-kompatible Software über den Umweg von AlmaLinux, Rocky Linux und Co. kostenfrei nutzen dürfen, erscheint mir das fair. Wiederum profitieren alle, letztlich sogar Red Hat bzw. IBM, weil ihre Software von vielen Anwendern genutzt und getestet wird, weil Studenten die Administration von RHEL-kompatiblen Systemen lernen (und nicht etwas die von Debian oder Ubuntu) usw.
Ohne Not in den Shit Storm
Der Schritt von Red Hat, die Quellen zu RHEL (soweit es GPL-technisch überhaupt möglich ist) zu kappen, wäre verständlich, wenn man sich um die finanzielle Stabilität von Red Hat Sorgen machen müsste. Aber soweit man den Finanzberichten trauen kann, ist das nicht der Fall. IBM hat 2018 Red Hat für 34 Mrd. Dollar gekauft. Damals machte Red Hat 2,9 Mrd Dollar Umsatz und 259 Mil. Dollar Gewinn (Quelle). Seither werden keine eigenen Red-Hat-Zahlen mehr veröffentlicht, aber die Red-Hat-Sparte innerhalb von IBM hat sich offenbar prächtig weiterentwickelt (Quelle). Red Hat kämpft also nicht um sein finanzielles Überleben. Eher ist es wohl die Gier (IBMs?), aus einem gut gehenden Geschäft noch mehr rauszuholen. Auch wenn dabei die Fairness auf der Strecke bleibt.
Und eines muss man schon sagen: Das Timing ist bösartig, ein freundlicheres Wort fällt mir nicht ein. Sowohl die Kommunikation über das CentOS-Ende (Ende 2020) als auch der Stopp der Veröffentlichung der RHEL-Quellen unter git.centos.org (Juni 2023) erfolgte jeweils äußerst kurzfristig mitten im Release-Zyklus. Es ist beabsichtigt, die Anwender von (damals) CentOS und (heute) AlmaLinux, Rocky Linux, Oracle Linux ganz bewusst zu verunsichern und vor den Kopf zu stoßen.
fosspost.org hat die Aktion Red Hat als Schuss ins Knie bezeichnet. Mir erscheint diese Einschätzung zutreffend. Ansible-Entwickler Jeff Geerling fragt: »Are you dumb?« und überlegt, ob er sich überhaupt noch die Mühe machen soll, RHEL zu unterstützen (also z.B. Fehlermeldungen zu bearbeiten, die sich auf RHEL beziehen).
Als Red Hat das CentOS-Projekt in seiner bisherigen Form stoppte, hatte ich Sorgen um die freie Verfügbarkeit von RHEL-Klonen. Dann erlebte das Konzept in Form von AlmaLinux und Rocky Linux eine Wiedergeburt und funktioniert heute besser denn je. Womöglich wird sich dieses Spiel wiederholen. An den Regeln der GNU Public Licence geht auch für Red Hat/IBM kein Weg vorbei. Sicher ist aber schon jetzt: Red Hat (IBM) verliert in der Open-Source-Community gerade massiv Reputation und Gunst.
Das High Efficiency Image File Format (HEIF) ist ein relativ neues Dateiformat für Bilder und Bildsequenzen. Es ist durch die Moving Picture Experts Group (MPEG) standardisiert und wird seit 2017 vor allem von Apple eingesetzt. Die resultierenden *.heif– bzw. *.heic-Dateien ermöglichen bei gleicher Bildqualität kleinere Dateigrößen. Die Kennung *.heic weist auf die Kombination von HEIF mit dem Video-Codec Efficiency Video Coding (HEVC) hin.
Kürzlich wollte ich ein paar mit dem iPhone aufgenommene Bilder unter Linux mit Shotwell verarbeiten. Dabei bin ich, leider beinahe erwartungsgemäß, auf Probleme gestoßen. Einige ließen sich lösen, aber nicht alle.
Mit etwas Überredungskunst kann Shotwell auch mit HEIC-Dateien umgehen.
Ubuntu
Es beginnt damit, dass das weit verbreitete Foto-Management-Programm Shotwell erst seit April 2023 (Version 0.32) kompatibel mit dem HEIF-Format ist. Ubuntu bis einschließlich Version 23.04 liefert Shotwell aber in der Version 0.30 aus.
Um Version 0.32 zu installieren, müssen Sie zuerst ein Private Package Archive (PPA) aktivieren. Außerdem müssen
Sie die Bibliotheken libheif1 und heif-gdk-pixbuf installieren. (Diese Pakete gelten nicht als Abhängigkeiten und werden daher nicht automatisch installiert.)
Sind diese Hürden einmal überwunden, funktioniert der Import von HEIC-Dateien in Shotwell problemlos, wenn auch sehr langsam.
Fedora
Unter Fedora 38 sieht die Lage nicht viel besser aus. Shotwell steht zwar in der aktuellen Version 0.32 wahlweise als Flatpak- oder als RPM-Paket zur Verfügung, scheitert aber in beiden Varianten beim Import von HEIC-Dateien. Schuld sind wiederum fehlende Bibliotheken.
Bei der Flatpak-Variante lässt sich dieses Problem aktuell nicht lösen, weil Shotwell die Bibliotheken aus Framework-Flatpaks liest, auf die Sie als Anwender keinen Einfluss haben. (Habe ich schon einmal erwähnt, dass ich weder von Snaps noch von Flatpaks viel halte?)
Die RPM-Version von Shotwell wird HEIF-kompatibel, wenn Sie die Paketquellen RPM Fusion Free und Nonfree aktivieren (siehe https://rpmfusion.org/Configuration) und das dort enthaltene Paket libheif-freeworld installieren:
Unter Fedora scheiterte Shotwell jetzt aber am Auslesen der EXIF-Daten. Damit fehlen Informationen, wann die Fotos aufgenommen wurden. Eine Lösung zu diesem Problem habe ich nicht gefunden. Die Sache ist ein wenig unbegreiflich, weil der Import unter Ubuntu mit EXIF-Daten funktioniert.
Nautilus und Gimp
Nicht nur Shotwell zickt, wenn es auf HEIC-Dateien stößt, ähnliche Probleme haben auch Gimp, Nautilus und Co. Bei Gimp besteht die Lösung darin, das Paket gimp-heif-plugin zu installieren.
Nautilus unter Debian/Ubuntu setzt den heif-thumbnailer voraus, der aber ebenfalls nicht automatisch installiert wird. Unter Fedora müssen Sie stattdessen die libheif-tools installieren.
heic-convert
Eine Notlösung besteht darin, HEIC-Dateien vorweg in das JPEG-Dateien umzuwandeln. Dabei hilft das Kommando heif-convert aus dem Paket libheif-tools (Fedora) bzw. libheif-examples (Ubuntu). Das folgende Kommando durchläuft alle *.HEIC-Dateien im aktuellen Verzeichnis und erzeugt JPEG-Dateien in hoher Qualität. Die resultierenden Dateien sind leider wesentlich größer als die HEIC-Originale.
for f in *.HEIC; do heif-convert -q 95 --with-exif $f $f.jpg; done
Fazit
Wenn sich immer wieder einmal jemand wundert, warum aus Linux am Desktop nichts wird — hier ist die Antwort: Aufgrund vieler Kleinigkeiten versagt Linux im praktischen Betrieb und treibt seine Anwender zur Verzweiflung. Und den schwarzen Peter jetzt Apple zuzuschieben, das partout HEIF/HEVC einsetzt, ist nicht ganz fair: Diese Dateiformate kommen nun seit sechs (!) Jahren zum Einsatz, nicht erst seit gestern.
Und tatsächlich sind unter Linux eigentlich alle Puzzle-Stücke schon da. Aber ohne stundenlange Internet-Recherche lassen sie sich nicht zusammenfügen. (Ein verblüffendes Gegenbeispiel ist übrigens KDE Neon, ansonsten eigentlich nicht meine Lieblingsdistribution: Dort werden HEIC-Dateien auf Anhieb im KDE-Dateimanager korrekt angezeigt. Auch Digikam kommt mit den Dateien sofort zurecht. Leider auch nur fast: Digikam scheitert, im Portrait-Modus aufgenommene Bilder richtig zu drehen, obwohl die EXIF-Daten eigentlich da wären.)
(Aktualisiert am 11.10.2023, jetzt mit eigenen Tests)
Völlig überraschend hat die Raspberry Pi Foundation heute den Raspberry Pi 5 vorgestellt. Die wichtigsten Eckdaten im Überblick:
Neuer SoC (BCM2712 mit Quad-Core Cortex-A76) mit ca. zwei- bis dreifacher CPU-Leistung
Höherer Stromverbrauch (Leerlauf 3,25 W, Vollast 8,6 W ohne externe Geräte, laut heise.de)
Höhere Anforderungen an das USB-C-Netzteil: 5V/3A DC Minimum (15 W), 5V/5A DC empfohlen (25 W)
Lüfter empfohlen, es gibt einen eigenen Lüfteranschluss
Vorerst Modelle mit 4 und 8 GiB RAM
Weiterhin SD-Card als primärer Datenträger
Neuer SD-Card-Transfermodus SDR104 verspricht 100 MByte/s bei kompatiblen SD-Karten
PCIe-SSDs sollen in Zukunft über Erweiterungen (HATs) unterstützt werden
Ein/Aus-Schalter
Kein 3,5-mm-Klinkenstecker mehr (ungünstig für Audio-Anwendungen)
Sonstige Anschlüsse (GPIO, 4xUSB, 2x MicroHDMI, Ethernet) kompatibel zu den bisherigen Pis
Raspberry Pi 5
Das Gerät soll ca. ab Ende Oktober lieferbar sein. Die Preisempfehlung lautet 60 $ für das 4-GiB-Modell, 80 $ für das 8-GiB-Modell. Welche €-Preise sich daraus ergeben (inklusive Umsatzsteuer, evt. inklusive neuem Netzteil + Lüfter), muss abgewartet werden.
Erste Tests
Die Raspberry Pi Foundation hat mir dankenswerterweise ein Vorab-Exemplar für Journalisten zukommen lassen. Die Inbetriebnahme gelang erwartungsgemäß mühelos. Wie alle anderen Webseiten kann auch ich bestätigen, dass der Rechner bei der Desktop-Nutzung jetzt unglaublich schnell ist. Bei einem Neustart dauert es nur wenige Sekunden, bis der Desktop erscheint. (Das geht definitiv viel schneller als bei meinem 2000-EUR-Notebook, auch wenn dieses zugegebenermaßen nicht mehr ganz neu ist. Dennoch faszinierend.)
Der winzige Ein/Aus-Schalter ist eine unscheinbare aber dennoch enorm zweckmäßige Verbesserung und schont sicher die USB-C-Buchse für die Stromversorgung. Bisher war es immer notwendig, das Kabel zu lösen und neu einzustecken, um einen ausgeschalteten Raspberry Pi wieder in Betrieb zu nehmen. Jetzt reicht ein Tastendruck.
Sehr empfehlenswert ist der von der Raspberry Pi Foundation angebotene Lüfter. In Kombination mit Raspberry Pi OS wird dieser nur bei Bedarf verwendet. Im Leerlaufbetrieb bleibt der Lüfter ausgeschalten, der Raspberry Pi profitiert aber dennoch vom relativ großen Kühlkörper. Die Temperatur beträgt dann ca. 45 bis 50°C — mehr als genug. Nur bei CPU-intensiven Aufgaben springt der Lüfter an und sorgt für eine aktive Kühlung und somit mehr Rechenleistung. (Ohne Kühlung reduziert der Raspberry Pi automatisch die CPU-Frequenz.)
Raspberry Pi OS
Meinem Exemplar lag eine SD-Karte mit einer Vorab-Version von Raspberry Pi OS Bookworm bei (also auf der Basis von Debian 12). Auf den ersten Blick hat sich an der Desktop-Oberfläche wenig geändert.
Hinter den Kulissen ist mehr neu:
Der Kernel läuft standardmäßig im 64-Bit-Modus.
Die Netzwerkkonfiguration erfolgt über den NetworkManager (kein dhcpcd mehr).
Die gesamte Software hat Debian 12 als Fundament (d.h. z.B. Python 3.11).
Bei meinen Tests verlangte Mathematica einen Lizenzcode. Ob es dabei bleibt, kann ich nicht sagen — das wäre sehr schade.
Mehr Infos zu Raspberry Pi OS Bookworm folgen demnächst auf diesem Blog.
Einschätzung
Die höhere CPU-Leistung ist vor allem bei der Anwendung des Geräts als Desktop-Rechner, zur Software-Entwicklung bzw. als Media-Center spannend. Aus dieser Perspektive ist es sehr schade, dass der Pi 5 weiterhin keine Möglichkeit bietet, SSDs direkt anzuschließen. Zwar gibt es eine neue PCI-Schnittstelle; die soll in Zukunft über ein Erweiterungs-Board (HAT) genutzt werden können. Das ist aber eine umständliche und teure Lösung.
Aus Bastel-Perspektive war schon die Leistung der bisherigen Modelle (3B+, 4B) ausreichend. Diese Modelle werden — sofern sie zu vernünftigen Preisen lieferbar sind — weiterhin eine attraktive Basis für Bastelprojekte bleiben. Das neue Modell 5 ist aus Maker-Sicht dagegen ein zweischneidiges Schwert: Ja, mehr CPU-Leistung ist immer gut. Aber die höheren Anforderungen an Netzteil und Lüfter sowie der Umstand, dass es vorerst keine Modelle mit weniger als 4 GiB RAM geben soll, führen zu einer massiven Preissteigerung selbst für Minimal-Setups. Auch der höhere Strombedarf im Leerlauf ist kein Pluspunkt.
Anmelden
