»Immer Ärger mit Nautilus« wäre eigentlich eine treffendere Überschrift. In diesem Text geht es darum, wie Sie mit dem Gnome-Dateimanager auf Windows- oder Samba-Netzwerkverzeichnisse zugreifen. Dieses Programm hieß ursprünglich Nautilus (der Paketname lautet weiterhin so), später bekam es den nichtssagenden Namen Dateien bzw. im Englischen Files. Ich bleibe hier bei Nautilus, wobei der Name ja noch das geringste Problem ist …

Wie es früher funktionierte

Vor langer Zeit führten Sie in Nautilus das Menükommando Orte / Netzwerk aus. Nautilus zeigte eine Liste aller Windows-Rechner bzw. Samba-Server im lokalen Netzwerk an. Per Doppelklick wählten Sie einen Rechner aus und bekamen eine Liste von Netzwerkverzeichnissen (shares) zu sehen. Ein weiterer Doppelklick öffnete das Verzeichnis. Wenn das Verzeichnis mit einem Passwort abgesichert wurde, mussten Sie sich entsprechend anmelden. Alles in allem ein unkomplizierter Prozess.

Mittlerweile ist die Sache schwieriger, und warum das so ist, bedarf einer etwas längeren Erklärung …

SMB-Grundlagen

Die Basis aller Windows- bzw. Samba-Netzwerkverzeichnisse ist das Protokoll Server Message Block, kurz SMB (Wikipedia). Dieses Protokoll gibt es in verschiedenen Versionen seit 1983 (!!). Die folgende Tabelle fasst überblicksmäßig einige wichtige SMB-Versionen zusammen — und ab welcher Windows- bzw. Samba-Version diese unterstützt werden. (Die Samba-Versionsnummer ist aber mit Vorsicht zu genießen, weil neue SMB-Funktionen oft erst Schritt für Schritt über mehrere Samba-Versionen implementiert wurden. Die Tabelle soll nur als Richtlinie dienen.)

SMB 1.0     Windows 2000       ???
SMB 2.0     Windows Vista      ab Samba 3.6
SMB 2.1     Windows 7          ab Samba 3.6
SMB 3       Windows 8          ab Samba 4.1
SMB 3.1     Windows 10         ab Samba 4.3

Aus Gründen der Abwärtskompatibilität unterstützen Windows und Samba alle Versionen parallel. Client und Server kommunizieren also miteinander, stellen fest, welche Version die Gegenseite unterstützt, und einigen sich auf die bestmögliche Lösung.

In den letzten Jahren haben sich allerdings gravierende Sicherheitsprobleme in SMB 1 herausgestellt, die unter anderem von der Schadsoftware WannaCry ausgenutzt wurde. Microsoft empfiehlt schon seit 2016, SMB 1 explizit zu deaktivieren. In aktuellen Windows-Versionen ist dies standardmäßig der Fall. Auch in aktuellen Samba-Versionen ist SMB 1 mittlerweile standardmäßig deaktiviert; es kann aber bei geeigneter Konfiguration weiterhin aktiviert werden.

Längerfristig werden also immer weniger Netzwerkverzeichnisse SMB 1 unterstützen, ganz egal ob diese von Windows-Rechner, NAS-Geräten oder Linux-Servern angeboten werden. Und in ein paar Jahren ist SMB 1 hoffentlich (endlich) ausgestorben. Wer also auf Windows- oder Samba-Netzwerkverzeichnisse zugreifen will, muss zumindest SMB 2 verstehen.

Browsing

Woher weiß ein Windows- oder Linux-Rechner, welche Netzwerkverzeichnisse im lokalen Netzwerk verfügbar sind? Bis SMB 1 hieß die Antwort Browsing. Das Protokoll SMB enthielt also spezielle Funktionen, um anderen Rechnern mitzuteilen, welche SMB-Server sich im Netzwerk befinden, welche Verzeichnisse (shares) sie anbieten usw.

Diese Funktionen wurden allerdings mit SMB 2 entfernt. Als Ersatz kommt unter Windows das Protokoll WS-Discovery (WSD) zum Einsatz. Linux kann mit Avahi zumindest andere Server/Geräte im lokalen Netz erkennen, allerdings nicht feststellen, welche Netzwerkverzeichnisse diese anbieten. Umgekehrt sehen auch Windows-Rechner nicht, welche Ressourcen ein Samba-Server anbietet. Die bessere Integration von WSD-Diensten unter Linux/Samba ist seit mehr als einem Jahrzehnt eine offene Baustelle.

Vorsicht, Firewall

Unter Debian und Ubuntu gibt es standardmäßig keine Firewall, die den Zugriff auf Windows-Verzeichnisse blockiert. Unter CentOS, Fedora, (open)SUSE und RHEL ist dies hingegen der Fall. Losgelöst von allen SMB-Protokollproblemen wird der Zugriff auf Netzwerkverzeichnisse nie funktionieren, wenn eine Firewall die entsprechenden Ports blockiert. Sie müssen also SMB explizit erlauben. Die Firewall-Konfigurationsprogramme aller genannten Distributionen bieten diese Möglichkeit.

Ärger mit Nautilus

Nach diesem langen Exkurs zurück zu Nautilus. Dieses Programm verwendet für den Zugriff auf SMB-Shares die Bibliothek gvfs-smb. (Die betreffenden Dateien sind je nach Distribution im Paket gvfs-backends versteckt.) Leider funktioniert der Umgang mit Netzwerkverzeichnissen seit Jahren erbärmlich, und daran sind nicht nur die (zugegebenermaßen komplizierten) technische Gegebenheiten schuld. Nautilus stürzt sang- und klanglos ab, zeigt unsinnige bzw. nicht zielführende Fehlermeldungen an und lässt seine Nutzer dumm sterben, um es etwas drastisch zu formulieren.

Dank Avahi erkennt Nautilus in der Regel die meisten im Netzwerk befindlichen anderen Geräte/Rechner/Server/Arbeitsgruppen. Der Versuch, per Doppelklick eine Verbindung zu einem Rechner mit Windows-Netzwerkverzeichnissen herzustellen, scheitert aber zumeist mit einer Fehlermeldung (siehe die Abbildungen am Beginn des Blog-Beitrags). Was nun?

Im Internet werden Sie auf diverse Anleitungen stoßen, Client- oder Server-seitig das Protokoll SMB 1 zu erzwingen. Das ist aber selten eine gute Idee. Die Anweisung client max protocol = NT1 in /etc/samba/smb.conf auf dem lokalen Rechner nützt nichts, wenn der Server (der Windows-Rechner, das NAS-Gerät) zumindest SMB 2 voraussetzt; das ist, wie oben erläutert, zunehmend der Regelfall. Und bei eigenen Samba-Servern handeln Sie sich mit server max protocol = NT1 alle erdenklichen Sicherheitsprobleme ein.

Eine deutlich bessere Lösung gibt es, wenn Sie wissen, wie der Name des Netzwerkverzeichnisses lautet: Dann drücken Sie in Nautilus zuerst Strg+L und geben dann smb://hostname/sharename ein, wobei Sie hostname durch den Namen des Rechners/Geräts ersetzen und sharename durch den Namen des Netzwerkverzeichnisses (in der folgenden Abbildung also users/ms/pictures). Anschließend gelangen Sie in einen Login-Dialog, in dem Sie den Benutzernamen für das Netzwerkverzeichnis und das dazugehörende Passwort angeben.

Nicht immer ist offensichtlich, welchen Share-Namen ein Netzwerkverzeichnis hat. Wenn das Verzeichnis von einem Windows-Rechner angeboten ist, klicken Sie es dort im Dateimanager mit der rechten Maustaste an und führen das Kontextmenükommando Eigenschaften / Bilder aus.

In den meisten Fällen werden Sie wie oben beschrieben zum Ziel kommen. Dann empfiehlt es sich, das Netzwerkverzeichnis gleich als Lesezeichen zu speichern, damit Sie sich den Ärger beim nächsten Mal ersparen: Klicken Sie in der Seitenleiste von Nautilus auf das Netzwerkverzeichnis und führen den Kontextmenüeintrag Lesezeichen hinzufügen aus!

Letzter Ausweg: Terminal

Ich hatte allerdings auch schon Fälle, wo Strg+L samt der Angabe der korrekten Share-Bezeichnung nicht funktionierte, zuletzt unter Ubuntu 19.04. Dann gilt die alte Linux-Regel, dass es im Terminal immer eine Lösung gibt. Erzeugen Sie also ein lokales Verzeichnis, in dem Sie das Netzwerkverzeichnis einbinden möchten, und führen Sie danach mount -cifs wie im folgenden Beispiel aus:

sudo mkdir /media/nas
sudo mount -t cifs -o user=myname,uid=1000 //myhostname/mysharename /media/nas
Password for myname@//myhostname/mysharename:  ******

Dabei geben Sie mit user=myname den Login-Namen für das Netzwerkverzeichnis an. myhostname ersetzen Sie durch den Namen des Windows-Rechners oder NAS-Geräts, mysharename durch den Namen des Netzwerkverzeichnisses. Dank uid=1000 hat der Standardbenutzer Ihres Linux-Rechners Zugriff auf das Netzwerkverzeichnis. Wenn es auf Ihrem Linux-Rechner mehrere Benutzer gibt, ermitteln Sie die richtige UID-Nummer des aktuellen Accounts mit dem Kommando id. In Nautilus können Sie nun das Verzeichnis /media/nas öffnen.

Wenn Sie fertig sind, lösen Sie mit umount das Netzwerkverzeichnis wieder.

sudo umount /media/nas

Quellen

• https://de.wikipedia.org/wiki/Server_Message_Block
• https://en.wikipedia.org/wiki/Samba_(software)
• https://de.wikipedia.org/wiki/WannaCry
• https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/Stop-using-SMB1/ba-p/425858
• https://en.wikipedia.org/wiki/WS-Discovery
• https://en.wikipedia.org/wiki/Avahi_(software)
• https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1831441
• https://github.com/christgau/wsdd (WSD-Dämon für Linux)

Es ist sonst nicht meine Art, Produkte zu testen und darüber zu berichten. Aber da es zu meinem neuen Monitor, einem Lenovo T27p-10, momentan kaum Testberichte gibt, mache ich hier eine Ausnahme. Für Ungeduldige die Kurzfassung: Die Bildqualität ist gut, aber die USB-C-Funktionen sind enttäuschend.

Technische Daten: 27 Zoll, 4k-IPS-Panel, USB-C/DisplayPort/HDMI 2, Ständer mit Höhenverstellung und Pivot-Funktion

Mehr Produktdetails, Bilder etc.: Lenovo

Datenblatt: via Geizhals

Handbuch: Lenovo Support-Seite

Preise: geizhals, edustore.at

Traum …

