Filesystem Hierarchy Standard
Filesystem Hierarchy Standard
Here are some excerpts to help explain why GT.M needs to go in /opt and not /usr/local. You may want to glance at some of this to understand why the FHS was written, why it's important, and why software distributions (like GT.M) need to be placed in a certain directory.
Here is the home of the Filesystem Hierarchy Standard (FHS). Refer to the original for the complete text. The copy you are reading is version 2.3, announced January 29, 2004.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Contents
Introduction
This standard consists of a set of requirements and guidelines for file and directory placement under UNIX-like operating systems. The guidelines are intended to support interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems.
Purpose
This standard enables:
• Software to predict the location of installed files and directories, and
• Users to predict the location of installed files and directories.
We do this by:
• Specifying guiding principles for each area of the filesystem,
• Specifying the minimum files and directories required,
• Enumerating exceptions to the principles, and
• Enumerating specific cases where there has been Historical conflict.
The FHS document is used by:
• Independent software suppliers to create Applications which are FHS compliant, and work with distributions which are FHS complaint,
• OS creators to provide systems which are FHS compliant, and
• Users to understand and maintain the FHS compliance of a system.
The FHS document has a limited scope:
• Local placement of local files is a local issue, so FHS does not attempt to usurp system administrators.
• FHS addresses issues where file placements need to be coordinated between multiple parties such as local sites, distributions, Applications, documentation, etc.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The Filesystem
This standard assumes that the operating system underlying an FHS-compliant file system supports the same basic security features found in most UNIX filesystems.
It is possible to define two independent distinctions among files: shareable vs. unshareable and variable vs. static. In general, files that differ in either of these respects should be located in different directories. This makes it easy to store files with different usage characteristics on different filesystems.
"Shareable" files are those that can be stored on one host and used on others. "Unshareable" files are those that are not shareable. For example, the files in user home directories are shareable whereas device lock files are not.
"Static" files include binaries, libraries, documentation files and other files that do not change without system administrator intervention. "Variable" files are files that are not static.
Rationale:
Shareable files can be stored on one host and used on several others. Typically, however, not all files in the filesystem hierarchy are shareable and so each system has local storage containing at least its unshareable files. It is convenient if all the files a system requires that are stored on a foreign host can be made available by mounting one or a few directories from the foreign host.
Static and variable files should be segregated because static files, unlike variable files, can be stored on read-only media and do not need to be backed up on the same schedule as variable files. Historical UNIX-like filesystem hierarchies contained both static and variable files under both /usr and /etc. In order to realize the advantages mentioned above, the /var hierarchy was created and all variable files were transferred from /usr to /var. Consequently /usr can now be mounted read-only (if it is a separate filesystem). Variable files have been transferred from /etc to /var over a longer period as technology has permitted.
Here is an example of a FHS-compliant system. (Other FHS-compliant layouts are possible.)
┌────────┬───────────────┬───────────┐ │ │ shareable │unshareable│ ├────────┼───────────────┼───────────┤ │static │/usr │/etc │ ├────────┼───────────────┼───────────┤ │ │/opt │/boot │ ├────────┼───────────────┼───────────┤ │variable│/var/mail │/var/run │ ├────────┼───────────────┼───────────┤ │ │/var/spool/news│/var/lock │ └────────┴───────────────┴───────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The Root Filesystem
/opt : Add-on Application software packages
Purpose
/opt is reserved for the installation of add-on Application software packages.
A package to be installed in /opt must locate its static files in a separate / opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider's LANANA registered name.
Requirements
Directory Description <package> Static package objects <provider> LANANA registered provider name
The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt /man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories.
Programs to be invoked by users must be located in the directory /opt/<package> /bin or under the /opt/<provider> hierarchy. If the package includes UNIX manual pages, they must be located in /opt/<package>/share/man or under the / opt/<provider> hierarchy, and the same substructure as /usr/share/man must be used.
Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information.
Host-specific Configuration files must be installed in /etc/opt. See the section on /etc for more information.
No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock and devices must be located in /dev.
Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.
Rationale:
The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition), provides for an /opt structure very similar to the one defined here.
The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a similar structure for /opt.
Generally, all data required to support a package on a system must be present within /opt/<package>, including files intended to be copied into /etc/opt/<package> and /var/opt/<package> as well as reserved directories in/opt.
The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution-installed and locally-installed software, especially in the case of fixed pathnames found in some binary software.
The structure of the directories below /opt/<provider> is left up to the packager of the software, though it is recommended that packages are installed in /opt/<provider>/<package> and follow a similar structure to the guidelines for /opt/package. A valid reason for diverging from this structure is for support packages which may have files installed in /opt/ <provider>/lib or /opt/<provider>/bin.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The /usr Hierarchy
Purpose
/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.
Large software packages must not use a direct subdirectory under the /usr hierarchy.
Requirements
The following directories, or symbolic links to directories, are required in / usr.
Directory Description bin Most user commands include Header files included by C programs lib Libraries local Local hierarchy (empty after main installation) sbin Non-vital system binaries share Architecture-independent data
Specific Options
Directory Description X11R6 XWindow System, version 11 release 6 (optional) games Games and educational binaries (optional) lib<qual> Alternate Format Libraries (optional) src Source code (optional)
An exception is made for the X Window System because of considerable precedent and widely-accepted practice.
The following symbolic links to directories may be present. This possibility is based on the need to preserve compatibility with older systems until all implementations can be assumed to use the /var hierarchy.
/usr/spool -> /var/spool /usr/tmp -> /var/tmp /usr/spool/locks -> /var/lock
Once a system no longer requires any one of the above symbolic links, the link may be removed, if desired.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
/usr/local : Local hierarchy
Purpose
The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.
Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr. [27]
Requirements
The following directories, or symbolic links to directories, must be in /usr/ local
Directory Description bin Local binaries etc Host-specific system [[configuration~|Configuration]] for local binaries games Local game binaries include Local C header files lib Local libraries man Local online manuals sbin Local system binaries share Local architecture-independent hierarchy src Local source code
No other directories, except those listed below {omitted}, may be in /usr/local after first installing a FHS-compliant system.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Background of the FHS
The process of developing a standard filesystem hierarchy began in August 1993 with an effort to restructure the file and directory structure of Linux. The FSSTND, a filesystem hierarchy standard specific to the Linux operating system, was released on February 14, 1994. Subsequent revisions were released on October 9, 1994 and March 28, 1995.
In early 1995, the goal of developing a more comprehensive version of FSSTND to address not only Linux, but other UNIX-like systems was adopted with the help of members of the BSD development community. As a result, a concerted effort was made to focus on issues that were general to UNIX-like systems. In recognition of this widening of scope, the name of the standard was changed to Filesystem Hierarchy Standard or FHS for short.
Volunteers who have contributed extensively to this standard are listed at the end of this document. This standard represents a consensus view of those and other contributors.
General Guidelines
Here are some of the guidelines that have been used in the development of this standard:
• Solve technical problems while limiting transitional difficulties.
• Make the specification reasonably stable.
• Gain the approval of distributors, developers, and other decision-makers in relevant development groups and encourage their participation.
• Provide a standard that is attractive to the implementors of different UNIX-like systems.
Scope
This document specifies a standard filesystem hierarchy for FHS filesystems by specifying the location of files and directories, and the contents of some system files.
This standard has been designed to be used by system integrators, package developers, and system administrators in the construction and maintenance of FHS compliant filesystems. It is primarily intended to be a reference and is not a tutorial on how to manage a conforming filesystem hierarchy.
The FHS grew out of earlier work on FSSTND, a filesystem organization standard for the Linux operating system. It builds on FSSTND to address interoperability issues not just in the Linux community but in a wider arena including 4.4BSD-based operating systems. It incorporates lessons learned in the BSD world and elsewhere about multi-architecture support and the demands of heterogeneous networking.
