OS-RELEASE(5) | os-release | OS-RELEASE(5) |
os-release, initrd-release, extension-release - Betriebssystemidentifikation
/etc/os-release
/usr/lib/os-release
/etc/initrd-release
/usr/lib/extension-release.d/extension-release.ABBILD
Die Dateien /etc/os-release und /usr/lib/os-release enthalten Betriebssystemidentifizierungsdaten.
Das Dateiformat von os-release ist eine durch Zeilenumbrüche getrennte Liste von umgebungsartigen, Shell-kompatiblen Variablenzuweisungen. Es ist möglich, die Konfiguration aus Bourne-Shell-Skripten einzulesen, allerdings werden außer einfachen Variablenzuweisungen keine Shell-Funktionalitäten unterstützt. (Das bedeutet, Variablenexpansion wird explizit nicht unterstützt). Damit wird Anwendungen erlaubt, die Datei einzulesen, ohne eine Shell-kompatible Ausführungseinheit zu implementieren. Variablenzuweisungen müssen in doppelte oder einzelne englische Anführungszeichen eingeschlossen werden, falls sie Leerzeichen, Semikola oder andere besondere Zeichen außerhalb von A…Z, a…z, 0…9 enthalten. (Zuweisungen, die diese besonderen Zeichen nicht enthalten, können auch in Anführungszeichen eingeschlossen werden, dies ist aber optional.) Besondere Zeichen der Shell (»$«, Anführungszeichen, Rückwärtsschrägstrich, Gravis) müssen im Shell-Stil mit Rückwärtsschrägstrichen geschützt werden. Alle Zeichenketten sollten in UTF-8-Kodierung sein und nicht druckbare Zeichen sollten nicht verwandt werden. Die Aneinanderreihung individueller Zeichenketten in Anführungszeichen wird nicht unterstützt. Zeilen, die mit »#« beginnen, werden als Kommentar behandelt. Leere Zeilen sind erlaubt und werden ignoriert.
Die Datei /etc/os-release hat vor /usr/lib/os-release Vorrang. Anwendungen sollten auf erstere prüfen und deren Daten exklusiv nutzen, falls sie exsitiert, und nur auf /usr/lib/os-release zurückfallen, falls sie fehlt. Anwendungen sollten nicht aus beiden Dateien gleichzeitig Daten auslesen. /usr/lib/os-release ist der bevorzugte Ort, um Betriebssystemveröffentlichungsinformationen wie Teile des Lieferantenbaums abzulegen. /etc/os-release sollte ein relativer Symlink auf /usr/lib/os-release sein, um Kompatibilität für Anwendungen bereitzustellen, die nur nach /etc/ schauen. Ein relativer Symlink anstatt eines absoluten ist notwendig, damit der Link auch in einer Chroot oder Initrd-Umgebung wie Dracut funktioniert.
os-release enthält Daten, die durch den Betriebssystemlieferanten definiert werden und sollte im Allgemeinen durch den Administrator nicht geändert werden.
Da diese Datei nur Namen und Kennungen kodiert, sollte sie nicht lokalisiert werden.
Die Dateien /etc/os-release und /usr/lib/os-release können Symlinks auf andere Dateien sein, aber es ist wichtig, dass diese Datei vom frühsten Zeitpunkt des Systemstarts an verfügbar ist, und sie muss sich daher auf dem Wurzeldateisystem befinden.
os-release darf keine wiederholenden Schlüssel enthalten. Dennoch sollten Leseprogramme den hinteren Eintrag in der Datei wählen, falls Wiederholungen auftreten, ähnlich wie das beim Einlesen von Dateien durch die Shell passiert. Ein Leseprogramm darf bei wiederholenden Einträge warnen.
Für eine längere Begründung für os-release lesen Sie bitte die Ankündigung von /etc/os-release[1].
In der Initrd[2] spielt /etc/initrd-release die gleiche Rolle wie os-release im Hauptsystem. Zusätzlich bedeutet die Existenz dieser Datei, dass das System in der Initrd-Phase ist. /etc/os-release sollte ein Symlink auf /etc/initrd-release sein (oder umgekehrt), so dass Programme, die nur nach /etc/os-release schauen (wie oben beschrieben), korrekt funktionieren.
Der Rest dieses Dokuments, das von os-release berichtet, sollte so verstanden werden, dass es auch für initrd-release gilt.
/usr/lib/extension-release.d/extension-release.ABBILD spielt die gleiche Rolle für Erweiterungsabbilder wie os-release für das Hauptsystem und folgt der Syntax und den Regel wie in Dokumentation portabler Dienste[3] beschrieben. Der Zweck dieser Datei ist die Identifizierung der Erweiterung und der Ermöglichung für das Betriebssystem, zu überprüfen, dass das Erweiterungsabbild auf das zugrundeliegende Betriebssystem passt. Dies wird typischerweise implementiert, indem geprüft wird, dass die Option ID= übereinstimmt und entweder SYSEXT_LEVEL= existiert und auch übereinstimmt oder, falls das nicht vorhanden ist, dass VERSION_ID= existiert und übereinstimmt. Dies stellt ABI/API-Kompatibilität zwischen den Ebenen sicher und verhindert das Zusammenführen von inkompatiblen Abbildern in einer Überlagerung.
In dem Dateinamen extension-release.ABBILD muss der ABBILD-Anteil genau auf den Dateinamen des enthaltenden Abbildes mit entfernter Endung passen. Falls es nicht möglich ist, dass ein stabiler Abbildname garantiert werden kann, kann diese Überprüfung gelockert werden: falls genau eine Datei in dem Verzeichnis vorhanden ist, deren Name auf »extension-release.*« passt und die Datei mit einem user.extension-release.strict xattr(7) gesetzt auf die Zeichenkette »0« markiert ist, dann wird sie stattdessen verwandt.
Der Rest dieses Dokuments, der von os-release handelt, sollte so gelesen werden, das er auch auf extension-release angewandt werden kann.
Die folgenden Betriebssystemidentifikationsparameter können mittels os-release gesetzt werden:
NAME=
Beispiele: »NAME=Fedora«, »NAME="Debian GNU/Linux"«.
ID=
Beispiele: »ID=fedora«, »ID=debian«.
ID_LIKE=
Beispiele: Für ein Betriebssystem mit »ID=centos« wäre eine Zuweisung von »ID_LIKE="rhel fedora"« geeeignet. Für ein Betriebssystem mit »ID=ubuntu« ist eine Zuweisung »ID_LIKE=debian« geeignet.
PRETTY_NAME=
Beispiel: »PRETTY_NAME="Fedora 17 (Beefy Miracle)"«.
CPE_NAME=
Beispiel: »CPE_NAME="cpe:/o:fedoraproject:fedora:17"«
VARIANT=
Beispiele: »VARIANT="Server Edition"«, "VARIANT=»Smart Refrigerator Edition"«.
Beachten Sie: Dieses Feld dient nur Anzeigezwecken. Für programmgesteuerte Entscheidungen sollte das Feld VARIANT_ID benutzt werden.
VARIANT_ID=
Beispiele: »VARIANT_ID=server«, »VARIANT_ID=embedded«.
VERSION=
Beispiele: »VERSION=17«, »VERSION="17 (Beefy Miracle)"«.
VERSION_ID=
Beispiele: »VERSION_ID=17«, »VERSION_ID=11.04«.
VERSION_CODENAME=
Beispiele: »VERSION_CODENAME=buster«, »VERSION_CODENAME=xenial«.
BUILD_ID=
Beispiele: »BUILD_ID="2013-03-20.3"«, »BUILD_ID=201303203«.
IMAGE_ID=
Beispiele: »IMAGE_ID=vendorx-cashier-system«, »IMAGE_ID=netbook-image«.
IMAGE_VERSION=
Beispiele: »IMAGE_VERSION=33«, »IMAGE_VERSION=47.1rc1«.
Um zusammenzufassen: Falls die Abbildaktualisierungen als umfassende Einheiten gebaut und ausgeliefert werden, passt IMAGE_ID+IMAGE_VERSION am besten. Falls andernfalls die Aktualisierungen schließlich die vorher installierten Inhalte komplett ersetzen, wie dies in einer typischen binären Distribution der Fall ist, sollte VERSION_ID verwandt werden, um die Hauptveröffentlichungen des Betriebssystems zu kennzeichnen. BUILD_ID kann statt oder zusätzlich zu VERSION_ID verwandt werden, wenn die Version des ursprünglichen Systemabbildes wichtig ist.
HOME_URL=, DOCUMENTATION_URL=, SUPPORT_URL=, BUG_REPORT_URL=, PRIVACY_POLICY_URL=
Beispiele: »HOME_URL="https://fedoraproject.org/"«, »BUG_REPORT_URL="https://bugzilla.redhat.com/"«.
SUPPORT_END=
Beispielsweise bedeutet »SUPPORT_END=2001-01-01«, dass das System bis zum letzten Tag des letzten Jahrtausends unterstützt wurde.
LOGO=
Beispiele: »LOGO=fedora-logo«, »LOGO=distributor-logo-opensuse«
ANSI_COLOR=
Beispiele: »ANSI_COLOR="0;31"« für rot, »ANSI_COLOR="1;34"« für helles blau oder »ANSI_COLOR="0;38;2;60;110;180"« für Fedora-blau.
DEFAULT_HOSTNAME=
Siehe org.freedesktop.hostname1(5) für eine Beschreibung, wie systemd-hostnamed.service(8) den Rückfall-Rechnernamen bestimmt.
ARCHITECTURE=
SYSEXT_LEVEL=
Beispiele: »SYSEXT_LEVEL=2«, »SYSEXT_LEVEL=15.14«.
SYSEXT_SCOPE=
PORTABLE_PREFIXES=
Falls Sie diese Datei verwenden, um das Betriebssystem oder eine bestimmte Version davon zu ermitteln, benutzen Sie die Felder ID und VERSION_ID, möglicherweise mit ID_LIKE als Rückfallwert. Wenn Sie nach einer Betriebssystemkennungszeichenkette für die Darstellung beim Benutzer suchen, verwenden Sie das Feld PRETTY_NAME.
Beachten Sie, dass Betriebssystemanbieter sich entscheiden könnten, keine Versionsinformationen zu liefern, beispielsweise um rollende Veröffentlichungen (»rolling releases«) zu berücksichtigen. In diesen Fällen können VERSION und VERSION_ID ungesetzt sein. Anwendungen sollte sich nicht darauf verlassen, dass diese Felder gesetzt sind.
Betriebssystemanbieter können das Dateiformat erweitern und neue Felder einführen. Es wird nachdrücklich empfohlen, neuen Feldern einen betriebssystemspezifischen Namen voranzustellen, um Namenskollisionen zu vermeiden. Anwendungen, die diese Datei lesen, müssen unbekannte Felder ignorieren.
Beispiel: »DEBIAN_BTS="debbugs://bugs.debian.org/"«.
Verwalter von Containern und Sandbox-Laufzeitumgebungen können die Identifizierungsdaten des Rechners Anwendungen zur Verfügung stellen, indem sie die Datei /etc/os-release (falls verfügbar, andernfalls /usr/lib/os-release als Rückfalloptione) als /run/host/os-release bereitstellen.
Beispiel 1. Datei os-release für Fedora Workstation
NAME=Fedora VERSION="32 (Workstation Edition)" ID=fedora VERSION_ID=32 PRETTY_NAME="Fedora 32 (Workstation Edition)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:32" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/" SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=32 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=32 PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT="Workstation Edition" VARIANT_ID=workstation
Beispiel 2. extension-release file für eine Erweiterung für Fedora Workstation 32
ID=fedora VERSION_ID=32
Beispiel 3. os-release in sh(1) einlesen
#!/bin/sh -eu # SPDX-License-Identifier: MIT-0 test -e /etc/os-release && os_release='/etc/os-release' || os_release='/usr/lib/os-release' . "${os_release}" echo "Ausführung auf ${PRETTY_NAME:-Linux}" if [ "${ID:-linux}" = "debian" ] || [ "${ID_LIKE#*debian*}" != "${ID_LIKE}" ]; then
echo "Sieht nach Debian aus!" fi
Beispiel 4. os-release in python(1) (Version >= 3.10) einlesen
#!/usr/bin/python # SPDX-License-Identifier: MIT-0 import platform os_release = platform.freedesktop_os_release() pretty_name = os_release.get('PRETTY_NAME', 'Linux') print(f'Ausführung auf {pretty_name!r}') if 'fedora' in [os_release.get('ID', 'linux'),
*os_release.get('ID_LIKE', '').split()]:
print('Sieht nach Fedora aus!')
Siehe Dokumentation für platform.freedesktop_os_release[7] für weitere Details.
Beispiel 5. os-release in python(1) (jede Version) einlesen
#!/usr/bin/python # SPDX-License-Identifier: MIT-0 import ast import re import sys def read_os_release():
try:
filename = '/etc/os-release'
f = open(filename)
except FileNotFoundError:
filename = '/usr/lib/os-release'
f = open(filename)
for line_number, line in enumerate(f, start=1):
line = line.rstrip()
if not line or line.startswith('#'):
continue
m = re.match(r'([A-Z][A-Z_0-9]+)=(.*)', line)
if m:
name, val = m.groups()
if val and val[0] in '"\'':
val = ast.literal_eval(val)
yield name, val
else:
print(f'{filename}:{line_number}: ungültige Zeile {line!r}',
file=sys.stderr) os_release = dict(read_os_release()) pretty_name = os_release.get('PRETTY_NAME', 'Linux') print(f'Ausführung auf {pretty_name!r}') if 'debian' in [os_release.get('ID', 'linux'),
*os_release.get('ID_LIKE', '').split()]:
print('Sieht nach Debian aus!')
Beachten Sie, dass die obige Version, die die eingebaute Implementierung verwendet, in den meisten Fällen bevorzugt wird, und dass die hier bereitgestellte offen kodierte Version als Referenz dient.
systemd(1), lsb_release(1), hostname(5), machine-id(5), machine-info(5)
platform.freedesktop_os_release
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.
systemd 252 |