Der Monitor ersetzt einen schon etwas älteren Asus PB287Q (Herstellerseite mit TN-Panel. Der Lenovo-Monitor hat hingegen ein IPS-Panel mit etwas mehr Helligkeit (350 cd/m2 anstelle von 300 cd/m2 laut Datenblatt). Er liefert, wenig überraschend, ein viel besseres Bild. So weit, so gut.

Der Lenovo T27p verfügt über drei Signaleingänge: USB-C, DisplayPort und HDMI. Der USB-C Eingang ist mit einem USB-Hub verbunden und unterstützt laut Datenblatt USB-Charging mit bis zu 75 W. In meiner naiven Vorstellung dachte ich, ein USB-C-Kabel zwischen meinem Notebook (Lenovo P1 mit 2 x Thunderbolt) und dem Monitor würde reichen, um

• den Bildschirminhalt (4k@60 Hz) zum Monitor zu übertragen,
• das Notebook zu laden und
• diverse USB-Geräte (Maus, Tastatur und Backup-Festplatte) via Monitor anzuschließen.

Falsch gedacht.

… und Wirklichkeit

In der Realität gibt es bei meinem Setup zwei fundamentale Probleme. Eines ließ sich lösen, das andere nicht.

4k nur mit 30 Hz? Das erste Ärgernis bestand darin, dass der Monitor 4k via USB-C nur mit 30 Hz anzeigte. Ich hatte mir eigentlich 60 Hz erwartet. Auf die richtige Spur brachte mich erst der ausgezeichnete Blog-Artikel Explaining 4K 60Hz Video Through USB-C Hub. Die Kurzfassung: Ein USB-C/Displayport-Kabel schafft immer 4k@60Hz. Bei USB-C-zu-USB-C gibt es dagegen zwei Varianten: Wenn Sie mit USB 2 zufrieden sind, dann sind 4k@60 Hz möglich. Wollen Sie dagegen USB 3, dann beansprucht USB 3 zwei der vier Signal-Leitungen des Kabels. Die anderen zwei bleiben für Display Port übrig, reichen aber nur für 4k@30Hz. (Tatsächlich gibt es im Handbuch des Monitors einen versteckten Hinweis auf diese Einschränkung — siehe S. 2-7 in der englischen Fassung.)

Im OSD-Menü des Monitors können Sie zwischen USB 2 und USB 3 umschalten. Ich dachte zuerst, USB 3 wäre besser — aber das ist in diesem Fall eben der entscheidende Irrtum. Wenn Sie 4k@60Hz haben wollen, müssen Sie den USB-Hub des Monitors auf USB 2 stellen. Das hat natürlich Auswirkungen auf die Geschwindigkeit. Für Tastatur und Maus reicht USB 2, aber externe Datenträger auf USB 2 zu bremsen ist keine so tolle Idee. Für eine optimale Geschwindigkeit müssen die weiter direkt mit dem Notebook verbunden werden.

USB Charging: Das zweite Ärgernis betrifft die Stromversorgung des Notebooks über das USB-C-Kabel. Zumindest für mein Lenovo-Notebook funktioniert die Ladefunktion leider nicht.

Lenovo macht diesbezüglich eher vage Angaben. Auf der Produktseite heißt es: delivers one cable connection for power, data, video and audio to compatible devices. Die Frage ist: Welches sind kompatible Geräte? Mein Lenovo-Notebook gehört anscheinend nicht dazu. (Mit einem 65-W-USB-C-Netzteil lässt sich das Notebook dagegen sehr wohl laden, die Funktion ist also Notebook-seitig nicht defekt.)

Im Datenblatt findet sich bei genauem Lesen eine weitere Einschränkung: The Smart Power function intelligently detects overall power consumption and dynamically manages the power delivery to each device. 75W power delivery can be achieved when downstream USB ports are not connected and OSD brightness setting is <61. Ich habe natürlich entsprechende Tests durchgeführt, alle Geräte vom USB-Hub entfernt und die Helligkeit entsprechend moderat eingestellt. Es hilft nichts. Das OSD-Menü behauptet zwar, 75 W Leistung zur Verfügung stellen zu können, im Notebook kommt aber nichts davon an.

Fazit

Der Monitor an sich ist gut, das Preis/Leistungsverhältnis erscheint mir OK (im Okt. 2019 EUR 390 auf edustore.at), drei Jahre Garantie sind überdurchschnittlich.

Der Kabelsalat am Schreibtisch hat sich aber leider nur marginal verbessert. Hier verspricht Lenovo mehr, als es halten kann. (Mit Schuld ist natürlich auch die USB-Spezifikation, die viel zu viel Varianten vorsieht und diverse Sonderfälle offen lässt. Gerade beim Laden via USB-C ist es ein Lotteriespiel, ob zwei Geräte miteinander kooperieren. Aber man hätte eigentlich erwarten können, dass zumindest die Kombination Lenovo-Monitor <--> Lenovo-Notebook funktionieren würde.)

Hilfreich wäre auf jeden Fall, wenn sich Lenovo sowohl auf bei der Produktbeschreibung als auch im Handbuch die Mühe machen würde, die Spezifikationen und Einschränkungen ordentlich zu dokumentieren, inklusive der Bedeutung der diversen Optionen im OSD-Menü.

Die meist-diskutierte Neuerung in Ubuntu 19.10 »Eoan Ermine« besteht darin, dass während der Installation ein ZFS-Dateisystem eingerichtet werden kann. Dieses noch experimentelle Feature richtet sich eher an Linux-Freaks. Ansonsten ist Ubuntu 19.10 eine Distribution mit vielen Software-Updates, die vor allem dann interessant sind, wenn Ubuntu auf ein neues Notebook installiert werden soll. (Egal, ob Sie sich heute für das stabile Ubuntu 18.04 oder für die aktuelle Version 19.10 entscheiden — in einem halben Jahr ist so oder anders ein Update auf Version 20.04 fällig.)

Neuerungen

Auf ZFS gehe ich unten ausführlich ein.

Änderungen gab es bezüglich der i386-Unterstützung: Ursprünglich wollte Canonical die Wartung von i386-Paketen ganz aufgeben. Das hat sich als äußerst unpopulär erwiesen: Vor allem das Wine-Projekt und die Spieleplattform Steam ist auf die Pakete angewiesen. Canonical ist daraufhin etwas zurückgerudert, wichtige i386-Pakete werden innerhalb der 64-Bit-Distribution weiter gepflegt.

Definitiv eingestellt wurde hingegen die 32-Bit-Variante von Ubuntu.

In der Beta-Phase gab es auch Pläne, Ubuntu (schon wieder) ein neues Theme zu verpassen (siehe OMG Ubuntu). Insbesondere hätten die dunklen Fensterrahmen hell werden sollen. Letztlich ist man, wohl primär aus Zeitmangel, vorerst beim aktuellen Theme geblieben. (Da die dunklen Fensterrahmen fast schon ein Markenzeichen von Ubuntu sind, hätte die Umstellung vermutlich wenig Begeisterung ausgelöst. Wenn Sie eine Vorschau auf das neue Thema ansehen möchten, installieren Sie das Paket gnome-tweaks und aktivieren dann im Dialogblatt Erscheinungsbild das Anwendungsthema Yaru light.)

Benutzerfreundlicher ist Ubuntu für NVIDIA-Nutzer geworden. Die proprietären NVIDIA-Treiber sind jetzt auf dem Installations-Image enthalten und werden bei Bedarf sofort installiert.

Der Webbrowser Chromium ist nur noch als Snap-Paket verfügbar. (Aus meiner Sicht ein Grund mehr, gleich das Original, also Google Chrome, zu installieren.)

Versionsnummern

Wie üblich wurden in Ubuntu 19.10 alle erdenklichen Programme auf den aktuellen Stand gebracht:

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel      5.3   Gnome        3.34   bash       5.0   Apache     2.4
glibc      2.30   Firefox        69   gcc        9.2   CUPS       2.2
X-Server   1.20   Gimp         2.10   Java        11   MySQL      8.0
Wayland    1.17   LibreOffice   6.3   PHP        7.3   OpenSSH    8.0
Mesa       19.2   Thunderbird    68   Python     3.7   qemu/KVM   4.0
Systemd     242                                        Postfix    3.4
NetworkMan 1.20                                        Samba     4.10
GRUB       2.04 

Java steht in den Versionen 8, 11, 13 und 14 zur Auswahl, wobei aber nur Version 11 in der main-Paketquelle ist.

ZFS

Das ursprünglich von Sun entwickelte Dateisystem ZFS hat den Ruf, das beste Dateisystem für Unix zu sein. Oracle hat die Weiterentwicklung eingestellt, aber BSD sowie anderen Organisationen/Firmen haben ZFS in den vergangenen Jahren aktiv genutzt und auch um neue Features erweitert.

Eine Integration von ZFS in den Linux-Kernel ist aufgrund von Lizenz-Inkompatibilitäten unmöglich. Auch die von Canonical betriebene Verwendung von ZFS durch ein externes Modul ist lizenztechnisch ziemlich umstritten. Canonical hat sich ein Gutachten erstellen lassen, das zum Schluss kommt, die Nutzung sei OK.

ZFS in Ubuntu ist ein noch experimentelles Feature, das nicht für den Produktiv-Einsatz gedacht ist! Unklar ist die Motivation von Canonical, mit ZFS wieder einmal einen Sonderweg zu beschreiten. Einsteiger überfordern die Möglichkeiten von ZFS. Sollten Probleme auftreten, ist eine Hilfestellung viel schwieriger als bei einem normalen ext4-Dateisystem. Profis bzw. Server-Administratoren sind bei Dateisystemen auch eher konservativ. ext4 und XFS sind erprobt und robust — wozu also Experimente mit ZFS wagen?

Ähnlich wie SUSE bei btrfs zerlegt auch Ubuntu das ZFS in diverse voneinander getrennte Bereiche (datasets). Entsprechend unübersichtlich sieht die mount-Liste aus:

findmnt -t zfs

TARGET                       SOURCE                                           FSTYPE OPTIONS
/                            rpool/ROOT/ubuntu_to662f                         zfs    rw,relatime,xattr,posixacl
├─/boot                      bpool/BOOT/ubuntu_to662f                         zfs    rw,nodev,relatime,xattr,posixacl
├─/var/lib                   rpool/ROOT/ubuntu_to662f/var/lib                 zfs    rw,relatime,xattr,posixacl
│ ├─/var/lib/dpkg            rpool/ROOT/ubuntu_to662f/var/lib/dpkg            zfs    rw,relatime,xattr,posixacl
│ ├─/var/lib/apt             rpool/ROOT/ubuntu_to662f/var/lib/apt             zfs    rw,relatime,xattr,posixacl
│ ├─/var/lib/AccountServices rpool/ROOT/ubuntu_to662f/var/lib/AccountServices zfs    rw,relatime,xattr,posixacl
│ └─/var/lib/NetworkManager  rpool/ROOT/ubuntu_to662f/var/lib/NetworkManager  zfs    rw,relatime,xattr,posixacl
├─/root                      rpool/USERDATA/root_76pl3s                       zfs    rw,relatime,xattr,posixacl
├─/var/games                 rpool/ROOT/ubuntu_to662f/var/games               zfs    rw,relatime,xattr,posixacl
├─/var/mail                  rpool/ROOT/ubuntu_to662f/var/mail                zfs    rw,relatime,xattr,posixacl
├─/var/snap                  rpool/ROOT/ubuntu_to662f/var/snap                zfs    rw,relatime,xattr,posixacl
├─/home/kofler               rpool/USERDATA/kofler_76pl3s                     zfs    rw,relatime,xattr,posixacl
├─/srv                       rpool/ROOT/ubuntu_to662f/srv                     zfs    rw,relatime,xattr,posixacl
├─/var/spool                 rpool/ROOT/ubuntu_to662f/var/spool               zfs    rw,relatime,xattr,posixacl
├─/var/www                   rpool/ROOT/ubuntu_to662f/var/www                 zfs    rw,relatime,xattr,posixacl
├─/var/log                   rpool/ROOT/ubuntu_to662f/var/log                 zfs    rw,relatime,xattr,posixacl
└─/usr/local                 rpool/ROOT/ubuntu_to662f/usr/local               zfs    rw,relatime,xattr,posixacl

Bei einer Testinstallation von Ubuntu in einer virtuellen Maschine war auffällig, dass der Platzbedarf einer Standardinstallation mit ZFS kaum mehr als die Hälfte des Platzes einer ext4-Installation beanspruchte (2,5 versus 4,9 GB). Das liegt daran, dass ZFS eine eingebautet Kompressionsfunktion hat. Deren Funktionsweise kann mit zfs get compressratio kontrolliert werden:

zfs get compressratio

NAME                                              PROPERTY       VALUE  SOURCE
bpool                                             compressratio  1.00x  -
bpool/BOOT                                        compressratio  1.00x  -
bpool/BOOT/ubuntu_to662f                          compressratio  1.00x  -
rpool                                             compressratio  1.74x  -
rpool/ROOT                                        compressratio  1.74x  -
rpool/ROOT/ubuntu_to662f                          compressratio  1.74x  -
rpool/ROOT/ubuntu_to662f/srv                      compressratio  1.00x  -
rpool/ROOT/ubuntu_to662f/usr                      compressratio  1.00x  -
rpool/ROOT/ubuntu_to662f/usr/local                compressratio  1.01x  -
rpool/ROOT/ubuntu_to662f/var                      compressratio  1.30x  -
rpool/ROOT/ubuntu_to662f/var/games                compressratio  1.00x  -
rpool/ROOT/ubuntu_to662f/var/lib                  compressratio  1.28x  -
rpool/ROOT/ubuntu_to662f/var/lib/AccountServices  compressratio  1.00x  -
rpool/ROOT/ubuntu_to662f/var/lib/NetworkManager   compressratio  1.01x  -
rpool/ROOT/ubuntu_to662f/var/lib/apt              compressratio  2.23x  -
rpool/ROOT/ubuntu_to662f/var/lib/dpkg             compressratio  2.37x  -
rpool/ROOT/ubuntu_to662f/var/log                  compressratio  6.87x  -
rpool/ROOT/ubuntu_to662f/var/mail                 compressratio  1.00x  -
rpool/ROOT/ubuntu_to662f/var/snap                 compressratio  1.00x  -
rpool/ROOT/ubuntu_to662f/var/spool                compressratio  1.03x  -
rpool/ROOT/ubuntu_to662f/var/www                  compressratio  1.00x  -
rpool/USERDATA                                    compressratio  4.31x  -
rpool/USERDATA/kofler_76pl3s                      compressratio  4.42x  -
rpool/USERDATA/root_76pl3s                        compressratio  1.00x  -

Die Benchmark-Website Phoronix hat natürlich auch schon erste Tests durchgeführt, ob ext4 oder ZFS schneller ist. Die Kurzfassung: ext4 ist zumeist (aber nicht immer) im Vorteil. In den Kommentaren zu diesen Tests wird allerdings zurecht kritisiert, dass Michael Larabel nicht weiter auf die unzähligen ZFS-Parameter Rücksicht nimmt, die durchaus Tuning-Möglichkeiten geben würden.

In der ubuntu-devel-Mailingliste gab es einen Vorwurf, das Feature-Set von ZFS unter Ubuntu wäre nicht kompatibel mit dem anderer Betriebssysteme mit ZFS. In einer sehr detaillierten Antwort erläutert der ZFS-Entwickler Richard Laager, warum das so ist und dass es Bestrebungen gibt, ZFS in Linux und ZFS in FreeBSD möglichst anzugleichen.

Probleme

Bei der Installation in virtuelle Maschinen ist mir aufgefallen, dass 2 GB RAM offensichtlich nicht mehr ausreichen. (Das war bisher mein Standardwert, wenn ich keine besonderen Ansprüche an die virtuelle Maschine stellte.)

Massive Probleme hatte ich auf einem relativ neuen Testrechner (CPU i3-8100 mit integrierter GPU), der allerdings über ein VGA-Kabel mit einem alten Monitor verbunden war. Nach dem Bootprozess wurde der Monitor schwarz und schaltete sich in den Energiesparmodus. Selbst ein Parallel-Betrieb HDMI/VGA zum Debugging scheiterte; erst als ich den PC nur noch mit einem HDMI-Monitor verband, funktionierte alles. Derartige Schwierigkeiten hatte ich noch nie, d.h. weder mit anderen Distributionen noch mit älteren Ubuntu-Versionen. Merkwürdig.

Im Zuge des Updates von Ubuntu 19.04 auf Ubuntu 19.10 gibt es einige kleinere Kollateralschäden:

• Gnome 3.34 gibt keine Möglichkeit mehr, eine einzelne Farbe als Hintergrund einzustellen. Ich brauche das oft, wenn ich Screenshots mache.
• Wie üblich funktionieren nach dem Gnome-Update einige Shell Extensions nicht mehr. Insbesondere habe ich keinen Weg gefunden, den blöden Text »Aktivitäten« durch ein Icon meiner Wahl zu ersetzen.
• Thunderbird 68 ist inkompatibel mit dem von mir eingesetzten Add-on Dorando keyconfig

Links/Quellen

• Download
• Release Notes
• Ubuntu auf DistroWatch
• heise.de
• golem.de
• omgubuntu
• derstandard.at

ZFS

• ZFS (Wikipedia)
• ZFS on Linux
• ZFS Licensing and Linux (Die Sicht von Canonical)
• ZFS on Linux kämpft mit GPL
• ZFS vs. ext4 Benchmarktests
• Diskussion über ZFS in ubuntu-devel

Soeben ist die neueste Auflage meines Linux-Buchs erschienen — und auf die Eckdaten bin ich ein wenig stolz ;-)

