Schlagwort-Archive: RHEL

Warum entwickelt/testet ihr (nicht) auf CentOS Stream, Fedora oder RHEL?

Hi, mein Name ist Jörg. Ich arbeite seit März 2023 als Senior Technical Account Manager für Red Hat und mir schwirren derzeit folgende Fragen im Kopf herum:

Wer sind die Menschen, die Open Source Software auf bzw. für CentOS Stream, Fedora und/oder RHEL entwickeln?
- Sind es Menschen, die dies ausschließlich in ihrer Freizeit tun?
- Arbeiten sie in Unternehmen, welche nach dem Open Source Entwicklungsmodell arbeiten?
Warum habt ihr euch für oder gegen die eine oder andere Distribution entschieden?
Was hindert euch daran, eine der genannten Distributionen zu verwenden?
Aus welchem Grund bevorzugt ihr andere Distributionen und welche sind dies?

Hinsichtlich dieser Fragen habe ich selbst offensichtlich einen Interessenskonflikt und bin darüber hinaus zu einem hohen Grad betriebsblind. Deshalb bin ich umso mehr daran interessiert, eure Antworten auf diese Fragen zu lesen.

Ich freue mich, wenn ihr euch die Zeit nehmt, um mir zu antworten und mir zu erläutern, wie ihr dazu steht. Eure Nachrichten nehme ich gern auf folgenden Kanälen entgegen:

Als Kommentar unter diesem Artikel
Als E-Mail an jkastning+distribution (at) my-it-brain (dot) de
Als Chat-Nachricht in #my-it-brain:matrix.org

Es freut mich, wenn daraus eine freundliche und konstruktive Diskussion entsteht. Sollte es dabei allerdings zu Trolling oder unangemessenen Äußerungen kommen, werde ich die Kommentare schließen und die Kommunikation einstellen. Bitte geht daher höflich miteinander um und behandelt einander so, wie ihr selbst auch behandelt werden möchtet.

Red Hat Enterprise Linux registrieren und System Purpose konfigurieren mit Ansible

Schreibe eine Antwort

Um die Paketquellen von Red Hat für Red Hat Enterprise Linux (RHEL) nutzen zu können, wird eine sogenannte Software-Subskription benötigt. Diese bestimmt, auf welche Paketquellen ein System zugreifen und deren Inhalt konsumieren kann.

Das System der Subskriptionen befindet sich im Umbruch (siehe [1]). In diesem Artikel beschreibe ich, wie es bisher war, was sich durch die Aktivierung von Simple Content Access (SCA) [2] ändert und wie ich aktuell meine RHEL-Systeme registriere und deren System Purpose konfiguriere.

Der Text vermittelt dabei Wissen zum Red Hat Subscription Management (RHSM), Simple Content Access (SCA), Subscription Watch (SWatch), dem System Purpose und verlinkt relevante Quellen.

Aus Transparenz-Gründen möchte ich an dieser Stelle darauf hinweisen, dass ich Mitglied der Red Hat Accelerators bin (vgl. hier). Dieser Text spiegelt ausschließlich meine persönliche Meinung wider.

Subskriptions-Verwaltung ohne SCA

Eine Subskription berechtigt zur Nutzung bestimmter Paketquellen von Red Hat. Sie umfasst in der Regel eine gewisse Menge sogenannter Entitlements. Diese bestimmen, wie viele Systeme von einer Subskription abgedeckt werden.

Ein Beispiel: Eine Subskription für „Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes)“ beinhaltet zwei Entitlements. Damit lassen sich ein physischer Server mit bis zu zwei CPU-Sockeln oder zwei virtuelle Maschinen (mit einer beliebigen Anzahl CPUs) zur Nutzung der Paketquellen berechtigen.

In der Regel werden RHEL-Systeme über den subscription-manager beim Red Hat Subscription Management (RHSM) oder einem Satellite Server registriert. Anschließend werden sie mit einer Subskription verknüpft. Wie man dies lösen kann, habe ich 2019 in dem Artikel RHEL-System registrieren und Subskription hinzufügen beschrieben.

Vorteile des RHSM

Das RHSM im Customer Portal bietet eine gute Übersicht über die vorhandenen Verträge, die Subskriptionen, deren Laufzeiten und verknüpfte Systeme. Man sieht hier auf einen Blick, ob man ausreichend Subskription hat, um all seine Systeme damit abdecken zu können.

Nachteile des RHSM

Um ein System beim RHSM zu registrieren und mit einer Subskription zu verknüpfen, muss das System eine Verbindung ins Internet zum RHSM-Dienst aufbauen. Dies ist im Datacenter häufig nicht erwünscht. Für Systeme ohne Zugang zum Internet gibt es die optionale Offline-Registrierung [3], welche jedoch etwas umständlich ist und bei vielen Offline-Systemen nicht skaliert.

Registriert man die Systeme nicht, ist man dennoch zu einer ordentlichen Buchführung verpflichtet, um sicherzustellen, dass man nicht dauerhaft mehr Systeme einsetzt, als durch vorhandene Subskriptionen abgedeckt sind.

Läuft ein Subskriptionsvertrag ab, werden die Entitlements ungültig. Die damit verknüpften Systeme fangen an, sich beim Update-Versuch darüber zu beschweren und verweigern den Zugriff auf die Paketquellen. Das ist besonders ärgerlich, weil es nach meiner Erfahrung bei jeder Vertragsverlängerung passiert. Denn tatsächlich wird der Vertrag nicht verlängert. Es gibt einen neuen Vertrag mit der entsprechenden Anzahl Subskriptionen. Diese müssen dann manuell neu verknüpft werden, was jedes Mal manuellen Pflegeaufwand bedeutet.

Vermutlich um dem zuvor genannten Ärgernis entgegenzuwirken hat Red Hat die Funktion auto-attach entwickelt. Wird die mit einem registrierten System verknüpfte Subskription ungültig sucht auto-attach automatisch nach einer geeigneten freien Subskription und verknüpft diese mit dem jeweiligen System. Nun mag sich manch einer Fragen, wie auto-attach wohl entscheidet, wenn es mehrere Subskriptionen gibt, die prinzipiell geeignet sind. Nach meiner Erfahrung wählt auto-attach mit einer Wahrscheinlichkeit von >95 % die am wenigsten geeignete Subskription aus. In meinen Augen nervt es mehr, als das es hilft.

Das Verknüpfen von Subskriptionen ist für die Buchführung praktisch, für den Betrieb eher nervig. Teilweise stört es sogar Betriebsabläufe, wenn z.B. Updates vorübergehend nicht installiert werden können. Um dem zu begegnen, hat Red Hat Simple Content Access (SCA) [2] geschaffen.

Was ändert sich durch SCA?

Wird SCA im RHSM aktiviert, müssen Subskriptionen nicht mehr mit Systemen verknüpft werden. RHEL-Systeme, die im RHSM registriert sind, erkennen dies und setzen für den Zugriff auf die Paketquellen kein Entitlement mehr voraus.

Vorteile

Der Betrieb wird vereinfacht. Ein System muss nur noch registriert werden und kann sofort auf Inhalte der diversen Paketquellen zugreifen.

Unterbrechungen im Betriebsablauf bei Ablauf einer Subskription gehören der Vergangenheit an.

Auch auto-attach bereitet nun keinen Ärger mehr.

Nachteile

Die Buchführung wird aufwändiger, da RHSM mit aktivierten SCA nur noch begrenzt dafür taugt. Man muss sich nun einen anderen Weg überlegen, wie man den Überblick behält.

Subscription Watch

Subscription Watch [4, 5] ist ein SaaS-Dienst in der Hybrid Cloud Console [6], welcher den Kunden dabei unterstützen soll, im Blick zu behalten, wie viele Subskriptionen er besitzt und wie viele er konsumiert. Dabei ist es möglich, mehr zu konsumieren, als man besitzt. Wird dies angezeigt, kann man handeln und fehlende Subskriptionen nachkaufen.

Leider hat die Sache einen Haken. Es funktioniert nicht richtig. In meinem Fall kommt eine Mischung aus kostenpflichtigen Subskriptionen und der Developer Subscription for Teams zum Einsatz. Im Subscription Watch gibt es einen Bug, durch den mir angezeigt wird, ich würde mehr Subskriptionen nutzen, als ich im Bestand habe, obwohl dies nicht der Fall ist.

Ich habe zu dem Fall ein Support-Ticket, in dem das Verhalten reproduziert werden konnte und der Fehler bestätigt wurde. Nur eine Lösung gibt es noch nicht. Leider ist Subscription Watch im aktuellen Status damit nutzlos für mich.

System Purpose

Was der System Purpose ist, wird im Detail in [1] und [7] beschrieben. Red Hat empfiehlt den System Purpose zu pflegen, um u.a. Subscription Watch dabei zu helfen, die konsumierten Inhalte korrekt zu zählen. Das hat folgenden Hintergrund.

Sowohl mit der „Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes)“ Subskription als auch mit der „Developer Subscription for Teams“ darf man das RHEL-8-BaseOS-Repo nutzen. Gezählt werden soll in Subscription Watch jedoch nur die kostenpflichtige Subskription (Erstgenannte). Mit Hilfe des System Purpose gibt man an, ob es sich um ein Produktionssystem oder ein Test-/Entwicklungs-System handelt und steuert darüber, ob ein System in Subscription Watch gezählt wird.

