Linux-Version prüfen: So geht's

In komplexen Linux-Beständen sind die meisten „rätselhaften“ Ausfälle in Wahrheit gar keine Rätsel. Eine globale Umfrage aus dem Jahr 2023 ergab, dass fast zwei Drittel der IT-System- und Software-Ausfälle durch Konfigurations- oder Change-Management-Fehler verursacht wurden und nicht durch die zugrunde liegenden Plattformen selbst. Das falsche Auslesen eines Linux-Kernels oder einer OS-Version vor einem Sicherheits-Patch-Rollout ist genau die Art von kleinem Versehen, das sich zu einem großflächigen Ausfall ausweiten kann.

Dies geschieht in IT-Umgebungen häufig, da die Erkennung der Linux-Version nicht so einfach ist wie das Überprüfen einer einzelnen Zahl. Um die wahre Version Ihres Linux-Systems zu verstehen, müssen mehrere Ebenen geprüft werden, die unterschiedliche Kompatibilitätsfragen beantworten. Jede ausgelassene Ebene erzeugt blinde Flecken in Ihrem Infrastruktur-Management.

Hier erfahren Sie alles, was Sie wissen müssen, um Ihre Linux-Version schnell und einfach zu prüfen.

»Neu bei Linux? Erfahren Sie, welcher Linux-Befehl Nachrichten an Netzwerkschnittstellen sendet.

Warum die Überprüfung Ihrer Linux-Version so komplex ist

Bei der Validierung von Kompatibilität und Support müssen Sie drei verschiedene Ebenen trennen, da sie grundlegend unterschiedliche Fragen beantworten:

• Die Kernel-Version verrät Ihnen, welche Hardware-Treiber, Sicherheitsfixes und Low-Level-Funktionen das System tatsächlich besitzt. Identische Distributions-Versionen mit unterschiedlichen Kerneln können verschiedene Support-Level haben; so haben Ubuntu 20.04-Server mit einem 5.4-Kernel eine eingeschränktere Unterstützung für Netzwerkkarten (NIC) und Eingabegeräte im Vergleich zu Systemen mit dem 5.15 HWE-Kernel.
• Die Distributions-Version definiert die Paketierung, die Standardeinstellungen und den Support-Lebenszyklus des Herstellers. Zwei Systeme können denselben Kernel ausführen, sich aber unterschiedlich verhalten, wenn eines Ubuntu und das andere Rocky Linux ist.
• Das OS-Release kombiniert die Distro-Version, die Kernel-Richtlinie und das Support-Fenster in einem einzigen Support-Vertrag.

Aus betrieblicher Sicht validieren Kernel-Checks die Hardware-Kompatibilität, Distro-Checks bestätigen Tools und Bibliotheken, und OS-Release-Checks bestimmen, ob das System noch Anspruch auf Updates und Herstellersupport hat.

Wie Build-Typen die verfügbaren Versionsinformationen verändern

Enterprise-Linux-Builds wie RHEL, Ubuntu LTS oder SUSE liefern designbedingt umfassende Versionsinformationen, da Wartbarkeit entscheidend ist. Standardmäßig finden Sie /etc/os-release, detaillierte Kernel-Metadaten, Hersteller-Tools und Lebenszyklus-Kennungen. In Enterprise-RHEL- und Ubuntu-Flotten ist diese Ausführlichkeit beabsichtigt, da Unternehmen einen prüffähigen Support-Status und eine lückenlose Patch-Historie benötigen.

Minimal-Builds verändern dieses Gleichgewicht. Auf abgespeckten Ubuntu-Server- oder Alpine-Images existieren möglicherweise nur die Kernel-Version und eine einfache /etc/os-release-Datei, während Utilities wie lsb_release entfernt wurden, um den Speicherbedarf zu reduzieren. Dies kann Administratoren zu der Annahme verleiten, ein System sei „unbekannt“, obwohl es lediglich minimal konfiguriert ist.

Container-optimierte Builds abstrahieren die OS-Identität absichtlich. In Docker-, Bottlerocket- oder „Distroless“-Images sehen Sie unter Umständen nur die Kernel-Version des Hosts, während der Container selbst wenig oder gar keine Distro-Metadaten preisgibt.

