Red Hat Enterprise Linux 8

CentOS 8 ist noch nicht verfügbar. Deswegen habe ich mir eine 30-tägige Testversion von Red Hat Enterprise Linux 8 (RHEL 8) besorgt, um mir ein erstes Bild vom neuen Linux-Server-Standard zu machen.

RHEL8 mit Gnome-Desktop und »Cockpit« im Webbrowser

Installation

Wer schon einmal Fedora oder CentOS installiert hat, stößt bei RHEL 8 auf wenig Überraschungen. Der Partitionierungsdialog ist unübersichtlich wie eh und je, davon abgesehen ist die Installation aber ein Kinderspiel.

Partitionen und Dateisysteme einrichten
Installationsüberblick
Installationsumfang festlegen

Registrierung

Der Code von RHEL ist zwar Open Source, die Nutzung der Enterprise-Distribution und insbesondere der Zugriff auf die Paketquellen erfordert aber eine Lizenz. Die Aktivierung der 30-Tage-Testlizenz hat sich mühsamer gestaltet als erwartet. Der grafische Red Hat Subscription Manager, offenbar eine Art Web-Console, hat bei meinen Tests kläglich versagt. Wenn es dem Programm überhaupt gelang, eine Verbindung zu Red Hat herzustellen, dann scheiterte der Login mit der Fehlermeldung, die Organisation sei ungültig. In meinem für die 30-Tage-Evaluation eingerichteten Account bei https://access.redhat.com/management gibt es aber gar keine Möglichkeit, eine Organisation einzustellen.

Letztlich ist die Registrierung in einem Terminalfenster gelungen (und auch dort erst im fünften oder sechsten Versuch …):

subscription-manager register --username <yourname> --password <pw>
subscription-manager role          --set="Red Hat Enterprise Linux Server"
subscription-manager service-level --set="Self-Support"
subscription-manager usage         --set="Development/Test"
subscription-manager attach
  Aktueller Status der installierten Produkte:
  Produktname: Red Hat Enterprise Linux for x86_64
  Status:      Subskribiert

yum update
  Updating Subscription Management repositories.
  ....

Nach der erfolgreichen Registrierung zeigte dann auch der grafische Subscription Manager den korrekten Status an. Das ändert aber nichts daran, dass ich bei der Inbetriebnahme von RHEL 8 öfters an eine andere Firma gedacht habe (M…t).

Lizenzinformationen im Subscription Manager

Update 17.5.2019: Auf einem PC (also nicht in einer virtuellen Maschine) habe ich heute eine weitere RHEL-8-Installation durchgeführt. Deren Aktivierung im Rahmen eines Red Hat Developer Accounts gelang mit dem grafischen Subscription Manager auf Anhieb. Vielleicht hatte ich gestern einfach Pech?

Paketverwaltung und AppStreams

dnf/yum: Fedora ist schon vor Jahren auf dnf umgestiegen, RHEL jetzt auch (genaugenommen auf die dnf-Version 4.0). Aus Kompatibilitätsgründen kann das Kommando weiterhin mit yum aufgerufen werden. Auch in der Red-Hat-Dokumentation ist immer von yum die Rede.

Aus Sicht eines Fedora-Anwenders extrem lästig ist, dass bei yum install libre<tab> das Autocomplete funktioniert (wenn auch mit sekundenlangen Verzögerungen), mit dnf install libre<tab> hingegen nicht. Red Hat drängt seine Anwender also dazu, das Kommando als yum und nicht als dnf aufzurufen.

AppStream: Das in Fedora 28 eingeführte Modularity-Konzept wurde wie erwartet in RHEL integriert und hat bei der Gelegenheit auch gleich den neuen Namen AppStreams erhalten. Ein Blick in die Liste des AppStream-Repositories vermittelt den Eindruck, als würden sich ein Großteil aller Pakete nun dort befinden (und nicht mehr in der Basis-Paketquelle). Hier finden Sie ausführliche Dokumentation zum AppStream-Konzept in RHEL.

AppStreams geben viel neuer Flexibilität, machen den Umgang mit Paketen aber nicht unbedingt einfacher. Das Gnome-Programm Software kommt mit AppStreams überhaupt nicht zurecht und findet die meisten Programme ganz einfach nicht. Immer wieder frage ich mich, was dieses Programm in einer Distribution zu suchen hat, die sich an Administratoren, Entwickler etc., also in der Regel an Profis richtet.

Module sind Gruppen zusammengehöriger Pakete. yum module list liefert eine Liste aller Module. Dabei tauchen bekannte Namen wie mariadb, mysql, nginx, nodejs, php, python36 etc. auf. yum module info <name> liefert Details zu einem Modul:

yum module info mariadb