Funktionieren tut das Ganze leider (noch) nicht. Unter anderem ist der zuvor erwähnte Bug dafür verantwortlich. Ich pflege den System Purpose jedoch trotzdem, in der Hoffnung, dass es in der Zukunft funktionieren wird.

Wie registriere ich meine Systeme heute?

Ich habe dazu eine kleine Ansible-Rolle erstellt, welche folgende Struktur besitzt:

roles/register_syspurpose/
├── defaults
│   └── main.yml
├── README.md
└── tasks
    └── main.yml

Das Readme.md enthält eine Beschreibung der notwendigen Variablen und ein Beispiel-Playbook, wie man diese Rolle nutzt:

register_syspurpose
===================

Register host to RHSM and set System Purpose.

Requirements
------------

 * [community.general collection](https://galaxy.ansible.com/community/general)

You might already have installed this collection if you are using Ansible Engine 2.9 or the `ansible` package. It is not included in `ansible-core`. To check whether it is installed, run `ansible-galaxy collection list`.

To install it, use: `ansible-galaxy collection install community.general`.

To use it in a playbook, specify: `community.general.redhat_subscription`.

Role Variables
--------------

```yaml
register_syspurpose_activationkey: register-syspurpose # activationkey for access.redhat.com or Satellite
register_syspurpose_org_id: 123456 # Org ID on access.redhat.com or Satellite
register_syspurpose_role: "Red Hat Enterprise Linux Server"
# possible values are:
# Red Hat Enterprise Linux Server
# Red Hat Enterprise Linux Workstation
# Red Hat Enterprise Linux Compute Node

register_syspurpose_sla: "Self-Support"
# possible values are:
# Premium
# Standard
# Self-Support

register_syspurpose_usage: "Development/Test"
# possible values are:
# Development/Test
# Disaster Recovery
# Production
```

I got these values from the KB [syspurpose_usage: "Development/Test"](https://access.redhat.com/articles/5713081).
There might be other possible values out there. In case you know some valid
addtional values please sent a PR to add them to this documentation.

Dependencies
------------

None.

Example Playbook
----------------

Including an example of how to use your role (for instance, with variables passed in as parameters) is always nice for users too:

~~~
- hosts: all
  gather_facts: no
  roles:
    - register_syspurpose
~~~

License
-------

MIT.

Author Information
------------------

Joerg Kastning - "joerg (dot) kastning '@' uni-bielefeld (dot) de"

Auch die Tasks-Datei ist sehr übersichtlich:

---
# tasks file for register_syspurpose
- name: Register system to RHSM and set syspurpose attributes
  redhat_subscription:
    state: present
    activationkey: "{{ register_syspurpose_activationkey }}"
    org_id: "{{ register_syspurpose_org_id }}"
    syspurpose:
      role: "{{ register_syspurpose_role }}"
      service_level_agreement: "{{ register_syspurpose_sla }}"
      usage: "{{ register_syspurpose_usage }}"
      sync: true

Um die Variablen mit Werten zu belegen, nutze ich group_vars. Ich verwende ein statisches Inventory, in dem ich Gruppen für die möglichen Kombinationen aus role, sla und usage definiert habe. So wird jeder neue Host der entsprechenden Gruppe hinzugefügt und anschließend bei der Provisionierung direkt registriert und korrekt konfiguriert. Detaillierte Informationen zum verwendeten Modul redhat_subscription bietet die Dokumentation unter [8].

Ihr seht, es steckt keine Magie in der Rolle. But I like to Keep It Simple, Stupid.

Fazit

Das Red Hat Subscription Management ist kompliziert, hat seine Macken, eine Geschichte und etliche Altlasten. Ein Team um Rich Jerrido hat es sich zur Aufgabe gemacht, das Subskriptions-System zu überarbeiten und alte Zöpfe abzuschneiden. Ich beneide das Team nicht um diese Aufgabe.

Das System befindet sich aktuell im Übergang (siehe [1]). Damit gehen Herausforderungen sowohl für Red Hat als auch dessen Kunden einher.

Das Red Hat die technischen Abhängigkeiten zwischen Betriebssystem und RHSM mit SCA abschafft, weiß ich zu schätzen. Schade, dass die Unterstützung bei der Buchführung dabei auf der Strecke bleibt.

Subscription Watch bietet mir auch in der nahen Zukunft keinen Nutzen. Um meinen Pflichten aus [9] nachzukommen, werde ich mir Red Hat Discovery näher ansehen. Meine Erfahrungen werde ich anschließend hier im Blog niederschreiben.

Quellen und weiterführende Links

Potenzielle Mehrwerte einer Red Hat Enterprise Linux Subscription

Schreibe eine Antwort

Wer Red Hat Enterprise Linux (RHEL) betreiben möchte, benötigte dazu eine sogenannte Subskription, im Folgenden RHEL-Sub genannt. Die Kosten für eine RHEL-Sub ergeben sich aus der Art der RHEL-Sub und dem damit verbundenen Service-Level. Der schon etwas ältere Artikel Support-Subskriptionen von SUSE und Red Hat gibt hierzu einen kleinen Einblick.

Da RHEL-Klone wie AlmaLinux und Rocky Linux kostenlos verfügbar sind, kommt schnell die Frage auf: „Warum soll ich für RHEL soviel Geld bezahlen, wenn ich quasi das gleiche OS unter anderem Namen kostenlos nutzen kann?“

Um bei der Beantwortung dieser Frage zu helfen, stelle ich in diesem Artikel einige potenzielle Mehrwerte vor, die man mit dem Erwerb einer RHEL-Sub erhält.

Aus Gründen der Transparenz weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community und System-Administrator diverser RHEL-Server bin. Dieser Text gibt ausschließlich meine persönlichen Ansichten und nicht die von Red Hat oder die meines Arbeitgebers wieder. Zwar können diese in einzelnen Punkten übereinstimmen, müssen es aber nicht.

Kostenlose RHEL-Subs

Nicht alle RHEL-Subs kosten Geld. Es gibt auch zwei Subskriptionen, mit denen sich RHEL und bestimmten Rahmenbedingungen kostenlos betreiben lässt.

Red Hat Developer Subscription for Individuals

Ein jeder kann über das Red Hat Developers Program (engl.) kostenlos eine persönliche RHEL Developer Subscription (engl.) erhalten. Mit dieser Sub erhält der Besitzer das Recht, bis zu 16 Systeme (physisch oder virtuell) zu betreiben; auch in Produktion.

Die Subskription muss jedes Jahr verlängert werden. Die Verlängerung ist ebenfalls kostenlos.

Die Subskription beinhaltet keinen kommerziellen Support. Man hat lediglich Zugriff auf die Wissensdatenbank und die Customer Portal Community. Die SaaS-Dienste Red Hat Insights und Image Builder können auch mit dieser Subskription genutzt werden.

Red Hat Developer Subscription for Teams

Im Unterschied zur oben vorgestellten individuellen Subskription dürfen Systeme mit der RHEL-Sub-for-Teams nicht in Produktion betrieben werden. Sie dient ausschließlich der Entwicklung, dem Test und der Qualitätssicherung. Dafür dürfen mit dieser Sub eine sehr große Anzahl RHEL-Systeme provisioniert werden.

Ich bin mir nicht sicher, ob ich eine genaue Zahl nennen darf. Darum glaubt mir bitte, wenn ich euch sage: „Es sind wirklich eine Menge Berechtigungen für physische und virtuelle Systeme enthalten.“

Diese Subskription erhaltet ihr nur über euer Red Hat Account Management. Falls ihr dieses (noch) nicht kennt, wendet euch im Zweifel an die Firma, wo ihr eure RHEL-Subs kauft.

Mich selbst hat es einige Mühen gekostet, an diese Sub zu kommen. Laut Aussage meines Account-Managers war ich der erste Kunde in Deutschland, der diese Sub kannte und haben wollte. Dank der Red Hat Accelerators und meines Account-Managers, der nicht aufgegeben hat, hat es schlussendlich geklappt. Falls ihr Probleme habt, diese Sub zu bekommen, schreibt mich einfach an. Vielleicht habe ich noch einen Tipp für euch.

Für den Support, Zugriff auf Red Hat Insights und Image Builder gelten die gleichen Bedingungen wie für die RHEL Developer Subscription for Individuals.

Support

Support meint an dieser Stelle nicht die Hilfe und Unterstützung, die man auf Mailinglisten, in Foren oder Chats erhalten kann. Gemeint ist ausschließlich der kommerzielle Support der Firma Red Hat, welchen man per Telefon, E-Mail oder das Customer Portal erreichen kann.

Über den Support hat man Kontakt zu den Menschen, die sich vermutlich am besten mit dem Produkt auskennen. Hier sitzen Menschen, die dafür bezahlt werden, uns Kunden bestmöglich zu unterstützen. Dabei mag es von Fall zu Fall Schwankungen in der Reaktionszeit und/oder der Qualität geben.

Mir persönlich hat der Support schon in etlichen Fragestellungen und bei einigen hartnäckigen Problemen weiterhelfen können. Dabei waren so schöne Dinge wie Kernel Panic bei Zugriff auf eine eingehängte DFS-Ressource, deren Shares in einer HNAS-Speicher-Infrastruktur liegen. Ich glaube, sowas haben die wenigsten Menschen bei sich daheim im Keller stehen. Und die Chance, bei diesem Problem Hilfe in einem Forum oder Chat zu finden, dürfte dementsprechend gering sein. Der Support stellte in diesem Fall Kontakt zu einem Engineer her, der über eine hervorragende Kenntnis der beteiligten Protokolle und Protokollversionen verfügte und beim Debugging unterstützte. Am Ende erhielten wir einen angepassten Kernel, der das Problem löste und den wir nutzen konnten, bis das Problem auch Upstream und im regulären RHEL-Kernel gefixt wurde.

Nicht zuletzt ist kommerzieller Support ein guter Verbündeter, wenn man selbst nicht weiterweiß und sich Druck aufbaut. Nach dem Motto: „Wenn selbst der Hersteller nicht weiter weiß, woher soll ich dann wissen, warum es nicht geht?“ Es ist nie schön, wenn es soweit kommt. Noch hässlicher wird es, wenn man dann nicht auf jemand anderen zeigen kann.

Red Hat Insights

Zu Red Hat Insights (engl.) habe ich in der Vergangenheit bereits eine eigene Serie geschrieben, auf die ich an dieser Stelle verweise:

Dieser Dienst steht auch mit den kostenlosen Developer-Subs zur Verfügung. Vorausgesetzt, die Nutzung ist unter geltendem Recht möglich, stellt dieser Dienst einen echten Mehrwert dar. Ein vergleichbarer Dienst existiert für AlmaLinux und Rocky Linux nicht.

Image Builder (SaaS)

In größeren Umgebungen (IHMO >2 Systeme) werden Server meist nicht mehr individuell installiert, sondern von sogenannten Images oder Templates provisioniert. Diese sind initial zu erstellen und fortlaufend zu pflegen.

Image Builder ist ein SaaS-Dienst in Red Hat Insights, welcher bei der Erstellung solcher Templates unterstützt. Dabei können Images direkt für die Cloud Anbieter Amazon Web Services, Google Cloud Platform, Microsoft Azure, VMware vSphere, KVM/QEMU (.qcow2) und Bare Metal erstellt werden.

Es handelt sich dabei um einen noch recht jungen Dienst, der einige Einschränkungen hat. So ist das einzige derzeit unterstützte Dateisystem für Images XFS. Ein RFE, um Ext4 als unterstütztes Dateisystem hinzuzufügen, ist gestellt.

Auch lassen sich aktuell über diesen Dienst noch keine User oder SSH-Public-Keys in die Images integrieren. Für diese Funktionalität habe ich ebenfalls bereits RFEs geschrieben.

Ich bin gespannt, wie Red Hat diesen Dienst weiterentwickelt. In meinen Augen hat er das Potenzial, zu einem nützlichen Werkzeug zu reifen.

Diesen Dienst kann man ebenfalls mit den kostenlosen Developer-Subs nutzen, während ein vergleichbarer Dienst meines Wissens für AlmaLinux und Rocky Linux nicht existiert.

Fazit

Ob die genannten Mehrwerte tatsächlich zum Tragen kommen, muss jeder für sich und seine Organisation selbst beurteilen. Sie sollten jedoch vor einer Entscheidung in die Überlegungen mit einbezogen werden.

Die Nutzung von Red Hat Insights ist in unserem Rechtsraum schwierig, bis nahezu unmöglich. Dort wo der Dienst genutzt werden kann, stellt er ein gutes Werkzeug dar, welches dem Admin die tägliche Arbeit erleichtert.

Ich werde ein kleines Heimlabor aus RHEL-Servern aufbauen und diese in Red Hat Insights integrieren. Vielleicht gewinne ich dadurch Erkenntnisse, die sich auch auf den Betrieb im Rechenzentrum übertragen lassen.

Der Image Builder ist als SaaS in seiner jetzigen Form nur von geringem Nutzen für mich. Ich hoffe, dass meine RFEs akzeptiert und umgesetzt werden, um diesen Service und dessen Nutzen weiter auszubauen.

Ein Blick auf AlmaLinux, RHEL und Rocky Linux

2 Antworten

In diesem Artikel möchte ich einen Blick auf die Linux Distributionen AlmaLinux und Rocky Linux werfen und sie ihrem Upstream-Projekt Red Hat Enterprise Linux (RHEL) gegenüber stellen. Dabei interessieren mich insbesondere die folgenden Punkte:

Wer betreibt das Projekt bzw. steht hinter dem Projekt?
Wie finanziert sich das Projekt? Gibt es ein funktionierendes Geschäftsmodell?
Welchen Eindruck hinterlässt die Dokumentation?
Wie lange wird ein Major-Release unterstützt?
Wie viele Tage liegen zwischen einem RHEL-Release und den Releases der beiden Projekte?
Wie handhaben die Projekte Sicherheits-Updates?

Was haben beide Projekte gemeinsam?

Sowohl AlmaLinux als auch Rocky Linux sind nach eigener Aussage:

Produktionsreife Betriebssysteme
Binärkompatibel zu RHEL
Werden aus den RHEL-Quelltexten übersetzt
Für den Nutzer kostenlos
Bieten 10 Jahre Unterstützung für ein Major-Release

Auch Red Hat bietet 10 Jahre Support auf seine RHEL-Major-Releases (Login erforderlich), an die sich eine Extended Life Phase anschließen kann. Selbstverständlich ist auch RHEL nach eigener Aussage reif für den produktiven Einsatz. Im Unterschied zu AlmaLinux und Rocky Linux kann RHEL jedoch nur zusammen mit einer kostenpflichtigen Subskription sinnvoll betrieben werden. Je nach Größe der Umgebung und Anzahl RHEL-Instanzen können hier beträchtliche Kosten anfallen.

Wer steht hinter den Distributionen?

Bei AlmaLinux handelt es sich um ein Community-Projekt, welches von der Firma CloudLinux Inc. gestartet wurde, welche das Projekt auch mit 1 Mio. USD pro Jahr unterstützt. Entwickelt und gesteuert wird das Projekt durch die Community, zu deren Unterstützung die gemeinnützige AlmaLinux OS Foundation gegründet wurde.

Neben der jährlichen Zuwendung von CloudLinux finanziert sich das Projekt durch diverse Sponsoren.

Die Firma CloudLinux Inc. verfügt selbst über mehr als 10 Jahre Erfahrung in der Pflege eines RHEL-Klons sowie den Betrieb der dazu notwendigen Infrastruktur. Nach eigener Aussage möchte CloudLinux Inc. durch die Unterstützung des Projekts den eigenen Bekanntheitsgrad steigern und hofft auf neue Kunden für das kommerzielle CloudLinux OS und KernelCare.

RHEL wird von der Firma Red Hat entwickelt, welches eines der weltweit erfolgreichsten Open Source Unternehmen ist. Haupteinnahmequelle des Unternehmens ist der Vertrieb von Subskriptionen für RHEL und weitere Produkte aus dem Portfolio. Eine Subskription berechtigt zum Bezug von Software-Aktualisierungen und umfasst kommerziellen Support.

Rocky Linux ist ein Community-Projekt, welches vom CentOS-Mitbegründer Gregory Kurtzer gegründet wurde. Das Projekt verfolgt die gleichen Ziele wie das ursprüngliche CentOS, welches zugunsten von CentOS Stream aufgegeben wurde.

Ähnlich wie AlmaLinux finanziert sich das Projekt durch verschiedene Sponsoren. Wie die Webseite Linuxnews am 16. Mai 2022 berichtete, konnte sich Rocky Linux eine Finanzierung in Höhe von 26 Mio. USD von Google sichern.

Hilfe, Unterstützung und Dokumentation

Wie oben bereits beschrieben haben alle Distributionen ein Unterstützungszeitraum von 10 Jahren. Das heißt, dass ein Major-Release wie AlmaLinux/RHEL/Rocky Linux 8 für einen Zeitraum von 10 Jahren Aktualisierungen in Form von Bug-/Security-Fixes und ausgewählter Verbesserungen erhält. AlmaLinux und Rocky Linux profitieren hier von der Vorarbeit, welche Red Hat für RHEL geleistet hat.

Hilfe für individuelle Probleme, Sorgen, Nöte und Anträge erhält man bei AlmaLinux und Rocky Linux in Foren, Chats und auf Mailinglisten. Darüber hinaus kann man kommerziellen Support für AlmaLinux bei TuxCare einkaufen. Rocky Linux listet CIQ und OpenLogic by Perforce als Support-Anbieter. Red Hat unterhält mit der Red Hat Customer Portal Community ebenfalls einen Bereich mit Disussions-Forum. Darüber hinaus bietet Red Hat im Rahmen seiner Subskriptionen Support direkt vom Hersteller.

Für alle drei Distributionen gibt es also sowohl freie/kostenlose Support-Angebote, als auch kommerzielle Support-Verträge, entweder direkt vom Hersteller oder durch Drittanbieter.

Ob man kommerziellen Support benötigt oder der Community-Support ausreicht, hängt von verschiedenen Faktoren wie z.B. den eigenen Fähigkeiten und nicht zuletzt von der eigenen Risikofreudigkeit ab. Ich persönlich habe die Erfahrung gemacht, dass in Enterprise- bzw. Provider-Umgebungen Probleme auftreten können, die im Hobbykeller, im Verein oder im SoHo ausbleiben und völlig unbekannt sind. In diesen Fällen darf man sich nicht wundern, wenn sich in den Community-Foren niemand findet, der helfen kann. Hier kann ein kommerzieller Support vorteilhaft sein, der auf diese Umgebungen ausgerichtet ist und über mehr Erfahrung in diesem Bereich verfügt.

Ich persönlich bin mit dem Red Hat Support für RHEL zufrieden. Er hat mir schon einige Male bei Problemen und Fragestellungen geholfen, wo ich im Forum vermutlich ohne Antwort geblieben wäre. Die Support-Qualität bei AlmaLinux und Rocky Linux kann ich mangels Erfahrung nicht beurteilen.

Softwareunterstützung

Alle drei betrachteten Distributionen sind zueinander binärkompatibel. Das bedeutet, dass Anwendungen, die unter RHEL ausgeführt werden können, in aller Regel auch unter AlmaLinux und Rocky Linux ausgeführt werden können und umgekehrt.

Software-Hersteller führen in ihren Systemvoraussetzungen häufig unterstützte Betriebssysteme auf. Hier finden sich manchmal nur die kommerziellen Enterprise-Betriebssysteme wie RHEL oder SuSE Linux Enterprise Server (SLES). In solch einem Fall kann es passieren, dass der Software-Hersteller den Support ablehnt, wenn man seine Anwendung auf einem RHEL-Klon ausführt statt auf dem Original. Evtl. verlangt der Hersteller auch nur, dass das Problem unter einem offiziell unterstützten Betriebssystem nachgestellt wird. Dieser Punkte sollte bei der Auswahl einer Distribution mit bedacht werden.

Dokumentation

Red Hat bietet für RHEL eine ausführliche Produkt-Dokumentation und eine umfassende Wissensdatenbank. Zwar ist auch hier nicht alles perfekt, doch hat man dies auch schon deutlich schlechter gesehen. Um die Dokumentation kontinuierlich zu verbessern, bietet Red Hat allen Kunden und Nutzern die Möglichkeit, Dokumentations-Feedback direkt in der Dokumentation zu geben. Aus eigener Erfahrung kann ich berichten, dass gefundene Fehler meist innerhalb weniger Tage behoben werden.

Bei AlmaLinux habe in hinsichtlich Dokumentation auf den ersten Blick nur ein Wiki gefunden, welches auf mich hinsichtlich Gliederung und Umfang einen enttäuschenden Eindruck macht.

Rocky Linux hat ebenfalls ein Wiki und einen gesonderten Bereich für Dokumentation. Auch hier lässt mich die Gliederung etwas verstört und hilflos zurück. Zwar finden sich auf den ersten Blick mehr Anleitungen als bei AlmaLinux, an die RHEL-Dokumentation reicht sie jedoch keinesfalls heran.

Die schwache bis mangelhafte Dokumentation bei AlmaLinux bzw. Rocky Linux mag nicht so sehr ins Gewicht fallen, da man in vielen Fällen einfach die RHEL-Doku zurate ziehen kann. Auch hier profitieren die beiden Projekte wieder von der Vorarbeit des Originals.

Release-Zyklen

Seit RHEL 8 hat sich Red Hat feste Release-Zyklen auferlegt, welche alle 6 Monate ein Minor- bzw. Point-Release und alle 3 Jahre ein Major-Release vorsehen. Da AlmaLinux und Rocky Linux als Downstream-Projekte aus den RHEL-Quelltexten gebaut werden, erscheinen deren Releases stets nach der Veröffentlichung eines RHEL-Release. Die folgende Tabelle gibt einen kleinen Überblick, wann welche Distribution ein Minor-Release veröffentlicht hat.

Release	AlmaLinux	RHEL	Rocky Linux
8.4	2021-05-26	2021-05-18	2021-06-21
8.5	2021-11-12	2021-11-09	2021-11-15
8.6	2022-05-12	2022-05-10	2022-05-16
8.7	2022-11-10	2022-11-09	2022-11-14
9 beta	2022-04-19	2021-11-03	N/A
9.0 GA	2022-05-26	2022-05-18	2022-07-14
9.1	2022-11-17	2022-11-16	2022-11-26

Zeitpunkt der Veröffentlichungen

Bisher folgen die Releases von AlmaLinux und Rocky Linux in der Regel wenige Tage auf das RHEL-Release. Beim Major-Release 9 hing RockyLinux ca. 1,5 Monate hinterher.

Bereitstellung von Sicherheits-Updates

Alle drei Projekte stellen Produkt-Errata im Internet bereit:

AlmaLinux Product Errata – https://errata.almalinux.org/
Red Hat Product Errata – https://access.redhat.com/errata
Rocky Linux Product Errata – https://errata.rockylinux.org/

Dabei werden Errata in Bugfix-, Enhancement- und Security-Advisory unterschieden.

Während Bugs und fehlende Funktionalität störend und ärgerlich sein können, stellt die schnelle Verfügbarkeit von Sicherheits-Updates einen kritischen Faktor dar, um Sicherheitslücken zeitnah schließen zu können. Nach Aussage von AlmaLinux werden Errata bei AlmaLinux und Rocky Linux mit einem Geschäftstag Verzögerung in Bezug auf das RHEL-Errata-Release veröffentlicht. Ob beide Projekte dies durchhalten können, werde ich in der Zukunft stichprobenartig kontrollieren.

Mein Open-Source-Projekt Ansible: Patch-Management für Red Hat Systeme nutzt die Red Hat Security Advisories, um sogenannte Patch-Sets zu definieren, welche zu bestimmten Stichtagen installiert werden. Es ist darauf angewiesen, dass Errata-Informationen als Meta-Informationen in den Paket-Repositorien verfügbar sind. Bei CentOS fehlten diese, sodass mein Patch-Management für CentOS nicht nutzbar ist.

Daher bin ich sehr erfreut, dass AlmaLinux und Rocky Linux diese Meta-Informationen ebenfalls in ihren Repositorien bereitstellen. Prinzipiell sollte mein Patch-Management auch mit diesen beiden Distributionen funktionieren. Ein Test steht jedoch noch aus.

Zusammenfassung

Mit AlmaLinux und Rocky Linux gibt es zwei von einer Gemeinschaft entwickelte binärkompatible RHEL-Klone, welche von unterschiedlichen Unternehmen unterstützt und gesponsort werden. Erste Unternehmen bieten kommerziellen Support für diese Distributionen an.

Mir fällt positiv auf, dass beide Projekte in ihren Repos Errata-Informationen wie z.B. ALSA oder RLSA bereitstellen. Dies erleichtert die gezielte Installation von sicherheitsrelevanten Aktualisierungen. Hier bieten beide Projekte mehr, als es CentOS in der Vergangenheit tat.

Die Dokumentation scheint bei beiden Projekten keine große Rolle zu spielen. Ich empfinde sie als unübersichtlich und lückenhaft. Hier kann man jedoch vermutlich auf die Dokumentation des Originals (RHEL) zurückgreifen, welche sich mit sehr geringer Transferleistung auch für AlmaLinux und Rocky Linux nutzen lässt.

Auf den ersten Blick scheint es sich sowohl bei AlmaLinux als auch bei Rocky Linux um zwei solide Distributionen für alle jene zu handeln, die sich RHEL nicht leisten können oder wollen.

Updates auf ein spezifisches RHEL-Minor-Release beschränken

Schreibe eine Antwort

Wenn man einen Anwendungs-Dienst betreibt, welcher nur für ein bestimmtes Release von Red Hat Enterprise Linux wie bspw. RHEL 8.4 freigegeben ist, gilt es effektiv zu verhindern, dass bei Updates Pakete installiert werden, die zu einem folgenden Release wie z.B. RHEL 8.5 gehören. Andernfalls verliert man bestenfalls die Unterstützung vonseiten des Herstellers der Anwendung. Im schlimmsten Fall ist die Anwendung nicht mehr lauffähig und man muss das Upade zurückrollen.

Hinweis von Steffen Frömer (Senior Technical Account Manager bei Red Hat): Um Updates für ein spezifisches Minorrelease zu bekommen, auch wenn wie im Beispiel RHEL 8.5 bereits verfügbar ist, müssen Repositories mit verlängertem Support (z.B. Extended Update Support, EUS) verwendet werden. Andernfalls bekommt man keine Paketupdates.

Weiterführende Informationen zum Thema Extended Update Support bietet der Link unter [3].

Der folgende Code-Block zeigt, wie man Updates für ein RHEL-8-System auf das Release 8.4 beschränkt:

# subscription-manager release --set=8.4
# rm -rf /var/cache/dnf

Das Kommando in der letzten Zeile, geht auf den Wissensartikel [1] zurück, welcher darauf hinweist, dass nur so der Paket-Cache sicher geleert wird. Dies ist notwendig, da der Paketmanager andernfalls fälschlicherweise Paketversionen eines höheren Release aus dem lokalen Cache installieren könnte, was zu Abhängigkeitsproblemen führt.

Mit folgendem Befehl lässt sich die Beschränkung wieder entfernen:

# subscription-manager release --unset
   Release preference has been unset

Das war auch schon alles.

Quellen und weiterführende Links

How to tie a system to a specific update of Red Hat Enterprise Linux? — https://access.redhat.com/solutions/238533 (Login erforderlich)
How to limit updates a [sic] specific version of Red Hat Enterprise Linux? — https://access.redhat.com/solutions/2761031 (Login erforderlich)
Red Hat Enterprise Linux (RHEL) Extended Update Support (EUS) Overview — https://access.redhat.com/articles/rhel-eus (Login erforderlich)

In-Place-Upgrade für Red Hat Enterprise Linux (RHEL)

Schreibe eine Antwort

In diesem Beitrag beschreibe ich exemplarisch, wie ein In-Place-Upgrade von RHEL 7 auf RHEL 8 durchgeführt werden kann. Dabei beschreibe ich zuerst, was ein In-Place-Upgrade ist und in welchen Fällen es sinnvoll sein kann, bevor ich im Hauptteil anhand einer Test-VM die Durchführung demonstriere.

Was ist ein In-Place-Upgrade?

Als In-Place-Upgrade wird der Vorgang bezeichnet, bei dem ein Betriebssystem auf ein neues Major-Release aktualisiert wird, ohne das System dabei neuinstallieren zu müssen. Statt dessen werden alle zum Betriebssystem gehörenden Dateien gegen die entsprechende Version des neuen Release ausgetauscht.

Nutzer von Debian und Ubuntu kennen dieses Verfahren unter dem Begriff Distributions-Upgrade.

In-Place-Upgrade vs. Neuinstallation

Grundsätzlich bevorzuge ich die Neuinstallation eines Systems. Da man sich üblicherweise mit Backups und Deployment-Skripten darauf vorbereitet hat, einen Dienst bzw. eine Anwendung nach einem Verlust des laufenden Systems wiederherstellen zu können, kann man sich dies auch zu Nutze machen und den Dienst bzw. die Anwendung auf einem frisch installierten System wiederherzustellen. Auf diese Weise werden keine Altlasten über mehrere Betriebssystemversionen mitgeschleppt.

Gleichzeitig kann man die Downtime verkürzen, indem das neue System parallel zum alten aufgebaut wird und man nach dem Abschluss aller Arbeiten und Tests umschaltet. Das Altsystem kann im Nachgang in Ruhe abgebaut werden.

Es gibt jedoch auch Gründe, die für ein In-Place-Upgrade sprechen. Verfügt man nur über einen einzigen Host und kann kein Parallelsystem aufbauen, kann ein In-Place-Upgrade die Lösung sein.

Evtl. verfügt man selbst zwar über ausreichend Berechtigungen, um das vorhandene System zu aktualisieren, für die Provisionierung neuer Systeme ist man jedoch auf die Unterstützung weiterer Stellen angewiesen. Die Abhängigkeitskette lässt sich hier zum Teil deutlich reduzieren.

Dabei muss stets bedacht werden, dass bei einem In-Place-Upgrade auch ein katastrophaler Fehler eintreten kann, welcher zum Verlust des Systems führt. Es ist daher dringend angeraten, eine Datensicherung zu haben, aus welcher das System wiederhergestellt werden kann. Besitzt man ein Backup, auf das man sich verlassen kann, kann es auch schon losgehen.

Das Upgrade von RHEL 7 auf RHEL 8

Laut Kapitel 1 der unter [0] verlinkten Dokumentation stellt das In-Place-Upgrade den von Red Hat unterstützten und empfohlenen Weg dar, um auf das nächste Major-Release zu aktualisieren. Dabei kann man stets nur von der letzten Verfügbaren RHEL 7 Version auf das jeweils letzte gerade RHEL 8 Release (z.B. 8.4) aktualisieren. Details hierzu können im Artikel unter [1] nachgelesen werden.

Die folgenden Abschnitte können die Dokumentation unter [0] nicht ersetzen. Sie sollen lediglich einen kompakten Überblick über den Prozess geben.

Limitierungen

Zum Zeitpunkt der Artikelerstellung , kann das In-Place-Upgrade nicht auf Systemen mit verschlüsselten Dateisystemen durchgeführt werden.

Netzwerkspeicher, wie z.B. iSCSI oder NAS, werden nicht unterstützt und müssen während des Upgrades ausgehängt werden. Die dazugehörigen Dienste, wie z.B. autofs müssen vorübergehend deaktiviert werden.

Weitere bekannte Probleme sind Kapitel 8 in [0] zu entnehmen.

Vorbereitung

Bevor man mit dem Upgrade beginnen kann, sind folgende Voraussetzungen zu schaffen:

Das System erfüllt die minimalen Systemvoraussetzungen für RHEL 8 (siehe [2]).
Zugriff auf Repos mit aktuellen Paketen für RHEL 7.9 und RHEL 8.4.
Korrekte Registrierung des Systems am Red Hat Content Delivery Network (CDN) oder den Red Hat Satellite Server mittels Red Hat Subscription Manager (RHSM).

Wichtig: Ich empfehle ausdrücklich, vor Beginn der Arbeiten ein aktuelles Backup bzw. einen Snapshot zu erstellen, um auf den Ausgangszustand vor der Upgrade-Prozedur zurückkehren zu können.

Kapitel 2 in [0] bietet eine ausführliche Schritt-für-Schritt-Anleitung zur Vorbereitung des Upgrades. Der folgende Codeblock bietet eine kompakte Übersicht der einzelnen Schritte. Als Zielsystem dient eine aktuelle RHEL 7.9 Minimal-Installation.

[tronde@rhel7-t1 ~]$ # Überprüfung, ob eine RHEL-Subskription abonniert wurde
[tronde@rhel7-t1 ~]$ sudo subscription-manager list --installed
[sudo] password for tronde: 
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+
Product Name:   Red Hat Enterprise Linux Server
Product ID:     69
Version:        7.9
Arch:           x86_64
Status:         Subscribed
Status Details: 
Starts:         06.10.2020
Ends:           06.10.2021

[tronde@rhel7-t1 ~]$ # Aktivierung des RHEL 7 Basis- und Extras-Repo
[tronde@rhel7-t1 ~]$ sudo subscription-manager repos --enable rhel-7-server-rpms
Repository 'rhel-7-server-rpms' is enabled for this system.
[tronde@rhel7-t1 ~]$ sudo subscription-manager repos --enable rhel-7-server-extras-rpms
Repository 'rhel-7-server-extras-rpms' is enabled for this system.

[tronde@rhel7-t1 ~]$ # Ist locale auf en_US.UTF-8 gesetzt?
[tronde@rhel7-t1 ~]$ cat /etc/locale.conf
LANG="en_US.UTF-8"

[tronde@rhel7-t1 ~]$ sudo yum install leapp leapp-repository
# Ausgabe gekürtzt
Transaction Summary
================================================================================
Install  2 Packages (+24 Dependent packages)

Total download size: 5.3 M
Installed size: 19 M
Is this ok [y/d/N]: y
# Ausgabe gekürtzt

Pre-Upgrade-Bericht erstellen

Bevor das eigentliche Upgrade durchgeführt wird, führe ich auf meinem Testsystem das Kommando leapp preupgrade aus. Dieses sammelt Informationen über das System, um die Upgradefähigkeit zu bewerten und erstellt einen detaillierten Bericht, welcher im Pfad /var/log/leapp/leapp-report.txt abgelegt wird.

[tronde@rhel7-t1 ~]$ sudo leapp preupgrade
# Ausgabe gekürzt
============================================================
                           ERRORS                           
============================================================

2021-08-31 06:33:26.035495 [ERROR] Actor: repository_mapping
Message: Data file /etc/leapp/files/repomap.csv is invalid or could not be retrieved.
Summary:
    Details: Could not fetch repomap.csv from https://cert.cloud.redhat.com/api/pes/repomap.csv (unreachable address).
    Hint: Read documentation at: https://access.redhat.com/articles/3664871 for more information about how to retrieve the file.
2021-08-31 06:35:22.415297 [ERROR] Actor: restricted_pcis_scanner
Message: Data file /etc/leapp/files/unsupported_driver_names.json is invalid or could not be retrieved.
Summary:
    Details: Could not fetch unsupported_driver_names.json from https://cert.cloud.redhat.com/api/pes/unsupported_driver_names.json (unreachable address).
    Hint: Read documentation at: https://access.redhat.com/articles/3664871 for more information about how to retrieve the file.
2021-08-31 06:35:47.800140 [ERROR] Actor: pes_events_scanner
Message: Data file /etc/leapp/files/pes-events.json is invalid or could not be retrieved.
Summary:
    Details: Could not fetch pes-events.json from https://cert.cloud.redhat.com/api/pes/pes-events.json (unreachable address).
    Hint: Read documentation at: https://access.redhat.com/articles/3664871 for more information about how to retrieve the file.

============================================================
                       END OF ERRORS                        
============================================================


Debug output written to /var/log/leapp/leapp-preupgrade.log

============================================================
                           REPORT                           
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT                        
============================================================

Answerfile has been generated at /var/log/leapp/answerfile
[tronde@rhel7-t1 ~]$

Dem obigen Codeblock ist zu entnehmen, dass der Pre-Upgrade-Check Fehler festgestellt hat, die behoben werden müssen, bevor ein In-Place-Upgrade durchgeführt werden kann. Dankenswerter Weise ist sowohl in der Ausgabe auf STDOUT als auch in /var/log/leapp/leapp-report.txt der Knowledge-Base-Artikel [3] verlinkt, welcher die Lösung parat hält.

Ist dieser Fehler behoben, lässt man leapp preupgrade ein weiteres Mal laufen und prüft die Ausgabe erneut. Auf meinem Testsystem erhalte ich nun folgende Ausgabe:

[root@rhel7-t1 ~]# leapp preupgrade
# Ausgabe gekürzt
============================================================
                     UPGRADE INHIBITED                      
============================================================

Upgrade has been inhibited due to the following problems:
    1. Inhibitor: Missing required answers in the answer file
Consult the pre-upgrade report for details and possible remediation.

============================================================
                     UPGRADE INHIBITED                      
============================================================


Debug output written to /var/log/leapp/leapp-preupgrade.log

============================================================
                           REPORT                           
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT                        
============================================================

Answerfile has been generated at /var/log/leapp/answerfile

Diesmal weist die Ausgabe darauf hin, dass ein Upgrade durch fehlende Antworten in /var/log/leapp/answerfile verhindert wird. Die genannte Datei kann mit einem Editor geöffnet und entsprechend bearbeitet werden:

[remove_pam_pkcs11_module_check]
# Title:              None
# Reason:             Confirmation
# =================== remove_pam_pkcs11_module_check.confirm ==================
# Label:              Disable pam_pkcs11 module in PAM configuration? If no, the upgrade process will be interrupted.
# Description:        PAM module pam_pkcs11 is no longer available in RHEL-8 since it was replaced by SSSD.
# Type:               bool
# Default:            None
# Available choices: True/False
# Unanswered question. Uncomment the following line with your answer
confirm = True

Die Datei enthält direkt eine Erklärung, warum das erwähnte Modul zu entfernen ist und wie dies zu geschehen hat.

Anschließend empfiehlt sich ein Blick in den Bericht unter /var/log/leapp/leapp-report.txt, um zu prüfen, ob einem Upgrade evtl. weitere Gründe entgegen stehen. Auf die Ausgabe des Berichts in diesem Artikel wird aus Platzgründen verzichtet. Da der Inhalt auf jedem System unterschiedlich ausfallen kann, ist sein Nutzen an dieser Stelle ohnehin stark begrenzt.

Durchführung des In-Place-Upgrade

An dieser Stelle wird es ernst. Man sollte sich noch einmal vergewissern, dass man einen Snapshot bzw. ein geeignetes Backup des Systems hat. Dann wird das Upgrade mit folgendem Befehl gestartet:

# leapp upgrade
# Ausgabe gekürzt
============================================================
                           REPORT                           
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT                        
============================================================

Answerfile has been generated at /var/log/leapp/answerfile

Dieser Vorgang kann mehrere Minuten dauern. Leapp lädt notwendige Daten herunter und bereitet die RPM-Transaktionen für das Upgrade vor. Dabei wird erneut geprüft, ob Gründe vorliegen, die ein Upgrade verhindern können. Sollte dies der Fall sein, bricht leapp den Vorgang ab und erzeugt einen neuen Bericht.

Ist das Upgrade erfolgreich durchgelaufen, muss das System manuell neugestartet werden. Das System startet anschließend in eine RAM-Disk und aktualisiert alle Pakete des Systems. Anschließend wird automatisch ein Neustart ausgeführt. Dieser Vorgang lässt sich am besten an einer (virtuellen) Konsole beobachten.

Nachdem das Upgrade abgeschlossen ist, kann man sich wieder am System anmelden und mit folgenden Kommandos prüfen, ob das System den gewünschten Status hat (vgl. Kapitel 5 in [0]):

[root@rhel7-t1 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux release 8.4 (Ootpa)

[root@rhel7-t1 ~]# uname -r
4.18.0-305.12.1.el8_4.x86_64

[root@rhel7-t1 ~]# subscription-manager list --installed
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+
Product Name:   Red Hat Enterprise Linux for x86_64
Product ID:     479
Version:        8.4
Arch:           x86_64
Status:         Subscribed
Status Details: 
Starts:         06.10.2020
Ends:           06.10.2021

[root@rhel7-t1 ~]# subscription-manager release
Release: 8.4

Hier sieht alles gut aus.

Post-Upgrade-Tasks

Kapitel 6 in [0] beschreibt detailliert, welche Aufgaben nach einem erfolgreichen In-Place-Upgrade noch auszuführen sind, um ein möglichst sauberes System zu erhalten.

Auf meinem Testsystem sind einige RHEL 7 Pakete zurückgeblieben, welche ich mit folgendem Kommando entferne:

# dnf remove `rpm -qa | grep -e '\.el[67]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort`
Updating Subscription Management repositories.
Dependencies resolved.
===============================================================================
 Package              Arch       Version                     Repository   Size
===============================================================================
Removing:
 doxygen              x86_64     1:1.8.5-4.el7               @System      15 M
 kernel               x86_64     3.10.0-1160.31.1.el7        @System      64 M
 kernel               x86_64     3.10.0-1160.36.2.el7        @System      64 M
 leapp                noarch     0.12.1-1.el7_9              @System      93 k
 leapp-repository     noarch     0.14.0-4.el7_9              @System     1.7 M
 python2-leapp        noarch     0.12.1-1.el7_9              @System     618 k
 ustr                 x86_64     1.0.4-16.el7                @System     279 k

Transaction Summary
===============================================================================
Remove  7 Packages

Freed space: 146 M
Is this ok [y/N]:

# cd /lib/modules && ls -d *.el7*
3.10.0-1160.25.1.el7.x86_64  3.10.0-1160.36.2.el7.x86_64
3.10.0-1160.31.1.el7.x86_64

# /bin/kernel-install remove 3.10.0-1160.36.2.el7.x86_64 /lib/modules/3.10.0-1160.36.2.el7.x86_64/vmlinuz
# /bin/kernel-install remove 3.10.0-1160.25.1.el7.x86_64 /lib/modules/3.10.0-1160.25.1.el7.x86_64/vmlinuz
# /bin/kernel-install remove 3.10.0-1160.31.1.el7.x86_64 /lib/modules/3.10.0-1160.31.1.el7.x86_64/vmlinuz

Damit ist es geschafft. Das System wurde erfolgreich auf RHEL 8 aktualisiert.

Fazit

Dieser Artikel stellt das RHEL-In-Place-Upgrade vor und nennt kurz einige Gründe, wann dies gegenüber einer Neuinstallation Vorteile bietet. Anschließend wurde das Upgrade an einem Testsystem demonstriert mit dem Ziel, einen Überblick über den Upgrade-Prozess zu geben.

Für In-Place-Upgrades von Produktionssystemen ist ein Blick in die Hersteller-Dokumentation, Backups und sorgfältige Planung unerlässlich.

Das für diesen Artikel verwendete Testsystem besteht lediglich aus einer Minimal-Installation ohne Anwendungen von Dritten. Ob ein In-Place-Upgrade auch mit installierten Anwendungen Dritter funktioniert, hängt vom Einzelfall ab und ist sorgfältig zu prüfen und zu testen.

Erste Versuche mit Web- und Anwendungsservern aus unserer Umgebung konnten mit positivem Ergebnis abgeschlossen worden.

Es gibt Anwendungsfälle, wo ein In-Place-Upgrade vorteilhaft ist. Ich persönlich bevorzuge, wenn möglich und vom Aufwand vertretbar, jedoch die Neuinstallation inkl. Migration der Daten auf einem neuen System. So kann sichergestellt werden, dass keine unentdeckten Altlasten mitgeschleppt werden.

[0] Upgrading from RHEL 7 to RHEL 8. Instructions for an in-place upgrade from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. Red Hat Enterprise Linux 8. Red Hat Customer Content Services.

[1] Supported in-place upgrade paths for Red Hat Enterprise Linux (Login required)

[2] Red Hat Enterprise Linux technology capabilities and limits

[3] Data required by the Leapp utility for an in-place upgrade from RHEL 7 to RHEL 8 (Login required)

CVE — Ist mein RHEL-System betroffen? Was kann ich tun?

Schreibe eine Antwort

Regelmäßig berichtet die IT-Fachpresse über neue Common Vulnerabilities and Exposures (CVE). Dieser Artikel möchte euch eine kleine Hilfestellung geben, um herauszufinden, ob euer RHEL-System von einem CVE betroffen ist.

In unserem Rechenzentrum betreibe ich ein Patchmanagement mit Ansible für unsere RHEL-Systeme. Dieses stellt sicher, dass einmal im Monat verfügbare Red Hat Security Advisories (RHSA) auf allen RHEL-Systemen installiert werden. Damit gewährleisten wir ein Mindestmaß an Sicherheit. Selbstverständlich können darüber hinaus alle System-Betreiber*innen zu jeder Zeit verfügbare Updates auf den von ihnen betreuten Servern installieren.

Wie eingangs erwähnt berichtet in der Regel die IT-Fachpresse über neue Sicherheitslücken und Schwachstellen. Diese Meldungen enthalten häufig auch die sogenannten CVE-Nummern, welche eine Schwachstelle/Sicherheitslücke eindeutig identifizieren. Mit Hilfe dieser Nummer könnt ihr feststellen, ob euer RHEL-System verwundbar ist und ob ggf. schon ein Patch existiert, welcher das Problem behebt.

Für diesen Text habe ich exemplarisch zwei Schwachstellen ausgewählt:

Nutzung der Red Hat CVE-Datenbank

Red Hat betreibt eine CVE-Datenbank unter der URL: https://access.redhat.com/security/security-updates/#/cve

Hier kann man nach einer CVE-Nummer suchen und zu weiterführenden Informationen zu einer Schwachstelle gelangen (siehe Abb. 1). Hinter dem Link in der Tabelle verbirgt sich eine Detail-Seite für den jeweiligen CVE.

Abb. 1: Screenshot der Red Hat CVE-Datenbank für CVE-2020-0543

Liefert eine Suche keine Treffer zurück, kann dies verschiedene Ursachen haben (siehe Abb. 2).

Abb. 2: Red Hat CVE-Datenbank liefert nicht zu jeder CVE-Nummer einen Treffer

Nutzung des Paket-Managers auf der Kommandozeile

Mit Hilfe des Paket-Managers YUM kann für jedes System individuell geprüft werden, ob für einen CVE ein entsprechender Fix existiert. Der folgende Codeblock veranschaulicht dies:

$ sudo yum updateinfo list --cve CVE-2020-0543                                
[...]
RHSA-2020:2432 Moderate/Sec. microcode_ctl-2:2.1-61.6.el7_8.x86_64
updateinfo list done
$
$ sudo yum updateinfo list --cve CVE-2020-13777
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
updateinfo list done
$

Die erste Abfrage nach CVE-2020-0543 zeigt, dass es ein Security-Advisory für ein installiertes Paket gibt, welches von der Schwachstelle betroffen ist. Gegen CVE-2020-13777 ist das System hingegen nicht verwundbar. Dies ist in diesem Fall der Tatsache geschuldet, dass GnuTLS auf dem genutzten System nicht installiert ist.

Mit Hilfe des folgenden Befehls lassen sich auch auf der Kommandozeile weitere Informationen zu einem CVE abrufen:

$ sudo yum updateinfo info --cve CVE-2020-0543 
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager

===============================================================================
  Moderate: microcode_ctl security, bug fix and enhancement update
===============================================================================
  Update ID : RHSA-2020:2432
    Release : 0
       Type : security
     Status : final
     Issued : 2020-06-09 18:20:28 UTC
       Bugs : 1788786 - CVE-2020-0548 hw: Vector Register Data Sampling
	    : 1788788 - CVE-2020-0549 hw: L1D Cache Eviction Sampling
	    : 1827165 - CVE-2020-0543 hw: Special Register Buffer Data Sampling (SRBDS)
       CVEs : CVE-2020-0543
	    : CVE-2020-0548
	    : CVE-2020-0549
Description : Security Fix(es):
            : 
            : * hw: Special Register Buffer Data Sampling
            :   (SRBDS) (CVE-2020-0543)
            : 
            : * hw: L1D Cache Eviction Sampling (CVE-2020-0549)
            : 
            : * hw: Vector Register Data Sampling
            :   (CVE-2020-0548)
            : 
            : For more details about the security issue(s),
            : including the impact, a CVSS score,
            : acknowledgments, and other related information,
            : refer to the CVE page(s) listed in the References
            : section.
            : 
            : Bug Fix(es):
            : 
            : * Update Intel CPU microcode to microcode-20200602
            :   release, addresses:
            :   - Update of 06-2d-06/0x6d (SNB-E/EN/EP C1/M0)
            :     microcode from revision 0x61f up to 0x621;
[...]

CVE durch Update schließen

Ich persönlich empfehle in der Regel, das gesamte System mittels sudo yum -y upgrade zu aktualisieren und so alle installierten Pakete auf den aktuellsten Stand zu bringen. Es ist jedoch auch möglich, nur die Updates zu installieren, die notwendig sind, um eine spezielle Schwachstelle zu schließen. Auch hierfür wird wieder die CVE-Nummer genutzt:

$ sudo yum upgrade --cve CVE-2020-0543
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
 --> mock-2.2-1.el7.noarch from @epel removed (updateinfo)
 --> unbound-libs-1.6.6-3.el7.x86_64 from @rhel-7-server-rpms removed (updateinfo)
 --> mock-2.3-1.el7.noarch from epel removed (updateinfo)
 --> unbound-libs-1.6.6-4.el7_8.x86_64 from rhel-7-server-rpms removed (updateinfo)
1 package(s) needed (+0 related) for security, out of 3 available
Resolving Dependencies
--> Running transaction check
---> Package microcode_ctl.x86_64 2:2.1-61.el7 will be updated
---> Package microcode_ctl.x86_64 2:2.1-61.6.el7_8 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================================================================
 Package                              Arch                          Version                                   Repository                                 Size
==============================================================================================================================================================
Updating:
 microcode_ctl                        x86_64                        2:2.1-61.6.el7_8                          rhel-7-server-rpms                        2.6 M

Transaction Summary
==============================================================================================================================================================
Upgrade  1 Package

Total size: 2.6 M
Is this ok [y/d/N]:

Obigem Code-Block ist zu entnehmen, dass Updates für insgesamt drei Pakete zur Verfügung stehen. Um CVE-2020-0543 zu schließen, wird jedoch nur das Paket microcode_ctl aktualisiert. Die beiden anderen Pakete werden nicht verändert.

Weitere Informationsquellen zu diesem Thema

RHEL 7: Wie stelle ich sicher, dass nur Pakete aus unterstützten Quellen installiert sind?

Schreibe eine Antwort

In diesem Artikel dokumentiere ich (vor allem für mich selbst), wie man ein System in einen Zustand versetzen kann, in dem ausschließlich RPM-Pakete aus Repositories (Repos) installiert sind, für die man kommerziellen Support erhält.

Dazu gehe ich kurz auf den Hintergrund der Aufgabenstellung ein, bevor ich anschließend eine mögliche Lösung beschreibe.

Die Hintergrundgeschichte

Für meine ersten Gehversuche mit Red Hat Enterprise Linux habe ich mich unter der URL „https://developers.redhat.com/“ für eine Developer Subscription registriert. Diese gestattet die unbeschränkte Nutzung zu Forschungs- und Entwicklungszwecken.

Mit der Developer Subscription erhält man Zugriff auf eine ganze Reihe von Repos, aus denen man Software installieren kann. Etliche Pakete wie z.B. sed, less, etc. sind dabei in mehreren Quellen verfügbar.

Nach einer gewissen Evaluierungszeit sollte das System produktiv genutzt werden. Da eine produktive Nutzung in der Developer Subscription ausgeschlossen ist, wurde eine RHEL Standard Subscription für das System beschafft. Diese wurde dem System über den „Subscription Manager“ hinzugefügt. Die Developer Subscription wurde im Gegenzug entfernt.

Um zu überprüfen, ob auf dem System Pakete aus anderen Repos als „rhel-7-server-rpms“ installiert waren, wurde folgendes Kommando genutzt:
# yum list installed | grep -v "rhel-7-server-rpms\|anaconda" Loaded plugins: product-id, search-disabled-repos, subscription-manager Installed Packages NetworkManager-config-server.x86_64 Red_Hat_Enterprise_Linux-Release_Notes-7-en-US.noarch libdnet.x86_64 1.12-13.1.el7 @rhel-7-server-eus-rpms libicu.x86_64 50.1.2-15.el7 @rhel-7-server-eus-rpms libmspack.x86_64 0.5-0.4.alpha.el7 @rhel-7-server-eus-rpms net-tools.x86_64 2.0-0.17.20131004git.el7 @rhel-7-server-eus-rpms sed.x86_64 4.2.2-5.el7.sjis.1 @rhel-sjis-for-rhel-7-server-eus-rpms

# yum repolist enabled Loaded plugins: product-id, search-disabled-repos, subscription-manager repo id repo name status rhel-7-server-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server (RPMs) 14,280 repolist: 14,280

Der Ausgabe ist zu entnehmen, dass fünf Pakete aus Quellen stammen, die auf dem System nicht mehr verfügbar sind. Diesen Zustand galt es zu ändern.

Die Lösung

Für die ersten vier Pakete bestand die Lösung darin, diese einfach neuzuinstallieren:
yum reinstall libdnet libicu libmspack net-tools

Bei sed stellte sich dieser Ansatz als problematisch heraus, da der Versuch das Paket neuzuinstallieren mit folgender Meldung quittiert wurde:
# yum reinstall sed Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager rhel-7-server-optional-rpms | 3.5 kB 00:00:00 rhel-7-server-rpms | 3.5 kB 00:00:00 rhel-server-rhscl-7-rpms | 3.5 kB 00:00:00 Installed package sed-4.2.2-5.el7.sjis.1.x86_64 (from rhel-sjis-for-rhel-7-server-eus-rpms) not available. Error: Nothing to do

Der zweite Ansatz, das Paket erst zu entfernen und dann erneut zu installieren, scheiterte an der Überprüfung der Paket-Abhängigkeiten (Auszug der Ausgabe):
# yum remove sed [...] --> Finished Dependency Resolution Error: Trying to remove "systemd", which is protected Error: Trying to remove "yum", which is protected

Die Lösung gelang mit dem dritten Versuch. Hierbei wurde ein Downgrade auf die Paket-Version aus dem Repo „rhel-7-server-rpms“ durchgeführt:
# yum downgrade sed-4.2.2-5.el7.x86_64 Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager Resolving Dependencies --> Running transaction check ---> Package sed.x86_64 0:4.2.2-5.el7 will be a downgrade ---> Package sed.x86_64 0:4.2.2-5.el7.sjis.1 will be erased --> Finished Dependency Resolution


Dependencies Resolved
===============================================================================================================================================================

Package Arch Version Repository Size

===============================================================================================================================================================

Downgrading:

sed x86_64 4.2.2-5.el7 rhel-7-server-rpms 231 k
Transaction Summary

===============================================================================================================================================================

Downgrade 1 Package
Total download size: 231 k

Is this ok [y/d/N]: y

Downloading packages:

sed-4.2.2-5.el7.x86_64.rpm | 231 kB 00:00:00

Running transaction check

Running transaction test

Transaction test succeeded

Running transaction

Installing : sed-4.2.2-5.el7.x86_64 1/2

Cleanup : sed-4.2.2-5.el7.sjis.1.x86_64 2/2

Verifying : sed-4.2.2-5.el7.x86_64 1/2

Verifying : sed-4.2.2-5.el7.sjis.1.x86_64 2/2
Removed:

sed.x86_64 0:4.2.2-5.el7.sjis.1
Installed:

sed.x86_64 0:4.2.2-5.el7

Complete! # yum list installed | grep sed sed.x86_64 4.2.2-5.el7 @rhel-7-server-rpms

Am Ende des Listings ist zu sehen, dass sed nun aus dem Repo „rhel-7-server-rpms“ installiert wurde. Damit stammen nun alle Pakete wieder aus Quellen, die von einer Subscription mit Support abgedeckt.

Bei zukünftigen Installationen mit einer Developer Subscription werde ich jedoch von Anfang an darauf achten, dass nur die Repos verwendet werden, die auch in der RHEL Standard Subscription enthalten sind.

Verweise

Reinstall packages from a specific repository

SELinux Booleans

Schreibe eine Antwort

Bei SELinux Booleans handelt es sich um kleine Schalter, mit denen sich das Verhalten der SELinux-Richtlinien beeinflussen lässt. Dieser Artikel knüpft an die „Einführung in das grundlegende Konzept von SELinux“ an und erläutert die Verwendung von SELinux Booleans anhand eines einfachen Beispiels.

Hinweis: Das Beispiel aus diesem Artikel wurde auf einem RHEL/CentOS 7.3 getestet. Unter CentOS 7.2 funktioniert die hier gezeigte Konfiguration nicht. Für Details wird auf das Topic[2. Solved SELinux Booleans and httpd_enable_homedirs] im CentOS-Support-Forum verwiesen.

Im Einführungsartikel[3. „Einführung in das grundlegende Konzept von SELinux“] wurde SELinux dazu genutzt, um den Zugriff des Apache auf das DocumentRoot-Verzeichnis /var/www/html zu beschränken. Nun möchte der Webmaster den Benutzern gestatten, Webseiten über ihre HOME-Verzeichnisse zu veröffentlichen und aktiviert dazu die Konfiguration für das Modul Userdir.[4. Linux Basics: How To Enable Apache UserDir In CentOS 7/RHEL 7 {en}] [5. Enable Userdir in CentOS 7 {en}] [6. Apache: Benutzerspezifische Verzeichnisse – wiki.ubuntuusers.de]

[root@centos ~]$ cat /etc/httpd/conf.d/userdir.conf

    UserDir enabled
    UserDir public_html



    AllowOverride FileInfo AuthConfig Limit Indexes
    Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
    Require method GET POST OPTIONS


[root@centos ~]#

Nun kann ein Benutzer in seinem HOME-Verzeichnis den Ordner public_html erstellen und eine test.txt-Datei erstellen:

[jkastning@centos ~]$ mkdir public_html
[jkastning@centos ~]$ sudo chmod 711 /home/jkastning/
[jkastning@centos ~]$ sudo chmod 755 public_html/
[jkastning@centos ~]$ vim public_html/test.txt

Hello User

Nach einem Neustart des Dienstes httpd sollte sich nun die Datei index.html aus dem Benutzerverzeichnis abrufen lassen. Statt dessen wird der Zugriff verweigert.

httpd_enable_homdirs –> off

In den Logdateien finden sich Hinweise, die auf SELinux als Ursache hindeuten.

[root@centos ~]# tail /var/log/audit/audit.log|grep AVC
type=AVC msg=audit(1480446615.354:844): avc:  denied  { getattr } for  pid=23150 comm="httpd" path="/home/jkastning/public_html/index.html" dev="sda1" ino=1052157 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=file

[root@centos ~]# tail /var/log/messages | grep SELinux
Nov 29 20:10:44 centos setroubleshoot: SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html. For complete SELinux messages. run sealert -l 13419731-cedd-4433-abb7-b2e7715d5636

Um weitere Informationen zu erhalten, führen wir das Kommando aus /var/log/messages aus (Ausgabe gekürzt):

[root@centos ~]# sealert -l 13419731-cedd-4433-abb7-b2e7715d5636
SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html.

*****  Plugin catchall_boolean (24.7 confidence) suggests   ******************

If you want to allow httpd to enable homedirs
Then you must tell SELinux about this by enabling the 'httpd_enable_homedirs' boolean.
You can read 'None' man page for more details.
Do
setsebool -P httpd_enable_homedirs 1

In der obigen Ausgabe wird neben der Ursache auch gleich die Lösung mitgeliefert. Nach der Aktivierung des SELinux Boolean httpd_enable_homedirs kann der Inhalt der Datei index.html im Webbrowser abgerufen werden.

httpd_enable_homedirs –> on

Damit wurde eine weitere Funktionalität von SELinux kurz vorgestellt. Für weiterführende Informationen sei auf die Manpages booleans(8)[6. booleans(8) – Linux man page {en}], getsebool(8)[7. getsebool(8) – Linux man page {en}] und setsebool(8)[8. setsebool(8) – Linux man page {en}] verwiesen.

Benutzer die Ausführung eines Skripts mit sudo gestatten

2 Antworten

In diesem kurzen Tutorial wird beschrieben, wie man einem normalen Benutzer das Recht einräumt, ein einzelnes Skript mit sudo auszuführen. Das Tutorial ist auf alle Linux-Distributionen anwendbar, welche sudo[1. sudo – Wikipedia] unterstützen.

Schritt 1: Skript und Benutzerkonto erstellen

Zuerst wird natürlich das Skript benötigt, welches der neue Benutzer später ausführen soll. Als Beispiel mag hier folgendes einfaches Beispiel dienen:

#!/bin/bash
echo "Hallo Welt."

Wichtig! Der Benutzer, welcher das Skript später ausführen soll, darf selbst keine Schreibrechte darauf besitzen. Andernfalls könnte er das Skript bearbeiten und durch eintragen von bash eine root-shell öffnen. Danke an Gerald für diesen wichtigen Hinweis.

Der Benutzer kann, sofern er nicht schon existiert, mit folgendem Kommando angelegt werden:

sudo adduser USERNAME

Schritt 2: /etc/sudoers konfigurieren

Um einem Benutzer das Recht zu verleihen, gibt es grundsätzlich mehrere Möglichkeiten.

Benutzer einer Gruppe hinzufügen

Auf vielen Linux-Distributionen existiert bereits eine Gruppe, deren Mitglieder die Berechtigung zur Verwendung von sudo besitzen. Unter Ubuntu ist dies z.B. die Gruppe ’sudo‘. Unter RHEL, CentOS und Fedora ist dies bspw. die Gruppe ‚wheel‘. Um welche Gruppe es sich konkret handelt, kann in der Datei /etc/sudoers nachgeschlagen werden. Dort findet sich auf einem Ubuntu 16.04 LTS z.B. folgender Eintrag:

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

Da dem Benutzer im hier beschriebenen Fall jedoch nur erlaubt werden soll, ein einziges Skript mittels sudo auszuführen, ist diese Methode ungeeignet.

Benutzer in /etc/sudoers

Um einem Benutzer das Recht zu gewähren, ein bestimmtes Skript oder Programm mit sudo auszuführen, kann der Benutzer wie folgt in die Datei /etc/sudoers eingetragen werden.

Wichtig! Die Datei /etc/sudoers sollte nur als root mit dem Kommando visudo editiert werden, da hiermit eine Syntaxprüfung erfolgt. Eine Beschädigung der Datei /etc/sudoers, z.B. durch Syntaxfehler, kann dazu führen, dass das gesamte System unbrauchbar wird.

# User privilege specification
USERNAME    ALL=/path/to/script.sh

Mit obiger Zeile wird dem Benutzer ‚USERNAME‘ erlaubt, das Skript unter /path/to/script.sh mit sudo auszuführen.

Diese Methode ist bereits geeignet, um die gestellte Aufgabe zu lösen.

Datei unter /etc/sudoers.d/ erstellen

Unter aktuellen Versionen von Debian, Ubuntu, RHEL, CentOS und Fedora besteht die Möglichkeit, eine Datei im Verzeichnis /etc/sudoers.d/ zu erstellen, welche den Eintrag aus dem vorangegangenen Abschnitt enthält. Voraussetzung dafür ist, dass die Datei /etc/sudoers folgende Direktive enthält:

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Beachte: Das Zeichen ‚#‘ vor ‚includedir‘ stellt in diesem Fall kein Kommentarzeichen dar.

Diese Methode hat den Vorteil, dass die Datei /etc/sudoers unverändert bleibt und es bei Updates nicht zu einem Versionskonflikt kommen kann.

Fazit

Mittels /etc/sudoers ist es möglich, sudo-Berechtigungen granular an Benutzer zu delegieren. Neben dem in diesem Tutorial beschriebenen Beispiel existieren noch weitere Möglichkeiten. Beispiele dazu finden sich in der Manpage von sudoers.