table of contents
- BEZEICHNUNG
- BESCHREIBUNG
- ALLGEMEINE STRUKTUR
- LAUFZEITDATEN
- VOM LIEFERANTEN BEREITGESTELLTE BETRIEBSSYSTEMRESSOURCEN
- DAUERHAFTE VARIABLE SYSTEMDATEN
- VIRTUELLE KERNEL- UND API-DATEISYSTEME
- KOMPATIBILITÄTS-SYMLINKS
- HOME-VERZEICHNIS
- NICHT PRIVILEGIERTER SCHREIBZUGRIFF
- KNOTENTYPEN
- SYSTEMPAKETE
- BENUTZERPAKETE
- SIEHE AUCH
- ANMERKUNGEN
- ÜBERSETZUNG
| FILE-HIERARCHY(7) | file-hierarchy | FILE-HIERARCHY(7) |
BEZEICHNUNG¶
file-hierarchy - Dateisystemhierarchie-ÜberblickBESCHREIBUNG¶
Betriebssysteme, die das System und den Diensteverwalter von systemd(1) verwenden, sind auf einer von UNIX inspirierten und auf ihr basierenden Dateisystemhierarchie organisiert, genauer der in der Spezifikation Dateisystem-Hierarchie[1] und hier(7) mit verschiedenen Erwetierungen, 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 (»tempfs«). 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
System Partition (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. Die
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).
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 nutzerbezogene 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, privaten 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)[5] 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, bevölkert 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
bevölkern.
/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 dieses Verzeichnis
normalerweise von einem dauerhaften physischen 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).
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, dass die Prozesslisten
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. 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
Kerneleinsteller 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 ermittelte
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 für 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 diesem Verzeichnis 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 diesem Verzeichnis
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 aufgrufen werden können;
andere Programme sollten stattdessen in Unterverzeichnissen von ~/.local/lib/
abgelegt werden. Bei der Ablage von architekturabhängigen Programmen
sollte an diesem Platz Vorsicht walten gelassen werden, 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 mit allen
Architekturen kompatibel sind.
~/.local/lib/Architekturkennung/
Ort zur Ablage öffentlicher Laufzeitbibliotheken.
Die zu verwendende Architekturkennzeichnung ist in der Liste
Multiarch-Architekturkennungen (Tupel)[5] 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 diesem Verzeichnis 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, übersetzt für eine der unterstützten Architekturen, die zum Betriebssystem kompatibel ist. 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 generische Namen sein und eindeutige Dateinamen für Ihre hier abzulegenden Dateinamen 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 privaten 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 diese 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 Ablge 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 generische Namen sein und eindeutige Dateinamen für Ihre hier abzulegenden Dateinamen wählen, um Namenskonflikte zu vermeiden. |
| ~/.local/lib/Paket/ | Private, statische Lieferantenressourcen des Pakets, kompatibel mit allen Architekturen oder jede Art von rein lesbaren Lieferantendaten. |
| ~/.local/lib/Architekturkennung/Paket/ | Private andere Liferantenressourcen 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 die 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
- 2.
- XDG-Basisverzeichnisspezifikation
- 3.
- XDG-Benutzerverzeichnisse
- 4.
- IEEE Std 1003.1
- 5.
- Multiarch-Architekturkennungen (Tupel)
Ü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>.
| systemd 239 |