FILE-HIERARCHY(7) file-hierarchy FILE-HIERARCHY(7) BEZEICHNUNG file-hierarchy - Dateisystemhierarchie-Uberblick 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 Vorschlage und Begrenzungen, die Systemd in Bezug auf die Dateisystemhierarchie macht, genauer definiert. Viele der hier beschriebenen Pfade konnen mit dem Werkzeug systemd-path(1) abgefragt werden. ALLGEMEINE STRUKTUR / Die Wurzel des Dateisystems. Normalerweise schreibbar, aber dies wird nicht benotigt. Moglicherweise ein temporares Dateisystem (>>tmpfs<<). Wird nicht mit anderen Rechnern gemeinsam benutzt (ausser nur-lesbar). Hinzugefugt in Version 215. /boot/ Die Systemstartpartition, wird zum Hochfahren des Systems verwandt. Auf EFI-Systemen ist dies moglicherweise 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, ausser 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 benotigen. Hinzugefugt in Version 215. /efi/ Falls die Systemstartpartition /boot/ separat von der EFI-Systempartition (ESP), wird letztere hier eingehangt. Werkzeuge, die mit der EFI-Systempartition arbeiten mussen, sollten hier zuerst unter diesem Einhangepunkt schauen, und dann auf /boot/ zuruckfallen, falls ersterer nicht geeignet ist (falls es beispielsweise kein Einhangepunkt ist oder nicht den korrekten Dateisystemtyp MSDOS_SUPER_MAGIC hat). Hinzugefugt in Version 239. /etc/ Systemspezifische Konfiguration. Dieses Verzeichs kann, muss aber nicht nur lesbar sein. Haufig wird dieses System vorab mit vom Lieferanten bereitgestellten Konfigurationsdateien befullt, aber Anwendungen sollten keine Annahmen daruber treffen, ob dieses Verzeichnis voll oder uberhaupt befullt ist, und sollten auf Vorgaben zuruckfallen, falls die Konfiguration fehlt. Hinzugefugt in Version 215. /home/ Der Ort fur die Home-Verzeichnisse der normalen Benutzer. Moglicherweise von mehreren Systemen gemeinsam benutzt und niemals nur lesbar. Dieses Verzeichnis sollte nur fur normale Benutzer verwandt werden, niemals fur Systembenutzer. Dieses Verzeichnis und moglicherweise die darin enthaltenen Verzeichnisse konnten erst spat im Systemstartprozess oder sogar erst nach der Benutzeranmeldung verfugbar werden. Dieses Verzeichnis kann auf Netzwerkdateisystemen mit eingeschrankter Funktionalitat abgelegt werden, daher sollten Anwendungen nicht davon ausgehen, dass die komplette Menge der Datei-APIs fur dieses Verzeichnis verfugbar ist. Anwendungen sollten im Allgemeinen dieses Verzeichnis nicht direkt referenzieren, sondern uber die pro Benutzer gultige Umgebungsvariable $HOME oder uber das Home-Verzeichnisfeld der Benutzerdatenbank. Hinzugefugt in Version 215. /root/ Das Home-Verzeichnis des Benutzers root. Das Home-Verzeichnis des Benutzers root liegt ausserhalb von /home/, um sicherzustellen, dass der Benutzer root sich selbst dann anmelden kann, wenn /home/ nicht verfugbar und eingehangt ist. Hinzugefugt in Version 215. /srv/ Der Ort, an dem allgemeine Server-Nutzdaten gespeichert werden, verwaltet vom Administrator. Es gibt keine Einschrankungen, wie dieses Verzeichnis intern organisiert wird. Im Allgemeinen schreibbar und moglicherweise von mehreren Systemen gemeinsam genutzt. Dieses Verzeichnis konnte erst spat wahrend des Systemstarts verfugbar oder schreibbar werden. Hinzugefugt in Version 215. /tmp/ Der Ort fur kleine, temporare Dateien. Dieses Verzeichnis wird normalerweise als >>tmpfs<<-Instanz eingehangt und sollte daher nicht fur grossere Dateien verwandt werden. (Verwenden Sie /var/tmp/ fur grossere Dateien.) Dieses Verzeichnis wird normalerweise beim Systemstart geleert. Es konnen auch Dateien, auf die innerhalb einer bestimmten Zeit nicht zugegriffen wurde, automatisch geloscht 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] fur 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 ahnlichen Aufrufen erstellt werden. Fur weitere Details siehe Sichere Verwendung von /tmp/ und /var/tmp/[5]. Hinzugefugt in Version 215. LAUFZEITDATEN /run/ Ein Dateisystem >>tmpfs<<, in das Systempakete Laufzeitdaten,Socket-Dateien und ahnliches ablegen konnen. Dieses Verzeichnis wird beim Systemstart bereinigt und ist im Allgemeinen nur fur privilegierte Programme schreibbar. Immer schreibbar. Hinzugefugt in Version 215. /run/log/ Laufzeitsystemprotokolle. Systemkomponenten konnen private Protokolle in diesem Verzeichnis ablegen. Immer schreibbar, selbst wenn /var/log/ noch nicht zugreifbar sein sollte. Hinzugefugt in Version 215. /run/user/ Enthalt benutzerbezogene Laufzeitverzeichnisse, jede normalerweise individuell als Instanz >>tmpfs<< eingehangt. 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. Hinzugefugt in Version 215. VOM LIEFERANTEN BEREITGESTELLTE BETRIEBSSYSTEMRESSOURCEN /usr/ Vom Lieferanten bereitgestellte Betriebssystemressourcen. Normalerweise nur lesbar, aber dies ist nicht zwingend. Moglicherweise von mehreren Rechnern gemeinsam benutzt. Dieses Verzeichnis sollte vom Administrator nicht verandert werden, ausser bei der Installation oder Entfernung von Paketen, die vom Lieferanten bereitgestellt wurden. Hinzugefugt in Version 215. /usr/bin/ Ausfuhrbare und Binarprogramme fur Benutzerbefehle, die im Suchpfad $PATH auftauchen sollen. Es wird empfohlen, in diese Verzeichnisse nur Programme abzulegen, die sinnvollerweise aus einer Shell aufgrufen werden konnen (z.B. keine Daemon-Programme); andere Programme sollten stattdessen in Unterverzeichnissen von /usr/lib/ abgelegt werden. Hinzugefugt in Version 215. /usr/include/ C- und C++-API-Header-Dateien von Systembibliotheken. Hinzugefugt in Version 215. /usr/lib/ Statische, private Daten des Lieferanten, die zu allen Architekturen kompatibel sind (aber nicht notwendigerweise architekturunabhangig). Beachten Sie, dass dies interne Programme oder andere Programme, die nicht typischerweise von der Shell aus aufgerufen werden, beinhaltet. Solche Programme konnen fur jede vom System unterstutzte Architektur sein. Legen Sie in dieses Verzeichnis keine offentlichen Bibliotheken, verwenden Sie stattdessen $libdir (siehe unten). Hinzugefugt 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 fur $libdir sind /usr/lib/, /usr/lib64/. Dieses Verzeichnis sollte nicht fur paketspezifische Daten verwandt werden, ausser diese Daten sind auch architekturabhangig. Um $libdir bezuglich der primaren Architektur des Systems abzufragen, rufen Sie Folgendes auf: # systemd-path system-library-arch Hinzugefugt 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 Interoperabilitat sicherstellen. Hinzugefugt in Version 215. /usr/share/doc/ Dokumentation fur das Betriebssystem oder Systempakete. Hinzugefugt in Version 215. /usr/share/factory/etc/ Depot fur durch Lieferanten bereitgestellte Vorgabekonfigurationsdateien. Dieses Verzeichnis sollte mit unverfalschten Versionen samtlicher vom Lieferanten bereitgestellten Konfigurationsdateien, die in /etc/ abgelegt werden konnten, bestuckt werden. Dies ist nutzlich, um die lokale Konfiguration eines Systems mit den Vorgaben des Lieferanten zu vergleichen und die lokalen Konfigurationen mit den Vorgaben zu bestucken. Hinzugefugt in Version 215. /usr/share/factory/var/ Ahnlich /usr/share/factory/etc/, aber fur Lieferantenversionen von Dateien in dem variablen, dauerhaften Datenverzeichnis /var/. Hinzugefugt in Version 215. DAUERHAFTE VARIABLE SYSTEMDATEN /var/ Dauerhafte, variable Systemdaten. Wahrend des normalen Betriebs des Systems beschreibbar. Dieses Verzeichnis kann mit vom Lieferanten bereitgestellten Daten vorbestuckt sein, aber Anwendungen sollten in der Lage sein, notwendige Dateien und Verzeichnisse in dieser Unterhierarchie wieder herzustellen, falls sie fehlen, da das System hochfahren konnte, ohne dass dieses Verzeichnis bestuckt ist. Dauerhaftigkeit wird empfohlen, ist aber optional, um kurzlebige Systeme zu unterstutzen. Dieses Verzeichnis konnte erst spat beim Systemstart verfugbar oder schreibbar werden. Komponenten, die fur den Betrieb wahrend der fruhen Systemstartphase benotigt werden, durfen daher nicht bedingungslos von diesem Verzeichnis abhangen. Hinzugefugt in Version 215. /var/cache/ Dauerhafte Systemzwischenspeicherdaten. Systemkomponenten konnen entbehrliche Daten in dieses Verzeichnis ablegen. Entleerung dieses Verzeichnisses sollte keine Auswirkung auf den Betrieb von Programmen haben, ausser fur erhohte Laufzeit, notwendig, um diese Zwischenspeicher neu aufzubauen. Hinzugefugt in Version 215. /var/lib/ Dauerhafte Systemdaten. Systemkomponenten konnen private Daten in dieses Verzeichnis ablegen. Hinzugefugt in Version 215. /var/log/ Dauerhafte Systemprotokolle. Systemkomponenten konnen private Protokolle in dieses Verzeichnis ablegen, allerdings wird empfohlen, den Grossteil der Protokollierung uber Aufrufe von syslog(3) und sd_journal_print(3) durchzufuhren. Hinzugefugt in Version 215. /var/spool/ Dauerhafte System-Spool-Daten, wie Drucker- oder E-Mail-Warteschlangen. Hinzugefugt in Version 215. /var/tmp/ Der Ort fur grossere und dauerhafte temporare Dateien. Im Gegensatz zu /tmp/ wird in dieses Verzeichnis normalerweise ein dauerhaftes physisches Dateisystem eingehangt und kann grossere Dateien akzeptieren. (Verwenden Sie /tmp fur kleinere, kurzlebigere Dateien.) Dieses Verzeichnis wird typischerweise beim Systemstart nicht bereinigt, aber zeitbasiertes Aufraumen von Dateien, auf die in einer bestimmten Zeit nicht zugegriffen wurde, wird durchgefuhrt. Falls Anwendungen erkennen, dass die Variable $TMPDIR gesetzt ist, sollten sie das darin festgelegte Verzeichnis gegenuber Referenzen auf /var/tmp bevorzugen (siehe environ(7) fur Details). Es gelten die gleichen Sicherheitseinschrankungen wie bei /tmp: mkstemp(3), mkdtemp(3) und ahnliche Aufrufe sollten verwandt werden. Fur weitere Details uber dieses Verzeichnis, siehe Sichere Verwendung von /tmp und /var/tmp[5]. Hinzugefugt in Version 215. VIRTUELLE KERNEL- UND API-DATEISYSTEME /dev/ Das Wurzelverzeichnis fur Gerateknoten. Normalerweise wird dieses Verzeichnis als >>devtmpfs<<-Instanz eingehangt, 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 fur spezielle Zwecke konnten unterhalb dieses Verzeichnisses eingehangt sein. Hinzugefugt in Version 215. /dev/shm/ Platz fur gemeinsame Speichersegmente gemass 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. Fur normale Benutzer werden gemeinsam benutzte Speichersegmente in diesem Verzeichnis normalerweise geloscht, wenn sich der Benutzer abmeldet. Normalerweise ist es daher eine bessere Idee, Speicher-gemappte Dateien in /run/ (fur Systemprogramme) oder in $XDG_RUNTIME_DIR (fur Benutzerprogramme) statt gemeinsamen Speichersegementen gemass POSIX zu verwenden, da diese Verzeichnisse nicht fur das gesamte System schreibbar und daher nicht fur Sicherheits-sensible Namenskollisionen verwundbar sind. Hinzugefugt in Version 215. /proc/ Ein virtuelles Kerneldateisystem, das die Prozesslisten und andere Funktionalitaten offenlegt. Dieses Dateisystem ist hauptsachlich ein API als Schnittstelle fur den Kernel und kein Ort, an dem normale Dateien gespeichert werden durfen. Fur Details siehe proc(5). Eine Reihe von virtuellen Dateisystemen fur spezielle Zwecke konnten unterhalb dieses Verzeichnisses eingehangt sein. Hinzugefugt in Version 215. /proc/sys/ Eine Hierarchie unter /proc/, die eine Reihe von Kerneleinstellern offenlegt. Die primare 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 eingehangt. Hinzugefugt in Version 215. /sys/ Ein virtuelles Kerneldateisystem, das entdeckte Gerate und andere Funktionalitaten offenlegt. Dieses Dateisystem ist hauptsachlich ein API, um an den Kernel zu koppeln und kein Ort, an dem normale Dateien gespeichert werden durfen. In Sandbox-/Container-Umgebungen ist dieses Verzeichnis im Allgemeinen nur lesbar eingehangt. Eine Reihe von virtuellen Dateisystemen fur spezielle Zwecke konnten unterhalb dieses Verzeichnisses eingehangt sein. Hinzugefugt 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 durfen. Auf aktuellen Systemen, die im Standardmodus >>vereinigt<< laufen, dient dieses Verzeichnis als der Einhangepunkt fur das >>cgroup2<<-Dateisystem, das eine vereinigte Ggroup-Hierarchie fur alle Ressourcen-Controller bereitstellt. Auf Systemen, die nicht-Standard-Konfigurationen verwenden, darf dieses Verzeichniss stattdessen ein Tmpfs-Dateisystem sein, das die Einhangepunkte fur die verschiedenen >>cgroup<<- (v1-)-Ressourcen-Controller enthalt; in diesen Konfigurationen wird >>cgroup2<< (falls uberhaupt) unter /sys/fs/cgroup/unified/ eingehangt, aber an Cgroup2 werden keine Ressourcen-Controller angehangt. In Sandbox- oder Container-Installationen kann dieses Verzeichnis entweder nicht existieren oder darf eine Untermenge der Funktionalitat enthalten. Hinzugefugt in Version 251. KOMPATIBILITATS-SYMLINKS /bin/, /sbin/, /usr/sbin/ Diese Kompatibilitatssymlinks zeigen auf /usr/bin/ und stellen sicher, dass Skripte und Programme, die diese veralteten Pfade referenzieren, korrekt ihre Programme finden. Hinzugefugt in Version 215. /lib/ Diese Kompatibilitatssymlinks zeigen auf /usr/lib/ und stellen sicher, dass Programme, die diesen veralteten Pfad referenzieren, korrekt ihre Ressourcen finden. Hinzugefugt in Version 215. /lib64/ Auf einigen Architektur-ABIs zeigt dieser Kompatibilitatssymlink 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. Hinzugefugt in Version 215. /var/run/ Dieser Kompatibilitatssymlink zeigt auf /run/, um sicherzustellen, dass Programme, die diesen veralteten Pfad referenzieren, korrekt ihre Laufzeitdaten finden. Hinzugefugt in Version 215. HOME-VERZEICHNIS Benutzeranwendungen konnten 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 schwacher). Zusatzliche Orte fur abstrakte Benutzerressourcen werden durch xdg-user-dirs[3] definiert. ~/.cache/ Dauerhafte Benutzerzwischenspeicherdaten. Benutzerprogramme konnen entbehrliche Daten in dieses Verzeichnis ablegen. Entleerung dieses Verzeichnisses sollte keine Auswirkung auf den Betrieb von Programmen haben, ausser eine erhohte 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. Hinzugefugt in Version 215. ~/.config/ Anwendungskonfiguration. Wenn ein neuer Benutzer erstellt wird, wird dieses Verzeichnis leer sein oder uberhaupt nicht existieren. Anwendungen sollten auf Vorgaben zuruckfallen, 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. Hinzugefugt 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 konnen; andere Programme sollten stattdessen in Unterverzeichnissen von ~/.local/lib/ abgelegt werden. Bei der Ablage von architekturabhangigen Programmen sollte Sie an diesem Platz Vorsicht walten lassen, da diese problematisch sein konnten, falls das Home-Verzeichnis auf verschiedenen Rechnern mit verschiedenen Architekturen gemeinsam benutzt wird. Hinzugefugt in Version 215. ~/.local/lib/ Statische, private Lieferantendaten, die zu allen Architekturen kompatibel sind. Hinzugefugt in Version 215. ~/.local/lib/Architekturkennung/ Ort zur Ablage offentlicher dynamischer Bibliotheken. Die zu verwendende Architekturkennzeichnung ist in der Liste Multiarch-Architekturkennungen (Tupel)[6] definiert. Hinzugefugt 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, abhangig von der Spezifikation, die die Interoperabilitat sicherstellt. Falls eine Anwendung ein gesetztes $XDG_DATA_HOME findet, sollte es das darin festgelegte Verzeichnis statt dieses Verzeichnisses verwenden. Hinzugefugt in Version 215. ~/.local/state/ Anwendungszustand. Wenn ein neuer Benutzer erstellt wird, wird dieses Verzeichnis leer sein oder uberhaupt nicht existieren. Anwendungen sollten auf Vorgaben zuruckfallen, 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. Hinzugefugt in Version 254. SCHREIBZUGRIFF Nicht privilegierter Schreibzugriff Nicht privilegierten Prozessen fehlt im Allgemeinen der Schreibzugriff auf den Grossteil der Hierarchie. Die Ausnahmen fur 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. Fur 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/ benotigt, wird empfohlen, es entweder vor der Abgabe von Privilegien im Daemon-Code oder es mittels tmpfiles.d(5)-Fragementen wahrend des Systemstarts oder mittels der Anweisungen StateDirectory= und RuntimeDirectory= in Dienste-Units (siehe systemd.unit(5) fur Details) zu erzeugen. /tmp/, /var/tmp/ und /dev/shm/ sollten nosuid und nodev eingehangt werden, wodurch Dateien mit set-user-id-Modus und Blockspezialgerate auf diesen Dateisystemen nicht interpretiert werden. Im Allgemeinen ist es nicht moglich, sie mit noexec einzuhangen, da verschiedene Programme diese Verzeichnisse fur dynamisch erstellten oder optimierten Code verwenden und mit diesem Schalter diese Anwendungsszenarien fehlschlagen wurden. Auf Spezialinstallationen oder Systemen, auf denen samtliche installierbare Software bekannt ist und diese Funktionalitat nicht benotigt, ist die Verwendung dieses Schalters moglich. Siehe die Diskussion von nosuid/nodev/noexec in mount(8) und PROT_EXEC in mmap(2). Fehlen von Schreibzugriff auf schreibgeschutzten Systemen und wahrend der Systemwiederherstellung Wie oben angemerkt arbeiten einige Systeme mit schreibgeschutzten /usr- und /etc-Hierarchien, moglicherweise wird der Schreibzugriff nur wahrend Paket-Upgrades erlaubt. Andere Teile der Hierarchie werden im Allgemeinen lese- und schreibbar eingehangt (insbesondere /var und /var/tmp), konnten aber schreibgeschutzt sein, wenn der Kernel die Dateisysteme in Folge eines Fehlers schreibgeschutzt neu einhangt oder wenn das System schreibgeschutzt 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 fuhrt, dass die Anwendung nicht lauft. Das Verzeichnis /run/ ist seit der fruhsten Systemstartphase verfugbar und kann immer beschrieben werden. Es sollte fur alle Laufzeitdaten und -Sockets verwandt werden, so dass Schreibzugriff auf z.B. /etc oder /var nicht notwendig ist. KNOTENTYPEN Unix-Dateisysteme unterstutzen verschiedene Arten von Dateiknoten, einschliesslich regularer Dateien, Verzeichnisse, Symlinks, Zeichen- und Blockgerateknoten, Sockets und FIFOs. Es wird nachdrucklich empfohlen, dass /dev/ der einzige Ort ist, unterhalb dessen Gerateknoten abgelegt werden. Ahnlich sollte /run/ der einzige Ort sein, an dem Sockets und FIFOs abgelegt werden. Regulare Dateien, Verzeichnisse und Symlinks konnen in allen Verzeichnissen verwandt werden. SYSTEMPAKETE Entwickler von Systempaketen sollten strengen Regeln beim Ablegen eigener Dateien im Dateisystem folgen. Die nachfolgende Tabelle fuhrt empfohlene Orte fur bestimmte, vom Lieferanten bereitgestellte Dateien auf. Tabelle 1. Ort fur Lieferantendateien aus Systempaketen +-----------------------------------+----------------------------+ |Verzeichnis | Zweck | +-----------------------------------+----------------------------+ |/usr/bin/ | Paketprogramme, die im | | | ausfuhrbaren Suchpfad | | | $PATH auftauchen sollen, | | | fur eine der unterstutzten | | | 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, fur hier | | | abzulegende Dateien | | | eindeutige Namen | | | auszuwahlen, die | | | wahrscheinlich nicht in | | | Konflikt zu den Dateien | | | anderer Pakete stehen. | +-----------------------------------+----------------------------+ |/usr/lib/Arch-Kennung/ | Offentliche dynamische | | | Bibliotheken des Pakets. | | | Wie oben sollten Sie | | | sorgfaltig bei der | | | Verwendung zu generischer | | | Namen sein und eindeutige | | | Namen fur Ihre hier | | | abzulegenden Dateien | | | wahlen, um Namenskonflikte | | | zu vermeiden. | +-----------------------------------+----------------------------+ |/usr/lib/Paket/ | Private statische | | | Lieferantenressourcen des | | | Pakets, einschliesslich | | | privater Programme und | | | Bibliotheken oder jede | | | andere Art von | | | rein-lesbaren | | | Lieferantendaten. | +-----------------------------------+----------------------------+ |/usr/lib/Architekturkennung/Paket/ | Private weitere | | | Lieferantenressourcen des | | | Pakets, die | | | architekturabhangig sind | | | und nicht von | | | verschiedenen | | | Architekturen gemeinsam | | | benutzt werden konnen. | | | Beachten Sie, dass dies im | | | Allgemeinen keine privaten | | | Programme einschliesst, da | | | Programme einer bestimmten | | | Architektur frei von jeder | | | anderen unterstutzten | | | Systemarchitektur | | | aufgerufen werden konnen. | +-----------------------------------+----------------------------+ |/usr/include/Paket/ | Offentliche C/C++-APIs von | | | offentlichen dynamischen | | | Bibliotheken des Pakets. | +-----------------------------------+----------------------------+ Zusatzliche statische Lieferantendateien konnen in der Hierarchie /usr/share an die Orte, die durch verschiedene, zutreffende Spezifikationen festgelegt werden, installiert werden. Die folgenden Verzeichnisse mussen fur durch das Paket fur lokale Konfiguration und zur Laufzeit erstellte Dateien verwandt werden: Tabelle 2. Ort fur variable Dateien aus Systempaketen +------------------+----------------------------+ |Verzeichnis | Zweck | +------------------+----------------------------+ |/etc/Paket/ | Systemspezifische | | | Konfiguration fur das | | | Paket. Es wird empfohlen, | | | standardmassig sichere | | | Ruckfalloptionen zu | | | verwenden, falls diese | | | Konfiguration fehlt, falls | | | das moglich ist. | | | Alternativ kann ein | | | tmpfiles.d(5)-Fragment | | | verwandt werden, um die | | | notwendigen Dateien und | | | Verzeichnisse von | | | /usr/share/factory/ | | | wahrend des Systemstarts | | | mittels der Anweisungen | | | >>L<< oder >>C<< zu | | | symlinken oder zu | | | kopieren. | +------------------+----------------------------+ |/run/Pakete/ | Laufzeitdaten fur das | | | Paket. Pakete mussen 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 | | | wahrend 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) fur | | | Details). | +------------------+----------------------------+ |/run/log/Paket/ | Laufzeitprotokolldaten fur | | | 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 | | | nachsten Aufruf korrekt | | | arbeiten, allerdings | | | moglicherweise | | | 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 | | | aufgefuhrten Kategorien | | | fallen. Pakete sollten in | | | der Lage sein, die | | | notwendigen | | | Unterverzeichnisse in | | | diesem Baum selbst zu | | | erstellen, da das | | | Verzeichnis beim | | | Systemstart fehlen konnte. | | | 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, moglicherweise | | | mittels tmpfiles.d(5) oder | | | LogsDirectory= (siehe | | | systemd.exec(5)) zu | | | erstellen, da es fehlen | | | konnte. | +------------------+----------------------------+ |/var/spool/Paket/ | Dauerhafte | | | Spool-/Warteschlangendaten | | | des Pakets. Wie oben | | | sollte das Paket | | | sicherstellen, das | | | Verzeichnis, falls | | | notwendig, zu erstellen, | | | da es fehlen konnte. | +------------------+----------------------------+ BENUTZERPAKETE Programme, die im Benutzerkontext laufen, sollten strengen Regeln bei der Ablage ihrer eigenen Dateien im Home-Verzeichnis des Benutzers folgen. Die nachfolgende Tabelle fuhrt empfohlene Orte im Home-Verzeichnis fur bestimmte Arten von Dateien des Lieferanten auf, falls die Anwendung im Home-Verzeichnis installiert ist. (Systemweit installierte Benutzeranwendungen sind von den oben dargestellten Regeln fur Lieferantendateien abgedeckt.) Tabelle 3. Lieferantenpaketorte unter dem Home-Verzeichnis des Benutzers +---------------------------------------+----------------------------+ |Verzeichnis | Zweck | +---------------------------------------+----------------------------+ |~/.local/bin/ | Paketprogramme, die im | | | ausfuhrbaren 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, fur hier | | | abzulegende Dateien | | | eindeutige Namen | | | auszuwahlen, die | | | wahrscheinlich nicht in | | | Konflikt zu den Dateien | | | anderer Pakete stehen. | +---------------------------------------+----------------------------+ |~/.local/lib/Architekturkennung/ | Offentliche dynamische | | | Bibliotheken des Pakets. | | | Wie oben sollten Sie | | | sorgfaltig bei der | | | Verwendung ubermassig | | | generischer Namen sein und | | | eindeutige Namen fur Ihre | | | hier abzulegenden Dateien | | | wahlen, 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 | | | architekturabhangig sind | | | und nicht auf | | | verschiedenen | | | Architekturen gemeinsam | | | benutzt werden konnen. | +---------------------------------------+----------------------------+ Zusatzliche statische Lieferantendateien konnen in der Hierarchie ~/.local/share/ abgelegt werden und dabei die im obigen Abschnitt >>Vom Lieferanten bereitgestellte Betriebssystemressourcen<< festgelegten Verzeichnisse spiegeln. Die folgenden Verzeichnisse mussen fur durch das Paket fur benutzerbezogene lokale Konfiguration und zur Laufzeit erstellte Dateien verwandt werden: Tabelle 4. Ort fur variable Dateien aus Benutzerpaketen +------------------------+----------------------------+ |Verzeichnis | Zweck | +------------------------+----------------------------+ |~/.config/Paket/ | Benutzerbezogene | | | Konfiguration und Zustand | | | fur das Paket. Es wird | | | verlangt, sichere | | | Ruckfallstandardwerte zu | | | verwenden, falls diese | | | Konfiguration fehlt. | +------------------------+----------------------------+ |$XDG_RUNTIME_DIR/Paket/ | Benutzerlaufzeitdaten fur | | | das Paket. | +------------------------+----------------------------+ |~/.cache/Paket/ | Dauerhafte | | | Zwischenspeicherdaten des | | | Pakets. Falls dieses | | | Verzeichnis geleert wird, | | | sollte die Anwendung beim | | | nachsten Aufruf korrekt | | | arbeiten, allerdings | | | moglicherweise | | | 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 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 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 FILE-HIERARCHY(7)