• 16 Auflagen
• 25 Jahre (genaugenommen sind es erst 24,7 Jahre …)
• 1467 Seiten
• Gesamtauflage > 250.000

Aber nicht nur die Zahlen glänzen. Inhaltlich habe ich für die gerade erschienene Neuauflage besonders viel Zeit investiert, und entsprechend lang ist die Liste der Neuerungen/Änderungen:

• Distributionen: Red Hat Enterprise Linux 8 / CentOS 8, Pop!_OS und Clear Linux
• Moderne Apps: Texpander, Syncthing, Etcher, KDE Connect, Duplicati, Borg
• Optimale Notebook-Nutzung: NVIDIA-Grafikkarten, Undervolting, Batterie- und CPU-Tuning
• Raspberry Pi 4: Anwendung als Desktop-, Multimedia- und Maker-System
• Server-Einsatz: RAID- und LVM-Setups, LAMP/LEMP-Beispiele, MySQL/MariaDB-Absicherung, Spam-Handling mit Postfix, Zwei-Faktor-Authentifizierung mit SSH
• Linux in der Cloud: AWS EC2, Hetzner Cloud Hosting
• Virtualisierung & Co.: VirtualBox- und KVM-Arbeitstechniken, Neuerungen in WSL2 und Docker

Weitere Informationen, Leseproben und Bestell-Links finden Sie unter https://kofler.info/buecher/linux. Ein paar Anekdoten zur Geschichte des Linux-Buchs habe ich vor einigen Jahren zum damals 20-jährigen Jubiläum zusammengestellt.

Fedora 31 wurde heute untypisch pünktlich fertiggestellt. Rein optisch hat sich wenig geändert, aber hinter den Kulissen finden sich doch ein paar Veränderungen abseits der üblichen Versionsnummersprünge.

Neuerungen

• 64-Bit only: Die 32-Bit-Variante von Fedora wurde eingestellt.

• SSH root: Standardmäßig kann sich root nicht mehr via SSH anmelden (PermitRootLogin = no in /etc/ssh/sshd_config).

• cgroups: Die größte technische Neuerung in Fedora 31 besteht darin, dass standardmäßig Control Groups 2 (cgroups 2) zum Einsatz kommen. Diese im Kernel verankerten Funktionen erlauben die Überwachung von Prozessen und die Limitierung der Ressourcen, die einem Prozess zur Verfügung stehen. cgroups 2 stellt diesbezüglich eine Menge neue Funktionen zur Verfügung, allerdings gibt es momentan diverse Programme, die mit cgroups 2 noch nicht kompatibel sind. Dazu zählt auch Docker (siehe die folgende Überschrift).

• RPM: RPM-Pakete sind jetzt mit Zstandard statt mit xz komprimiert. Das macht das Entpacken der Pakete schneller, verspricht also ganz generell die flottere Installation von Paketen sowie Updates mit weniger Lüftergeheule. Unverändert lahm ist allerdings die Eingabe dnf install abc [Tabulator] um herauszufinden, welche Pakete, deren Name mit abc beginnt, installiert werden können.

Docker

Fedora enthält keine Docker-Pakete mehr. Die Fedora-Entwickler empfehlen stattdessen den Einsatz des von Red Hat entwickelten Konkurrenzprodukts Podman (Kurzbeschreibung auf der inklupedia, Website). Podman bietet ähnliche Funktionen und hat technische Vorteile (root-less Betrieb, cgroups2-Unterstützung), ist aber nur begrenzt kompatibel zu Docker und daher nicht für jeden Entwickler eine sinnvolle Alternative.

Wenn Sie moby-engine (enthält das Kommando docker in der Version 18.09, aber nicht docker-compose) oder die Docker-Pakete von docker.com verwenden möchten, müssen Sie Fedora durch eine Kernel-Option auf cgroups1 zurücksetzen. Die Vorgehensweise ist in Common F31 bugs beschrieben:

sudo grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) systemd.unified_cgroup_hierarchy=0"
sudo reboot

Das oben genannte Kommando grub2-editenv fügt der Datei /boot/grub2/grubenv eine zusätzliche Kerneloption hinzu.

Versionsnummern

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel      5.3   Gnome        3.34   bash       5.0   Apache     2.4
glibc      2.30   Firefox        69   gcc        9.2   CUPS       2.2
X-Server   1.20   Gimp         2.10   Java        11   MariaDB   10.3
Wayland    1.17   LibreOffice   6.3   PHP        7.3   OpenSSH    8.0
Mesa       19.2   Thunderbird    68   Python     3.7   qemu/KVM   4.1
systemd     243                                        Postfix    3.4
NetworkMan 1.20                                        Samba     4.11
GRUB       2.02 

Quellen und Links

• Download
• Release Notes
• Change Set
• Common Bugs
• Test von heise.de
• Bericht bei pro-linux.de
• Fedora auf distrowatch.com

Seit Red Hat auf seine eigene Docker-Lösung Podman setzt, ist die Verwendung von Docker unter CentOS und Fedora zunehmend mühsamer geworden. Man könnte fast den Eindruck gewinnen, Red Hat will Docker das Leben so schwer wie möglich machen …