Name             : mariadb
Stream           : 10.3 [d][a]
Version          : 820190206164045
Context          : 9edba152
Profiles         : client, server [d], galera
Default profiles : server
Repo             : rhel-8-for-x86_64-appstream-rpms
Summary          : MariaDB Module
Description      : MariaDB is a community developed branch of MySQL ...
Artifacts        : Judy-0:1.0.5-18.module+el8+2765+cfa4f87b.x86_64
                 : galera-0:25.3.23-5.module+el8+2765+cfa4f87b.x86_64
                 : mariadb-3:10.3.11-1.module+el8+2765+cfa4f87b.x86_64
                 : mariadb-backup-3:10.3.11-1.module+el8+2765+cfa4f87b.x86_64
                 : mariadb-common-3:10.3.11-1.module+el8+2765+cfa4f87b.x86_64
                 : mariadb-devel-3:10.3.11-1.module+el8+2765+cfa4f87b.x86_64
                 : mariadb-embedded-3:10.3.11-1.module+el8+2765+cfa4f87b.x86_64
...

Um alle Pakete aus einem Modul zu installieren, führen Sie yum module install <modulname> aus.

Es ist nicht immer leicht zu erkennen, ob es von einem Modul mehrere Versionen gibt. (Das entscheidende Feature von AppStream ist es ja, dass ein Paket bzw. ein ganzes Modul in verschiedenen Versionen zur Verfügung gestellt werden kann. Das bedeutet aber nicht, dass alle Pakete im AppStream-Repository von dieser Funktion Gebrauch machen. Vielmehr gibt es von der Mehrheit der Pakete aktuell nur eine Versionsnummer.)

yum module info <name> zeigt immer nur die Hauptversion (Defaultversion) an. Ob es mehrere Versionen gibt, können Sie mit yum module list --all bzw. yum module list --all <name> ermitteln. Das trifft aktuell nur für die Module container-tools, perl und postgresql zu.

yum module list --all postgresql

Name          Stream      Profiles            Summary                                                              
postgresql    10 [d]      client, server [d]  PostgreSQL server and client module                                  
postgresql    9.6         client, server [d]  PostgreSQL server and client module          

Bei postgresql gilt also 10 als Default-Version. Wenn Sie davon abweichend die ältere Version 9.6 installieren möchten, führen Sie dieses Kommando aus:

yum module install postgresql:9.6
yum install @postgresql:9.6             (Kurzschreibweise)

Tipp: Wenn Sie ein Paket partout nicht finden, hilft zumeist yum search <name> weiter.

EPEL: Wie üblich beschränkt sich Red Hat bei den Paketen auf das Wesentliche. Wer nicht-offizielle Pakete sucht, wurde in der Vergangenheit in der EPEL-Paketquelle fündig. Allerdings unterstützt EPEL momentan RHEL 8 noch nicht. Es gibt Berichte, wonach die EPEL-Quellen für RHEL 7 auch für RHEL 8 funktionieren, aber eine optimale Lösung ist das natürlich nicht.

Flatpak: Die Flatpak-Bibliotheken sind standardmäßig installiert. Die Defaultausstattung für eine Desktop-Installation umfasst aber keine Flatpak-Pakete, und Software ist nicht in der Lage, nach Flatpaks zu suchen. Flatpaks befinden sich also gewissermaßen im »Stealth-Modus«, gut verborgen vor einer irrtümlichen Anwendung ;-)

Versionsnummern

Die folgende Tabelle fasst die wichtigsten Versionsnummern in RHEL8 zusammen.

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel     4.18   Gnome        3.28   bash       4.4   Apache     2.4
glibc      2.28   Firefox ESR    60   gcc        8.2   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       18.3   Thunderbird    60   Python 2.7/3.6   OpenSSH    7.8
systemd     239                                        qemu/KVM  2.12
NetworkMan 1.14                                        Postfix    3.3
GRUB       2.02                                        Samba      4.9

Natürlich ist RHEL nicht so aktuell wie Fedora. Aber Gimp 2.8?

Java-8-Pakete gibt es im Supplementary Repository.

LibreOffice, MariaDB, MySQL und Thunderbird sind im AppStream Repository versteckt.

Interessant ist mitunter auch, was fehlt: Nicht in den offiziellen Paketquellen enthalten sind unter anderem Docker und KDE. (Gnome ist der einzig offizielle Desktop für RHEL. Und zu Docker bietet Red Hat eigene Alternativen an.)

Zuletzt noch die Links zu den offiziellen Paketlisten: Basispakete und AppStream-Pakete

Desktop und Grafik

Für RHEL-7-Anwender macht Gnome mit Version 3.28 einen recht großen Sprung. Bemerkenswert ist auch, dass der Gnome-Classic-Modus zwar weiterhin angeboten wird; standardmäßig kommt jetzt aber das »richtige« Gnome mit der Gnome-Shell zum Einsatz. Wenn möglich, wird als Grafiksystem Wayland verwendet. Xorg steht natürlich weiter zur Verfügung.

