OS-RELEASE(5) os-release OS-RELEASE(5) BEZEICHNUNG os-release, initrd-release, extension-release - Betriebssystemidentifikation UBERSICHT /etc/os-release /usr/lib/os-release /etc/initrd-release /usr/lib/extension-release.d/extension-release.ABBILD BESCHREIBUNG Die Dateien /etc/os-release und /usr/lib/os-release enthalten Betriebssystemidentifizierungsdaten. Das Dateiformat von os-release ist eine durch Zeilenumbruche getrennte Liste von umgebungsartigen, Shell-kompatiblen Variablenzuweisungen. Es ist moglich, die Konfiguration aus Bourne-Shell-Skripten einzulesen, allerdings werden ausser einfachen Variablenzuweisungen keine Shell-Funktionalitaten unterstutzt. (Das bedeutet, Variablenexpansion wird explizit nicht unterstutzt). Damit wird Anwendungen erlaubt, die Datei einzulesen, ohne eine Shell-kompatible Ausfuhrungseinheit zu implementieren. Variablenzuweisungen mussen in doppelte oder einzelne englische Anfuhrungszeichen eingeschlossen werden, falls sie Leerzeichen, Semikola oder andere besondere Zeichen ausserhalb von AZ, az, 09 enthalten. (Zuweisungen, die diese besonderen Zeichen nicht enthalten, konnen auch in Anfuhrungszeichen eingeschlossen werden, dies ist aber optional.) Besondere Zeichen der Shell (>>$<<, Anfuhrungszeichen, Ruckwartsschragstrich, Gravis) mussen im Shell-Stil mit Ruckwartsschragstrichen geschutzt werden. Alle Zeichenketten sollten in UTF-8-Kodierung sein und nicht druckbare Zeichen sollten nicht verwandt werden. Die Aneinanderreihung individueller Zeichenketten in Anfuhrungszeichen wird nicht unterstutzt. 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 prufen und deren Daten exklusiv nutzen, falls sie exsitiert, und nur auf /usr/lib/os-release zuruckfallen, falls sie fehlt. Anwendungen sollten nicht aus beiden Dateien gleichzeitig Daten auslesen. /usr/lib/os-release ist der bevorzugte Ort, um Betriebssystemveroffentlichungsinformationen wie Teile des Lieferantenbaums abzulegen. /etc/os-release sollte ein relativer Symlink auf /usr/lib/os-release sein, um Kompatibilitat fur 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 enthalt Daten, die durch den Betriebssystemlieferanten definiert werden und sollte im Allgemeinen durch den Administrator nicht geandert werden. Da diese Datei nur Namen und Kennungen kodiert, sollte sie nicht lokalisiert werden. Die Dateien /etc/os-release und /usr/lib/os-release konnen Symlinks auf andere Dateien sein, aber es ist wichtig, dass diese Datei vom fruhsten Zeitpunkt des Systemstarts an verfugbar ist, und sie muss sich daher auf dem Wurzeldateisystem befinden. os-release darf keine wiederholenden Schlussel enthalten. Dennoch sollten Leseprogramme den hinteren Eintrag in der Datei wahlen, falls Wiederholungen auftreten, ahnlich wie das beim Einlesen von Dateien durch die Shell passiert. Ein Leseprogramm darf bei wiederholenden Eintrage warnen. Fur eine langere Begrundung fur os-release lesen Sie bitte die Ankundigung von /etc/os-release[1]. /etc/initrd-release In der Initrd[2] spielt /etc/initrd-release die gleiche Rolle wie os-release im Hauptsystem. Zusatzlich 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 fur initrd-release gilt. /usr/lib/extension-release.d/extension-release.ABBILD /usr/lib/extension-release.d/extension-release.ABBILD spielt die gleiche Rolle fur Erweiterungsabbilder wie os-release fur das Hauptsystem und folgt der Syntax und den Regel wie in Seite Portable Dienste[3] beschrieben. Der Zweck dieser Datei ist die Identifizierung der Erweiterung und der Ermoglichung fur das Betriebssystem, zu uberprufen, dass das Erweiterungsabbild auf das zugrundeliegende Betriebssystem passt. Dies wird typischerweise implementiert, indem gepruft wird, dass die Option ID= ubereinstimmt und entweder SYSEXT_LEVEL= existiert und auch ubereinstimmt oder, falls das nicht vorhanden ist, dass VERSION_ID= existiert und ubereinstimmt. Dies stellt ABI/API-Kompatibilitat zwischen den Ebenen sicher und verhindert das Zusammenfuhren von inkompatiblen Abbildern in einer Uberlagerung. Um das Erweiterungsabbild selbst zu identifizieren, konnen die nachfolgend definierten Felder zu der Datei extension-release mit einem Prafix SYSEXT_ (um es im Hinblick auf Felder eindeutig zu machen, die auf das Basisabbild passen) hinzugefugt werden. Z.B.SYSEXT_ID=myext, SYSEXT_VERSION_ID=1.2.3. In dem Dateinamen extension-release.ABBILD muss der ABBILD-Anteil genau auf den Dateinamen des enthaltenden Abbildes mit entfernter Endung passen. Falls es nicht moglich ist, dass ein stabiler Abbildname garantiert werden kann, kann diese Uberprufung 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. OPTIONEN Die folgenden Betriebssystemidentifikationsparameter konnen mittels os-release gesetzt werden: Allgemeine Informationen zum Ermitteln des Betriebssystems NAME= Eine Zeichenkette, die das Betriebssystem identifiziert, ohne Versionskomponente und fur die Anzeige beim Benutzer geeignet. Falls nicht gesetzt, kann die Vorgabe >>NAME=Linux<< verwandt werden. Beispiele: >>NAME=Fedora<<, >>NAME="Debian GNU/Linux"<<. ID= Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen ausserhalb von 09, az, >>.<<, >>_<< und >>-<<), die das Betriebssystem identifiziert, ohne irgendwelche Versionsinformationen und geeignet fur die Verarbeitung durch Skripte oder zur Verwendung in erstellten Dateinamen. Falls nicht gesetzt, kann die Vorgabe >>ID=linux<< verwandt werden. Beachten Sie, dass die Zeichenkette weiterhin in Anfuhrungszeichen eingeschlossen werden darf, obwohl sie keine Zeichen enthalt, die fur die Shell das Einschliessen in Anfuhrungszeichen benotigten. Beispiele: >>ID=fedora<<, >>ID=debian<<. ID_LIKE= Eine durch Leerzeichen getrennte Liste von Betriebssystemkennungen in der gleichen Syntax wie die Einstellung ID=. Sie sollte Kennungen von Betriebssystemen auflisten, die eng in Zusammenhang zu dem lokalen Betriebssystem im Hinblick auf Paketierung und Programmierschnittstellen sind, beispielsweise eine oder mehrere Betriebssystemkennungen auflisten, von denen das lokale Betriebssystem abgeleitet ist. Ein Betriebssystem sollte im Allgemeinen nur andere Betriebssystemkennungen auflisten, von denen es selbst abgeleitet ist, und nicht andere Betriebssysteme, die von ihm abgeleitet sind, obwohl symmetrische Beziehungen moglich sind. Bauskripte und ahnliches konnten diese Variable uberprufen, falls sie das lokale Betriebssystem identifizieren mussen und der Wert von ID= nicht erkannt wird. Betriebssysteme sollten in der Reihenfolge aufgelistet werden, wie eng das lokale Betriebssystem in Bezug zu den aufgefuhrten steht, beginnend mit dem engsten. Dieses Feld ist optional. Beispiele: Fur ein Betriebssystem mit >>ID=centos<< ware eine Zuweisung von >>ID_LIKE="rhel fedora"<< geeeignet. Fur ein Betriebssystem mit >>ID=ubuntu<< ist eine Zuweisung >>ID_LIKE=debian<< geeignet. PRETTY_NAME= Ein schoner Betriebssystemname in einem Format, das zur Darstellung bei Benutzern geeignet ist. Wie passend kann dies auf irgendeine Art den Release-Code-Namen oder die Betriebssystemversion enthalten oder auch nicht. Falls nicht gesetzt, kann die Vorgabe >>PRETTY_NAME=Linux<< verwandt werden. Beispiel: >>PRETTY_NAME="Fedora 17 (Beefy Miracle)"<<. CPE_NAME= Ein CPE-Name fur das Betriebssystem, in URI-Anbindungssyntax, gemass der Gemeinsamen Plattform-Aufzahlungs-Spezifikation[4], wie von NIST vorgeschlagen. Dieses Feld ist optional. Beispiel: >>CPE_NAME="cpe:/o:fedoraproject:fedora:17"<< VARIANT= Eine Zeichenkette, die eine spezielle Variante oder Edition des Betriebssystems identifiziert, die zur Darstellung bei Benutzern geeignet ist. Dieses Feld kann den Benutzer daruber informieren, dass die Konfiguration dieses Systems einer speziellen abweichenden Gruppe von Regeln oder einer Standardkonfigurationseinstellung unterliegt. Dieses Feld ist optional und konnte nicht auf allen Systemen implementiert sein. Beispiele: >>VARIANT="Server Edition"<<, "VARIANT=>>Smart Refrigerator Edition"<<. Beachten Sie: Dieses Feld dient nur Anzeigezwecken. Fur programmgesteuerte Entscheidungen sollte das Feld VARIANT_ID benutzt werden. Hinzugefugt in Version 220. VARIANT_ID= Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen ausserhalb von 09, az, >>.<<, >>_<< und >>-<<), die eine spezielle Variante oder eine spezielle Edition des Betriebssystems identifiziert. Dies kann von anderen Paketen interpretiert werden, um eine abweichende Standardkonfiguration zu ermitteln. Dieses Feld ist optional und konnte nicht auf allen Systemen implementiert sein. Beispiele: >>VARIANT_ID=server<<, >>VARIANT_ID=embedded<<. Hinzugefugt in Version 220. Informationen uber die Betriebssystemversion VERSION= Eine Zeichenkette, die die Betriebssystemversion identifiziert, ohne irgendeinen Betriebssystemnamen, moglicherweise einschliesslich eines Code-Namens fur das Release, und fur die Anzeige beim Benutzer geeignet. Dieses Feld ist optional. Beispiele: >>VERSION=17<<, >>VERSION="17 (Beefy Miracle)"<<. VERSION_ID= Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen ausserhalb von 09, az, >>.<<, >>_<< und >>-<<), die die Betriebssystemversion identifiziert, ohne irgendwelche Betriebssystemnamensinformationen oder Release-Code-Namen und geeignet fur die Verarbeitung durch Skripte oder zur Verwendung in erstellten Dateinamen. Dieses Feld ist optional. Beispiele: >>VERSION_ID=17<<, >>VERSION_ID=11.04<<. VERSION_CODENAME= Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen ausserhalb von 09, az, >>.<<, >>_<< und >>-<<), die den Release-Namen des Betriebssystems identifiziert, ohne irgendwelche Betriebssystemnamensinformationen oder Release-Versionen und geeignet fur die Verarbeitung durch Skripte oder zur Verwendung in erstellten Dateinamen. Dieses Feld ist optional und konnte nicht auf allen Systemen implementiert sein. Beispiele: >>VERSION_CODENAME=buster<<, >>VERSION_CODENAME=xenial<<. Hinzugefugt in Version 231. BUILD_ID= Eine Zeichenkette, das das Systemabbild eindeutig identifiziert, das ursprunglich als Installationsgrundlage verwandt wurde. In den meisten Fallen werden VERSION_ID oder IMAGE_ID+IMAGE_VERSION aktualisiert, wenn das gesamte Systemabbild wahrend einer Aktualisierung ersetzt wird. BUILD_ID kann in Distributionen verwandt werden, bei denen die Version des ursprunglichen Installationsabbildes wichtig ist; VERSION_ID wurde sich wahrend schrittweiser Systemaktualisierungen andern, aber nicht BUILD_ID. Dieses Feld ist optional. Beispiele: >>BUILD_ID="2013-03-20.3"<<, >>BUILD_ID=201303203<<. Hinzugefugt in Version 200. IMAGE_ID= Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen ausserhalb von 09, az, >>.<<, >>_<< und >>-<<), die ein spezielles Abbild des Betriebssystems identifiziert. Dies ist fur Umgebungen gedacht, in denen Betriebssystemabbilder als umfassende und konsistente Betriebssystemabbilder vorbereitet, gebaut, ausgeliefert und aktualisiert werden. Dieses Feld ist optional und konnte nicht auf allen Systemen implementiert sein, insbesondere nicht auf solchen, die nicht uber Abbilder verwaltet werden, sondern aus einzelnen Paketen auf dem lokalen System zusammengesetzt und aktualisiert werden. Beispiele: >>IMAGE_ID=vendorx-cashier-system<<, >>IMAGE_ID=netbook-image<<. Hinzugefugt in Version 249. IMAGE_VERSION= Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen ausserhalb von 09, az, >>.<<, >>_<< und >>-<<), die die Betriebssystemversion identifiziert. Dies ist zur Verwendung mit dem oben beschriebenen IMAGE_ID gedacht, um verschiedene Versionen des gleichen Abbilds zu unterscheiden. Beispiele: >>IMAGE_VERSION=33<<, >>IMAGE_VERSION=47.1rc1<<. Hinzugefugt in Version 249. Um zusammenzufassen: Falls die Abbildaktualisierungen als umfassende Einheiten gebaut und ausgeliefert werden, passt IMAGE_ID+IMAGE_VERSION am besten. Falls andernfalls die Aktualisierungen schliesslich die vorher installierten Inhalte komplett ersetzen, wie dies in einer typischen binaren Distribution der Fall ist, sollte VERSION_ID verwandt werden, um die Hauptveroffentlichungen des Betriebssystems zu kennzeichnen. BUILD_ID kann statt oder zusatzlich zu VERSION_ID verwandt werden, wenn die Version des ursprunglichen Systemabbildes wichtig ist. Darstellungsinformationen und Links HOME_URL=, DOCUMENTATION_URL=, SUPPORT_URL=, BUG_REPORT_URL=, PRIVACY_POLICY_URL= Links auf Ressourcen im Internet mit Bezug zu dem Betriebssystem. HOME_URL= sollte sich auf die Homepage des Betriebssystems oder alternativ auf die Homepage der bestimmten Version des Betriebssystems beziehen. DOCUMENTATION_URL= sollte sich auf die Hauptdokumentationsseite fur dieses Betriebssystem beziehen. SUPPORT_URL= sollte sich auf die Hauptseite fur Unterstutzung fur das Betriebssystem beziehen, falls es eine solche gibt. Dies ist hauptsachlich fur Anbieter, die Unterstutzung dafur bereitstellen. BUG_REPORT_URL= sollte sich auf die Hauptseite fur die Fehlerdatenbank fur das Betriebssystem beziehen, falls es eine solche gibt. Dies ist hauptsachlich fur Betriebssysteme gedacht, die sich auf Qualitatssicherung der Gemeinschaft verlassen. PRIVACY_POLICY_URL= sollte sich auf die Hauptseite der Datenschutzrichtlinie fur das Betriebssystem beziehen, falls es eine solche gibt. Diese Einstellungen sind optional und es ist typisch, das nur ein Teil dieser Einstellungen bereitgestellt werden. Diese URLs sind fur die Angabe in Oberflachen >>Uber dieses System<< gedacht, unter Links mit den Uberschriften >>Uber dieses Betriebssystem<<, >>Hilfe erhalten<<, >>Einen Fehler berichten<< oder >>Datenschutzrichtlinie<<. Diese Werte sollten im RFC3986-Format[5] sein und sollten >>http:<<- oder >>https:<<-URLs und moglicherweise >>mailto:<< oder >>tel:<< sein. Fur jede Einstellung darf nur eine URL aufgelistet werden. Falls mehrere Ressourcen referenziert werden mussen, wird empfohlen, eine Online-Anlaufstelle bereitzustellen, auf der alle verfugbaren Ressourcen verlinkt sind. Beispiele: >>HOME_URL="https://fedoraproject.org/"<<, >>BUG_REPORT_URL="https://bugzilla.redhat.com/"<<. SUPPORT_END= Das Datum, an dem die Unterstutzung fur diese Version des Betriebssystems endet. (Was genau >>Ende der Unterstutzung<< bedeutet hangt vom Lieferanten ab, aber im Allgemeinen sollten Benutzer davon ausgehen, dass Aktualisierungen, einschliesslich Sicherheitskorrekturen, nicht bereitgestellt werden.) Der Wert ist ein Datum im ISO-8601-Format >>YYYY-MM-DD<< und gibt den ersten Tag an, den dem die Unterstutzung nicht bereitgestellt wird. Beispielsweise bedeutet >>SUPPORT_END=2001-01-01<<, dass das System bis zum letzten Tag des letzten Jahrtausends unterstutzt wurde. Hinzugefugt in Version 252. LOGO= Eine Zeichenkette, die den Namen eines Icons wie er in der Freedesktop.org-Icon-Thema-Spezifikation[6] definiert ist, angibt. Dies kann von graphischen Anwendungen zur Darstellung eines Logos des Betriebssystems oder des Distributors verwandt werden. Dieses Feld ist optional und muss nicht notwendigerweise auf allen Systemen implementiert sein. Beispiele: >>LOGO=fedora-logo<<, >>LOGO=distributor-logo-opensuse<< Hinzugefugt in Version 240. ANSI_COLOR= Eine vorgeschlagene Farbe zur Darstellung des Betriebssystemnamens auf der Konsole. Dies sollte als Zeichenkette angegeben werden, die zur Einbindung in den >>ESC [ m ANSI/ECMA-48<<-Maskierungscode zum Setzen der graphischen Bildwiedergabe geeignet ist. Dieses Feld ist optional. Beispiele: >>ANSI_COLOR="0;31"<< fur rot, >>ANSI_COLOR="1;34"<< fur helles blau oder >>ANSI_COLOR="0;38;2;60;110;180"<< fur Fedora-blau. VENDOR_NAME= Der Name des Betriebssystemlieferanten. Dies ist der Name der Organisation oder der Firma, die das Betriebssystem erstellt. Dieses Feld ist optional. Dieser Name ist dazu gedacht, in graphischen Oberflachen in >>Uber dieses System<< oder in Software-Aktualisierungs-Oberflachen bei Bedarf offengelegt zu werden, um den Betriebssystemlieferanten von dem Betriebssystem selbst zu unterscheiden. Er sollte menschenlesbar sein. Beispiele: >>VENDOR_NAME="Fedora Project"<< fur Fedora Linux, >>VENDOR_NAME="Canonical"<< fur Ubuntu. Hinzugefugt in Version 254. VENDOR_URL= Die Homepage des Betriebssystemlieferanten. Dieses Feld ist optional. Das Feld VENDOR_NAME= sollte gesetzt sein, wenn dieses gesetzt ist, allerdings sollten Clients damit umgehen konnen, dass jedes von beiden fehlen konnte. Der Wert sollte im RFC3986-Format[5] und eine >>http:<<- oder >>https:<<-URL sein. Nur eine URL darf in dieser Einstellung aufgefuhrt sein. Beispiele: >>VENDOR_URL="https://fedoraproject.org/"<<, >>VENDOR_URL="https://canonical.com/"<<. Hinzugefugt in Version 254. Vorgaben und Metadaten auf Distributionsebene DEFAULT_HOSTNAME= Eine Zeichenkette, die den Rechnernamen festlegt, falls hostname(5) nicht vorhanden ist und keine weitere Konfigurationsquelle den Rechnernamen festlegt. Muss entweder ein freistehender DNS-Kennzeichner sein (eine Zeichenkette, die aus 7-Bit-ASCII-Zeichen in Kleinschreibung besteht und keine Leerzeichen und Punkte enthalt, begrenzt auf das Format, das fur DNS-Domain-Namen erlaubt ist), oder eine Abfolge solcher Kennzeichner, getrennt durch einzelne Punkte, die einen gultigen DNS FQDN bildet. Der Rechnername darf hochstens 64 Zeichen lang sein, was eine Linux-Begrenzung ist (DNS erlaubt langere Namen). Siehe org.freedesktop.hostname1(5) fur eine Beschreibung, wie systemd-hostnamed.service(8) den Ruckfall-Rechnernamen bestimmt. Hinzugefugt in Version 248. ARCHITECTURE= Eine Zeichenekette, die die CPU-Architektur angibt, die die Programme des Anwendungsraums benotigen. Die Architekturkennzeichner sind identisch zu den in systemd.unit(5) beschriebenen fur ConditionArchitecture=. Das Feld ist optional und sollte nur verwandt werden, wenn nur eine einzelne Architektur unterstutzt wird. Sie konnte redundante Informationen bereitstellen, wenn sie in einer GTP-Partition mit einem GUID-Typ verwandt wird, der bereits die Architektur kodiert. Falls dies nicht der Fall ist, sollte die Architektur z.B. in einem Erweiterungsabbild festgelegt werden, um zu verhindern, dass ein inkompatibler Rechner sie ladt. Hinzugefugt in Version 252. SYSEXT_LEVEL= Eine Zeichenkette in Kleinbuchstaben (keine Leerzeichen oder andere Zeichen ausserhalb von 09, az, >>.<<, >>_<< und >>-<<), die die Unterstutzungsstufe fur Betriebssystemerweiterungen festlegt, um anzuzeigen, welche Erweiterungs-Abbilder unterstutzt werden. Siehe /usr/lib/extension-release.d/extension-release.ABBILD, initrd[2] und systemd-sysext(8) fur weitere Informationen. Beispiele: >>SYSEXT_LEVEL=2<<, >>SYSEXT_LEVEL=15.14<<. Hinzugefugt in Version 248. CONFEXT_LEVEL= Semantisch zu SYSEXT_LEVEL= identisch, aber fur Confext-Abbilder. Siehe /etc/extension-release.d/extension-release.ABBILD fur weitere Informationen. Beispiele: >>CONFEXT_LEVEL=2<<, >>CONFEXT_LEVEL=15.14<<. Hinzugefugt in Version 254. SYSEXT_SCOPE= Akzeptiert eine Leerzeichen-getrennte Liste von einem oder mehreren Zeichenketten >>system<<, >>initrd<< und >>portable<<. Dieses Feld wird nur in extension-release.d/-Dateien unterstutzt und zeigt an, auf welche Umgebungen die Systemerweiterung anwendbar ist: d.h. regulare Systeme, fur Initrd oder fur portierbare Diensteabbilder. Falls nicht festgelegt, wird >>SYSEXT_SCOPE=system portable<< impliziert, d.h. jede Systemerweiterung ohne dieses Feld ist auf regulare Systeme und portierbare Diensteumgebungen anwendbar, aber nicht auf Initrd-Umgebungen. Hinzugefugt in Version 250. CONFEXT_SCOPE= Semantisch zu SYSEXT_SCOPE= identisch, aber fur Confext-Abbilder. Hinzugefugt in Version 254. PORTABLE_PREFIXES= Akzeptiert eine Leerzeichen-getrennte Liste von einem oder mehreren Prafix-Ubereinstimmungszeichenketten fur die Logik der Portierbaren Dienste[3]. Dieses Feld dient zwei Zwecken: Es informiert, kennzeichnet portierbare Diensteabbilder als solche (und ermoglicht damit, dass sie von anderen Betriebssystemabbildern unterschieden werden konnen, wie bootbaren Systemabbildern). Es wird auch verwandt, wenn ein portierbares Diensteabbild angehangt wird: das festgelegte oder implizierte portierbare Diensteprafx wird gegen die hier festgelegte Liste gepruft, um Beschrankungen, wie Abbilder an das System angehangt werden durfen, durchzusetzen. Hinzugefugt in Version 250. Hinweise Falls Sie diese Datei verwenden, um das Betriebssystem oder eine bestimmte Version davon zu ermitteln, benutzen Sie die Felder ID und VERSION_ID, moglicherweise mit ID_LIKE als Ruckfallwert. Wenn Sie nach einer Betriebssystemkennungszeichenkette fur die Darstellung beim Benutzer suchen, verwenden Sie das Feld PRETTY_NAME. Beachten Sie, dass Betriebssystemanbieter sich entscheiden konnten, keine Versionsinformationen zu liefern, beispielsweise um rollende Veroffentlichungen (>>rolling releases<<) zu berucksichtigen. In diesen Fallen konnen VERSION und VERSION_ID ungesetzt sein. Anwendungen sollte sich nicht darauf verlassen, dass diese Felder gesetzt sind. Betriebssystemanbieter konnen das Dateiformat erweitern und neue Felder einfuhren. Es wird nachdrucklich empfohlen, neuen Feldern einen betriebssystemspezifischen Namen voranzustellen, um Namenskollisionen zu vermeiden. Anwendungen, die diese Datei lesen, mussen unbekannte Felder ignorieren. Beispiel: >>DEBIAN_BTS="debbugs://bugs.debian.org/"<<. Verwalter von Containern und Sandbox-Laufzeitumgebungen konnen die Identifizierungsdaten des Rechners Anwendungen zur Verfugung stellen, indem sie die Datei /etc/os-release (falls verfugbar, andernfalls /usr/lib/os-release als Ruckfalloptione) als /run/host/os-release bereitstellen. BEISPIELE Beispiel 1. Datei os-release fur 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 fur eine Erweiterung fur 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 "Ausfuhrung 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'Ausfuhrung 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 fur platform.freedesktop_os_release[7] fur 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}: ungultige Zeile {line!r}', file=sys.stderr) os_release = dict(read_os_release()) pretty_name = os_release.get('PRETTY_NAME', 'Linux') print(f'Ausfuhrung 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 Fallen bevorzugt wird, und dass die hier bereitgestellte offen kodierte Version als Referenz dient. SIEHE AUCH systemd(1), lsb_release(1), hostname(5), machine-id(5), machine-info(5) ANMERKUNGEN 1. Ankundigung von /etc/os-release https://0pointer.de/blog/projects/os-release 2. initrd https://docs.kernel.org/admin-guide/initrd.html 3. Portable Dienste https://systemd.io/PORTABLE_SERVICES 4. Gemeinsame Plattform-Aufzahlungs-Spezifikation http://scap.nist.gov/specifications/cpe/ 5. RFC-3986-Format https://tools.ietf.org/html/rfc3986 6. freedesktop.org-Icon-Thema-Spezifikation https://standards.freedesktop.org/icon-theme-spec/latest 7. platform.freedesktop_os_release https://docs.python.org/3/library/platform.html#platform.freedesktop_os_release UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 OS-RELEASE(5)