Filesystem Hierarchy Standard: Unterschied zwischen den Versionen

Aus Foxwiki
Keine Bearbeitungszusammenfassung
Zeile 105: Zeile 105:


== Usrmerge ==
== Usrmerge ==
[[Usrmerge]]
Bei der meist mit „Usrmerge“ (für „[[#/usr|/usr]] merge“) oder „merged-usr“ bezeichneten Vereinigung der Verzeichnisse <code>/bin</code>, <code>/sbin</code> und <code>/lib</code> sowie gegebenenfalls <code>/lib[[32-Bit-Architektur|32]]</code> oder <code>/lib[[64-Bit-Architektur|64]]</code> bei [[#Multilib|Multilib]]-Systemen mit ihren jeweiligen Gegenstücken unter <code>/usr</code> geht die strikte formale Trennung dieser Verzeichnisse gemäß FHS zwar verloren, solange die Verzeichnisse [[Symbolische Verknüpfung|symlinks]] aufeinander sind, bleibt die Kompatibilität zum FHS allerdings weiterhin bestehen.
* Dieser „merge“ (dt.&nbsp;für „Vereinigung [der Verzeichnisse]“) wurde von fast allen großen [[Linux-Distribution]]en in den 2010er-Jahren durchgeführt.
* Ob die entsprechenden Dateien nach der Umstellung im relevanten Unterverzeichnis unterhalb von <code>/usr</code> abgelegt werden oder im Wurzelverzeichnis, ist danach ohne Belang.
 
* /usr/bin
* /usr/sbin
* /usr/lib
* /usr/lib64
 
Im Beispiel wird aus <code>/bin</code> ein Symlink auf <code>/usr/bin</code> sowie <code>/sbin</code> auf <code>/usr/sbin</code>; dasselbe gilt für die /usr befinden, widerspricht zwar der im FHS definierten Trennung, die Umstellung ist allerdings für alte („legacy“) wie aktuelle [[Computerprogramm|Programme]] vollständig transparent.
 
Begründung für die Umstellung ist, neben der Tatsache, dass die Trennung gemäß FHS überflüssig geworden ist,
vor allem die Vereinfachung in der Handhabung.
* So wird nicht nur die Übersichtlich- und Durchsuchbarkeit erhöht, sondern insbesondere auch die Anwendung für Sandboxes und Container vereinfacht.
 
Nach [[Solaris (Betriebssystem)|Solaris]] Ende 2010 und [[Fedora (Linux-Distribution)|Fedora]] 2012 führten auch [[Arch Linux|Arch]] und [[Ubuntu (Betriebssystem)|Ubuntu]] den Usrmerge durch.
* Bei [[Debian]] wird seit Version 10 (Buster) ein vereinheitlichtes Dateisystem ausgeliefert und ist voraussichtlich ab Version 13 (Trixie) vollständig umgesetzt.


<noinclude>
<noinclude>

Version vom 13. Dezember 2024, 09:09 Uhr

Filesystem Hierarchy Standard (FHS) - Richtlinie für die Verzeichnisstruktur unter Unix-ähnlichen Betriebssystemen

Beschreibung

Beispiel eines Standard-Stammverzeichnisses

Der Standard richtet sich an Softwareentwickler, Systemintegratoren und Systemadministratoren.

Die Entwicklung dieser Richtlinie begann im August 1993 und war zunächst nur auf Linux bezogen.

  • Zwischenzeitlich trugen einige Entwickler von FreeBSD dazu bei, einen umfassenden Standard für alle Unix-ähnlichen Systeme zu schaffen.
  • Diese Zusammenarbeit wurde im Mai 2011 offiziell eingestellt, nachdem die Linux Foundation das Projekt übernommen hatte.

Derzeit wird dieser Standard nur von Linux-Distributionen verwendet.

Die erste Dokumentation solcher Hierarchie erschien in AT&T UNIX Version 7.

Seit etwa 2011 führen verschiedene, große Distributionen den so genannten Usrmerge (/usr-Merge) durch, welcher mit dem FHS formal per symbolischer Verknüpfung vereinbar ist.

  • Dadurch wird zwar die Systematik des FHS nicht vollständig beibehalten, die Kompatibilität zu bestehenden Programmen ist damit aber weiterhin gewährleistet.
| Maintainer = Linux Foundation
| Hersteller = LSB-Arbeitsgruppe
| Erscheinungsjahr = 1994
| Betriebssystem = Linux
| Website = refspecs.linuxfoundation.org/fhs

Dateikategorien

Der FHS unterscheidet Dateien unter zwei Aspekten
Aspekt Beschreibung
„static“ oder „variable“
  • Als „static“ gelten jene Dateien, die sich ohne den Eingriff eines Systemadministrators nicht ändern.
  • Alle anderen Dateien werden als „variable“ betrachtet.
„shareable“ oder „unshareable“
  • Als „shareable“ gelten jene Dateien, die über ein Rechnernetz von anderen Computern genutzt werden können.
  • Alle anderen Dateien werden als „unshareable“ betrachtet.
Kategorien von Dateien

Aus diesen beiden Aspekten ergeben sich vier Kategorien von Dateien:

  • „static shareable“
  • „static unshareable“
  • „variable shareable“
  • „variable unshareable“

Um Datensicherungen und Bereitstellungen im Rechnernetz effizienter zu gestalten, sieht der FHS vor, keine Dateien unterschiedlicher Kategorie im selben Verzeichnis zu speichern.

Stammverzeichnis

Das Volume, meist in Form einer Partition, des Stammverzeichnisses muss all jene Dateien enthalten, die zum Hochfahren des Betriebssystems und zum Einbinden weiterer Partitionen notwendig sind.

  • Um ein System reparieren zu können, muss sie auch die dazu notwendigen Hilfsmittel enthalten.

Um die Flexibilität und Zuverlässigkeit zu erhöhen, empfiehlt der FHS, Teile der Verzeichnisstruktur in anderen Partitionen anzulegen.

Folgende Verzeichnisse oder symbolische Verknüpfungen auf Verzeichnisse werden im Stammverzeichnis verlangt:

/bin Binärdateien grundlegender Befehle
/boot statische Dateien des Bootloaders
/dev Gerätedateien „devices“ (Geräte wie Festplatten und Systemkonsole)
/etc Host-spezifische Systemkonfiguration
/lib grundlegende dynamische Bibliotheken und Kernel-Module
/lib32 Alternative Kernel-Module und dynamische Bibliotheken Multilib
/lib64 Alternative Kernel-Module und dynamische Bibliotheken Multilib
/media Einhängepunkt für Wechseldatenträger
/mnt für temporär eingehängtes Dateisystem
/proc Prozessdateisystem
/opt zusätzliche Anwendungsprogramme
/run für laufende Prozesse relevante Daten
/sbin essenzielle Binärdateien des Systems
/srv Daten für Dienste
/tmp temporäre Dateien „temporary files“ (temporäre Dateien, üblicherweise auf schnellem Gerät)
/usr sekundäre Hierarchie
/var variable Daten Die Verzeichnisse /var sind so konzipiert, dass sie nicht in der Partition des Stammverzeichnisses liegen müssen.
/home Benutzerverzeichnisse: Verzeichnisse der Benutzer
/root Benutzerverzeichnis des Root-Kontos
/lib… alternative dynamische Bibliotheken, beispielsweise /lib64 für Multilib-Systeme (Bibliotheken für sowohl einen 32-Bit- als auch einen 64-Bit-Betriebsmodus)
Andere Verzeichnisse sollen im Stammverzeichnis nicht angelegt werden
  • Anwendungsprogramme sollen keine Dateien im Stammverzeichnis fordern oder anlegen

Usrmerge

Bei der meist mit „Usrmerge“ (für „/usr merge“) oder „merged-usr“ bezeichneten Vereinigung der Verzeichnisse /bin, /sbin und /lib sowie gegebenenfalls /lib32 oder /lib64 bei Multilib-Systemen mit ihren jeweiligen Gegenstücken unter /usr geht die strikte formale Trennung dieser Verzeichnisse gemäß FHS zwar verloren, solange die Verzeichnisse symlinks aufeinander sind, bleibt die Kompatibilität zum FHS allerdings weiterhin bestehen.

  • Dieser „merge“ (dt. für „Vereinigung [der Verzeichnisse]“) wurde von fast allen großen Linux-Distributionen in den 2010er-Jahren durchgeführt.
  • Ob die entsprechenden Dateien nach der Umstellung im relevanten Unterverzeichnis unterhalb von /usr abgelegt werden oder im Wurzelverzeichnis, ist danach ohne Belang.
  • /usr/bin
  • /usr/sbin
  • /usr/lib
  • /usr/lib64

Im Beispiel wird aus /bin ein Symlink auf /usr/bin sowie /sbin auf /usr/sbin; dasselbe gilt für die /usr befinden, widerspricht zwar der im FHS definierten Trennung, die Umstellung ist allerdings für alte („legacy“) wie aktuelle Programme vollständig transparent.

Begründung für die Umstellung ist, neben der Tatsache, dass die Trennung gemäß FHS überflüssig geworden ist, vor allem die Vereinfachung in der Handhabung.

  • So wird nicht nur die Übersichtlich- und Durchsuchbarkeit erhöht, sondern insbesondere auch die Anwendung für Sandboxes und Container vereinfacht.

Nach Solaris Ende 2010 und Fedora 2012 führten auch Arch und Ubuntu den Usrmerge durch.

  • Bei Debian wird seit Version 10 (Buster) ein vereinheitlichtes Dateisystem ausgeliefert und ist voraussichtlich ab Version 13 (Trixie) vollständig umgesetzt.


Anhang

Siehe auch


Links

  1. https://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
  2. Filesystem Hierarchy Standard
  3. The Linux Assigned Names And Numbers Authority