Zweck

Verzeichnis /bin enthält Kommandos, die sowohl vom Systemverwalter als auch von Benutzern verwendet werden können, und die auch dann benötigt werden, wenn keine weiteren Dateisysteme eingebunden sind (z.B. im Einzelbenutzer-Modus). Es darf auch Kommandos enthalten, die nur indirekt von Skripten aufgerufen werden. [1]

Anforderungen

In /bin darf es keine Unterverzeichnisse geben.

Die folgenden Kommandos oder symbolischen Links zu Kommandos werden in /bin benötigt:

Wenn /bin/sh nicht die echte "Bourne shell" ist, so muss es ein fester oder symbolischer Link auf das tatsächliche shell-Kommando sein.

Die Kommandos [ und test müssen jeweils zusammen entweder unter /bin oder unter /usr/bin abgelegt werden.

	Hintergrund
	Beispielsweise verhält sich "bash" unterschiedlich, je nachdem ob es mit sh oder bash aufgerufen wird. Außerdem zeigt die Verwendung eines symbolischen Links dem Benutzer an, dass /bin/sh nicht die echte Bourne shell ist. Die Forderung, dass [ und test als Programmdateien vorhanden sein müssen, selbst wenn sie shell-intern implementiert sind, gründet sich auf den POSIX.2-Standard.

Optionen

Die folgenden Programme oder symbolischen Links zu Programmen müssen in /bin dann vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind:

Wenn gunzip und zcat vorhanden sind, müssen es symbolische Links zu gzip sein. /bin/csh darf ein symbolischer Link entweder zu /bin/tcsh oder zu /usr/bin/tcsh sein.

Hintergrund

Die Kommandos tar, gzip und cpio sind hier ergänzt worden, um das Wiederherstellen eines Systems - mit einem noch intakten /-Dateisystem - möglich zu machen. Umgekehrt sollten sie weggelassen werden, wenn ein Wiederherstellen von der Wurzelpartition aus niemals erwartet wird (z.B. bei einem ROM-Chip als Wurzel, wobei /usr über NFS eingebunden wird). Wenn ein Wiederherstellen des Systems über das Netz vorgesehen ist, dann müssen auch ftp oder tftp in der Wurzelpartition verfügbar sein, inclusive aller für die ftp-Verbindung benötigten Komponenten.

Zweck

Dieses Verzeichnis enthält alles, was für den Systemladevorgang nötig ist, ausgenommen die Konfigurationsdateien, die ja nicht zum Ladezeitpunkt gebraucht werden, und ebenso ausgenommen das Einrichtungsprogramm für die Zuordnungstabelle ("map installer"). Also enthält /boot solche Daten, die der Betriebssystemkern braucht, bevor er Benutzerprogramme ausführt. Das können z.B. auch gesicherte MBRs ("master boot records") oder Zuordnungstabellen ("map files") sein. [2]

Optionen

Der Betriebssystemkern muss sich entweder in / oder in /boot befinden. [3]

Zweck

Das Verzeichnis /dev ist für Gerätedateien da.

Optionen

Wenn es möglich sein soll, Geräte in /dev manuell zu erzeugen, so muss es dort auch ein Kommando namens MAKEDEV geben, das Geräte nach Bedarf kreieren kann. Es darf für lokale Geräte auch ein Kommando namens MAKEDEV.local geben.

Wenn nötig, muss MAKEDEV die Fähigkeit haben, jedes beliebige Gerät, das möglicherweise auf dem System zu finden ist, zu erzeugen, nicht nur die bei einer bestimmten Installation vorgesehenen.

Zweck

Die /etc-Hierarchie enthält Konfigurationsdateien. Eine Konfigurationsdatei ist eine lokale Datei und wird benutzt um den Lauf von Programmen zu steuern. Sie muss statisch und darf kein ausführbares Programm sein. [4]

Anforderungen

Unter /etc sollen keine ausführbaren Programme plaziert werden.

Es wird empfohlen, Dateien in Unterverzeichnissen von /etc anstatt direkt in /etc zu speichern. (Dieser Satz erscheint im englischen Original - wohl versehentlich - als Fußnote: A.d.Ü.)

Folgende Verzeichnisse oder symbolische Links zu Verzeichnissen werden in /etc benötigt:

Optionen

Die folgenden Verzeichnisse oder symbolischen Links zu Verzeichnissen müssen in /etc dann vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind:

Die folgenden Dateien oder symbolischen Links zu Dateien müssen in /etc vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind: [5]

mtab erfüllt nicht die für /etc geforderte Eigenschaft "statisch": Diese Ausnahme wird aus historischen Gründen gemacht. [6]

/etc/opt : Einstellungen für /opt

---

Anforderungen

Für /etc/opt/<Name> wird eine interne Struktur nicht vorgeschrieben.

Sollte es für das Funktionieren der Software nötig sein, dass die Einstellungen an anderer Stelle gespeichert werden müssen, so ist das auch erlaubt.

	Hintergrund
	(siehe: Hintergrund zu /opt)

/etc/X11 : Einstellungen für das X-Window-System (optional)

/etc/sgml : Einstellungen für SGML (optional)

/etc/xml : Einstellungen für XML (optional)

Zweck

Dieses Konzept ist ziemlich üblich, aber es bleibt ganz klar eine Sache der Betreiber. [8] Der Aufbau wird von Rechner zu Rechner unterschiedlich sein. Deshalb sollte kein Programm sich auf diese Plazierung verlassen. [9]

Anforderungen

Benutzerspezifische Einstellungen von Anwendungen werden im jeweiligen Benutzerverzeichnis in einer Datei, deren Namen mit einem Punkt beginnt ("dot file") abgelegt. Benötigt die Anwendung mehr als eine solche Datei, sollten diese in einem Unterverzeichnis abgelegt werden, dessen Name mit einem Punkt beginnt ("dot directory"). Dort sollen die Dateinamen dann aber nicht mit einem Punkt beginnen. [10]

Zweck

Das Verzeichnis /lib enthält jene Programmbibliotheken, die gebraucht werden, um das System zu starten und die Kommandos im Wurzeldateisystem, d.h. die lauffähigen Programme in /bin und /sbin, zu betreiben. [11]

Anforderungen

Für die folgenden Dateinamensmuster muss jeweils mindestens eine Entsprechung vorhanden sein, egal ob als Datei oder symbolischer Link.

Wenn ein C-Präpozessor installiert ist, so muss, aus historischen Gründen, /lib/cpp ein Verweis darauf sein. [12]

Optionen

Die folgenden Verzeichnisse oder symbolischen Links zu Verzeichnissen müssen in /lib dann vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind:

Zweck

Auf Systemen, die mehr als ein Format ausführbarer Programme unterstützen und deshalb getrennte Bibliotheken brauchen, dürfen eine oder mehr Varianten von /lib vorhanden sein. [13]

Anforderungen

Wenn es eine oder mehrere solcher Verzeichnisse gibt, gelten für diese dieselben Anforderungen wie auch für das "normale" /lib; nur /lib<Suffix>/cpp wird hier nicht gebraucht. [14]

Zweck

Dieses Verzeichnis enthält Unterverzeichnisse, die als Einhängepunkte für Wechselmedien wie Diskette, CD-ROMs oder ZIP-Datenträger genutzt werden.

Hintergrund

Blickt man zurück, so wurden Wechselmedien an den verschiedensten Stellen eingehängt, so zum Beispiel unter /cdrom, /mnt oder /mnt/cdrom. Wenn man alle Einhängepunkte direkt im Wurzelverzeichnis plazieren würde, hätte man bald eine Vielzahl von zusätzlichen Unterverzeichnisse von /. Das Einrichten von Unterverzeichnissen unter /mnt ist auch üblich geworden, gerät aber in Konflikt mit der älteren Tradition, /mnt direkt als temporären Einhängepunkt zu nutzen.

Optionen

Die folgenden Verzeichnisse oder symbolischen Links zu Verzeichnissen müssen in /media dann vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind:

Bei Systemen, bei denen mehrere Geräte eines Typs gibt, können Verzeichnisse zum Einhängen erzeugt werden, indem man eine Ziffer (beginnend mit "0") an den Namen anhängt; den unqualifizierten Namen muss es aber weiterhin geben. [15]

Zweck

Diese Verzeichnis dient einem Systemadministrator dazu, im Bedarfsfall ein Dateisystem vorübergehend einzubinden. Der Inhalt dieses Verzeichnisses liegt in lokaler Verantwortung und sollte keinen Einfluss auf das Verhalten irgendwelcher Programme haben.

Dieses Verzeichnis darf von Installationsprogrammen nicht benutzt werden; stattdessen muss ein passendes temporäres Verzeichnis benutzt werden, das nicht vom System verwendet wird.

Zweck

/opt ist reserviert für zusätzliche Softwarepakete.

Ein Paket, das unter /opt installiert wird, muss seine statischen Dateien in einem eigenen Unterverzeichnis namens /opt/<Paket> oder /opt/<Hersteller> plazieren, wobei dann <Paket> der Name des Softwarepakets ist und <Hersteller> der bei LANANA registrierte Herstellername.

Anforderungen

Die Verzeichnisse /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib und /opt/man wurden für den Gebrauch durch Systemverwalter reserviert. Softwarepakete dürfen dort Dateien ablegen (als Link oder Kopie), müssen aber auch in Abwesenheit dieser Verzeichnisse funktionsfähig bleiben.

Lauffähige Programme, die vom Benutzer aufgerufen werden sollen, gehören entweder nach /opt/<Paket>/bin oder nach /opt/<Hersteller>/bin. Enthält das Paket UNIX Online-Handbücher ("manual pages"), so müssen diese nach /opt/<Paket>/share/man oder /opt/<Hersteller>/share/man (Im englischen Original steht hier - wohl versehentlich - nur "/opt/<provider>": A.d.Ü.) abgelegt werden, mit derselben Struktur wie /usr/share/man.

Variable Dateien eines Softwarepakets, also solche, die sich bei normalen Operationen des Programms ändern, werden in /var/opt gespeichert. Genaueres dazu steht im Abschnitt über /var/opt.

Rechnerbezogene Konfigurationsdateien gehören nach /etc/opt. Genaueres dazu steht im Abschnitt über /etc.

Ausserhalb von /opt, /var/opt und /etc/opt sollen keine Dateien existieren, die von Zusatzsoftwarepaketen stammen. Ausnahmen sind nur solche Dateien, deren fehlerfreies Arbeiten von ihrer besonderen Plazierung abhängt. Beispielsweise müssen Sperrdateien für Geräte in /var/lock plaziert werden und Gerätedateien in /dev.

Distributionen dürfen Software in /opt installieren aber sie dürfen dort andere (vom Verwalter eingerichtete) Software ohne dessen Zustimmung weder verändern noch löschen.

Hintergrund

Die Verwendung von /opt für Zusatzsoftware ist weit verbreitete Praxis in der UNIX-Gemeinde. Das "System V Application Binary Interface [AT&T 1990]", welches auf "System V Interface Definition (Third Edition)" aufbaut, sieht für /opt eine Struktur vor, die dieser hier sehr ähnelt. Auch der "Intel Binary Compatibility Standard v. 2 (iBCS2)" sieht eine ähnliche Struktur für /opt vor. Allgemein soll gelten, dass alle Dateien, die ein Programmpaket auf einem bestimmten System benötigt, in /opt/<Paket> vorhanden sein müssen, also auch diejenigen, die nach /etc/opt/<Paket> und /var/opt/<Paket> kopiert werden sollen, und auch reservierte Unterverzeichnisse von /opt. Die kleine Einschränkung für die Benutzung von /opt durch Distributionen ist nötig, weil sonst Konflikte zwischen Software, die durch die Distribution, und solcher, die vom Verwalter installiert wurde, möglich wären. Insbesondere passiert das bei Software, bei denen Pfadnamen fest einprogrammiert wurden. Die Verzeichnisstruktur unterhalb von /opt/<Hersteller> bleibt dem Paketbetreuer überlassen. Allerdings wird empfohlen, Pakete nach /opt/<Hersteller>/<Paket> zu installieren und dort die Richtlinien für /opt/<Paket> zu übernehmen. Ein Grund dafür, von dieser Regel abzuweichen, sind Support-Softwarepakete, die Dateien möglicheweise in /opt/<Hersteller>/lib oder /opt/<Hersteller>/bin installieren.

Zweck

Plazierung des Benutzerverzeichnisses von "root" kann nach lokalen Prioritäten festgelegt werden; dies hier ist aber die empfohlene Stelle. [16]

Zweck

Hilfsprogramme für die Systemverwaltung (und andere nur für "root" vorgesehene Kommandos) werden in /sbin, /usr/sbin und /usr/local/sbin gespeichert. Dabei enthält /sbin alle notwendigen Programme für Systemstart, Reparatur und Wiederherstellung des Systems, die über die Programme in /bin hinausgehen. [17] Programme, die erst nach dem erfolgreichen Einbinden von /usr ausgeführt werden, werden üblicherweise nach /usr/sbin abgelegt. Lokal installierte Systemverwaltungswerkzeuge sollten in /usr/local/sbin plaziert sein. [18]

Anforderungen

Die folgenden Kommandos oder symbolischen Links zu Kommandos werden in /sbin benötigt:

Optionen

Die folgenden Dateien oder symbolischen Links zu Dateien müssen in /sbin vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind:

Zweck

/srv enthält betreiberspezifische Daten, die von Diensten dieses Systems zur Nutzung angeboten werden.

Hintergrund

Dieses Verzeichnis wurde vor allem eingeführt, um den Benutzern das Auffinden der Daten bestimmter Dienste zu erleichtern, und um Diensten, die einen einzelnen Verzeichnisbaum für Nur-Lese-Daten, Schreibdaten und Skripte (wie z.B. CGI-Skripte) brauchen, eine vernünftige Plazierung anzubieten. Dahingegen sollten Daten, die nur einen einzelnen Benutzer interessieren, im jeweiligen Benutzerverzeichnis abgelegt werden. Es gibt zur Zeit keinen Konsens über die Namensgebung für Unterverzeichnisse von /srv. Eine mögliche Methode wäre, Daten unterhalb von /srv nach Protokollen zu ordnen, also zum Beispiel ftp, rsync, www oder cvs. Auf großen Systemen kann es sinnvoll sein, /srv nach Verwaltungsgesichtspunkten zu unterteilen, beispielsweise /srv/Physik/www, /srv/Informatik/cvs usw. Das wird sich von System zu System unterscheiden. Also darf sich kein Programm auf die Existenz einer bestimmten Verzeichnisstruktur unterhalb von /srv verlassen. Immerhin sollte es auf FHS-koformen Systemen immer ein /srv geben, das die Standardplazierung für solche Daten ist. Distributionen dürfen hier lokal plazierte Dateien nicht ohne Erlaubnis des Verwalters entfernen. [19]

Zweck

Das Verzeichnis /tmp muss erreichbar sein für alle Programme, die mit temporären Daten arbeiten.

Programme dürfen nicht davon ausgehen, dass Dateien oder Verzeichnisse in /tmp zwischen zwei Programmläufen erhalten bleiben.

Hintergrund

Der Standard "IEEE standard P1003.2 (POSIX, part 2)" stellt ganz ähnliche Anforderungen. Auch wenn die Löschregelung für /tmp-Dateien der Verantwortung der Betreiber überlassen bleibt, wird hier empfohlen, Dateien und Verzeichnisse in /tmp bei jedem Systemstart zu löschen. Der FHS gibt diese Empfehlung auf der Basis von Tradition und üblicher Praxis. Sie hat aber nicht den Status einer Anforderung, weil Systemverwaltung nicht Thema diese Standards ist.

Zweck

Diese Hierarchie ist reserviert für das X-Window-System Version 11 Release 6 und die zugehörigen Dateien.

Zur Vereinfachung und um XFree86 besser mit den X-Window-Systemen auf anderen Platformen kompatibel zu machen, müssen folgende symbolischen Links unterhalb von /usr/X11R6 vorhanden sein:

    /usr/bin/X11 -> /usr/X11R6/bin
    /usr/lib/X11 -> /usr/X11R6/lib/X11
    /usr/include/X11 -> /usr/X11R6/include/X11

Allgemein darf Software nicht auf dem Weg über die genannten Links installiert oder gesteuert werden. Die Links sind nur für die Benutzer. Das Problem hängt mit dem X-Window-Release zusammen - in Zeiten des Übergangs ist es unmöglich zu wissen, welches Release von X11 genutzt wird.

Optionen

Rechnerspezifische Daten in /usr/X11R6/lib/X11 sollen nur als Muster betrachtet werden. Anwendungen, die Informationen über den aktuellen Rechner benötigen, müssen sich an eine Konfigurationsdatei in /etc/X11 wenden, welches dann verknüpft sein kann mit einer Datei in /usr/X11R6/lib. [20]

Zweck

Dies ist das wichtigste Verzeichnis für Kommandos im ganzen System.

Optionen

Die folgenden Verzeichnisse oder symbolischen Links zu Verzeichnissen müssen in /usr/bin dann vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind:

Wenn /usr/X11R6/bin existiert, dann muss /usr/bin/X11 ein symbolischer Link darauf sein.

Die folgenden Dateien oder symbolischen Links zu Dateien müssen in /usr/bin dann vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind:

Hintergrund

Weil Interpreter für Shell-Skripte (aufgerufen durch #!<Pfad> in der ersten Zeile) sich sonst nicht auf den Pfad verlassen könnten, ist es von Vorteil, die Plazierung zu standardisieren. Für die "Bourne shell" ebenso wie für die "C shell" ist der Ort bereits festgelegt mit /bin. Perl, Python und Tcl aber findet man an den unterschiedlichsten Stellen. Hier dürfen sie symbolische Links auf die tatsächlichen Interpreter sein.

Zweck

Hier sollen alle systemweit genutzten Include-Dateien für die Programmiersprache C abgelegt werden.

Optionen

Die folgenden Verzeichnisse oder symbolischen Links zu Verzeichnissen müssen in /usr/include dann vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind:

Wenn /usr/X11R6/include/X11 existiert, dann muss /usr/include/X11 ein symbolische Link darauf sein.

Zweck

/usr/lib enthält Objektdateien, Bibliotheken und interne lauffähige Programme, die nicht für die direkte Nutzung durch Benutzer oder Shell-Skripte vorgesehen sind. [21]

Anwendungsprogramme dürfen je ein Unterverzeichnis von /usr/lib benutzen. Wenn ein Anwendungsprogramm das tut, müssen alle architekturabhängige Daten, die ausschließlich von diesem Programm gebraucht werden, dort gespeichert werden. [22]

Optionen

Historisch bedingt muss /usr/lib/sendmail ein symbolischer Link auf /usr/sbin/sendmail sein, wenn letzteres existiert. [23]

Wenn /lib/X11 existiert, dann muss /usr/lib/X11 ein symbolischer Link darauf sein, oder auf das, worauf ein symbolische Link /lib/X11 zeigt. [24]

Zweck

/usr/lib<Suffix> spielt dieselbe Rolle wie /usr/lib, nur für alternative Binärformate. Ausnahmen: Die symbolischen Links /usr/lib<Suffix>/sendmail und /usr/lib<Suffix>/X11 sind nicht vorgeschrieben. [25]

Zweck

Die /usr/local-Hierarchie benutzt der Systemverwalter, wenn er Software lokal installiert. Es muss vor dem Überschreiben im Zuge einer Aktualisierung des Systems geschützt werden. Es darf für Programme genutzt werden, die von mehreren Rechnern genutzt werden kann, die aber nicht unter /usr gefunden werden können.

Lokal installierte Software gehört nach /usr/local und nicht nach /usr, solange sie nicht Software in /usr ersetzen oder erweitern soll. [26]

Anforderungen

Die folgenden Verzeichnisse oder symbolischen Links zu Verzeichnissen müssen in /usr/local vorhanden sein:

Soll das System FHS-konform sein, so darf es unter /usr/local ausschließlich die aufgeführten Verzeichnisse geben.

Optionen

Wenn es ein Verzeichnis /lib<Suffix> oder /usr/lib<Suffix> gibt, so muss es auch die Entsprechung unter /usr/local geben.

/usr/local/etc darf ein symbolischer Link auf /etc/local sein.

Hintergrund

Die durch /usr/local/etc erreichte Konsistenz ist von Vorteil für alle, die installieren müssen; auf anderen Systemen wird es bereits so genutzt. Da /usr/local komplett gesichert werden muss, um ein System wiederherstellen zu können, bedeutet das auch keinen zusätzlichen Wartungsaufwand. Ein symbolischer Link nach /etc/local genügt, wenn auf einem System alle Einstellungen in derselben Hierarchie erscheinen sollen. Beachten Sie, dass /usr/etc nach wie vor nicht erlaubt ist: Programme unter /usr sollen ihre Einstellungen unter /etc speichern.

/usr/local/share

Die Anforderungen für dieses Verzeichnis sind diegleichen wie für /usr/share. Einzige zusätzliche Regel ist, dass /usr/local/share/man und /usr/local/man dasselbe bedeuten müssen, also eines davon ein symbolischer Links aufs andere sein muss. [27]

Zweck

Dieses Verzeichnis enthält weniger wichtige Systemkommandos für den Systemverwalter. Verwaltungsprogramme aber, die für Reparatur und Wiederherstellen des Systems, für das Einhängen von /usr oder andere wesentliche Aufgaben gebraucht werden, gehören stattdessen nach /sbin, [28]

Zweck

Die /usr/share-Hierarchie ist für alle architekturunabhängigen Dateien gedacht, auf die nur lesend zugegriffen wird. [29]

Diese Hierarchie soll gemeinsam nutzbar sein von allen Architekturen unter einem Betriebssystem; also soll zum Beispiel ein Rechenzentrum ("site") mit i386-, Alpha- und PPC-Rechnern nur ein einziges /usr/share-Verzeichnis betreiben, das zentral eingebunden wird. Beachten Sie aber, dass /usr/share in der Regel nicht von verschiedenen Betriebssystemen oder verschiedenen Versionen eines Betriebssystems gemeinsam genutzt wird.

Programme oder Pakete mit Daten, die nicht verändert werden, sollten diese Daten in /usr/share (oder /usr/local/share, wenn lokal installiert) plazieren. Es wird empfohlen, dafür Unterverzeichnisse von /usr/share zu benutzen.

Spieledaten in /usr/share/games müssen rein statische Daten sein. Alle veränderbaren Dateien, wie Punkte-Dateien, Log-Dateien usw. müssen in /var/games gespeichert werden.

Anforderungen

Die folgenden Verzeichnisse oder symbolischen Links zu Verzeichnissen müssen in /usr/share vorhanden sein:

Optionen

Die folgenden Verzeichnisse oder symbolischen Links zu Verzeichnissen müssen in /usr/share dann vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind:

Es wird empfohlen, anwendungsspezifische, architekturunabhängige Verzeichnisse hier zu plazieren. Das schließt groff, perl, ghostscript, texmf, und kbd für Linux oder syscons für BSD ein. Es liegt aber im Ermessen der Distribution, sie nach /usr/lib zu plazieren (wegen Rückwärtskompatibilität). Ähnlich darf eine Distribution auch zusätzlich zu /usr/share/games eine /usr/lib/games-Hierarchie benutzen.

/usr/share/dict : Wortlisten (optional)

Zweck

Dieses Verzeichnis ist Heimat für Wortlisten des Systems. Traditionell enthält es nur die englische words-Datei, die von look(1) und anderen Rechtschreibprogrammen benutzt wird. words darf englische oder amerikanische Schreibweisen enthalten.

	Hintergrund
	Dass hier nur Wortlisten gespeichert sind, liegt daran, dass dies die einzigen Dateien sind, die allen Rechtsschreibungs-Prüfprogrammen gemeinsam sind.

/usr/share/man : Online-Handbücher ("man pages")

/usr/share/misc : Verschiedenes

Dieses Verzeichnis enthält verschiedene architekturunabhängige Daten, die ohne eigene Unterverzeichnisse von /usr/share auskommen.

/usr/share/sgml : SGML-Daten (optional)

/usr/share/xml : XML-Daten (optional)

Zweck

In diesem Verzeichnis kann Quellcode angelegt werden. Es ist nur zum Nachschlagen gedacht. [34]

Zweck

Dieses Verzeichnis enthält die Konten der aktuell aktiven Prozesse sowie Daten über zusammengesetzte Prozesse, wie sie in einigen UNIX-ähnlichen Betriebssystemen von lastcomm und sa benutzt werden.

Zweck

/var/cache ist vorgesehen als Datenpuffer für Anwendungsproramme. Das sind üblicherweise lokal generierte Daten, deren Erzeugung zeitaufwändig oder I-O-intensiv ist. Die Anwendungen müssen in der Lage sein, solche Daten neu zu erzeugen oder neu zu laden. Anders als bei /var/spool können Pufferdaten gelöscht werden, ohne verloren zu gehen. Pufferdaten müssen zwischen Programmaufruf und Systemneustart gültig bleiben.

Dateien unter /var/cache dürfen nach den Regeln der Anwendung und auch nach Maßgabe des Systemverwalters ihre Gültigkeit verlieren. Die Anwendung muss immer in der Lage sein, mit einem manuellen Löschen der Pufferdateien (in der Regel veranlasst durch Platzmangel) zurechtzukommen. Es gibt keine Vorschriften für das Datenformat.

	Hintergrund
	Die Existenz eines eigenen Verzeichnisses für Pufferdaten erlaubt dem Sytemverwalter, dieses bei Speicherung und Sicherung nach anderen Regeln zu behandeln, als die übrigen Verzeichnisse unter /var.

Optionen

/var/cache/fonts : Lokal generierte Schrifttypen (optional)

/var/cache/man : Lokal formatierte Handbücher (optional)

Zweck

Dieses Verzeichnis stellt eine Standardplazierung für Betreiber zu Verfügung, die /usr als Nur-Lese-Partition eingebunden haben, aber trotzdem lokale Formatierung den Online-Handbcher erlauben wollen. Wo /usr beschreibbar eingebunden wird (z.B. auf einem Einzelplatzrechner), mag man sich gegen /var/cache/man entscheiden und stattdessen die formatierten Handbücher direkt in den cat<section>-Unterverzeichnissen von /usr/share/man ablegen. Wir empfehlen dagegen eine der folgenden Vorgehensweisen:

• Halten Sie alle Online-Handbücher nicht nur unformatiert sondern auch in der formatierten Version bereit.

• Unterbinden Sie das Abspeichern der formatierten Handbücher, so dass ein Online-Handbuch bei jedem Aufruf formatiert wird.

• Erlauben Sie, dass formatierte Online-Handbcher in /var/cache/man gepuffert werden.

Die Struktur von /var/cache/man muss zweierlei wiederspiegeln: die Vielzahl der Handbuch-Hierarchien und die mögliche Mehrsprachenunterstützung.

Ausgehend vom unformatierten Handbuch, das normalerweise in <Pfad>/man/<Lokalanpassung>/man<Abschnitt> untergebracht ist, wird das formatierte Handbuch in /var/cache/man/<catPfad>/<Lokalanpassung>/cat<Abschnitt> plaziert, wobei <catPfad> dadurch erzeugt wird, dass von <Pfad> jede führende Zeichenkette usr und jede schließende Zeichenkette share entfernt wird. (Man beachte, dass <Lokalanpassung> fehlen kann.) [36]

Handbücher, die nach /var/cache/man geschrieben wurden, können in die entsprechenden Verzeichnisse in der Quell-man-Hierarchie übertragen werden oder aber ihre Gültigkeit verlieren; ebenso können formatierte Handbücher in der Quell-man-Hierarchie ihre Gültigkeit verlieren, wenn sie über einen bestimmten Zeitraum nicht benutzt wurden.

Vorformatierte Handbücher von einem Nur-Lese-Medium (z.B. CD-ROM) müssen in der Quell-man-Hierarchie eingebunden werden (z.B. als /usr/share/man/cat<Abschnitt>). Denn /var/cache/man ist nur als beschreibbarer Puffer für formatierte Handbücher vorgesehen.

	Hintergrund
	Im Release 1.2 dieses Standards war hierfür /var/catman vorgesehen. Der Pfad wurde zu /var/cache geändert, um den dynamischen Charakter der formatierten Handbücher zu betonen. Der Verzeichnisname wurde in man abgeändert, um eine Erweiterung der Hierarchie für andere Formatierungen als "cat", wie etwa PostScript, HTML oder DVI, möglich zu machen.

Zweck

Dieses Verzeichnis bietet Platz für Systemdumps. Zum Zeitpunkt der Veröffentlichung dieses Standards wurden solche Dumps von Linux nicht unterstützt, aber von anderen Systemen, die FHS-konform sein können.

Zweck

Hier sollen alle variablen Daten von Spielen aus /usr abgelegt werden. /var/games soll die variablen Daten enthalten, die früher in /usr gespeichert wurden; statische Daten wie Hilfetexte, Level-Beschreibungen usw. müssen an anderer Stelle, wie etwa /usr/share/games, verbleiben.

	Hintergrund
	/var/games wurde als eigene Hierarchie bestimmt anstatt - wie es noch in Release 1.2 war - mit /var/lib zu vermischen. Die Trennung erlaubt lokale Kontrolle über Sicherungsstrategien, Rechte und Plattennutzung, sie erlaubt gemeinsame Nutzung zwischen Rechnern, und sie bereinigt das Durcheinander in /var/lib. Zu guter Letzt sei erwähnt, dass /var/games der traditionelle Pfad unter BSD ist.

Zweck

Diese Hierarchie enthält Statusinformationen, die Anwendungen oder das System betreffen. Statusinformationen sind solche Daten, die von Programmen während der Laufzeit verändert werden, und die sich auf einen Rechner beziehen. Benutzer sollen Daten in /var/lib nicht verändern müssen.

Statusinformationen werden generell dazu genutzt, den Zustand einer Anwendung (oder einer Gruppe zusammengehörender Anwendungen) von einem Aufruf zum nächsten, oder von einer Instanz derselben Anwendung zur nächsten Instanz, zu erhalten. Statusinformationen sollten generell über einen Systemneustart hinaus gültig bleiben. Es soll sich nicht um Logbücher handeln und auch nicht um Spool-Daten.

Eine Anwendung (oder eine Gruppe zusammenhängender Anwendungen) muss für diese Daten ein Unterverzeichnis von /var/lib benutzen. Ein Unterverzeichnis, /var/lib/misc, ist vorgeschrieben für Statusdateien von solchen Anwendungen, die kein eigenes Unterverzeichnis benötigen, alle anderen Unterverzeichnisse sollen nur angelegt werden, wenn die zugehörige Anwendung auch in der jeweiligen Distribution enthalten ist. [37]

/var/lib/<Name> ist auch die Stelle, die die jeweiligen Paketverwaltungen der Distributionen benutzen müssen. Verschiedene Distributionen können, natürlich, verschiedene Namen benutzen.

Anforderungen

Die folgenden Verzeichnisse oder symbolischen Links zu Verzeichnissen werden in /var/lib benötigt:

Optionen

Die folgenden Verzeichnisse oder symbolischen Links zu Verzeichnissen müssen in /var/lib dann vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind:

/var/lib/<Editor> : Sicherungen und Status eines Editors (optional)

Zweck

Solche Verzeichnisse enthalten Sicherungsdateien, die von unerwarteten Pragrammabbrüchen eines Editors (z.B. elvis, jove, nvi) erzeugt werden.

Andere Editoren benötigen vielleicht kein Verzeichnis für Wiederherstellung nach einem Absturz, aber eventuell brauchen sie eine festgelegte Stelle für andere Laufzeitinformationen. Diese sollten in einem Unterverzeichnis von /var/lib/<Editor> abgelegt werden. (Beispielsweise plaziert der GNU-Emacs seine Sperrdateien in /var/lib/emacs/lock.)

Zukünftige Editoren brauchen vielleicht noch zusätzliche Statusinformationen, die über Wiederherstellung nach einem Absturz und über Sperrdateien hinaus gehen. Auch diese gehören dann unter /var/lib/<Editor>.

Hintergrund

Ältere Linux-Versionen und fast alle kommerziellen Anbieter benutzen /var/preserve für den vi und seine Nachahmer. Wie auch immer, jeder Editor benutzt sein eigenes Format für die genannten Dateien, und deshalb wird auch für jeden Editor ein eigenes Verzeichnis gebraucht. Editorbezogene Sperrdateien unterscheiden sich in der Regel sehr von Geräte-Sperrdateien in /var/lock, und werden deshalb in /var/lib gespeichert.

/var/lib/hwclock : Status von hwclock (optional)

Zweck

Hier ist /var/lib/hwclock/adjtime enthalten.

	Hintergrund
	In der FHS 2.1 hieß diese Datei /etc/adjtime. Das war offensichtlich falsch, weil hwclock die Datei verändert.

/var/lib/misc : Verschiedene Statusinformationen

Zweck

Sperrdateien sollten im Verzeichnis /var/lock gespeichert werden.

Sperrdateien für Geräte und andere Ressourcen, die von mehreren Anwendungen genutzt werden, wie etwa die Sperrdateien der seriellen Anschlüsse, die man ursprünglich in /usr/spool/locks oder /usr/spool/uucp finden konnte, müssen nun in /var/lock gespeichert werden. Die Konvention besagt, dass die Dateinamen mit "LCK.." beginnen worauf dann der Basisname des Gerätes folgt. Will man zum Beispiel /dev/ttyS0 sperren, so erzeugt man eine eine Datei namens "LCK..ttyS0". [39]

Für den Inhalt solcher Sperrdateien gilt das HDB-UUCP-Sperrdateiformat. Der Prozessbezeichner ("process identifier") PID wird in 10 Byte Länge als ASCII-Zeichen gespeichert gefolgt vom Zeichen für Zeilenvorschub. Ein Beispiel: Wenn der Prozess 1230 eine Sperrdatei erzeugt, dann enthält diese elf Zeichen: Leerzeichen, Leerzeichen, Leerzeichen, Leerzeichen, Leerzeichen, Leerzeichen, Eins, Zwei, Drei, Null und Zeilenvorschub.

Zweck

Dieses Verzeichnis enthält verschiedene Logbücher. Die meisten Logbücher gehören hierher oder in ein entsprechendes Unterverzeichnis.

Optionen

Die folgenden Dateien oder symbolischen Links zu Dateien müssen in /var/log vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind:

Zweck

Der Spool-Bereich für E-Mails muss unter /var/mail zu finden sein, die einzelnen Dateien müssen <Benutzer> heißen. [40]

Postfächer hier müssen im UNIX Standard-Postfachformat gespeichert werden.

Hintergrund

Dieses Verzeichnis wurde von /var/spool/mail hierher verschoben um den FHS mit nahezu allen UNIXen in Übereinklang zu bringen. Die Änderung ist wichtig fürs Zusammenspiel, weil oft ein einziges Verzeichnis /var/mail von mehreren Rechnern und verschiedenen Implementierungen von UNIX gemeinsam genutzt werden (trotz NFS-Sperrmechanismus). Wichtig in diesem Zusammenhang ist, dass der Spool-Bereich nicht physisch verlagert werden muss. Allerdings müssen Programme und Header-Dateien so geändert werden müssen, dass sie /var/mail nutzen.

Zweck

Variable Daten der Pakete in /opt müssen unter /var/opt/<Name> installiert werden, wobei <Name> der Name des Teilbaums in /opt ist, in dem sich die statischen Dateien des Pakets befinden. Ausgenommen sind die, die durch Dateien in /etc ersetzt wurden. Für /var/opt/<Name> ist keine interne Struktur vorgeschrieben.

	Hintergrund
	Siehe dazu den Hintergrund zu /opt.

Zweck

Dieses Verzeichnis enthält Informationen über das System seit seinem Start. Dateien in diesem Verzeichnis müssen zu Beginn des Systemstarts aufgeräumt werden, gelöscht oder geleert, je nachdem. Für Programme kann ein Unterverzeichnis von /var/run vorgesehen sein; dies wird empfohlen für Programme, die mehr als eine Laufzeit-Datei benutzen. [41] PID-Dateien ("process identifier files"), die ursprünglich einmal in /etc abgelegt waren, müssen nun in /var/run gespeichert werden. Namenskonvention für diese Dateien ist <Programmname>.pid. Beispielsweise heißt die PID-Datei des crond-Dämons /var/run/crond.pid.

Anforderungen

Das interne Format der PID-Dateien bleibt unverändert. Die Datei muss den Prozessbezeichner als Dezimalzahl im ASCII-Format gefolgt von einem Zeilenvorschub enthalten. Hat beispielsweise der crond-Dämon den Prozessbezeichner 25, so enthält die Datei /var/run/crond.pid drei Zeichen: Zwei, Fünf und das Zeichen für Zeilenvorschub.

Programme, die PID-Dateien zu lesen haben, sollten tolerant sein bei dem, was sie als gültig akzeptieren; z.B. sollten sie Leerstellen jeder Art ("whitespace") ignorieren, ebenso führende Nullen oder das Fehlen des nachfolgenden Zeilenvorschubs, ebenso zusätzliche Zeilen. Programme, die PID-Dateien erzeugen, sollten sich aber an die oben genannte einfache Spezifikation halten.

Hier findet man auch die Datei utmp, die Information darüber enthält, wer aktuell das System benutzt.

Systemprogramme, die sich um transiente Sockel von UNIX-Domänen kümmern, müssen diese hier ablegen.

Zweck

/var/spool enthält Daten, die auf Weiterverarbeitung warten. Diese Daten bedeuten "zu erledigende Arbeiten" (durch Programme, Benutzer oder Verwalter); oft werden sie nach der Verarbeitung gelöscht. [42]

Optionen

Die folgenden Verzeichnisse oder symbolischen Links zu Verzeichnissen müssen in /var/spool dann vorhanden sein, wenn auch die entsprechenden Subsysteme eingerichtet sind:

/var/spool/lpd : Druckerwarteschlange für den lpd-Dämon (optional)

/var/spool/rwho : Dateien des rwhod-Dämons (optional)

Zweck

Dieses Verzeichnis enthält die Informationen des rwhod-Dämons über andere Systeme im lokalen Netz.

	Hintergrund
	Einige Auslieferungen ("releases") von BSD benutzen stattdessen /var/rwho. Angesichts der langwährenden Praxis anderer Systeme, die Daten in /var/spool zu plazieren, und angesichts der guten Übereinstimmung mit der Definition von 'Spool-Daten' wurde diese Stelle hier als angemessener erachtet.

Zweck

Das Verzeichnis /var/tmp wird zur Verfügung gestellt für Programme, die temporäre Dateien oder Verzeichnisse benötigen, die bei einem Systemneustart erhalten bleiben. Deshalb sind Daten hier dauerhafter als solche in /tmp.

Dateien und Verzeichnisse in /var/tmp dürfen beim Systemstart nicht gelöscht werden. Auch wenn Daten in /var/tmp normalerweise nach Regeln des Betreibers gelöscht werden, empfehlen wir, das Löschen in größeren zeitlichen Abständen durchzuführen als für /tmp.

Zweck

Variable Daten des NIS ("Network Information Service"), früher bekannt als YP ("Sun Yellow Pages"), gehören hierher.

	Hintergrund
	/var/yp ist das Standardverzeichnis für NIS (YP). Es wird fast ausschließlich für NIS-Dokumentation von NIS-Systemen genutzt. [43]

/ : Das Wurzelverzeichnis

Wenn der Systemkern sich in / befindet, empfehlen wir für Linux die Namen vmlinux oder vmlinuz, die auch in aktuellen Quellpaketen von Linux benutzt werden.

/bin : Wesentliche Kommandos (für alle Benutzer)

Wenn Linux-Systeme sie benötigen, plazieren sie folgende zusätzliche Dateien in /bin:

• setserial

/dev : Gerätedateien

Die folgenden Geräte muss es unter /dev geben:

	Hintergrund
	Vorhergehende Versionen des FHS stellten strengere Anforderungen an /dev. Es dürfen jetzt weitere Geräte in /dev vorhanden sein. Gerätedateien dürfen auch symbolische Links auf andere Gerätedateien sein, die sich in /dev oder Unterverzeichnissen von /dev befinden. Es gibt keine Einschränkungen die Haupt- oder Nebengerätenummern betreffend.

/etc : Rechnerspezifische Systemeinstellungen

Wenn Linux-Systeme sie benötigen, plazieren sie folgende zusätzliche Dateien in /etc:

• lilo.conf

/lib64 und /lib32 : 64/32-Bit-Bibliotheken (architekturspezifisch)

Für die 64-Bit-Architekturene PPC64, s390x, sparc64 und AMD64 müssen die 64-Bit-Bibliotheken in /lib64 und die 32-Bit-Bibliotheken (bzw. die 31-Bit_bibliothken für s390) in /lib plaziert werden.

Für die 64-Bit-Architekture IA64 gehören die 64-Bit-Bibliotheken nach /lib.

Hintergrund

Dies ist eine Verfeinerung der generellen Regel für /lib<Suffix> und /usr/lib<Suffix>. Die Architekturen von PPC64, s390x, sparc64 und AMD64 unterstützen sowohl 32-Bit- (für s390 richtiger: 31-Bit-) als auch 64-Bit-Programme. Dadurch, dass /lib für 32-Bit-Programme benutzt wird, funktionieren auch die bereits vorhandenen 32-Bit-Programme - und das sind sicher viele - ohne Änderungen weiter. Beim IA64 wird das anders gehandhabt, weil dort 32-Bit-Programme (und -Bibliotheken) als veraltet gelten.

/proc : Virtuelles Dateisystem für Kern- und Prozessinformationen

Das proc-Dateisystem ist der De-fakto-Standard in Linux für die Handhabung von Prozess- und Systeminformationen, also nicht /dev/kmem oder andere ähnliche Methoden. Wir empfehlen wärmstens, diese Methode zum Speichern und für den Abruf von Prozess-, Kern- Hauptspeicherinformationen zu nutzen.

/sbin : Wesentliche Systemkommandos

Linux-Systeme plazieren folgende zusätzlichen Dateien in /sbin:

• e2fs-Kommandos ("Second Extended Filesystem"):

  • badblocks

  • dumpe2fs

  • e2fsck

  • mke2fs

  • mklost+found

  • tune2fs

• Einrichter ("map installer") des Systemladers (optional):

  • lilo

Optionale Dateien für /sbin:

• Statisch lauffähige Programme:

  • ldconfig

  • sln

  • ssync

  Das statische ln (sln) und das statische sync (ssync) sind nützlich, wenn mal etwas schiefgeht. Die zunächst wichtigeste Funktion von sln, nämlich fehlerhafte symbolische Links unterhalb von /lib zu reparieren (etwa nach einem schlecht organisierten Systemupdate), hat nicht mehr diese Bedeutung seitdem es das Programm ldconfig (üblicherweise in /usr/sbin) gibt, das uns beim Aktualisieren der dynamischen Bibliotheken bei der Hand nimmt. Das statische sync ist in mancher Notsituation nützlich. Man beachte, dass die genannten Kommandos statisch gebundene ("linked") Versionen der Standardkommandos ln und sync sein können, aber nicht müssen.

  ldconfig ist optionaler Bestandteil von /sbin, weil ein Betreiber sich dafür entscheiden kann, ldconfig beim Systemstart, anstatt nur beim Aktualisieren der Bibliotheken, einzusetzen. (Es ist noch nicht klar, ob es von Vorteil ist, ldconfig bei jedem Systemstart einzusetzen, oder nicht.) Jedenfalls möchten es viele für die folgenden (gar so üblichen) Situationen zur Hand haben:

  1. Gerade habe ich /lib/<Datei> gelöscht.

  2. Ich kann den Namen der Bibliothek nicht finden, weil ls dynamisch gebunden wurde, weil ich eine Shell benutze, die kein ls eingebaut hat und weil ich die Alternative "echo *" nicht kenne.

  3. Ich habe das statische sln-Kommando, aber ich weiß nicht, wie ich den Link nennen soll.

• Verschiedenes:

  • ctrlaltdel

  • kbdrate

  Um mit einigen Tastaturen zurechtzukommen, die wegen einer zu hohen Wiederholrate unbrauchbar sind, kann auf manchen Systemen kbdrate in /sbin zur Verfügung gestellt werden.

  Weil die Reaktion des Kerns auf die Tastenkombination Strg-Alt-Entf üblicherweise ein sofortiger Systemneustart ist, ist es ratsam, dieses Verhalten zu unterbinden, bevor das Wurzeldateisystem im Schreib-Lese-Modus eingebunden wird. Einige init-Verfahren sind dazu in der Lage, andere benötigen das Programm ctrlaltdel, das deshalb auf manchen Systemen unter /sbin zur Verfügung gestellt wird.

/usr/include : Header-Dateien für C-Programme

Folgende symbolischen Links werden benötigt, wenn ein C- oder ein C++-Compiler installiert ist - aber nur für Systeme, die nicht auf glibc basieren.

    /usr/include/asm -> /usr/src/linux/include/asm-<Architektur>
    /usr/include/linux -> /usr/src/linux/include/linux

/usr/src : Quellen

Für Systeme, die auf glibc basieren, gibt es keine weitergehenden Richtlinien zu diesem Verzeichnis. Für Systeme, die auf dem Vorläufer von glibc, der Linux-libc basieren, gelten folgende Regeln und folgender Hintergrund:

Der einzige Quellcode, der an einer bestimmten Stelle gespeichert werden soll, ist der des Linux-Systemkerns. Der wird abgelegt unter /usr/src/linux.

Wenn ein C- oder C++-Compiler installiert ist, aber nicht der komplette Quellcode des Linuxkerns, dann müssen die Include-Dateien des Kern-Quellcodes in folgenden Verzeichnissen sein:

    /usr/src/linux/include/asm-<Architektur>
    /usr/src/linux/include/linux

<Architektur> benennt dabei die Systemarchitektur.

/usr/src/linux darf ein symbolischer Link zum Verzeichnis der Kernquellen sein.

	Hintergrund
	Wichtig ist, dass die Include-Dateien für den Kern sich in /usr/src/linux und nicht in /usr/include befinden, sodass es keine Probleme gibt, wenn der Systemadministrator zum ersten Mal den Kern aktualisiert ("upgrade").

/var/spool/cron : cron- und at-Jobs

Dieses Verzeichnis enthält die variablen Daten für die Programme cron und at.