RHEL Dedicated Server

Ein RHEL-Dedicated-Server ist eine physische Single-Tenant-Maschine, die Red Hat Enterprise Linux direkt auf der Hardware ausführt — ohne Virtualisierungsschicht zwischen Ihrer Workload und CPU, Arbeitsspeicher und NVMe. Sie erhalten vollen Root-Zugriff, jeden Core und die zertifizierte, support-gestützte Plattform, gegen die Enterprise-Software und Compliance-Regime geschrieben sind.

RHEL wird per Abonnement lizenziert statt fest verkauft, daher lautet das Modell auf Bare Metal Bring-your-own: Sie binden Ihr bestehendes Red-Hat-Entitlement an die Maschine. Wenn Sie die RHEL-Plattform ohne Abonnement wollen, sind AlmaLinux und Rocky Linux freie, RHEL-kompatible Rebuilds, die wir kostenlos provisionieren — dieselben Binaries, minus der Vendor-Support-Beziehung.

Sie wägen RHEL gegen die freien Rebuilds ab? Lesen Sie unseren Leitfaden zu Linux-Dedicated-Servern.

Wie sich ein RHEL-Abonnement an einen physischen Server bindet

RHEL ist kein einmaliger Kauf — die Software wird durch ein Red-Hat-Abonnement entitled, und dieses Abonnement erkauft Ihnen zertifizierte Errata, ein Support-SLA und Zugang zum unterstützten Lebenszyklus. Auf einer Serverside-Maschine bringen Sie Ihr eigenes mit: Wir stellen das OS bereit und übergeben Ihnen Root, dann registrieren Sie die Maschine gegen Ihre Red-Hat-Organisation und sie beginnt, Updates aus Red Hats CDN zu ziehen.

Die Registrierung ist ein einziger Befehl — subscription-manager register mit Ihrer Organisations-ID und einem Activation Key —, nach dem das System entitled ist. Red Hats aktuelles Modell ist Simple Content Access (SCA), heute der Standard für Accounts: Sobald ein System registriert ist, hat es Content-Zugriff ohne expliziten attach-Schritt, sodass das alte subscription-manager attach nun ein No-op ist. Beachten Sie, dass die Aktivierung von SCA für eine Organisation eine einseitige Änderung ist.

Sie sind nicht auf unsere Images beschränkt: Mounten Sie Ihre eigene RHEL-Installer-ISO und führen Sie die Installation selbst über die KVM-Konsole durch — Sie sehen den grafischen oder Text-Installer genau so booten wie auf Hardware, die vor Ihnen steht. Das ist der saubere Weg, wenn Sie die Maschine nach Ihrem eigenen Kickstart- oder Partitionierungsstandard aufsetzen wollen, bevor Sie Ihr Red-Hat-Abonnement anbinden — bringen Sie Ihren eigenen Installer mit, bringen Sie Ihr eigenes Entitlement mit.

Jedes Entitlement ist an ein System gebunden, sodass ein Bare-Metal-Host ein Abonnement für die physische Maschine verbraucht, unabhängig davon, wie viele Cores sie hat — eine dichte EPYC-Maschine kostet in der Entitlement-Frage nicht mehr als eine kleine. Da Sie vollen Root-Zugriff haben und der Server standardmäßig unmanaged ist, liegt es ganz bei Ihnen, wie Sie registrieren, welche Repositories Sie aktivieren und wie Sie patchen.

Aktuelle Releases und der 10-jährige Lebenszyklus

RHEL 10 ist das aktuelle Major-Release, seit Mai 2025 allgemein verfügbar und auf einem modernen Kernel und Toolchain aufgebaut. RHEL 9 bleibt bis 2027 im Full Support, mit Maintenance bis 2032, und RHEL 8 ist bis 2029 in seiner Maintenance-Phase — sodass alle drei je nach dem, wogegen Ihr Anwendungs-Stack zertifiziert ist, gangbare Ziele sind.

Jedes RHEL-Major erhält einen zehnjährigen Lebenszyklus: rund fünf Jahre Full Support (neue Features und Hardware-Enablement), dann fünf Jahre Maintenance Support (Sicherheits- und dringende Fehlerkorrekturen auf dem finalen Minor), gefolgt von einer optionalen Extended-Life-Phase. Dieses jahrzehntelange, vorhersehbare Fenster ist ein Kerngrund, warum regulierte und langlebige Workloads auf RHEL standardisieren statt auf eine schnelllebigere Distribution.

Falls Sie auf einem bestimmten Minor-Release einfrieren müssen — weil ein ISV nur gegen, sagen wir, RHEL 9.4 zertifiziert —, hält Extended Update Support (EUS) einen gegebenen Minor 24 Monate lang gepatcht, und der SAP-fokussierte E4S-Stream erweitert das auf vier Jahre. Diese Add-ons setzen auf Ihrem Abonnement auf; die Hardware darunter ist dieselbe Maschine, die wir in unter einer Minute bereitstellen.

RHEL, AlmaLinux und Rocky nach der Quellcode-Änderung 2023

Mitte 2023 machte Red Hat CentOS Stream zum einzigen öffentlichen Repository für RHEL-bezogenen Quellcode und beendete die frühere Praxis, Quellen pro Release auf git.centos.org zu veröffentlichen. Zahlende Red-Hat-Kunden erhalten weiterhin vollständige RHEL-Quellen über das Customer Portal; die Änderung betraf speziell downstream Rebuilds, die sich auf diese öffentlichen Quellen verlassen hatten, um 1:1-Binärkopien zu erzeugen.