Schritt-für-Schritt-Anleitung zur Überprüfung der Linux-Version

Die Überprüfung Ihrer Linux-Version umfasst zwei einfache Schritte, um alle benötigten Ebenen genau zu identifizieren. So geht’s:

Schritt 1: Prüfen der laufenden Kernel-Version und Verifizieren der Boot-Konfiguration

Der erste Schritt besteht darin, den laufenden Kernel zu identifizieren, nicht das, was installiert ist. Auf jedem Linux-System meldet der Befehl uname -r die exakte Kernel-Version, die aktiv in den Speicher geladen ist.

Dieser Befehl zeigt Ihnen den Kernel, der aktuell ausgeführt wird. Dieser kann sich von installierten Paketen unterscheiden, die eventuell neuere Versionen enthalten, welche auf einen Neustart warten. Die Ausgabe von uname -r liefert den Kernel-Release-String (zum Beispiel 5.15.0-91-generic oder 5.14.0-427.22.1.el9.x86_64). Dies ist das Etikett auf dem Motor, der gerade läuft, nicht auf dem Ersatzteil im Kofferraum.

Obwohl dies nur die Kernel-Version und Architektur bestätigt, bietet es eine Basis für Kompatibilität und kann helfen, auf bestimmte Distributionen rückzuschließen:

• RHEL-Kernel enthalten oft Versions-Tags in ihrer Benennung (z. B. .el9 für RHEL 9).

Ubuntu-Kernel enden häufig auf -generic oder -hwe; diese Suffixe helfen bei der Identifizierung der Distributions-Familie.

Nachdem Sie dies getan haben, führen Sie auch diese Bestätigungen durch:

• Um installierte Kernel zu verifizieren, nutzen Sie Paket-Tools. Auf Debian-basierten Systemen zeigt dpkg –list | grep linux-image alle Kernel-Pakete auf der Festplatte an. Auf Red Hat-basierten Systemen liefert rpm -qa | grep kernel dieselbe Information. Wenn der neueste Kernel nicht läuft, müssen Sie neu starten.
• Um die beabsichtigte Boot-Konfiguration zu bestätigen, prüfen Sie den Bootloader. Auf GRUB-Systemen zeigt grub2-editenv list oder die Überprüfung von /boot/grub/grub.cfg den Standard-Kernel-Eintrag an. Dies verifiziert, welchen Kernel das System beim nächsten Bootvorgang laden wird.
• Stellen Sie schließlich sicher, dass der laufende Kernel mit der erwarteten Konfiguration übereinstimmt, indem Sie /proc/version und /boot/config-$(uname -r) gegenprüfen. Diese vollständige Sequenz verhindert falsches Vertrauen und deckt unbemerkte Boot-Diskrepanzen auf.

Schritt 2: Bestimmen der OS- und Distributions-Version über standardisierte Dateien

Die zuverlässigste Methode zur Bestimmung der OS- und Distributions-Version auf modernen Linux-Systemen ist das Auslesen von /etc/os-release. Diese Datei ist auf fast allen aktuellen Distributionen vorhanden und bietet standardisierte, strukturierte Informationen.

Untersuchen Sie die Datei mit cat /etc/os-release oder less /etc/os-release. Wichtige Felder zur Interpretation sind:

• NAME: Der Name der Distribution (z. B. Ubuntu, Rocky Linux).
• VERSION: Menschenlesbarer Release-String (z. B. „22.04.2 LTS“).
• ID: Kurzkennung für die Verwendung in Skripten (z. B. ubuntu).
• VERSION_ID: Numerische Version für automatisierte Prüfungen (z. B. 22.04).

PRETTY_NAME: Formatierter String, der Name und Version kombiniert.

