file-hierarchy - Dateisystemhierarchie-Überblick
Betriebssysteme, die das System und den Diensteverwalter von
systemd(1) verwenden, sind auf einer von UNIX inspirierten und auf
diesem basierenden Dateisystemhierarchie organisiert, genauer der in der
Spezifikation Dateisystem-Hierarchie[1] und hier(7) mit
verschiedenen Erweiterungen, teilweise in der
XDG-Basisverzeichnisspezifikation[2] und
XDG-Benutzerverzeichnisse[3] dokumentiert, festgelegten. Diese
Handbuchseite beschreibt die verallgemeinerte, allerdings minimale und
modernisierte Untermenge dieser Spezifikationen, die die Vorschläge
und Begrenzungen, die Systemd in Bezug auf die Dateisystemhierarchie macht,
genauer definiert.
Viele der hier beschriebenen Pfade können mit dem Werkzeug
systemd-path(1) abgefragt werden.
/
Die Wurzel des Dateisystems. Normalerweise schreibbar,
aber dies wird nicht benötigt. Möglicherweise ein
temporäres Dateisystem (»tmpfs«). Wird nicht mit anderen
Rechnern gemeinsam benutzt (außer nur-lesbar).
Hinzugefügt in Version 215.
/boot/
Die Systemstartpartition, wird zum Hochfahren des Systems
verwandt. Auf EFI-Systemen ist dies möglicherweise die
EFI-Systempartition (ESP), siehe auch
systemd-gpt-auto-generator(8).
Dieses Verzeichnis ist normalerweise streng an den lokalen Rechner gebunden
und sollte als nur lesbar betrachtet werden, außer wenn ein neuer
Kernel oder ein neues Systemstartprogramm installiert wird. Dieses Verzeichnis
existiert nur auf Systemen, die auf physischer oder emulierter Hardware
laufen, die Systemstartprogramme benötigen.
Hinzugefügt in Version 215.
/efi/
Falls die Systemstartpartition /boot/ separat von der
EFI-Systempartition (ESP), wird letztere hier eingehängt. Werkzeuge,
die mit der EFI-Systempartition arbeiten müssen, sollten hier zuerst
unter diesem Einhängepunkt schauen, und dann auf /boot/
zurückfallen, falls ersterer nicht geeignet ist (falls es
beispielsweise kein Einhängepunkt ist oder nicht den korrekten
Dateisystemtyp
MSDOS_SUPER_MAGIC hat).
Hinzugefügt in Version 239.
/etc/
Systemspezifische Konfiguration. Dieses Verzeichs kann,
muss aber nicht nur lesbar sein. Häufig wird dieses System vorab mit
vom Lieferanten bereitgestellten Konfigurationsdateien befüllt, aber
Anwendungen sollten keine Annahmen darüber treffen, ob dieses
Verzeichnis voll oder überhaupt befüllt ist, und sollten auf
Vorgaben zurückfallen, falls die Konfiguration fehlt.
Hinzugefügt in Version 215.
/home/
Der Ort für die Home-Verzeichnisse der normalen
Benutzer. Möglicherweise von mehreren Systemen gemeinsam benutzt und
niemals nur lesbar. Dieses Verzeichnis sollte nur für normale Benutzer
verwandt werden, niemals für Systembenutzer. Dieses Verzeichnis und
möglicherweise die darin enthaltenen Verzeichnisse könnten erst
spät im Systemstartprozess oder sogar erst nach der Benutzeranmeldung
verfügbar werden. Dieses Verzeichnis kann auf Netzwerkdateisystemen mit
eingeschränkter Funktionalität abgelegt werden, daher sollten
Anwendungen nicht davon ausgehen, dass die komplette Menge der Datei-APIs
für dieses Verzeichnis verfügbar ist. Anwendungen sollten im
Allgemeinen dieses Verzeichnis nicht direkt referenzieren, sondern über
die pro Benutzer gültige Umgebungsvariable
$HOME oder
über das Home-Verzeichnisfeld der Benutzerdatenbank.
Hinzugefügt in Version 215.
/root/
Das Home-Verzeichnis des Benutzers root. Das
Home-Verzeichnis des Benutzers root liegt außerhalb von /home/, um
sicherzustellen, dass der Benutzer root sich selbst dann anmelden kann, wenn
/home/ nicht verfügbar und eingehängt ist.
Hinzugefügt in Version 215.
/srv/
Der Ort, an dem allgemeine Server-Nutzdaten gespeichert
werden, verwaltet vom Administrator. Es gibt keine Einschränkungen, wie
dieses Verzeichnis intern organisiert wird. Im Allgemeinen schreibbar und
möglicherweise von mehreren Systemen gemeinsam genutzt. Dieses
Verzeichnis könnte erst spät während des Systemstarts
verfügbar oder schreibbar werden.
Hinzugefügt in Version 215.
/tmp/
Der Ort für kleine, temporäre Dateien.
Dieses Verzeichnis wird normalerweise als »tmpfs«-Instanz
eingehängt und sollte daher nicht für größere
Dateien verwandt werden. (Verwenden Sie /var/tmp/ für
größere Dateien.) Dieses Verzeichnis wird normalerweise beim
Systemstart geleert. Es können auch Dateien, auf die innerhalb einer
bestimmten Zeit nicht zugegriffen wurde, automatisch gelöscht werden.
Falls Anwendungen die gesetzte Umgebungsvariable $TMPDIR
finden, sollten Sie das darin festgelegte Verzeichnis statt /tmp/ verwenden
(siehe environ(7) und IEEE Std 1003.1[4] für
Details).
Da auf /tmp/ von anderen Benutzern des Systems aus zugegriffen
werden kann, ist es wesentlich, dass Dateien und Unterverzeichnisse unter
diesem Verzeichnis nur mit mkstemp(3), mkdtemp(3) und
ähnlichen Aufrufen erstellt werden. Für weitere Details siehe
Sichere Verwendung von /tmp/ und /var/tmp/[5].
Hinzugefügt in Version 215.
/run/
Ein Dateisystem »tmpfs«, in das
Systempakete Laufzeitdaten,Socket-Dateien und ähnliches ablegen
können. Dieses Verzeichnis wird beim Systemstart bereinigt und ist im
Allgemeinen nur für privilegierte Programme schreibbar. Immer
schreibbar.
Hinzugefügt in Version 215.
/run/log/
Laufzeitsystemprotokolle. Systemkomponenten können
private Protokolle in diesem Verzeichnis ablegen. Immer schreibbar, selbst
wenn /var/log/ noch nicht zugreifbar sein sollte.
Hinzugefügt in Version 215.
/run/user/
Enthält benutzerbezogene Laufzeitverzeichnisse,
jede normalerweise individuell als Instanz »tmpfs«
eingehängt. Immer schreibbar, wird bei jedem Systemstart und wenn sich
der Benutzer abmeldet bereinigt. Benutzer-Code sollte dieses Verzeichnis nicht
direkt sondern mittels der Umgebungsvariablen
$XDG_RUNTIME_DIR
referenzieren, wie dies in der
XDG-Basisverzeichnisspezifikation[2]
dokumentiert ist.
Hinzugefügt in Version 215.
/usr/
Vom Lieferanten bereitgestellte Betriebssystemressourcen.
Normalerweise nur lesbar, aber dies ist nicht zwingend. Möglicherweise
von mehreren Rechnern gemeinsam benutzt. Dieses Verzeichnis sollte vom
Administrator nicht verändert werden, außer bei der Installation
oder Entfernung von Paketen, die vom Lieferanten bereitgestellt wurden.
Hinzugefügt in Version 215.
/usr/bin/
Ausführbare und Binärprogramme für
Benutzerbefehle, die im Suchpfad
$PATH auftauchen sollen. Es wird
empfohlen, in diese Verzeichnisse nur Programme abzulegen, die sinnvollerweise
aus einer Shell aufgrufen werden können (z.B. keine Daemon-Programme);
andere Programme sollten stattdessen in Unterverzeichnissen von /usr/lib/
abgelegt werden.
Hinzugefügt in Version 215.
/usr/include/
C- und C++-API-Header-Dateien von Systembibliotheken.
Hinzugefügt in Version 215.
/usr/lib/
Statische, private Daten des Lieferanten, die zu allen
Architekturen kompatibel sind (aber nicht notwendigerweise
architekturunabhängig). Beachten Sie, dass dies interne Programme oder
andere Programme, die nicht typischerweise von der Shell aus aufgerufen
werden, beinhaltet. Solche Programme können für jede vom System
unterstützte Architektur sein. Legen Sie in dieses Verzeichnis keine
öffentlichen Bibliotheken, verwenden Sie stattdessen
$libdir
(siehe unten).
Hinzugefügt in Version 215.
/usr/lib/Arch-Kennung/
Ort zur Ablage dynamischer Bibliotheken, auch
$libdir benannt. Die zu verwendende Architekturkennung ist in der Liste
Multiarch-Architekturkennungen (Tupel)[6] definiert. Veraltete Orte
für
$libdir sind /usr/lib/, /usr/lib64/. Dieses Verzeichnis
sollte nicht für paketspezifische Daten verwandt werden, außer
diese Daten sind auch architekturabhängig. Um
$libdir
bezüglich der primären Architektur des Systems abzufragen, rufen
Sie Folgendes auf:
# systemd-path system-library-arch
Hinzugefügt in Version 215.
/usr/share/
Von mehreren Paketen gemeinsam benutzte Ressourcen, wie
Dokumentation, Handbuchseiten, Zeitzoneninformationen, Schriften und andere
Ressourcen. Normalerweise unterliegt der genaue Ort und das Format der
unterhalb dieses Verzeichnisses gespeicherten Dateien Vorgaben, die die
Interoperabilität sicherstellen.
Hinzugefügt in Version 215.
/usr/share/doc/
Dokumentation für das Betriebssystem oder
Systempakete.
Hinzugefügt in Version 215.
/usr/share/factory/etc/
Depot für durch Lieferanten bereitgestellte
Vorgabekonfigurationsdateien. Dieses Verzeichnis sollte mit
unverfälschten Versionen sämtlicher vom Lieferanten
bereitgestellten Konfigurationsdateien, die in /etc/ abgelegt werden
könnten, bestückt werden. Dies ist nützlich, um die
lokale Konfiguration eines Systems mit den Vorgaben des Lieferanten zu
vergleichen und die lokalen Konfigurationen mit den Vorgaben zu
bestücken.
Hinzugefügt in Version 215.
/usr/share/factory/var/
Ähnlich /usr/share/factory/etc/, aber für
Lieferantenversionen von Dateien in dem variablen, dauerhaften
Datenverzeichnis /var/.
Hinzugefügt in Version 215.
/var/
Dauerhafte, variable Systemdaten. Während des
normalen Betriebs des Systems beschreibbar. Dieses Verzeichnis kann mit vom
Lieferanten bereitgestellten Daten vorbestückt sein, aber Anwendungen
sollten in der Lage sein, notwendige Dateien und Verzeichnisse in dieser
Unterhierarchie wieder herzustellen, falls sie fehlen, da das System
hochfahren könnte, ohne dass dieses Verzeichnis bestückt ist.
Dauerhaftigkeit wird empfohlen, ist aber optional, um kurzlebige Systeme zu
unterstützen. Dieses Verzeichnis könnte erst spät beim
Systemstart verfügbar oder schreibbar werden. Komponenten, die
für den Betrieb während der frühen Systemstartphase
benötigt werden, dürfen daher nicht bedingungslos von diesem
Verzeichnis abhängen.
Hinzugefügt in Version 215.
/var/cache/
Dauerhafte Systemzwischenspeicherdaten. Systemkomponenten
können entbehrliche Daten in dieses Verzeichnis ablegen. Entleerung
dieses Verzeichnisses sollte keine Auswirkung auf den Betrieb von Programmen
haben, außer für erhöhte Laufzeit, notwendig, um diese
Zwischenspeicher neu aufzubauen.
Hinzugefügt in Version 215.
/var/lib/
Dauerhafte Systemdaten. Systemkomponenten können
private Daten in dieses Verzeichnis ablegen.
Hinzugefügt in Version 215.
/var/log/
Dauerhafte Systemprotokolle. Systemkomponenten
können private Protokolle in dieses Verzeichnis ablegen, allerdings
wird empfohlen, den Großteil der Protokollierung über Aufrufe
von
syslog(3) und
sd_journal_print(3) durchzuführen.
Hinzugefügt in Version 215.
/var/spool/
Dauerhafte System-Spool-Daten, wie Drucker- oder
E-Mail-Warteschlangen.
Hinzugefügt in Version 215.
/var/tmp/
Der Ort für größere und dauerhafte
temporäre Dateien. Im Gegensatz zu /tmp/ wird in dieses Verzeichnis
normalerweise ein dauerhaftes physisches Dateisystem eingehängt und
kann größere Dateien akzeptieren. (Verwenden Sie /tmp für
kleinere, kurzlebigere Dateien.) Dieses Verzeichnis wird typischerweise beim
Systemstart nicht bereinigt, aber zeitbasiertes Aufräumen von Dateien,
auf die in einer bestimmten Zeit nicht zugegriffen wurde, wird
durchgeführt.
Falls Anwendungen erkennen, dass die Variable $TMPDIR
gesetzt ist, sollten sie das darin festgelegte Verzeichnis gegenüber
Referenzen auf /var/tmp bevorzugen (siehe environ(7) für
Details).
Es gelten die gleichen Sicherheitseinschränkungen wie bei
/tmp: mkstemp(3), mkdtemp(3) und ähnliche Aufrufe
sollten verwandt werden. Für weitere Details über dieses
Verzeichnis, siehe Sichere Verwendung von /tmp und /var/tmp[5].
Hinzugefügt in Version 215.
/dev/
Das Wurzelverzeichnis für Geräteknoten.
Normalerweise wird dieses Verzeichnis als »devtmpfs«-Instanz
eingehängt, in Sandbox-/Container-Installationen kann es aber ein
anderer Typ sein. Dieses Verzeichnis wird gemeinsam vom Kernel und
systemd-udevd(8) verwaltet und andere Komponenten sollten nicht darein
schreiben. Eine Reihe von virtuellen Dateisystemen für spezielle Zwecke
könnten unterhalb dieses Verzeichnisses eingehängt sein.
Hinzugefügt in Version 215.
/dev/shm/
Platz für gemeinsame Speichersegmente
gemäß POSIX, wie sie von
shm_open(3) erstellt werden.
Dieses Verzeichnis wird beim Systemstart entleert und ist ein
»tmpfs«-Dateisystem. Da alle Benutzer in diesem Verzeichnis
Schreibrechte haben, sollte besondere Vorsicht walten gelassen werden, um
Namenskollisionen und Verwundbarkeiten zu vermeiden. Für normale
Benutzer werden gemeinsam benutzte Speichersegmente in diesem Verzeichnis
normalerweise gelöscht, wenn sich der Benutzer abmeldet. Normalerweise
ist es daher eine bessere Idee, Speicher-gemappte Dateien in /run/ (für
Systemprogramme) oder in
$XDG_RUNTIME_DIR (für
Benutzerprogramme) statt gemeinsamen Speichersegementen gemäß
POSIX zu verwenden, da diese Verzeichnisse nicht für das gesamte System
schreibbar und daher nicht für Sicherheits-sensible Namenskollisionen
verwundbar sind.
Hinzugefügt in Version 215.
/proc/
Ein virtuelles Kerneldateisystem, das die Prozesslisten
und andere Funktionalitäten offenlegt. Dieses Dateisystem ist
hauptsächlich ein API als Schnittstelle für den Kernel und kein
Ort, an dem normale Dateien gespeichert werden dürfen. Für
Details siehe
proc(5). Eine Reihe von virtuellen Dateisystemen
für spezielle Zwecke könnten unterhalb dieses Verzeichnisses
eingehängt sein.
Hinzugefügt in Version 215.
/proc/sys/
Eine Hierarchie unter /proc/, die eine Reihe von
Kerneleinstellern offenlegt. Die primäre Art, die Einstellungen in
diesem API-Dateibaum zu konfigurieren, ist mittels
sysctl.d(5)-Dateien.
In Sandbox-/Container-Umgebungen ist dieses Verzeichnis im Allgemeinen nur
lesbar eingehängt.
Hinzugefügt in Version 215.
/sys/
Ein virtuelles Kerneldateisystem, das entdeckte
Geräte und andere Funktionalitäten offenlegt. Dieses Dateisystem
ist hauptsächlich ein API, um an den Kernel zu koppeln und kein Ort, an
dem normale Dateien gespeichert werden dürfen. In
Sandbox-/Container-Umgebungen ist dieses Verzeichnis im Allgemeinen nur lesbar
eingehängt. Eine Reihe von virtuellen Dateisystemen für
spezielle Zwecke könnten unterhalb dieses Verzeichnisses
eingehängt sein.
Hinzugefügt in Version 215.
/sys/fs/cgroup/
Ein virtuelles Kerneldateisystem, das die
Prozess-Control-Gruppen (Cgroups) offenlegt. Dieses Dateisystem ist eine API
zu Schnittstellen im Kernel und kein Ort, an dem normale Dateien gespeichert
werden dürfen. Auf aktuellen Systemen, die im Standardmodus
»vereinigt« laufen, dient dieses Verzeichnis als der
Einhängepunkt für das »cgroup2«-Dateisystem, das
eine vereinigte Ggroup-Hierarchie für alle Ressourcen-Controller
bereitstellt. Auf Systemen, die nicht-Standard-Konfigurationen verwenden, darf
dieses Verzeichniss stattdessen ein Tmpfs-Dateisystem sein, das die
Einhängepunkte für die verschiedenen »cgroup«-
(v1-)-Ressourcen-Controller enthält; in diesen Konfigurationen wird
»cgroup2« (falls überhaupt) unter /sys/fs/cgroup/unified/
eingehängt, aber an Cgroup2 werden keine Ressourcen-Controller
angehängt. In Sandbox- oder Container-Installationen kann dieses
Verzeichnis entweder nicht existieren oder darf eine Untermenge der
Funktionalität enthalten.
Hinzugefügt in Version 251.
/bin/, /sbin/, /usr/sbin/
Diese Kompatibilitätssymlinks zeigen auf /usr/bin/
und stellen sicher, dass Skripte und Programme, die diese veralteten Pfade
referenzieren, korrekt ihre Programme finden.
Hinzugefügt in Version 215.
/lib/
Diese Kompatibilitätssymlinks zeigen auf /usr/lib/
und stellen sicher, dass Programme, die diesen veralteten Pfad referenzieren,
korrekt ihre Ressourcen finden.
Hinzugefügt in Version 215.
/lib64/
Auf einigen Architektur-ABIs zeigt dieser
Kompatibilitätssymlink auf
$libdir, um sicherzustellen, dass
Programme, die diesen veralteten Pfad referenzieren, korrekt ihre dynamischen
Lader finden. Dieser Symlink existiert nur auf Architekturen, deren ABI den
dynamischen Lader in diesem Pfad ablegt.
Hinzugefügt in Version 215.
/var/run/
Dieser Kompatibilitätssymlink zeigt auf /run/, um
sicherzustellen, dass Programme, die diesen veralteten Pfad referenzieren,
korrekt ihre Laufzeitdaten finden.
Hinzugefügt in Version 215.
Benutzeranwendungen könnten Dateien und Verzeichnisse in
dem Home-Verzeichnis des Benutzers ablegen wollen. Dies sollte der folgenden
grundlegenden Struktur folgen. Hinweis: Einige dieser Verzeichnisse sind
auch durch die XDG-Basisverzeichnisspezifikation[2] standardisiert
(allerdings schwächer). Zusätzliche Orte für abstrakte
Benutzerressourcen werden durch xdg-user-dirs[3] definiert.
~/.cache/
Dauerhafte Benutzerzwischenspeicherdaten.
Benutzerprogramme können entbehrliche Daten in dieses Verzeichnis
ablegen. Entleerung dieses Verzeichnisses sollte keine Auswirkung auf den
Betrieb von Programmen haben, außer eine erhöhte Laufzeit,
notwendig, um diese Zwischenspeicher neu aufzubauen. Falls eine Anwendung ein
gesetztes
$XDG_CACHE_HOME findet, sollte es das darin festgelegte
Verzeichnis statt dieses Verzeichnisses verwenden.
Hinzugefügt in Version 215.
~/.config/
Anwendungskonfiguration. Wenn ein neuer Benutzer erstellt
wird, wird dieses Verzeichnis leer sein oder überhaupt nicht
existieren. Anwendungen sollten auf Vorgaben zurückfallen, falls ihre
Konfiguration in diesem Verzeichnis fehlt. Falls eine Anwendung ein gesetztes
$XDG_CONFIG_HOME findet, sollte es das darin festgelegte Verzeichnis
statt dieses Verzeichnisses verwenden.
Hinzugefügt in Version 215.
~/.local/bin/
Programme, die im Suchpfad
$PATH des Benutzers
auftauchen sollen. Es wird empfohlen, in diese Verzeichnisse nur Programme
abzulegen, die sinnvollerweise aus einer Shell aufgerufen werden
können; andere Programme sollten stattdessen in Unterverzeichnissen von
~/.local/lib/ abgelegt werden. Bei der Ablage von architekturabhängigen
Programmen sollte Sie an diesem Platz Vorsicht walten lassen, da diese
problematisch sein könnten, falls das Home-Verzeichnis auf
verschiedenen Rechnern mit verschiedenen Architekturen gemeinsam benutzt wird.
Hinzugefügt in Version 215.
~/.local/lib/
Statische, private Lieferantendaten, die zu allen
Architekturen kompatibel sind.
Hinzugefügt in Version 215.
~/.local/lib/Architekturkennung/
Ort zur Ablage öffentlicher dynamischer
Bibliotheken. Die zu verwendende Architekturkennzeichnung ist in der Liste
Multiarch-Architekturkennungen (Tupel)[6] definiert.
Hinzugefügt in Version 215.
~/.local/share/
Ressourcen, die von mehreren Paketen gemeinsam benutzt
werden, wie Schriften oder Abbildungen. Normalerweise ist der genaue Ort und
das Format der Dateien, die unterhalb dieses Verzeichnisses gespeichert
werden, abhängig von der Spezifikation, die die
Interoperabilität sicherstellt. Falls eine Anwendung ein gesetztes
$XDG_DATA_HOME findet, sollte es das darin festgelegte Verzeichnis
statt dieses Verzeichnisses verwenden.
Hinzugefügt in Version 215.
~/.local/state/
Anwendungszustand. Wenn ein neuer Benutzer erstellt wird,
wird dieses Verzeichnis leer sein oder überhaupt nicht existieren.
Anwendungen sollten auf Vorgaben zurückfallen, falls ihre ihr Zustand
in diesem Verzeichnis fehlt. Falls eine Anwendung ein gesetztes
$XDG_STATE_HOME findet, sollte es das darin festgelegte Verzeichnis
statt dieses Verzeichnisses verwenden.
Hinzugefügt in Version 254.
Nicht privilegierten Prozessen fehlt im Allgemeinen der
Schreibzugriff auf den Großteil der Hierarchie.
Die Ausnahmen für normale Benutzer sind /tmp/, /var/tmp/,
/dev/shm/ sowie das Home-Verzeichnis $HOME (normalerweise unterhalb
von /home/) und das Laufzeitverzeichnis $XDG_RUNTIME_DIR (unterhalb
von /run/user/) des Benutzers, die alle schreibbar sind.
Für nicht privilegierte Systemprozesse sind nur /tmp/,
/var/tmp/ und /dev/shm/ schreibbar. Falls ein nicht privilegierter
Systemprozess ein privates schreibbares Verzeichnis in /var/ oder /run/
benötigt, wird empfohlen, es entweder vor der Abgabe von Privilegien
im Daemon-Code oder es mittels tmpfiles.d(5)-Fragementen
während des Systemstarts oder mittels der Anweisungen
StateDirectory= und RuntimeDirectory= in Dienste-Units (siehe
systemd.unit(5) für Details) zu erzeugen.
/tmp/, /var/tmp/ und /dev/shm/ sollten nosuid und
nodev eingehängt werden, wodurch Dateien mit set-user-id-Modus
und Blockspezialgeräte auf diesen Dateisystemen nicht interpretiert
werden. Im Allgemeinen ist es nicht möglich, sie mit noexec
einzuhängen, da verschiedene Programme diese Verzeichnisse für
dynamisch erstellten oder optimierten Code verwenden und mit diesem Schalter
diese Anwendungsszenarien fehlschlagen würden. Auf
Spezialinstallationen oder Systemen, auf denen sämtliche
installierbare Software bekannt ist und diese Funktionalität nicht
benötigt, ist die Verwendung dieses Schalters möglich. Siehe
die Diskussion von nosuid/nodev/noexec in
mount(8) und PROT_EXEC in mmap(2).
Wie oben angemerkt arbeiten einige Systeme mit
schreibgeschützten /usr- und /etc-Hierarchien, möglicherweise
wird der Schreibzugriff nur während Paket-Upgrades erlaubt. Andere
Teile der Hierarchie werden im Allgemeinen lese- und schreibbar
eingehängt (insbesondere /var und /var/tmp), könnten aber
schreibgeschützt sein, wenn der Kernel die Dateisysteme in Folge
eines Fehlers schreibgeschützt neu einhängt oder wenn das
System schreibgeschützt zu Wiederherstellungszwecken gestartet wird.
Soweit angemessen, sollten Anwendungen darauf vorbereitet sein, ohne
Schreibzugriff zu arbeiten, so dass beispielsweise ein Fehler beim Schreiben
nicht wesentlicher Daten nach /var/cache/ oder ein Fehler beim Erstellen
einer angepassten Protokolldatei unter /var/log nicht dazu führt,
dass die Anwendung nicht läuft.
Das Verzeichnis /run/ ist seit der frühsten
Systemstartphase verfügbar und kann immer beschrieben werden. Es
sollte für alle Laufzeitdaten und -Sockets verwandt werden, so dass
Schreibzugriff auf z.B. /etc oder /var nicht notwendig ist.
Unix-Dateisysteme unterstützen verschiedene Arten von
Dateiknoten, einschließlich regulärer Dateien, Verzeichnisse,
Symlinks, Zeichen- und Blockgeräteknoten, Sockets und FIFOs.
Es wird nachdrücklich empfohlen, dass /dev/ der einzige Ort
ist, unterhalb dessen Geräteknoten abgelegt werden. Ähnlich
sollte /run/ der einzige Ort sein, an dem Sockets und FIFOs abgelegt werden.
Reguläre Dateien, Verzeichnisse und Symlinks können in allen
Verzeichnissen verwandt werden.
Entwickler von Systempaketen sollten strengen Regeln beim Ablegen
eigener Dateien im Dateisystem folgen. Die nachfolgende Tabelle führt
empfohlene Orte für bestimmte, vom Lieferanten bereitgestellte
Dateien auf.
Tabelle 1. Ort für Lieferantendateien aus
Systempaketen
| Verzeichnis |
Zweck |
| /usr/bin/ |
Paketprogramme, die im ausführbaren Suchpfad $PATH
auftauchen sollen, für eine der unterstützten Architekturen,
die zum Betriebssystem kompatibel ist, kompiliert. Es wird nicht
empfohlen, interne Programme oder Programme, die typischerweise nicht von
der Shell aufgerufen werden, wie Daemon-Programme, hier abzulegen. Da
dieses Verzeichnis mit den meisten anderen Paketen des Systems gemeinsam
benutzt wird, sollte besondere Sorgfalt darauf verwandt werden, für
hier abzulegende Dateien eindeutige Namen auszuwählen, die
wahrscheinlich nicht in Konflikt zu den Dateien anderer Pakete
stehen. |
| /usr/lib/Arch-Kennung/ |
Öffentliche dynamische Bibliotheken des Pakets. Wie oben sollten
Sie sorgfältig bei der Verwendung zu generischer Namen sein und
eindeutige Namen für Ihre hier abzulegenden Dateien wählen,
um Namenskonflikte zu vermeiden. |
| /usr/lib/Paket/ |
Private statische Lieferantenressourcen des Pakets,
einschließlich privater Programme und Bibliotheken oder jede andere
Art von rein-lesbaren Lieferantendaten. |
| /usr/lib/Architekturkennung/Paket/ |
Private weitere Lieferantenressourcen des Pakets, die
architekturabhängig sind und nicht von verschiedenen Architekturen
gemeinsam benutzt werden können. Beachten Sie, dass dies im
Allgemeinen keine privaten Programme einschließt, da Programme
einer bestimmten Architektur frei von jeder anderen unterstützten
Systemarchitektur aufgerufen werden können. |
| /usr/include/Paket/ |
Öffentliche C/C++-APIs von öffentlichen dynamischen
Bibliotheken des Pakets. |
Zusätzliche statische Lieferantendateien können in
der Hierarchie /usr/share an die Orte, die durch verschiedene, zutreffende
Spezifikationen festgelegt werden, installiert werden.
Die folgenden Verzeichnisse müssen für durch das
Paket für lokale Konfiguration und zur Laufzeit erstellte Dateien
verwandt werden:
Tabelle 2. Ort für variable Dateien aus
Systempaketen
| Verzeichnis |
Zweck |
| /etc/Paket/ |
Systemspezifische Konfiguration für das Paket. Es wird empfohlen,
standardmäßig sichere Rückfalloptionen zu verwenden,
falls diese Konfiguration fehlt, falls das möglich ist. Alternativ
kann ein tmpfiles.d(5)-Fragment verwandt werden, um die notwendigen
Dateien und Verzeichnisse von /usr/share/factory/ während des
Systemstarts mittels der Anweisungen »L« oder
»C« zu symlinken oder zu kopieren. |
| /run/Pakete/ |
Laufzeitdaten für das Paket. Pakete müssen in der Lage
sein, die notwendigen Unterverzeichnisse in diesem Baum selbst zu
erstellen, da das Verzeichnis beim Systemstart automatisch geleert wird.
Alternativ kann ein tmpfiles.d(5)-Fragment verwandt werden, um die
notwendigen Verzeichnisse während des Systemstarts zu erstellen
oder die Anweisung RuntimeDirectory= von Dienste-Units kann
verwandt werden, um sie beim Hochfahren des Dienstes zu erstellen (siehe
systemd.unit(5) für Details). |
| /run/log/Paket/ |
Laufzeitprotokolldaten für das Paket. Wie oben muss das Paket
sicherstellen, dieses Verzeichnis falls notwendig zu erstellen, da es bei
jedem Systemstart bereinigt wird. |
| /var/cache/Paket/ |
Dauerhafte Zwischenspeicherdaten des Pakets. Falls dieses Verzeichnis
geleert wird, sollte die Anwendung beim nächsten Aufruf korrekt
arbeiten, allerdings möglicherweise verlangsamt, da sie alle
lokalen Zwischenspeicherdateien neu aufbauen muss. Die Anwendung muss in
der Lage sein, dieses Verzeichnis wieder zu erstellen, falls es fehlt und
notwendig ist. Um ein leeres Verzeichnis zu erstellen, kann ein
tmpfiles.d(5)-Fragment oder die Anweisung CacheDirectory=
von Dienste-Units (siehe systemd.unit(5)) verwandt werden. |
| /var/lib/Paket/ |
Dauerhafte private Daten des Pakets. Dies ist der Hauptort, um
dauerhafte Daten abzulegen, die nicht in die anderen aufgeführten
Kategorien fallen. Pakete sollten in der Lage sein, die notwendigen
Unterverzeichnisse in diesem Baum selbst zu erstellen, da das Verzeichnis
beim Systemstart fehlen könnte. Um ein leeres Verzeichnis zu
erstellen, kann ein tmpfiles.d(5)-Fragment oder die Anweisung
CacheDirectory= von Dienste-Units (siehe systemd.unit(5))
verwandt werden. |
| /var/log/Paket/ |
Dauerhafte Protokolldaten des Pakets. Wie oben sollte das Paket
sicherstellen, das Verzeichnis, falls notwendig, möglicherweise
mittels tmpfiles.d(5) oder LogsDirectory= (siehe
systemd.exec(5)) zu erstellen, da es fehlen könnte. |
| /var/spool/Paket/ |
Dauerhafte Spool-/Warteschlangendaten des Pakets. Wie oben sollte das
Paket sicherstellen, das Verzeichnis, falls notwendig, zu erstellen, da es
fehlen könnte. |
Programme, die im Benutzerkontext laufen, sollten strengen Regeln
bei der Ablage ihrer eigenen Dateien im Home-Verzeichnis des Benutzers
folgen. Die nachfolgende Tabelle führt empfohlene Orte im
Home-Verzeichnis für bestimmte Arten von Dateien des Lieferanten auf,
falls die Anwendung im Home-Verzeichnis installiert ist. (Systemweit
installierte Benutzeranwendungen sind von den oben dargestellten Regeln
für Lieferantendateien abgedeckt.)
Tabelle 3. Lieferantenpaketorte unter dem
Home-Verzeichnis des Benutzers
| Verzeichnis |
Zweck |
| ~/.local/bin/ |
Paketprogramme, die im ausführbaren Suchpfad $PATH
auftauchen sollen. Es wird nicht empfohlen, interne Programme oder
Programme, die typischerweise nicht von der Shell aufgerufen werden, wie
Daemon-Programme, hier abzulegen. Da dieses Verzeichnis mit den meisten
anderen Paketen des Systems gemeinsam benutzt wird, sollte besondere
Sorgfalt darauf verwandt werden, für hier abzulegende Dateien
eindeutige Namen auszuwählen, die wahrscheinlich nicht in Konflikt
zu den Dateien anderer Pakete stehen. |
| ~/.local/lib/Architekturkennung/ |
Öffentliche dynamische Bibliotheken des Pakets. Wie oben sollten
Sie sorgfältig bei der Verwendung übermäßig
generischer Namen sein und eindeutige Namen für Ihre hier
abzulegenden Dateien wählen, um Namenskonflikte zu vermeiden. |
| ~/.local/lib/Paket/ |
Private, statische Lieferantenressourcen des Pakets, kompatibel zu allen
Architekturen oder jede Art von rein lesbaren Lieferantendaten. |
| ~/.local/lib/Architekturkennung/Paket/ |
Private andere Lieferantenressourcen des Pakets, die
architekturabhängig sind und nicht auf verschiedenen Architekturen
gemeinsam benutzt werden können. |
Zusätzliche statische Lieferantendateien können in
der Hierarchie ~/.local/share/ abgelegt werden und dabei die im obigen
Abschnitt »Vom Lieferanten bereitgestellte
Betriebssystemressourcen« festgelegten Verzeichnisse spiegeln.
Die folgenden Verzeichnisse müssen für durch das
Paket für benutzerbezogene lokale Konfiguration und zur Laufzeit
erstellte Dateien verwandt werden:
Tabelle 4. Ort für variable Dateien aus
Benutzerpaketen
| Verzeichnis |
Zweck |
| ~/.config/Paket/ |
Benutzerbezogene Konfiguration und Zustand für das Paket. Es wird
verlangt, sichere Rückfallstandardwerte zu verwenden, falls diese
Konfiguration fehlt. |
| $XDG_RUNTIME_DIR/Paket/ |
Benutzerlaufzeitdaten für das Paket. |
| ~/.cache/Paket/ |
Dauerhafte Zwischenspeicherdaten des Pakets. Falls dieses Verzeichnis
geleert wird, sollte die Anwendung beim nächsten Aufruf korrekt
arbeiten, allerdings möglicherweise verlangsamt, da sie alle
lokalen Zwischenspeicherdateien neu aufbauen muss. Die Anwendung muss in
der Lage sein, dieses Verzeichnis wieder zu erstellen, falls es fehlt und
notwendig ist. |
systemd(1), hier(7), systemd-path(1),
systemd-gpt-auto-generator(8), sysctl.d(5),
tmpfiles.d(5), pkg-config(1), systemd.unit(5)
- 1.
- Dateisystem-Hierarchie
http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html
- 2.
- XDG-Basisverzeichnisspezifikation
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
- 3.
- XDG-Benutzerverzeichnisse
https://www.freedesktop.org/wiki/Software/xdg-user-dirs
- 4.
- IEEE Std 1003.1
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03
- 5.
- Sichere Verwendung von /tmp und /var/tmp
https://systemd.io/TEMPORARY_DIRECTORIES
- 6.
- Multiarch-Architekturkennungen (Tupel)
https://wiki.debian.org/Multiarch/Tuples
ÜBERSETZUNG
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.