Wie dem auch sei: Hier finden Sie eine Anleitung, wie Sie die originalen Docker-Pakete unter Fedora 31 bzw. CentOS 8 installieren und einrichten.

Docker unter Fedora 31 installieren

Wie unter Fedora 31 erläutert, verwendet Fedora 31 als erste »große« Distribution standardmäßig cgroups2. An sich ist das eine gute Sache, allerdings sind die meisten marktüblichen Container-Systeme noch nicht cgroups2 kompatibel. Sie müssen also cgroups1 reaktivieren. (Diese und alle weiteren Kommandos sind mit root-Rechten auszuführen.)

grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) systemd.unified_cgroup_hierarchy=0"
reboot

Falls Sie die Moby-Engine installiert haben, müssen Sie diese entfernen:

dnf remove moby-engine

Anschließend richten Sie die Docker-Paketquelle für Fedora ein und installieren mit docker-ce auch die abhängigen Pakete docker-ce-cli und containerd.io.

dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo
dnf install docker-ce 
systemctl enable --now docker    # Docker-Dämon starten

Das Kommando docker verrät, dass die Version 19.03 installiert ist:

docker version
  Client: Docker Engine - Community
     Version:         19.03.4
  Server: Docker Engine - Community
    Engine:
    Version:          19.03.4
  ...

Docker unter CentOS 8 installieren

RHEL 8 und CentOS 8 verwenden (noch?) das cgroups1-Framework; diesbezüglich sind also keine Änderungen erforderlich. Sie können also gleich damit beginnen, die Docker-Paketquelle einzurichten:

yum install -y yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

Der Versuch, nun wie unter Fedora einfach docker-ce zu installieren, scheitert aber mit einer Fehlermeldung. docker-ce setzt eine aktuelle Version des Pakets containerd.io voraus. Dieses Paket existiert in den Paketquellen, aber yum weigert sich aus unerfindlichen Gründen, es zu verwenden.

Die Installation gelingt über Umwege aber doch. Dazu werfen Sie zuerst einen Blick in die Paketquelle:

https://download.docker.com/linux/centos/7/x86_64/stable/Packages

Dort suchen Sie nach der aktuellsten verfügbaren Version des containerd.io-Pakets. Im November 2019 war das die Version 1.2.10. Diese Version installieren Sie nun, indem an yum explizit die Adresse des Pakets in der Paketquelle übergeben.

yum -y install https://download.docker.com/linux/centos/7/x86_64/stable/Packages/containerd.io-1.2.10-3.2.el7.x86_64.rpm

In der Folge klappt nun die Installation der restlichen Pakete und die Aktivierung des Docker-Dämons:

yum install docker-ce
systemctl enable --now docker

Damit steht dieselbe Docker-Version wie unter Fedora zur Verfügung:

docker version
  Client: Docker Engine - Community
     Version:         19.03.4
  Server: Docker Engine - Community
    Engine:
    Version:          19.03.4
  ...

Benutzer zur docker-Gruppe hinzufügen (gilt für CentOS + Fedora)

Das Kommando docker erfordert normalerweise root-Rechte. Um das ständige Voranstellen von sudo zu vermeiden, sollten Sie Ihren gewöhnlichen Arbeits-Account zur docker-Gruppe hinzufügen. (Alle Mitglieder der docker-Gruppe können das Kommando docker auch ohne sudo ausführen.)

usermod -aG docker <accountname>

Die Änderung wird erst nach einem neuerlichen Login wirksam.

Beachten Sie, dass diese scheinbar harmlose Gruppenzuordnung zwar viel Arbeitskomfort gibt und entsprechend beliebt ist, aber gleichzeitig auch ein großes Sicherheitsrisiko darstellen kann. Indirekt geben Sie dem betroffenen Account damit Root-Rechte! Warum das so ist, erläutert die Docker-Dokumentation. Auf einem Entwicklungsrechner, auf dem Sie ohnedies sudo-Rechte haben, ist die Einstellung OK. Auf einem Produktivsystem ist das usermod-Kommando eher nicht zu empfehlen.

Firewall-Probleme (gilt für CentOS + Fedora)