Die beiden großen Community-Rebuilds reagierten unterschiedlich. AlmaLinux verlagerte sein Ziel von „1:1 bug-for-bug“ zu Application-Binary-Interface-Kompatibilität (ABI) — für RHEL zertifizierte Software läuft weiterhin, aber Alma verspricht keine byte-identischen Pakete mehr. Rocky Linux, dessen Träger halfen, die Open Enterprise Linux Association (OpenELA) mit Oracle und SUSE zu gründen, zielt weiterhin auf bug-for-bug RHEL-Kompatibilität, bezogen über OpenELA. Beide sind frei, und wir provisionieren beide kostenlos.

Für die meisten selbst-unterstützten Workloads ist ein Rebuild die pragmatische Wahl: Sie erhalten die RHEL-Plattform und das Ökosystem ohne Abonnement. Zu echtem RHEL greifen Sie, wenn die Support-Beziehung, zertifizierte Errata oder die Vendor-Freigabe der Punkt sind — worum es genau im nächsten Abschnitt geht.

Wann bezahltes RHEL einen freien Rebuild schlägt — und wann nicht

Die Rebuilds sind binärkompatibel, sodass der entscheidende Faktor selten die Software selbst ist — es sind der Papierkram und die Vendor-Beziehung drumherum. Echtes RHEL verdient sein Abonnement, wenn ein Dritter in der Verantwortung steht:

• ISV-Zertifizierung: SAP, Oracle Database und viel kommerzielle Middleware sind nur auf RHEL (oder seinen SAP/E4S-Varianten) zertifiziert und unterstützt, und Anbieter lehnen es unter Umständen ab, auf einem Rebuild Fehler zu suchen
• Compliance-Regime, die ein unterstütztes, vendor-gestütztes OS mit SLA und nachvollziehbaren Errata vorschreiben
• Hardware- und Plattform-Zertifizierung, bei der ein bestimmter Server oder Beschleuniger gegen RHEL validiert ist
• Flottenverwaltung über Red Hat Lightspeed (früher Insights) und Satellite für Schwachstellen-, Patch- und Drift-Transparenz im großen Maßstab
• Umgekehrt: Für einen selbst gehosteten Web-Tier, Container-Hosts, CI-Runner oder internes Tooling geben Ihnen AlmaLinux oder Rocky dieselbe Plattform kostenlos — kein Abonnement zu verfolgen, eine Verlängerung weniger

SELinux standardmäßig im Enforcing-Modus

RHEL wird out of the box mit SELinux im Enforcing-Modus ausgeliefert — Mandatory Access Control, die Prozesse auf gelabelte Policy beschränkt, sodass ein kompromittierter Daemon auf das eingegrenzt wird, was sein Typ berühren darf, statt die Rechte des Aufrufers zu erben. Auf Debian und Ubuntu ist die entsprechende Schicht AppArmor; auf RHEL ist SELinux die native, standardmäßige Haltung, und die Policies des Ökosystems setzen voraus, dass es aktiv ist.

Operativ auf einem Dedicated Server bedeutet das, Zeit für Kontext- und Boolean-Tuning einzuplanen, statt es reflexartig auf permissive zu setzen: Labeln Sie Ihre Datenverzeichnisse korrekt (restorecon, semanage fcontext), setzen Sie die relevanten sebooleans für Dienste wie httpd oder Container und lesen Sie das Audit-Log (ausearch, sealert), wenn etwas verweigert wird. SELinux im Enforcing-Modus zu belassen, ist ein wesentlicher Grund, warum RHEL in regulierten Umgebungen vertraut wird, daher lohnt es sich, es aktiv zu lassen.

Segmentieren Sie das Netzwerk so, wie es ein Audit erwartet

SELinux grenzt Prozesse auf dem Host ein; die Netzwerkschicht grenzt ein, was sie erreichen kann, und RHEL-Shops brauchen in der Regel beides. Sie können Ihre Server in ein privates Netzwerk zwischen den Maschinen stellen und ein echtes mehrstufiges Deployment betreiben — der App-Tier spricht über die private Schnittstelle mit dem Datenbank-Tier, mit einer öffentlichen Schnittstelle nur auf dem Front-End, das zu den Nutzern zeigen muss. Die Datenbank braucht überhaupt keine öffentliche Adresse.

Für compliance-getriebene Segmentierung können Sie Ihre eigene Netzwerk-DMZ definieren: Exponieren Sie nur den Tier, der erreichbar sein muss, und halten Sie interne Systeme dahinter isoliert — genau die Topologie, die ein Auditor dokumentiert sehen möchte, wenn Ihre Workload PCI-, HIPAA- oder ähnliche Auflagen trägt. Da Sie die Segmentierung selbst definieren, folgt die Grenze Ihren Kontrollen statt einer geteilten Provider-Voreinstellung.

RHEL-eigenes Tooling

Die alltägliche Verwaltungsoberfläche ist der Red-Hat-Stack, den Sie erwarten würden, und alles davon funktioniert gleich auf echtem RHEL oder einem Rebuild:

• dnf und RPM für Paket- und Transaktionsverwaltung, mit Modularity und Application Streams
• kpatch Live-Kernel-Patching, um kritische Kernel-CVEs ohne Neustart einzuspielen — unterstützt seit RHEL 8.1 —, was gut zu einem Bare-Metal-Host mit langer Uptime passt
• Image Builder (osbuild), um reproduzierbare, angepasste OS-Images zu erzeugen, die Sie über eine Flotte hinweg neu ausrollen können
• Red Hat Lightspeed und Satellite (Abonnement-Features) für Advisories, Patch-Orchestrierung und kpatch-Rollout im großen Maßstab
• System Roles und Ansible-Content für wiederholbare Konfiguration auf einer Maschine, die von Anfang bis Ende Ihnen gehört