Provided by: manpages-de_2.16-1_all 
BEZEICHNUNG
file-hierarchy - Dateisystemhierarchie-Überblick
BESCHREIBUNG
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.
ALLGEMEINE STRUKTUR
/
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).
/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.
/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).
/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.
/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.
/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.
/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.
/tmp/
Der Ort für kleine temporäre Dateien. Dieses Verzeichnis wird normalerweise als
Instanz »tmpfs« eingehängt und sollte daher nicht für größere Dateien verwandt werden.
(Verwenden Sie /var/tmp/ für größere Dateien.) Da dieses Verzeichnis für andere
Benutzer des Systems zugreifbar ist, ist es wesentlich, dass in dieses Verzeichnis nur
mit mkstemp(3), mkdtemp(3) und anderen verwandten Aufrufen geschrieben wird. Dieses
Verzeichnis wird typischerweise beim Systemstart bereinigt. Auch werden Dateien, auf
die nicht innerhalb einer bestimmten Zeit zugegriffen wird, normalerweise gelöscht.
Falls Anwendungen erkennen, dass die Variable $TMPDIR gesetzt ist, sollten sie das
darin festgelegte Verzeichnis gegenüber Referenzen auf /tmp/ bevorzugen (siehe
environ(7) und IEEE Std 1003.1[4] für Details). Für weitere Details über dieses
Verzeichnis, siehe /tmp und /var/tmp sicher benutzen[5].
LAUFZEITDATEN
/run/
Ein Dateisystem »tmpfs«, in das Systempakete Laufzeitdaten ablegen können. Dieses
Verzeichnis wird beim Systemstart bereinigt und ist im Allgemeinen nur für
privilegierte Programme schreibbar. Immer schreibbar.
/run/log/
Laufzeitsystemprotokolle. Systemkomponenten können private Protokolle in diesem
Verzeichnis ablegen. Immer schreibbar, selbst wenn /var/log/ noch nicht zugreifbar
sein sollte.
/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.
VOM LIEFERANTEN BEREITGESTELLTE BETRIEBSSYSTEMRESSOURCEN
/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.
/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.
/usr/include/
C- und C++-API-Header-Dateien von Systembibliotheken.
/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).
/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 /lib/, /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
/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.
/usr/share/doc/
Dokumentation für das Betriebssystem oder Systempakete.
/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.
/usr/share/factory/var/
Ähnlich /usr/share/factory/etc/, aber für Lieferantenversionen von Dateien in dem
variablen, dauerhaften Datenverzeichnis /var/.
DAUERHAFTE VARIABLE SYSTEMDATEN
/var/
Dauerhafte, variable Systemdaten. Muss schreibbar sein. 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.
/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.
/var/lib/
Dauerhafte Systemdaten. Systemkomponenten können private Daten in dieses Verzeichnis
ablegen.
/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.
/var/spool/
Dauerhafte System-Spool-Daten, wie Drucker- oder E-Mail-Warteschlangen.
/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 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. Es gelten die gleichen Sicherheitseinschränkungen wie bei /tmp, und
daher sollten nur mkstemp(3), mkdtemp(3) oder ähnliche Aufrufe zur Verwendung dieses
Verzeichnisses eingesetzt werden. 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). Für weitere Details
über dieses Verzeichnis, siehe /tmp und /var/tmp sicher benutzen[5].
VIRTUELLE KERNEL- UND API-DATEISYSTEME
/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.
/dev/shm/
Place for POSIX shared memory segments, as created via shm_open(3). This directory is
flushed on boot, and is a "tmpfs" file system. Since all users have write access to
this directory, special care should be taken to avoid name clashes and
vulnerabilities. For normal users, shared memory segments in this directory are
usually deleted when the user logs out. Usually, it is a better idea to use memory
mapped files in /run/ (for system programs) or $XDG_RUNTIME_DIR (for user programs)
instead of POSIX shared memory segments, since these directories are not
world-writable and hence not vulnerable to security-sensitive name clashes.
/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.
/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.
/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.
KOMPATIBILITÄTS-SYMLINKS
/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.
/lib/
Diese Kompatibilitätssymlinks zeigen auf /lib/ und stellen sicher, dass Programme, die
diesen veralteten Pfad referenzieren, korrekt ihre Ressourcen finden.
/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.
/var/run/
Dieser Kompatibilitätssymlink zeigt auf /run/, um sicherzustellen, dass Programme, die
diesen veralteten Pfad referenzieren, korrekt ihre Laufzeitdaten finden.
HOME-VERZEICHNIS
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.
~/.config/
Anwendungskonfiguration und -zustand. Wenn ein neuer Benutzer erstellt wird, wird
dieses Verzeichnis leer sein oder überhaupt nicht existieren. Anwendungen sollten auf
Vorgaben zurückfallen, falls ihre Konfiguration oder ihr Zustand in diesem Verzeichnis
fehlt. Falls eine Anwendung ein gesetztes $XDG_CONFIG_HOME findet, sollte es das darin
festgelegte Verzeichnis statt dieses Verzeichnisses verwenden.
~/.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.
~/.local/lib/
Statische, private Lieferantendaten, die zu allen Architekturen kompatibel sind.
~/.local/lib/Architekturkennung/
Ort zur Ablage öffentlicher Laufzeitbibliotheken. Die zu verwendende
Architekturkennzeichnung ist in der Liste Multiarch-Architekturkennungen (Tupel)[6]
definiert.
~/.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.
NICHT PRIVILEGIERTER SCHREIBZUGRIFF
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.
KNOTENTYPEN
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.
SYSTEMPAKETE
Entwickler von Systempaketen sollten strengen Regeln beim Ablegen ihrer eigenen 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. │
├───────────────────────────────┼──────────────────────────────────┤
│/lib/Arch-Kennung/ │ Öffentliche Laufzeitbibliotheken │
│ │ 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. │
├───────────────────────────────┼──────────────────────────────────┤
│/lib/Paket/ │ Private statische │
│ │ Lieferantenressourcen des │
│ │ Pakets, einschließlich privater │
│ │ Programme und Bibliotheken oder │
│ │ jede andere Art von │
│ │ rein-lesbaren Lieferantendaten. │
├───────────────────────────────┼──────────────────────────────────┤
│/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 │
│ │ Laufzeitbibliotheken 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.
Während der Laufzeit und für lokale Konfiguration und Zustand sind zusätzliche
Verzeichnisse definiert:
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.unit(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. │
└──────────────────┴──────────────────────────────────┘
BENUTZERPAKETE
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. (Beachten Sie allerdings, dass
Benutzeranwendungen, die systemweit installiert sind, den oben dargelegten Regeln
bezüglich der Ablage der Lieferantendateien folgen sollten.)
Tabelle 3. Ort für Lieferantendateien aus Benutzerpaketen
┌───────────────────────────────────────┬──────────────────────────────────┐
│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 Laufzeitbibliotheken │
│ │ 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. │
├───────────────────────────────────────┼──────────────────────────────────┤
│~/.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/ in den
durch verschiedene relevante Spezifikationen definierten Orten abgelegt werden.
Während der Laufzeit und für lokale Konfiguration und Zustand sind zusätzliche
Verzeichnisse definiert:
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. │
└────────────────────────┴──────────────────────────────────┘
SIEHE AUCH
systemd(1), hier(7), systemd-path(1), systemd-gpt-auto-generator(8), sysctl.d(5),
tmpfiles.d(5), pkg-config(1), systemd.unit(5)
ANMERKUNGEN
1. Dateisystem-Hierarchie
http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html
2. XDG-Basisverzeichnisspezifikation
http://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. /tmp und /var/tmp sicher benutzen
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 <debian-l10n-german@lists.debian.org>.