Grundsätzlich können Sie Docker jetzt verwenden — aber es besteht noch ein großes Problem: In den Docker-Containern funktioniert der Internet-Zugang nicht. Genaugenommen ist nur der Nameserver-Zugriff blockiert, aber das ist schlimm genug. Im Web finden Sie diverse Lösungswege zur Behebung des Problems, von der kompletten Deaktivierung von firewalld bis hin zu Ausnahmeregeln für die vom Docker-Dämon verwendete Netzwerkschnittstelle docker0 (siehe auch die Links am Ende des Artikels). Sicherheitstechnisch am vernünftigsten erscheint es, für das aktive Firewall-Profil (unter Fedora normalerweise FedoraWorkstation, unter CentOS normalerweise public nur das Masquerading zu aktivieren. Dazu finden Sie zuerst den Profilnamen heraus, wobei Sie anstelle von enp1s0 den Namen Ihrer Netzwerkschnittstelle zum Internet angeben.

firewall-cmd --get-zone-of-interface=enp1s0
   FedoraWorkstation

firewall-cmd --zone=FedoraWorkstation --add-masquerade --permanent
firewall-cmd --reload

Um den Docker-Netzwerkzugang zu testen, richten Sie einen Container von Alpine Linux ein und führen darin ping mit irgendeiner bekannten Adresse aus:

docker run --rm -it alpine:latest /bin/sh
/ # ping google.de
PING google.de (172.217.22.67): 56 data bytes
64 bytes from 172.217.22.67: seq=0 ttl=53 time=25.920 ms
64 bytes from 172.217.22.67: seq=1 ttl=53 time=26.283 ms
^C
--- google.de ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 25.920/26.101/26.283 ms
/ # exit

Leider ist das nicht das einzige Firewall-Problem. Jeder Docker-Container kann in einer an sich
geschlossenen Firewall den Schutz für einzelne Ports »aufreißen« (siehe dieses github-Issue). Das liegt daran, dass das Firewall-Systeme von Fedora/CentOS/RHEL nicht mit Docker koordiniert ist. Ähnliche Probleme können auch bei anderen Linux-Distributionen auftreten, die eine Firewall aktivieren. Eine unmittelbare Lösung dafür gibt es nicht.

Quellen

• https://www.redhat.com/sysadmin/fedora-31-control-group-v2
• https://forums.docker.com/t/docker-ce-on-centos-8/81648
• https://www.reddit.com/r/docker/comments/d8j8jj/bad_news_for_those_wanting_to_use_docker_in

Zur Firewall-Problematik:

• https://serverfault.com/questions/987686
• https://unix.stackexchange.com/questions/199966
• https://docs.docker.com/network/iptables
• https://github.com/firewalld/firewalld/issues/461

Die sechste Auflage unseres Buchs ist erschienen!

Highlights der Neuauflage

• aktualisiert im Hinblick auf das neue Modell 4B
• berücksichtigt durchgängig das aktuelle Raspbian »Buster«
• neue Projekte: Smartlight-Systeme (Ikea Trådfri und Philips Hue), NAS (openmediavault), USB-Stick-Checker (CircLean)

Umfang: 1062 Seiten
Ausstattung: Farbdruck, Hard-Cover, Fadenbindung
ISBN: 978-3-8362-6933-9
Preis: Euro 44,90 (in D inkl. MWSt.)
Koautoren: Christoph Scherbeck und Charly Kühnast

 oder  oder  

E-Book: Nur auf der Rheinwerk-Webseite können Sie wahlweise nur das E-Book (EUR 39,90) oder die Kombination aus Buch und E-Book bestellen (EUR 49,90).

Mehr Infos auf pi-buch.info

Ubuntu Pro ist ein neues Angebot von Canonical und Amazon. Dabei handelt es sich um eine für die Amazon-Cloud (genaugenommen für Amazon EC2) optimierte Variante von Ubuntu LTS. Es gibt drei wesentliche Unterschiede zwischen Ubuntu LTS und Ubuntu Pro:

• Ubuntu Pro steht aktuell ausschließlich für Amazon EC2 zur Verfügung. Es kann also nicht auf einen eigenen Rechner oder in einem anderen Cloud-System installiert werden.
• Das Kernel-Live-Patching ist standardmäßig inkludiert.
• Der Wartungszeitraum beträgt statt fünf Jahren beachtliche zehn Jahre (Version 18.04, 20.04 etc.) bzw. immerhin noch acht Jahre für ältere LTS-Versionen.

Kosten

Die Kosten für Ubuntu Pro werden direkt von Amazon verrechnet — Sie brauchen also keinen direkten Lizenzvertrag mit Canonical abzuschließen. Eine EC2-Instanz mit Ubuntu Pro ist also etwas teurer als eine EC2-Instanz mit Ubuntu LTS. Der Aufpreis beträgt aktuell maximal 20% der Instanzkosten. (Bei leistungsstarken Instanzen ist der Aufpreis prozentuell geringer.)

Absolut sind die Kosten schwer zu beziffern, was mit dem sehr komplexen Kalkulationsmodell von Amazon EC2 zu tun hat. Das folgende Beispiel illustriert die Größenordnung und gibt einen Vergleich zu RHEL:

• Eine Cloud-Instanz für ein kostenloses Linux (z.B. Ubuntu LTS, Debian, CentOS) vom Typ t3.medium (2 CPU-Cores, 4 GiB RAM) kostet aktuell 0,048 USD pro Stunde (On-Demand Instanz mit Server-Standort in Frankfurt). Pro Monat kostet diese Instanz ohne Software-Aufpreis also ca. 34 USD.
• Wenn Sie die gleiche Instanz mit Ubuntu 18.04 Pro ausführen, steigen die Kosten auf 0,057 USD pro Stunde (ca. 41 USD pro Monat). Damit kostet Ubuntu Pro für diese Instanz ca. 7 USD pro Monat zusätzlich.
• Wenn Sie die gleiche Instanz mit Red Hat Enterprise Linux 8 ausführen, steigen die Kosten auf 0,108 USD pro Stunde (ca. 78 USD pro Monat). Damit betragen die Zusatzkosten für RHEL8 für diese Instanz ca. 44 USD pro Monat.

In allen drei Fällen kommen zu den Instanzkosten noch die Kosten für den Datenträger, für den Netzwerkverkehr sowie evt. für weitere Zusatzleistungen (fixe IP-Adresse, Backups auf Amazon S3 usw.).

Insgesamt erscheint die Preisgestaltung von Ubuntu Pro durchaus moderat. Im Vergleich zu RHEL ist Ubuntu Pro geradezu billig. Andererseits ist der Zusatznutzen im Vergleich zum »normalen« Ubuntu LTS natürlich auch recht gering. Wirklich interessant wird Ubuntu Pro dann, wenn eine sehr lange Laufzeit anvisiert wird.

(Losgelöst vom Software-Aufpreis für Ubuntu Pro oder RHEL erscheinen mir die Kosten für Cloud-Instanzen bei Amazon EC2 enorm hoch. Natürlich ist die Flexibilität des Cloud-Angebots praktisch grenzenlos; aber ein »simpler« Root-Server bietet pro USD/EUR fast die zehnfache Leistung.)

Quellen

• https://ubuntu.com/aws/pro
• https://aws.amazon.com/marketplace/search/results?x=0&y=0&searchTerms=ubuntu+pro
• https://aws.amazon.com/de/ec2/pricing
• https://aws.amazon.com/marketplace/pp/B0821T9RL2?qid=1576168043903&sr=0-1&ref_=srh_res_product_title#pdp-pricing

Die Überschrift sagt eigentlich schon alles: Ich habe seit sechs Wochen keine Updates mehr für meine CentOS-8-Systeme erhalten. (Ich beziehe mich dabei auf die zwei wichtigsten Paketquellen, Base und AppStream, jeweils für die Architektur x86_64.) Sicherheitstechnisch ist das sub-optimal, gelinde formuliert.

Konkret bedeutet das für einige ausgewählte Pakete (Stand 13.12.2019, jeweils nach yum update):

Paket              in RHEL 8           in CentOS 8
---------          ------------------  --------------
firefox            68.3.0              68.2.0
httpd              2.4.37-16           2.4.37-12
kernel             4.18.0-147          4.18.0-80
NetworkManager     1.20.0              1.14.0
openssh-server     8.0p1               7.8p1 
php                7.2.11-4            7.2.11-1

Red Hat hat seit dem 30.10.2019 diverse kritische Sicherheitslücken gestopft (Quelle). Betroffen sind unter anderem Firefox und PHP. CentOS-8-Anwender stehen diesbezüglich im Regen.

Ursache des Problems ist wohl die Umstellung auf CentOS 8.1, deren Ende nicht absehbar ist (Quelle). Red Hat hat ja Anfang November Version 8.1 vorgestellt, CentOS konnte diesen Versionssprung bisher nicht nachvollziehen.

Angesichts dieser Verzögerungen stellt sich aber die Frage, ob man CentOS noch als kostenlose RHEL-Alternative empfehlen kann. Im jetzigen Zustand offenbar nicht — es geht einfach nicht an, dass wichtige Sicherheits-Updates wochenlang ausbleiben.

Quellen

• Base-Pakete, geordnet nach letzter Änderung: http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/?C=M;O=D
• AppStream-Pakete, geordnet nach letzter Änderung: http://mirror.centos.org/centos/8/AppStream/x86_64/os/Packages/?C=M;O=D
• https://wiki.centos.org/About/Building_8.x
• https://access.redhat.com/security/security-updates/#/
• https://www.redhat.com/en/blog/whats-new-rhel-81-kernel-patching-more-insights-and-right-time

CentOS ist seit Ende Oktober 2019 nicht mehr in der Lage, Updates für CentOS 8 zur Verfügung zu stellen (siehe CentOS 8: Sechs Wochen ohne Updates). Von CentOS 8.1 ist keine Spur, auf der Statusseite ist kein Fortschritt zu erkennen.

Fast noch befremdlicher: Es scheint niemanden zu stören. Google-Suchen nach centos 8 updates missing oder centos 8 no updates liefern kaum relevante Ergebnisse. Weder auf den CentOS-Mailing-Listen noch im CentOS-Forum ist das mehrwöchige Ausbleiben von Updates ein Thema. Ist CentOS 8 ganz einfach noch nicht bei den Anwendern angekommen? Oder ist es tot und nur ich habe es nicht bemerkt?

Kostenlose Alternativen zu RHEL 8 gibt es nicht viele. Scientific Linux wird nur noch für Version 7 gepflegt, eine Version 8 wird es nicht geben. Damit bleibt eigentlich nur Oracle. Die Firma bietet ihren Red-Hat-Klon unter dem Namen »Oracle Linux« sowohl kostenlos als auch kommerziell an. Zahlende Kunden erhalten Support und Zugang zu Kernel-Live-Patches.

Oracle Linux

Oracle Linux ist zwar kostenlos verfügbar, Oracle macht den Download der Installationsdateien aber nicht besonders leicht: Zuerst müssen Sie sich einen (kostenlosen) Oracle-Account einrichten. Nach dem Login können Sie auf der Oracle Software Delivery Cloud anmelden. Dort suchen Sie nach Oracle Linux und geben die Version 8.1 in eine Art Einkaufswagen. (Keine Angst, Sie müssen beim Check-Out nichts bezahlen.)

Im Checkout bestätigen Sie die Auswahl, wobei Sie sich von der Größe von fast 20 GByte nicht beeindrucken lassen. Sie müssen nun die Oracle Standard Terms and Restrictions, die durchaus irritierend von einer 30-tägigen Testzeit sprechen. Laut Oracle Blog ist die Nutzung von Oracle Linux nämlich ohne Restriktionen kostenlos und keineswegs auf einen Testzeitraum limitiert. Im nächsten Schritt können Sie endlich angeben, dass Sie nur das ISO-Image herunterladen wollen. Wäre das nicht einfacher gegangen?

Update: In der Tat geht es einfacher, man nehme einen Mirror, z.B. https://mirror.netcologne.de/oracle-linux/OL8/u1/x86_64/. Danke an alle, die die Kommentarfunktion nutzen!

Ist die Download-Hürde einmal genommen, verläuft die Installation exakt gleich wie bei CentOS 8 (und einfacher als beim Original, weil keine Red-Hat-Subskriptionsdaten angegeben werden müssen).

Anders als CentOS hat Oracle den Produktionsprozess im Griff. Oracle Linux 8.1 wurde nur 10 Tage nach RHEL 8.1 freigegeben. Auch die Update-Versorgung klappt vorbildlich: Das am 18.12.2019 von Red Hat veröffentlichte systemd-Update war keine 24 Stunden später bereits in Oracle Linux verfügbar.

Bei meinem eher kurzen Test traten weder Auffälligkeiten noch Probleme auf. Das Einrichten der EPEL-Paketquelle gelang auf Anhieb mit dem folgenden Kommando:

yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

Versionsnummern

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel     4.18   Gnome        3.28   bash       4.4   Apache     2.4
glibc      2.28   Firefox ESR    68   gcc        8.3   CUPS       2.2
X-Server   1.20   Gimp          2.8   Java      8/11   MariaDB   10.3
Wayland    1.15   LibreOffice   6.0   PHP        7.2   MySQL      8.0
Mesa       19.1   Thunderbird    68   Python 2.7/3.6   OpenSSH    8.0
systemd     239                                        qemu/KVM  2.12
NetworkMan 1.20                                        Postfix    3.3
GRUB       2.02                                        Samba     4.10

Was gegen Oracle spricht

Oracle ist im Datenbank-Sektor die weltweit führende Firma, das bestreite ich nicht. Im Open-Source-Segment glänzt Oracle nicht so strahlend. Diverse durch Aufkäufe zugeführte Open-Source-Projekte haben ihren Popularitäts-Zenit überschritten, zum Teil sind Forks populärer als das Orignal.

• Java: Geänderte Lizenzbedingungen und halbjährliche Updates erschweren den Einsatz im Unterricht und in nicht-kommerziellen Projekten. Java EE ist in der Krise, Java am Desktop (JavaFX) mausetot. Google setzt für die App-Entwicklung mittlerweile voll auf Kotlin. Als erste Programmiersprache gewinnt Python an Popularität.

• OpenOffice hat jede Bedeutung verloren, die Alternative heißt LibreOffice.

• MySQL: Unstimmigkeiten beim Zugang auf Sicherheits-Updates haben den Linux-Distributoren jahrelang das Leben schwer gemacht und MariaDB enorm zu Popularität verholfen.

Die wohl wichtigste positive Ausnahme ist VirtualBox: Das Virtualisierungssystem ist trotz der Oracle-Übernahme auf allen Plattformen (Windows, macOS und Linux) populärer denn je, wird aktiv und sehr regelmäßig weiterentwickelt und ist auch im Open-Source-Umfeld beliebt.

Fazit: Alles in allem gelingt es mir nicht, Oracle als Open-Source-Vorzeigeunternehmen wahrzunehmen. Und entsprechend schwer fällt es mir, bei der Installation eines neuen Servers (wo ich mich in der Regel auf viele Jahre festlege) gerade auf Oracle zu setzen. Wenn Red-Hat-Kompatibilität kein Muss ist, erscheint mir Ubuntu LTS oder Debian trotz deutlich kürzerer Wartungszeiten die sicherere Alternative zu sein. Was CentOS betrifft, heißt es wohl: Abwarten und Tee trinken. Vielleicht sind die aktuellen Probleme nur vorübergehend und das Projekt gewinnt wieder an Fahrt. (CentOS 7 ist von den Update-Problemen übrigens nicht betroffen.)

Quellen

• Oracle Linux
• Download (Mirror-Liste)
• Oracle Blog: Announcing Oracle Linux 8.0
• Oracle Blog: Announcing Oracle Linux 8.1
• Oracle Linux 8.1 Release Notes
• Oracle Application Streams Life Cycle
• EPEL
• Oracle Linux Preisliste

Docker ist seit einigen Jahren die Schlüsseltechnologie abseits aller Programmiersprachen, die den Arbeitsalltag zahlloser Entwickler enorm vereinfacht. Docker ermöglicht es, Sprachen, Server, Linux-Umgebungen etc. in beliebigen Versionen parallel zueinander zu installieren und auszuführen — und das unter Linux, Windows und macOS.

In unserem Docker-Buchs geben wir eine Einführung in den Umgang mit Docker und präsentieren eine ganze Sammlung von Anleitungen und Beispielen aus der Praxis. Für die 2. Auflage haben wir das Buch komplett aktualisiert. Ganz neu ist ein Anhang zu »Podman«, einer weitestgehend syntax-kompatiblen Alternative zu Docker unter Red Hat/Fedora/CentOS.

Weitere Informationen

Seit JavaFX aus dem JDK entfernt wurde, ist es nicht mehr ganz einfach, ein minimalistisches JavaFX-Programm zu entwickeln. In der 3. Auflage meines Java-Grundkurses zeige ich, wie Sie die JavaFX-Bibliotheken manuell herunterladen und dann in ein IntelliJ-Projekt integrieren (Veränderung der Modulabhängigkeiten und der VM-Optionen). Das funktioniert, die resultierenden IntelliJ-Projekte laufen wegen der starr eingestellten Pfade aber nicht auf einem anderen Rechner. Besser ist es, das Build-Tool Gradle zu Hilfe zu nehmen.

Im Folgenden setze ich voraus, dass Sie auf Ihrem Rechner das JDK 11 sowie eine aktuelle Version der IntelliJ IDEA installiert haben.

IntelliJ-Projekt mit Gradle einrichten

Gradle ist ein Werkzeug, um Java-Programme zu kompilieren, die auf diverse externe Bibliotheken zurückgreifen. Gradle kommt z.B. standardmäßig zum Einsatz, wenn Sie in Android Studio eine Android-App entwickeln. (Die populärste Alternative zu Gradle ist Maven. Darauf gehe ich hier aber nicht ein.)

Um in IntelliJ ein neues Projekt zu erstellen, das auf Gradle als Build-Tool zurückgreift, wählen Sie im Projekt New Project den Projekttyp Gradle und belassen bei Additional Libraries die vorselektierte Option Java.

MainApp.java einrichten

Im nächsten Schritt fügen Sie in der Projektansicht im Pfad src/main/java (falls erwünscht) ein neues Package und (auf jeden Fall) Ihre erste Klasse ein. In diesem Beispiel habe ich mich für den Package-Namen info.kofler und die Klasse MainApp entschieden. Im Editor fügen Sie in MainApp die main-Methode mit System.out.println("Hello World") ein, damit Sie erste Tests (noch ohne JavaFX-Code) durchführen können.

build.gradle ergänzen

Nun öffnen Sie in der Projektansicht die schon vorhandene Datei build.gradle.

• Dort müssen Sie die Plugins application und javafxplugin hinzufügen.
• Sie müssen den Namen Ihrer Start-Klasse angeben. In diesem Beispiel ist das info.kofler.MainApp. Geben Sie den Namen Ihrer Klasse angeben, die die main-Methode enthält. Die Package-Bezeichnung entfällt, wenn Sie in Ihrem Projekt keine Packages verwenden.
• Schließlich müssen Sie die Gruppe javafx hinzufügen, die angibt, welche Version und welche Module der JavaFX-Bibliothek verwendet werden sollen.

Zuletzt klicken Sie auf Hide the tip (Sie wollen den Quellcode von JavaFX nicht in Ihr Projekt einbauen) sowie Import Changes (d.h., IntelliJ soll die in build.gradle durchgeführten Änderungen anwenden).

// Mustercode für build.gradle
plugins {
    id 'java'
    // add
    id 'application'
    id 'org.openjfx.javafxplugin' version '0.0.8'
}

// add
mainClassName = 'info.kofler.MainApp'

group 'org.example'
version '1.0-SNAPSHOT'

sourceCompatibility = 1.8

repositories {
    mavenCentral()
}

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.12'
}