Ältere Distributionen stellen möglicherweise auch /etc/issue oder /etc/*-release-Dateien bereit, diese sind jedoch weniger standardisiert. Für enterprise IT environments bietet die Gegenprüfung mit lsb_release -a zusätzliche Felder wie Distributor ID und Codename, die für die Paketverwaltung und Support-Verifizierung nützlich sind.

Bonus-Prüfungen

Sobald Sie die obigen Prüfungen durchgeführt haben (oder falls diese nicht funktionieren), gibt es weitere Tests, um die Linux-Version einzugrenzen:

• Die Untersuchung der Paketmanager-Datenbanken offenbart oft Distributionsdetails: Auf Red Hat-basierten Systemen listet rpm -qa | grep release oft Pakete wie redhat-release oder centos-release auf. In containerisierten Builds können Paket-Metadaten oder eingebettete Labels den Namen und die Version verraten, selbst wenn /etc/os-release entfernt wurde.

Auf Debian-basierten Systemen kann dpkg -l | head Basis-Release-Paketversionen aufzeigen. Der Befehl dpkg-query –showformat=’${Package} ${Version}\n’ -W base-files zeigt die Version des base-files-Pakets an, die häufig mit dem Distro-Release übereinstimmt.

Weitere wichtige Dateisystem-Marker, die man prüfen kann:

• /usr/lib/os-release: Alternativer Ort mit denselben strukturierten Daten wie /etc/os-release.
• /etc/centos-release, /etc/redhat-release, /etc/rocky-release: Distro-spezifische Dateien mit einzeiligen Versions-Strings.

/var/lib/dpkg/status (Debian/Ubuntu) oder /var/lib/rpm/Packages (RPM-basiert): Paketdatenbanken, in denen Sie nach Basispaketen suchen (greppen) können.

Automatisieren Sie Linux-Versionsprüfungen über IT-Umgebungen hinweg mit Atera

In großen IT-Umgebungen ist es nicht praktikabel, Linux-Versionen auf Dutzenden oder Hunderten von Systemen manuell zu prüfen. Administratoren benötigen eine zentrale Sicht darauf, was tatsächlich in der gesamten Flotte läuft, um Patch-Compliance sicherzustellen, Kompatibilitäts-IT-Probleme zu beheben und die Support-Abdeckung zu validieren.

Für schnelle Ad-hoc-Prüfungen auf einigen wenigen Systemen bietet SSH einen einfachen Ansatz. Sie können Befehle remote ausführen und Versionsinformationen sammeln: 

ssh user@server1 'cat /etc/os-release; uname -r'
ssh user@server2 'cat /etc/os-release; uname -r'

Dies funktioniert für Stichproben, wird aber bei steigender Anzahl unhandlich. Sie müssen sich manuell mit jedem System verbinden, Ausgaben kopieren und Ergebnisse zusammenstellen. Bei der Verwaltung von 20, 50 oder über 100 Linux-Servern ist dieses Vorgehen anfällig für menschliche Fehler und Zeitverschwendung.

Für ein automatisiertes, flottenweites Linux-Monitoring bietet die Remote Monitoring und Management-Plattform von Atera automatisierte Asset- und Inventar-Scans über Ihre gesamte Infrastruktur hinweg. Anstatt sich manuell per SSH in jedes System einzuwählen, sammelt Atera automatisch Systeminformationen durch geplante Scans, einschließlich:

• Betriebssystem- und Distributions-Version
• Kernel-Versionen und Patch Management-Level
• Hardware-Spezifikationen und Architektur
• Inventar der installierten Software

Diese Informationen werden automatisch im zentralen Dashboard von Atera angezeigt und bieten Ihnen eine stets aktuelle Sicht auf den Versionsstatus jedes Linux-Systems. Sie können schnell identifizieren, auf welchen Systemen veraltete Kernel laufen, welche ein Distributions-Upgrade benötigen oder welche nicht mehr Ihren Standardkonfigurationen entsprechen.

Und wenn Sie benutzerdefinierte Versionsprüfungs-Skripte in Ihrer Flotte ausführen müssen, kann der KI-Copilot von Atera maßgeschneiderte Skripte aus Anweisungen in natürlicher Sprache erstellen – ganz ohne Programmierkenntnisse. Sie könnten beispielsweise fragen: „Erstelle ein Skript, das prüft, ob der laufende Kernel mit dem neuesten installierten Kernel-Paket übereinstimmt, und melde alle Abweichungen“, und der Copilot generiert das Bash-Skript für Sie. Diese Skripte können dann über Ateras Automatisierungsprofile remote bereitgestellt werden, um zeitgesteuert auf spezifischen Systemen oder Ihrer gesamten Plattform ausgeführt zu werden.

»Interessiert?Testen Sie Atera kostenlos