Seit dem 7. Mai 2019 ist Red Hat Enterprise Linux RHEL 8 verfügbar. Puzzle hatte am 8. Mai 2019 das erste System mit dem neusten Major Releases des bewährten Enterprise Linux im Einsatz. Wir konnten nun seit vier Monaten Erfahrungen mit dessen Betrieb sammeln. Im Folgenden berichten wir darüber, was es bei der Umstellung von RHEL7 auf RHEL8 zu beachten gibt.
Anaconda
Anaconda ist seit langer Zeit das Installationstool von RHEL. Bereits beim Staging unseres ersten Servers mit RHEL8 stiessen wir auf das erste Problem. Bei RHEL7 verwendeten wir Anaconda-Konfigurationen, die wir von RHEL6 übernommen hatten. Diese waren bei RHEL7 zwar deprecated, haben aber noch funktioniert. Mit RHEL8 waren wir gezwungen diese umzuschrieben.
Alte iPXE-Config:
kernel \
ks=https://foreman.puzzle.ch/unattended/provision?static=yes \
ksdevice=00:12:34:56:78:aa \
network kssendmac ip=${netX/ip}::${netX/gateway}:${nenetmask}:::off nameserver=${dns}
Neue iPXE-Config:
kernel \
ks=https://foreman.puzzle.ch/unattended/provision?static=yes \
ksdevice=00:12:34:56:78:aa \
network kssendmac ip=${netX/ip} netmask=${netX/netmask} gateway=${netX/gateway} dns=${dns}
Während es bei RHEL6 noch inoffizielle Bestpractice war, den NetworkManager zu deinstallieren, entschieden wir uns, diesen bei RHEL8 im Einsatz zu lassen. Der NetworkManager bezieht seine Konfigurationen von den bekannten ifcfg-Files unter /etc/systconfig/Network-Scripts/. Änderungen, die mit nmcli abgesetzt werden, ändern die entsprechenden Configfiles. Unsere Erfahrung zeigt, dass der NetworkManager stabil läuft, selbst wenn die Konfigurationen initial mit Ansible über die Konfigurationsfiles definiert werden.
Security
Wie den Releasenotes von RHEL8 zu entnehmen ist, gibt es mit crypto-policies ein Konzept, das erlaubt, kryptographische Einstellungen systemweit zu setzen. Zum Beispiel werden nur noch TLS 1.2 und höher, IKEv2, SSH2 und RSA Keys mit einer Länge von mindestens 2047 Bits akzeptiert. Die neuen Policies zwangen uns ältere Shell-Scripte anzupassen, konkret mussten wir Hashes mit neueren Algorithmen generieren lassen. Wir hätten auch mit update-crypto-policies --set LEGACY auf dem System ältere kryptographische Policies erlauben können – was wir aber natürlich nicht wollten.
Ansible
Da wir unsere Systeme alle mittels Ansible konfigurieren, war es für uns kritisch, dass Ansible auf den neuen Systemen problemlos funktioniert. Zu Beginn war Ansible 2.8 und damit die Python Interpreter Discovery nicht verfügbar. Da bei RHEL8 Systemen nur noch Python3 installiert ist und dabei kein Executable /usr/bin/python mehr vorhanden ist, schlugen Ansible-Playbook-Runs fehl. Ein einfacher Symlink von /usr/bin/python auf das verfügbare Python-Executable konnte hier Abhilfe schaffen. Mit Ansible 2.8 ist aber das erwähnte Python Interpreter Discovery verfügbar und die Playbook-Runs funktionieren auch auf RHEL8 out-of-the-box.
YUM oder DNF?
Am 11. Mai 2015 wurde die erste stabile Version von DNF (aka Dandified YUM) veröffentlicht und mit Fedora 22 als Standard-Paketmanager mitgeliefert. DNF ist ein Rewrite von YUM (aka Yellow Dog Updater), dem Paketmanger von Red Hat für rpm-Pakete, und sollte einige Schwachstellen von YUM beseitigen. Der Gebrauch von dnf ist nahezu identisch mit dem Gebrauch von yum. Auf RHEL8 existieren Softlinks für die Befehle yum und dnf, so dass sich ein Administrator keine neuen Automatismen aneignen muss.
Repositories
Bei einer Basisinstallation mit einer Standard-RHEL-Subscription hat das System zwei Repositories verfügbar:
[root@rhel8test ~]# yum repolist Updating Subscription Management repositories. Last metadata expiration check: 0:20:33 ago on Tue 03 Sep 2019 07:58:27 AM EDT. repo id repo name status rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) 5,770 rhel-8-for-x86_64-baseos-rpms Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) 2,097 [root@rhel8test ~]#
[root@rhel8test ~]# yum repolist Updating Subscription Management repositories. Last metadata expiration check: 0:20:33 ago on Tue 03 Sep 2019 07:58:27 AM EDT. repo id repo name status rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) 5,770 rhel-8-for-x86_64-baseos-rpms Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) 2,097 [root@rhel8test ~]#
Im Repo „baseos“ sind die System-Pakete verfügbar und das Appstream-Repo wiederum bildet ein neues YUM-Feature ab: Module. Neu gibt es Software-Pakete, zum Teil in verschiedenen Versionen. Eine solche Version wird in einem „Modul“ abgebildet. Zusammenpassende Module wiederum werden in „Profiles“ gebündelt. PostgreSQL ist ein Beispiel für eine Software, die in verschiedenen Versionen („Modules“) verfügbar ist:
[root@rhel8test ~]# yum module info postgresql | grep Stream Stream : 10 [d][a] Stream : 9.6 [root@rhel8test ~]#
Verfügbare Profile sind „common“, „devel“ oder „minimal“. Bis jetzt haben wir in unseren Umgebungen keinen Verwendungszweck gefunden und können nicht über den Sinn von Profiles aus Betriebssicht urteilen. Die AppStreams scheinen eine gute Idee zu sein, es stellt sich aber die Frage, ob dem Bedürfnis nach spezifischen Softwareversionen nicht mit anderen Ansätzen, wie zum Beispiel Containern, besser Rechnung getragen werden.
Epel-Repository
Das Epel-Repository steht seit Juli 2019 zur Verfügung. Diese beinhaltet aber noch nicht alle Pakete, die im Epel-Repo von RHEL7 waren. Es gilt also abzuklären, ob benötigte Pakete aus dem EPEL-Repo tatsächlich verfügbar sind für RHEL8.
Systemd
Die Diskussionen um systemd sind auch mit RHEL8 nicht abgeflacht. Befürworter und Gegner führen immer noch angeregte Streitgespräche. Fakt ist, dass systemd auch bei RHEL8 ein zentraler Baustein ist und man sich damit auseinandersetzen muss. Einige Bestandteile von systemd sind auch heute noch nicht allen Systemadministratoren bekannt. Cockpit, zum Beispiel, nutzt einen Unit des Typs Socket. Damit ist es möglich, dass die Software Cockpit keine Systemressourcen verbraucht, solange keine Connection auf den definierten Port (default 9090) geöffnet ist. Socket-Units verlangen ein Service-Unit mit dem gleichen Namen (solange diese Konfiguration nicht explizit überschrieben wurde) und aktivieren den Service nur, wenn eine Verbindung auf den definierten Port geöffnet wird.
[root@rhel8test ~]# ps -ef | grep cockpit | grep -v cockpit [root@rhel8test ~]#
Keine Connection auf den Port bedeutet, auf dem System läuft kein Prozess
Nach Login auf der Webseite https://rhel8test:9090:
[root@rhel8test ~]# ps -ef | grep cockpit | grep -v grep cockpit+ 12098 1 11 07:37 ? 00:00:00 /usr/libexec/cockpit-ws root 12102 12098 1 07:37 ? 00:00:00 /usr/libexec/cockpit-session localhost root 12109 12102 14 07:37 ? 00:00:00 cockpit-bridge root 12124 12109 33 07:37 ? 00:00:00 /usr/bin/cockpit-bridge --privileged root 12132 12109 3 07:37 ? 00:00:00 /usr/libexec/cockpit-pcp [root@rhel8test ~]#
Sobald eine Connection auf den Port 9090 eröffnet wird, werden die benötigten Prozesse gestartet.
Der Vorteil eines Enterprise Linux besteht darin, dass der Anbieter meist garantiert, dass Pakete stabil laufen und Sicherheitslücken zeitnah geschlossen werden. Aus diesem Grund haben viele Administratoren in der Vergangenheit das Paket yum-cron installiert. Yum-cron stellte einen einfachen Mechanismus bereit, das Betriebssystem via Cron-Jobs stets aktuell zu halten. Auf RHEL8 sucht man vergeblich nach yum-cron. Auch dnf-cron gibt es nicht. Das Paket, das die gewünschte Funktionalität zur Verfügung stellt, heisst dnf-automatic. Für die regelmässige Ausführung von dnf ist nicht mehr ein Cronjob zuständig, sondern ein Systemd Timer-Unit. Timer-Unitfiles verlangen, gleich wie Socket-Unitfiles, dass ein Service-Unitfile mit demselben Namen existiert und dass es beim Aktivieren des Timer-Units ausgeführt wird. Ein Timer-Unit enthält eine Section [Timer], in der die Angaben zum Ausführungszeitpunkt enthalten sind. Im Beispiel von dnf-automatic.timer ist das:
[Timer] OnBootSec=1h OnUnitInactiveSec=1d RandomizedDelaySec=5m AccuracySec=1s
Der Timer wird also 1h nach dem Boot-Vorgang (OnBootSec) und einen Tag nach dem letzten Ausführen gestartet (OnUnitInactiveSec). Der Timer sollte in einer Sekunde abgearbeitet werden (AccuracySec) und wird zufällig um bis zu fünf Minuten verschoben (RandomizedDelaySec). Systemd Timers erlauben auch die Ausführung zu bestimmten Tagen und Uhrzeiten wie das von Cronjobs bekannt ist. Nähere Informationen findet man in der Manpage zu systemd.timer. Mit dem Befehl systemctl list-timers lassen sich alle Timers des aktuellen Users anzeigen.
Cockpit
Mit RHEL8 erhält das Cockpit-Projekt Einzug ins Enterprise Linux von Red Hat. Cockpit wird über eine Weboberfläche bedient und kann als Paket mit yum install cockpit installiert werden. Die Web-Oberfläche stellt ein graphisches Interface für viele administrative Tätigkeiten dar: System-Logs, Subskriptionen, Paketinstallationen, Services, Accounts, SELinux-Einstellung, Systemauslastungen und vieles mehr lässt sich damit einsehen und administrieren. Aus unserer Sicht ist Cockpit zur Zeit eher für Administratoren mit wenig Erfahrung interessant. Erfahrene System-Engineers werden wohl bei ihren gewohnten Tools auf der Commandline bleiben.
Byebye Virt-Manager
Da wir KVM-Virtualisierung im Einsatz haben, liess uns die Nachricht, dass der virt-manager deprecated ist und in Zukunft vom Projekt Cockpit abgelöst wird, aufhorchen. Damit im Cockpit Virtual Machines ebenfalls angezeigt wurden, musste das Paket „cockpit-machines“ nachinstalliert werden. Anschliessend lassen sich die Virtual Machines unter dem gleichnamigen Reiter einsehen.
Das Erstellen einer neuen VM über den Button „Create VM“ hat nicht funktioniert. Ebenfalls stellt Cockpit noch bei weitem nicht alle Features zur Verfügung, die der Virt-Manager anbietet. Aus diesen Gründen ist vom produktiven Einsatz von Cockpit als Virt-Manager-Ersatz noch abzuraten.
Fazit
Es gibt viele Gründe RHEL8 produktiv einzusetzen. Die bereits verfügbare Menge an Software ist gross und die Unterschiede in der Handhabung gegenüber RHEL7 sind gering. Wir stehen euch bei der Migration auf RHEL8 gerne zur Seite!