// add
javafx {
    version = "11"
    modules = [ 'javafx.controls', 'javafx.fxml' ]
}

Erster Test

Um zu testen, ob bis hierher alles funktioniert hat, öffnen Sie in IntelliJ mit View / Tool Windows / Gradle das Gradle-Fenster, klappen dort Tasks / application / run auf und führen Ihr Projekt durch einen Doppelklick auf run aus. Im Run-Fenster sollte die Ausgabe Hello World erscheinen. Dann wissen Sie, dass der Build-Prozess prinzipiell funktioniert. Gleichzeitig merkt sich IntelliJ den Prozess zur Programmausführung, d.h., Sie können in Zukunft wie bisher einfach auf den grünen Run-Button klicken.

JavaFX-Code

Nun bauen Sie MainApp.java dahingehend um, dass anstelle der Hello-World-Textausgabe ein simples JavaFX-Fenster am Bildschirm erscheint. Sie können sich dabei am folgenden Mustercode orientieren. Falls Ihre Datei nicht MainApp.java heißt, müssen Sie den Klassennamen entsprechend ändern!

// an den eigenen Package-Namen anpassen oder weglassen
package info.kofler;

import javafx.application.*;
import javafx.scene.*;
import javafx.scene.control.*;
import javafx.scene.layout.*;
import javafx.stage.*;

// MainApp durch den eigenen Dateinamen ersetzen
public class MainApp extends Application {
      public static void main(String[] args) {
        launch(args);
    }

    @Override
    public void start(Stage primaryStage) {
        primaryStage.setTitle("Hello JavaFX!");
        Button btn = new Button();
        btn.setText("Hello JavaFX!");
        btn.setOnAction( (event) -> Platform.exit() );
        Pane root = new StackPane();
        root.getChildren().add(btn);
        primaryStage.setScene(new Scene(root, 300, 150));
        primaryStage.show();
    }
}

Der Run-Button sollte nun Ihr JavaFX-Programm starten.

Quellen

https://openjfx.io/openjfx-docs/#IDE-Intellij

Download des Musterprojekts

https://kofler.info/wp-content/uploads/javafxtest.zip

Liebe LeserInnen, als erstes wünsche ich Ihnen natürlich, dass Sie gesund sind und es auch bleiben! Sollte das der Fall sein, haben Sie in diesen Wochen vielleicht mehr Zeit als sonst, sich in neue Technologien einarbeiten. Leider ist der Kauf von Büchern aktuell schwierig — eine äußerst unangenehme Situation nicht nur für IT-interessierte Leser, sondern auch für Autoren und Verlage.

Viele Buchhandlungen sind aktuell geschlossen und werden es wohl noch einige Wochen bleiben müssen. Werfen Sie einen Blick auf die Website Ihrer Lieblingsbuchandlung! Einige Buchhandlungen bieten auch die Möglichkeit zum Online-Kauf und zur Zustellung per Versand. Sie unterstützen damit den lokalen Handel!

Plan B (oder Plan A?) in solchen Fällen wäre natürlich amazon, der größte Online-Händler der Welt. Aber dort setzt man gerade andere Prioritäten — bei Waren des täglichen Gebrauchs. Das ist zweifellos praktisch für alle, die unter Quarantäne zuhause sitzen. Natürlich handelt amazon nicht aus purer Nächstenliebe. Vielmehr ergibt sich für amazon in der Corona-Krise die Chance, sich als systemrelevanter Händler zu etablieren und neue Märkte bzw. Marktsegmente zu erobern.

Unklar ist, ob es deswegen tatsächlich notwendig ist, Bücher als zweitrangige Artikel zu behandeln, die Lager leer laufen zu lassen und bei den Verlagen einfach nicht mehr nachzubestellen. Und sich gleichzeitig darüber zu freuen, wenn der potentieller Käufer dann denkt: »Dann kauf‘ ich mir das Buch halt als E-Book für den Kindle.«

Direktkauf beim Verlag

Offenbar kann amazon in der Krise nur gewinnen. Es sei denn, Sie durchbrechen Ihre Gewohnheiten und spielen nicht mit …

Die meisten meiner Bücher sind im Rheinwerk Verlag erschienen — und dort können sie auch gekauft werden! Der Versand ist in D/A/CH kostenfrei. Und für nur 5 EUR Aufpreis können Sie auf der Rheinwerk-Website (und aus rechtlichen Gründen leider nur dort) das praktische Bundle-Angebot Buch + E-Book nutzen. Damit erhalten Sie das E-Book sofort und in drei Formaten: PDF/EPUB/Mobi. (Persönlich bin ich der Meinung, dass bei IT-Büchern nur das PDF-Format sinnvoll ist. In den anderen Format sehen Listings und Tabellen je nach Lesegerät/Viewer mitunter schrecklich aus.) Das gedruckte Buch folgt zwei, drei Tage später per Post.

Quellen

• https://www.boersenblatt.net/2020-03-26-artikel-amazon_____hallo__geht___s_noch_-offener_brief_von_thomas_montasser.1837912.html
• https://www.politico.eu/article/amazon-suspends-delivery-of-non-essential-goods-in-coronavirus-response/
• https://www.zeit.de/2020/14/buchbranche-buchhaendler-verlage-krise-coronavirus
• https://www.faz.net/aktuell/feuilleton/buecher/corona-krise-im-buchhandel-was-wird-jetzt-aus-den-verlagen-16701255.html

Dass Passwörter nicht im Klartext gespeichert werden dürfen, sollte mittlerweile Allgemeinwissen sein: Sollte aus irgendeinem Grund die Benutzerdatenbank kompromittiert werden, bekäme der Angreifer Zugriff auf sämtliche Passwörter.

Lange Zeit lautete die Empfehlung, zuerst MD5-, dann SHA1- und schließlich SHA2-Hashes mit einem zufälligen Salt zu verwenden. Allerdings gelten die MD5- und SHA1-Algorithmen mittlerweile als unsicher. Bei SHA2 gibt es zwar noch keine fundamentalen Sicherheitsprobleme, aber der Algorithmus ist zu schnell. Sofern die Implementierung der Hash-Funktion bekannt ist, können CPUs/GPUs Millionen wenn nicht Milliarden von Passwörter pro Sekunde testen. Das ist besonders dann fatal, wenn unsichere Passwörter in der Art von 123456 oder topsecret zum Einsatz kommen, die in entsprechenden Passwort-Wörterbuchdateien an den ersten Stellen enthalten sind.

Gegen schlechte Passwörter helfen auch Key Derivation Functions nicht. KDFs verlangsamen aber Cracking-Angriffe um Größenordnungen. Dabei handelt es sich um Algorithmen, die im Prinzip wie Hash-Funktionen funktionieren, aber in zweierlei Hinsicht für den Umgang mit Passwörtern optimiert sind:

• Während normale Hash-Algorithmen in der Regel für große Datenmengen gedacht sind (z.B. um rasch einen eindeutigen Hash-Code für ein ISO-Image mit 3 GiB errechnen), sind Key Derivation Functions für winzige Datenmengen optimiert (also Passwörter, die nur wenige Byte lang sind).

• Die Algorithmen sind bewusst langsam konzipiert und erfordern viele serielle Durchläufe. Es mutet absurd an, das als Vorteil zu sehen — aber je schneller (GPU-unterstützte) Passwort-Cracker sind, desto wichtiger ist es, algorithmisch eine Bremse einzubauen.

Bekannte Key Derivation Functions bzw. Bibliotheken mit KDFs sind Argon2, Bcrypt, libsodium, PBKDF2 sowie Scrypt.

Bcrypt

Mit Bcrypt empfehle ich Ihnen hier nicht das kryptographisch beste Projekt, sondern das in seiner Anwendung einfachste. (Manche Experten sind sogar der Meinung, dass Bcrypt streng genommen gar keine KDF ist.)

Anders formuliert: Es gibt technisch gesehen noch bessere Lösungen, aber Bcrypt sollte zum gegenwärtigen Stand selbst bei hohen Anforderungen ausreichend gut sein — und auf jeden Fall besser als traditionelle Verfahren auf der Basis von MD5/SHA/SHA2. Der entscheidende Vorteil von Bcrypt ist seine Einfachheit:

• Um den Hash eines Passworts zu erzeugen, reicht eine Zeile Code.

• Um ein Passwort mit dem Hashes zu vergleichen, reicht noch eine Zeile Code.

Damit ist es eigentlich unmöglich, Fehler bei der Anwendung von Bcrypt zu machen. (Je länger ich mit IT zu tun habe, desto vehementer bin ich ein Anhänger der KISS-Regel: Keep it simple, stupid!, also: Mach‘ die Dinge nicht komplizierter, als sie sind!)

jBcrypt

JBcrypt ist eine Java-Implementierung von Bcrypt. Im Folgenden setze ich voraus, dass Sie zur Entwicklung Ihres Programms das Build-Tool Gradle einsetzen. Damit Sie die winzige Bibliothek jBcrypt in Ihrem Java- oder Kotlin-Projekt verwenden können, bauen Sie in den dependencies-Block von build.gradle eine Zeile ein:

// in build.gradle
dependencies {
    ...
    implementation "org.mindrot:jbcrypt:0.4"
}

Die Anwendung von jBcrypt in Kotlin sieht so aus:

// Kotlin-Code
import org.mindrot.jbcrypt.BCrypt
...
val bchash = BCrypt.hashpw("geheim", BCrypt.gensalt())
println(bchash)  // z.B. $2a$10$CpvZJVOLMeNgnyXhZAluGe3/sUrhULxOgSPA94VcqNO70TZM/yEtG
println(BCrypt.checkpw("geheim", bchash))  // true
println(BCrypt.checkpw("Geheim", bchash))  // false