Sonstige Neuerungen, veraltete Technologien

  • Das Dateisystem btrfs wird explizit nicht mehr unterstützt, das Kernelmodul steht nicht mehr zur Verfügung. Standardmäßig kommt xfs zum Einsatz, alternativ steht ext4 zur Wahl.

  • Firewalls basieren hinter den Kulissen auf der Nftables-Infrastruktur. Das Kommando iptables ist dazu kompatibel und funktioniert unverändert.

  • Wie bereits erwähnt, erfordert der Einsatz von RHEL (wie bisher) nicht gerade billige Lizenzen. Es gibt aber eine Ausnahme: Ein Basis-Image für den Container-Einsatz steht kostenlos zur Verfügung (siehe z.B. diesen Artikel auf zdnet.com). Für Entwickler gibt es im Rahmen des Red Hat Developer Program eine kostenlose Lizenz (nicht für den produktiven Einsatz).

  • Das Programm virt-manager zur Verwaltung von virtuellen Maschinen mit QEMU/KVM steht zwar weiter zur Verfügung, gilt aber als deprecated. Virtuelle Maschinen sollen nun in Cockpit eingerichtet werden. Das erfordert die Installation von cockpit-machines. Update 18.5.2019: Mittlerweile habe ich mir cockpit-machines angesehen. Da wird noch etwas Zeit vergehen, bis der virt-manager wirklich in den Ruhestand gehen kann. Die Verwaltung virtueller Maschinen im Cockpit versagt schon bei den Grundfunktionen.

  • Das Paket network-scripts gilt ebenfalls als deprecated. Für die Netzwerkkonfiguration ist nun alleine der NetworkManager zuständig. (Ich muss wohl meine Empfehlung revidieren, den NetworkManager bei Server-Installationen sofort zu entfernen. Das fällt mir schwer, zu oft habe ich dieses Programm schon verflucht …) Die Kommandos ifup und ifdown stehen weiterhin zur Verfügung, rufen aber den NetworkManager (nmcli) auf.

Cockpit

Beim ersten ssh-Login schlägt RHEL vor, ich solle doch das vorinstallierte Cockpit mit systemctl enable --now cockpit.socket aktivieren. Da lasse ich mich doch nicht zweimal bitten ….

Cockpit ist eine Webkonsole, die einen Systemüberblick gibt und grundlegende administrative Funktionen erfüllt. Der Funktionsumfang wächst, wenn Zusatzpakete wie cockpit-machines, cockpit-composer etc. installiert werden. Die Bedienung erfolgt über den Webbrowser (Adresse localhost:9090). Beim Login gelten die normalen Linux-Accounts. Ein root-Login ist möglich, und auch »gewöhnlichen« Benutzer können mittels sudo bzw. mit PolicyKit (pkexec) administrative Aufgaben erledigen.

Etwas konsterniert war ich, als ich bemerkt habe, dass Port 9090 nicht durch eine Firewall blockiert wird und nach außen hin zugänglich ist. Zudem fehlt Cockpit jeder Schutz gegen automatisierte Passwort-Cracker. Auch wenn sich die Cockpit-Entwickler eine Menge Gedanken gemacht haben, wie sicher Cockpit ist, erscheint mir das Setup doch mutig. Wenn Cockpit vorinstalliert ist, hätte man eigentlich fail2ban samt Cockpit-Regeln auch vorinstallieren können. (Hätte man nicht, weil fail2ban in den Paketquellen fehlt. Voraussichtlich wird das Paket in der EPEL-Paketquelle zu finden sein. Außerdem scheint es in fail2ban aktuell keine fertigen Regeln für Cockpit zu geben. Immerhin protokolliert Cockpit gescheiterte Login-Versuche, siehe journalctl -u cockpit.)

Ich will den Teufel jetzt nicht an die Wand malen, aber ich kann mir wirklich nicht vorstellen, dass ein gedankenloses Aktivieren von Cockpit sicherheitstechnisch empfehlenswert ist. Ob es eine gute Idee ist, dass Red Hat quasi bei erster Gelegenheit eine Anleitung zur Inbetriebnahme von Cockpit präsentiert, muss sich erst weisen.

Benutzerverwaltung in Cockpit in einem anderen Webbrowser im lokalen Netzwerk

CentOS 8

CentOS 8 ist in Arbeit, aber es ist nicht abzusehen, wie lange es dauern wird, bis die neue Version fertiggestellt wird. Einen groben Überblick über den Status der Arbeiten finden Sie auf der CentOS-Projektseite.

Quellen/Links

Red Hat Developer

Im Rahmen des Developer Programs stellt Red Hat eine kostenlose Lizenz für Entwicklungsarbeiten (nicht für den produktiven Einsatz) zur Verfügung:

Cockpit

Tests / Berichte