Wenn Sie (noch) mit Java arbeiten, sieht der Code so aus:

// Java-Code
import org.mindrot.jbcrypt.BCrypt;
...
String bchash = BCrypt.hashpw("geheim", BCrypt.gensalt());
System.out.println(bchash);
System.out.println(BCrypt.checkpw("geheim", bchash));  // true
System.out.println(BCrypt.checkpw("Geheim", bchash));  // false

Quellen/Links

• https://blog.tjll.net/please-stop-hashing-passwords
• https://en.wikipedia.org/wiki/Key_derivation_function
• https://crypto.stackexchange.com/questions/40757/key-derivation-functions-kdf-what-are-main-purposes-how-can-they-be-used
• https://codahale.com/how-to-safely-store-a-password
• https://www.mindrot.org/projects/jBCrypt
• https://en.wikipedia.org/wiki/Bcrypt
• https://de.wikipedia.org/wiki/KISS-Prinzip

Die letzten acht Jahre habe ich immer genau um diese Zeit ein neues E-Book zu Ubuntu 12.04, 14.04, 16.04 und 18.04 veröffentlicht. Diese Periodizität findet heuer leider ihr Ende.

Ich habe mich dazu entschieden, den Betrieb von ebooks.kofler mit Jahresende einzustellen. (Der Verkauf via amazon ist bereits beendet.) Aufwand und Einnahmen für das Projekt ebooks.kofler stehen in keinem vernünftigen Verhältnis mehr zueinander. Mein publizistischer Fokus bleibt damit bei »traditionellen« Büchern (bzw. Buch/E-Book-Kombinationen), die ich natürlich weiterhin für den Rheinwerk Verlag schreibe.

Einige ausgewählte Titel von ebooks.kofler, die noch nicht komplett veraltet sind, werde ich ab 1.4.2021 (kein Aprilscherz) zum freien Download anbieten.

Die Entwicklung von Ubuntu 20.04 hat mich untypisch wenig berührt — vermutlich, weil ich gerade an keinem Linux-Buch arbeite und insofern keine Notwendigkeit bestand, frühe Betas zu testen. Außerdem läuft Ubuntu 19.10 auf meinem primären Notebook aktuell so rund, dass ich überhaupt keinen Update-Drang verspüre. (Ich werde das Update in den nächsten Wochen natürlich dennoch durchführen.)

Vielleicht liegt es auch daran, dass Ubuntu 20.04 ein (weiteres) Release ist, das keine spannenden neuen Features bietet. Das klingt kritischer, als ich es meine: Für den täglichen Betrieb ist mir nichts lieber als ein stabiles Betriebssystem, das mir einerseits aktuelle Versionen der von mir eingesetzten Programme bietet aber andererseits keinen Ärger bereitet. Und diesbezüglich kann Ubuntu 20.40 (zumindest in meinen ersten Tests) durchaus punkten.

Neuerungen

• Wie üblich wurden alle erdenklichen Programme auf die neueste (oder beinahe neueste) Version aktualisiert — siehe unten. Viele sichtbare Neuerungen in Ubuntu 20.04 ergeben sich ganz einfach aus Neuerungen in der aktuellen Gnome-Version 3.36.

• Hochauflösende Monitore werden besser unterstützt. Die »Fraktionelle Skalierung« kann nun unkompliziert in den Systemeinstellungen aktiviert werden. (Das Feature funktioniert in virtuellen Maschinen häufig nicht. Laut Release Notes funktioniert es auch nicht im Zusammenspiel mit den proprietären NVIDIA-Treibern.)

• Der Bootprozess ist etwas schneller und erfolgt (je nach Hardware/Grafiksystem) ohne mehrfachen Wechsel des Grafikmodus (flicker-free booting).

• Die Unterstützung für das Dateisystem ZFS hat sich weiter verbessert. (Losgelöst von eventuellen Lizenzproblemen sehe ich den Charme von ZFS nicht so recht, schon gar nicht im Desktop-Bereich. Da ist mir das absolut robuste ext4-Dateisystem lieber.)

• Canonical setzt bei externen Paketen weiterhin auf das selbst entwickelte Snap-Format. Standardmäßig ist nur ein Snap-Paket installiert, und zwar (ausgerechnet) der Paketmanager Ubuntu Software (eine adaptierte Version von Gnome Software, wird von snap list unter dem Paketnamen snap-store aufgelistet). Immerhin sind die Gnome-Standard-Apps Protokolle, Taschenrechner und Zeichen nun wieder in Form herkömmlicher Debian-Pakete installiert.

• Für die Freunde der Finsternis gibt es eine bessere Dark-Mode-Unterstützung :-)

• Das sinnlose Amazon-Icon ist vom Desktop verschwunden. Ein Handgriff weniger nach der Installation.

• Bereits seit Version 19.10 hat sich die NVIDIA-Unterstützung verbessert: Die proprietären Treiber, für NVIDIA-Nutzer leider ein unvermeidliches Übel, können bereits während der Installation eingerichtet werden.

• Ebenfalls schon mit Version 19.10 wurde die 32-Bit-Version eingestellt. Wenn Sie Ubuntu 20.04 installieren möchten, brauchen Sie also eine 64-Bit-CPU. 4 GiB RAM sind empfehlenswert, nur zur Not geht es mit weniger. Der anfängliche Platzbedarf auf der Festplatte/SSD beträgt ca. 6 GiB.

• Bei Server-Installationen muss jetzt der neue Subiquity-Installer verwendet werden. (Bei Ubuntu 18.04 stand der Alternate-Installer immerhin noch als Plan B zur Auswahl.) Ich habe die Server-Installation von Version 20.04 bisher nur in einer simplen virtuellen Maschine getestet — da klappt alles problemlos. Die in der Vergangenheit aufgetretenen Probleme im Zusammenspiel mit LVM und RAID sind mittlerweile hoffentlich gelöst; mit Gewissheit kann ich es hier aber nicht sagen. In der Praxis kommt der Installer vermutlich eher selten zum Einsatz, weil beim Einsatz auf Root-Servern oder in der Cloud vorgefertigte Images des jeweiligen Anbieters die Regel sind.

• Ubuntu 20.04 unterstützt WireGuard, ein neues VPN-Verfahren. (WireGuard wurde eigentlich erst mit Version 5.6 offiziell in den Kernel integriert. Das Feature wurde aber in den mit Ubuntu ausgelieferten Kernel 5.4 rückportiert.)

Nicht neu:

• Das Defaultgrafiksystem ist weiterhin Xorg. Andere Distributionen sind da progressiver, in der Praxis wird aber wohl auch dort oft der Xorg-Fallback zum Einsatz kommen. Wer will (und keine Nvidia-Grafikkarte verwendet), kann selbstverständlich beim Login auf Wayland umstellen.

Versionsnummern

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel      5.4   Gnome        3.36   bash       5.0   Apache     2.4
glibc      2.31   Firefox        75   gcc        9.3   CUPS       2.3
X-Server   1.20   Gimp         2.10   Java        11   MySQL      8.0
Wayland    1.18   LibreOffice   6.4   PHP        7.4   OpenSSH    8.2
Mesa       20.0   Thunderbird    68   Python     3.8   qemu/KVM   4.2
Systemd     245                                        Postfix    3.4
NetworkMan 1.22                                        Samba     4.11
GRUB       2.04 

Schlusswort

Ubuntu wird weiterhin der De-facto-Standard und die Messlatte im Linux-Desktop-Bereich bleiben. Nicht, weil es so großartig ist, sondern weil es kaum Alternativen gibt. (Fedora gefällt mir gut, ist mir aber für den täglichen Einsatz zu experimentell/kurzlebig. Von openSUSE habe ich mich in den letzten Jahren zunehmend entfremdet; ich sehe keinen plausiblen Grund, warum ich diese Distribution einsetzen sollte. CentOS 8 wäre vielleicht eine Option, aber die mitgelieferten Programmversionen sind mitunter doch recht konservativ. Und die Update-Versorgung war in den letzten Monaten sehr unzuverlässig. Von Ubuntu abgeleitete Distributionen berücksichtige ich hier nicht — da kann ich gleich das Original verwenden.)

Anders ausgedrückt: Im aktuell verfügbaren Distributions-Mix erscheint mir Ubuntu trotz mancher Nachteile (Snap!) der bei weitem beste und ausgewogenste Kompromiss. Ubuntu LTS ist die Distribution, die ich anderen Leuten empfehle, und es ist die Distribution, die ich sowohl auf meinen Notebooks/Desktop-Rechnern als auch im Server-Bereich am häufigsten einsetze.

Auch wenn dieser Mini-Test nicht vor Begeisterung sprüht, so bin ich Canonical doch dankbar, dass es Ubuntu (auch und gerade am Desktop, wo aktuell kein Geld zu verdienen ist) weiter entwickelt und pflegt, jede LTS-Version über fünf Jahre mit Updates versorgt etc. Stellen Sie sich vor, Canonical würde zusperren und es gäbe kein Ubuntu mehr: Das würde in der Linux-Landschaft ein riesiges Loch hinterlassen.

Quellen / Links / Andere Tests

• Download
• Release Notes
• What’s new im Ubuntu Blog
• DistroWatch
• derstandard.at
• golem.de
• heise.de
• omgubuntu.co.uk
• Ubuntu 19.10 in diesem Blog (mit ZFS-Details)

Die Pünktlichkeit, mit der Fedora-Versionen aktuell erscheinen, erinnert an ein Schweizer Uhrwerk — oder an Ubuntu. Auch die Software-Komponenten sind natürlich ganz ähnlich wie die bei Ubuntu, wenn auch mit dem kleinen Unterschied, dass Fedora mitunter noch eine Versionsnummer weiter ist (Kernel 5.6, gcc 10, Samba 4.12, Postfix 3.4).

Große technische Neuerungen sind auch in Fedora 32 schwer zu erkennen. Interessant ist ein neuer Mechanismus, der bei Speicherknappheit versucht, den verantwortlichen Prozess rechtzeitig zu beenden (earlyoom, siehe die gute Beschreibung bei heise.de). Das Feature ist eine gute Idee, dringender nötig als bei Fedora wäre es aber in Raspbian.

Der Firewall-Dämon (firewalld) nutzt jetzt nftables und nicht mehr iptables. Auch wenn das aus Anwendersicht nichts ändern sollte, ist es doch eine Art Ritterschlag für nftables. (nftables ist eine neue Firewall-Technologie, die zwar schon seit Jahren im Kernel verankert ist, das bewährte iptables-System aber nur sehr langsam verdrängt.)

Besitzer von SSDs werden sich freuen (oder es gar nicht bemerken): Fedora führt nun einmal wöchentlich TRIM aus, bereinigt also nicht genutzte Speicherblöcke der SSD und beschleunigt so auf Dauer den Betrieb.

Versionsnummern

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel      5.6   Gnome        3.36   bash       5.0   Apache     2.4
glibc      2.31   Firefox        75   gcc       10.0   CUPS       2.3
X-Server   1.20   Gimp         2.10   Java        11   MariaDB   10.4
Wayland    1.18   LibreOffice   6.4   PHP        7.4   OpenSSH    8.2
Mesa       20.0   Thunderbird    68   Python     3.8   qemu/KVM   4.2
Systemd     245                                        Postfix    3.4
NetworkMan 1.22                                        Samba     4.12
GRUB       2.04 

Quellen und Links

• Download
• Release Notes
• Change Set
• Common Bugs
• Test von heise.de
• Test von golem.de
• Fedora auf distrowatch.com

Nachdem ich den ziemlich euphorischen Testbericht auf omg-ubunutu gelesen habe, wollte ich mir selbst nochmal ein Bild von der aktuellen Version von Pop!_OS machen.

Kurzer Rückblick: Vor gut einem Jahr habe ich auf mein damals neues Notebook Pop!_OS installiert. Später bin ich dann zu Ubuntu zurückgekehrt, vor allem, weil die HiDPI-Unterstützung von Pop!_OS bei meinem Setup mehr Probleme schuf als löste.

Pop!_OS 20.04 basiert auf Ubuntu 20.04. Es gibt aber ein paar (gewichtige) Unterschiede:

• Standardmäßig ist ein Tiling Window Manager installiert. Nachdem dieser über einen Icon im Panel aktiviert wird, werden Fenster nicht überlappend am Bildschirm platziert und können mit diversen Tastenkürzel (alle in Kombination mit der Super- bzw. Windows-Taste) manipuliert werden. Vermutlich habe ich nicht lange genug damit gespielt, aber erste Tests haben mich nicht überzeugt. Mir reicht es aus, wenn ich meine Fenster jeweils in eine Hälfte bzw. in einem Viertel des Desktops platzieren kann. Dazu habe ich mir unter Ubuntu ein paar Tastenkürzel definiert (mit der Put Windows Shell Extension). Pop!_OS bietet diesbezüglich viel mehr Möglichkeiten und Freiheiten, gleichzeitig ist die Nutzung aber deutlich komplizierter.

• Als zweites Paketsystem neben Debian ist FlatPak vorinstalliert, nicht Snap. Standardmäßig ist kein FlatPak-Paket installiert.

• Pop!_OS stellt beim gesamten Setup den Entwickler in den Fokus, nicht den unbedarften Linux-Einsteiger.

• Bei der HiDPI-Unterstützung gehen Pop!_OS und Ubuntu getrennte Wege, wobei Ubuntu in diesem Fall näher bei den etablierten Standards bleibt, während Pop!_OS auf einen HiDPI-Dämon vertraut.

In anderen Punkten sind sich Ubuntu und Pop!_OS im vergangenen Jahr ähnlicher geworden. Das Alleinstellungsmerkmal von Pop!_OS war früher die ausgezeichnete Unterstützung für die (elendigen) NVIDIA-Treiber. Hier hat Ubuntu aufgeholt. Ach bei Ubuntu können die Treiber jetzt schon während der Installation aktiviert werden, auch Ubuntu ist jetzt in der Lage, einzelne Programme mit expliziter NVIDIA-Unterstützung zu starten (*Mit dezidierter Grafikkarte starten*). Einzig beim Umschalten zwischen Integrierter Intel-GPU und NVIDIA bietet Pop!_OS unverändert mehr Komfort.

Fazit

Viele Ideen von Pop!_OS gefallen mir — und ganz speziell die Ausrichtung auf professionelle Anwender. Über den Tiling Window Manager kann man geteilter Meinung sein (nettes Wortspiel …), aber niemand ist gezwungen, die Funktion zu verwenden. (Standardmäßig ist diese Shell-Erweiterung gar nicht aktiv.)

Letztlich habe ich schon bei Version 19.10 zu wenig Alleinstellungsmerkmale im Vergleich zu Ubuntu gesehen. Da wie dort werden die meisten Anwender vermutlich ein wenig am Setup herumspielen und die eine oder andere Gnome Shell Extension einrichten, bis alle persönlichen Wünsche erfüllt sind. Diese Freiheit geben Ubuntu wie Pop!_OS, und das Endergebnis wird ziemlich ähnlich ausfallen.

Anders formuliert: Sie machen mit Pop!_OS sicher nichts verkehrt. Persönlich ist mir Ubuntu aber gut genug. Wenn etwas hakt, dann bin ich bei der Lösungssuche mit einer Mainstream-Distribution im Vorteil.

Quellen/Links

• Pop!_OS-Website
• Test bei omgubuntu

Seit gestern ist CentOS 8.2 (genaugenommen »CentOS Linux 8 (2004)«) verfügbar. CentOS 8 ist eine von Red Hat Enterprise Linux (RHEL) abgeleitete Distribution, die in der Vergangenheit über einen Zeitraum von 10 Jahre Updates versprach. Mittlerweile sind auf https://centos.org keine klaren Aussagen zum Life Cycle mehr zu finden. Stattdessen weisen die FAQs darauf hin, dass man versucht, Minor Releases von RHEL innerhalb von vier bis acht Wochen nachzubilden.

Dessen ungeachtet hat die Update-Versorgung für CentOS 7 immer ziemlich gut funktioniert, auch wenn es zwischen den Minor Releases zu einer Lücke in der Update-Versorgung von üblicherweise 4 bis 5 Wochen kam.

Deutlich schlechter sieht die Aktualisierung von CentOS 8 aus. Seit CentOS 8.0 im Sep. 2019 erschienen ist (von heute aus gerechnet vor 266 Tagen), hat es über 147 Tage Updates gegeben, während zwei Zeiträumen von insgesamt 119 Tagen aber keine Updates.

Technische Hintergründe

Wo ist eigentlich das Problem? Dass CentOS 8.2 erst 48 Tage nach RHEL 8.2 fertig wurde, wäre den meisten CentOS-Anwendern vermutlich ziemlich egal. Allerdings kann CentOS im Zeitraum zwischen dem RHEL-Minor-Release und dem entsprechenden CentOS-Minor-Release auch keine Updates zur Verfügung stellen. Die Update-Versorgung setzt voraus, dass das gesamte Minor Release nachgebaut werden kann — und das ist (auch wegen der mit RHEL 8 eingeführten Modularisierung) aufwändig.

Anders formuliert: Jedes Mal, wenn RHEL ein neues Minor Release vorstellt, unterbricht CentOS (und übrigens auch Oracle Linux) die Update-Versorgung, bis die eigene Variante des Minor Release fertig ist. CentOS-Anwender mussten ihre Systeme deswegen von Nov. 2019 bis Jän. 2020 (71 Tage) und von April 2020 bis Juni 2020 (48 Tage) ohne Updates betreiben.

Dass es schneller geht, beweist Oracle. Das Minor-Release 8.1 wurde innerhalb von 10 Tagen veröffentlicht, jenes für 8.2 innerhalb von 8 Tagen.

Anmerkung: Eigentlich gibt es gar kein »CentOS 8.1« oder »CentOS 8.2«. Stattdessen heißen die Versionen »CentOS Linux 8 (1911)« bzw. »CentOS Linux 8 (2004)«, wobei sich die Nummer 1911 oder 2004 auf Jahr und Monat des entsprechenden RHEL-Release beziehen. Der Einfachheit halber bleibe ich in diesem Artikel aber bei den durch RHEL vorgegebenen Versionsbezeichnungen.

Firmenpolitik

Red Hat hat sich das CentOS-Entwicklerteam 2014 einverleibt. Das kann man positiv sehen (Red Hat zahlt die CentOS-Entwickler), oder kritisch.

Mein persönlicher Eindruck ist, dass Red Hat (inzwischen genaugenommen IBM) CentOS zu Tode spart. Gleichzeitig müssen die wenigen Kapazitäten auch noch für neue Aufgaben (CentOS Stream) ausreichen.

Die unausgesprochene Wahrheit lautet: Wer Red Hat produktiv einsetzen will, soll dafür zahlen und nicht in Versuchung geführt werden, CentOS zu verwenden. Möglicherweise wird das dem anderen noch verfügbaren RHEL-Klon, nämlich Oracle Linux, neuen Auftrieb schaffen.

Fazit: Für den Produktiveinsatz nicht mehr geeignet

Der wochenlange Betrieb eines Servers ohne Update ist aus Sicherheitsgründen nicht zu empfehlen. Nun muss natürlich jeder Administrator für sich entscheiden, was zu lange ist: Zwei Tage ohne Updates? Zwei Wochen? Zwei Monate?

Wer Server für milliardenschwere Unternehmen oder für kritische Infrastruktur betreibt, ist diesbezüglich schon bisher keine Kompromisse eingegangen und hat eben eine Lizenz für RHEL erworben. Aber für eine kleinere Firmenwebsite war CentOS 7 in der Vergangenheit aus meiner Sicht ein tragbarer Kompromiss (und ist es bis heute). Für CentOS 8 ist das nicht mehr der Fall.

Damit wurde CentOS 8 zur Test- und Unterrichts-Plattform degradiert.

Quellen

• https://en.wikipedia.org/wiki/CentOS
• https://en.wikipedia.org/wiki/Oracle_Linux
• https://wiki.centos.org/FAQ/General#How_long_after_Red_Hat_publishes_a_fix_does_it_take_for_CentOS_to_publish_a_fix.3F

Update 19.6.2020

Nachdem Nicolas Kovacs eine Zusammenfassung und einen Link zu diesem Artikel in die CentOS-Mailingliste gesendet hat, wurde das Thema auch kurz diskutiert — allerdings ohne nennenswerte Resultate. Die langen Update-Lücken werden zwar bedauert, aber es hätte auch in der Vergangenheit keine Garantie für schnelle Updates gegeben.

Bei CentOS 8 sei alles noch komplizierter, und das CentOS-Team arbeite hart daran, das bestmögliche CentOS zu liefern. Mehr geht nicht. Johnny Hughes vom CentOS-Team: I am working my butt off everyday to make CentOS Linux the best it can be.

Johnny Hughes sieht die Zukunft in CentOS Stream, einer Art Rolling-Release-Development-Version von RHEL. Tatsächlich könnte das die Update-Lücken beheben. Allerdings ist CentOS Stream keine stabile Langzeit-Distribution, sondern ein Angebot für Entwickler. Vielleicht nicht so experimentell wie Fedora, aber eben auch nichts für den den Produktivbetrieb.

Andere Diskutanten sagen sinngemäß: Wer CentOS produktiv verwendet, ist eben selbst schuld.

https://lists.centos.org/pipermail/centos/2020-June/thread.html

Unser Bestseller ist soeben in der 2. Auflage erschienen.

Für die Neuauflage haben wir das Buch aktualisiert und um einige Abschnitte erweitert. Neue Themen sind unter anderem:

• Juice Shop (Testsystem für Web-Hacking mit JavaScript-Schwerpunkt)
• Koadic (Post-Exploitation-Framework)
• Password Spraying
• Fortgeschrittene Web-Hacking-Techniken (z.B. Angriff auf die Objektdeserialisierung)
• Pwnagotchi (WLAN-Hacking-Software für den Raspberry Pi)
• P4wnP1 (noch eine Angriffsplattform für den Raspberry Pi)

Mehr Details und Bestellinformationen finden Sie hier.