[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LINUX Filesystem standards
------------------------- linux fs std. part 2 -------------------------
/sbin : System binaries (binaries once kept in /etc)
Utilities used for system administration (and other root-only commands)
are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin typically
contains files essential for the booting phase of starting the system
up. Anything executed after /usr is known to be mounted (when there are
no problems) should be placed into /usr/sbin. Local-only system
administration stuff should now be placed into /usr/local/sbin.
The concept of what goes into "sbin" directories is simple. If a user
will need to run it, then it should go somewhere else. If it will only
be run by root (i.e., system administration commands, networking
daemons, system startup), then it should go in /sbin (or in /usr/sbin if
the item is not essential). Files such as `chfn' and `ac' which users
only occasionally use should still be placed in /usr/bin. `ping',
although it is absolutely necessary for root (network recovery and
diagnosis) is often used by users and should live in /bin for that
reason.
Let me state it one more time, if there is any chance at all that a user
should need to run it, do not put it here! Users should never have to
place /sbin (or any of the "sbin" directories) in their path. It is
true that they should probably not even be able to execute anything
dangerous in /sbin if you (and programmers) have done the job right. It
vis reasonable to want to let them see what files are in /sbin.
Therefore, don't make the directory totally unreadable unless you must.
/sbin was not created to protect users or to prevent them from seeing
the OS, but to provide a good division between binaries that everyone
uses and the commands that only administrators use (without exceptions).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
REQUIRED files for /sbin:
general:
{ getty, init, loadkeys, update, mkswap, swapon, swapoff }
shutdown commands:
{ halt, reboot, shutdown }
filesystem commands:
{ fdisk, fsck, fsck.*, tunefs (Ext2 only), mkfs, mkfs.*, mount, umount }
"*" = (ext, ext2, minix, msdos, xiafs)
LILO commands:
{ lilo }
networking:
{ arp, ifconfig, ifsetup, route }
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/sbin is traditionally known for statically linked files although as you
can see we have not even mentioned linking anything statically yet.
This is because we feel that the need for statically linked files is not
warranted except in several cases:
OPTIONAL files for /sbin:
Static ln and static sync are useful when things go wrong. The
primary use of sln (to repair hosed symlinks in /lib after a
poorly orchestrated upgrade) is no major longer a factor now
that the ldconfig program exists and can act as a guiding hand
in upgrading the dynamic libraries. Static sync is still useful
in some emergency situations.
{ sln, ssync }
------------------------------------------------------------------------
/tmp : temporary files
/tmp is normally treated differently than /usr/tmp. /tmp is usually
cleaned out on reboot and is often a memory based filesystem, where the
files in /usr/tmp stick around for an arbitrary length of time (system
tmp directories are not guaranteed to hold data for any length of time).
------------------------------------------------------------------------
/usr
/usr is the second major division of the filesystem. /usr is sharable
data. That means that /usr should be sharable between various machines
running Linux. Because it is sharable between machines, any information
that is machine-local must be stored elsewhere, hence /var enters the
picture.
/usr : Second major mount point (permanent)
|
|- X11 : The X windows directory (X Windows version 11)
|- bin : Most user commands
|- dict : Spelling dictionaries
|- doc : Miscellaneous documentation
|- etc : Other configuration files (for programs in /usr/bin)
|- g++-include : GNU C++ include files
|- games : Games and educational binaries
|- include : Header files included by C programs
|- info : The GNU info documentation system's primary directory
|- lib : Libraries
|- local : Local directory (empty after main installation)
|- man : Online manuals
|- sbin : Non-essential system administration binaries
|- share : Architecture-independent data
\- src : Source code
X11 is possibly a symlink to /usr/X386 or something else (/usr/X11R5,
for instance).
The following list of directory symbolic links need to be added. This
only needs to be done until compatibility with the /var scheme can be
assumed to exist.
/usr/adm -> /var/adm
/usr/preserve -> /var/preserve
/usr/spool -> /var/spool
/usr/tmp -> /var/tmp
/usr/spool/locks -> /var/lock
Most of the above symlinks should in time become unneeded as packages
are changed to support /var in addition to /usr. The exception, the
directory that should be referenced in /usr rather than /var is /usr/tmp
because some systems link it to different directories within /var.
The GNU Emacs lock file directory, if Emacs is installed, should be a
symlink pointing to /var/lock/emacs if you want to be able to mount
/usr read-only. It is usually found in /usr/emacs, /usr/lib/emacs, or
/usr/local/lib/emacs (preferably not the first).
------------------------------------------------------------------------
/usr/X11 : X386 X11 installation directory
|- bin
|- doc
|- include
|- lib
\- man
This hierarchy is reserved for the use of XFree86 X11 releases.
In order to simplify matters and make X386 more compatible with other
X11 packages from XFree86, our recommendation is to place a symbolic
link, /usr/X11 pointing to /usr/X386 (or whatever directory your X11
package was compiled to utilize).
------------------------------------------------------------------------
/usr/etc : Non-essential system configuration files
All non-essential system configuration should be placed in here.
Basically, files placed in here will be configuration for files in
/usr/bin or /usr/sbin.
Configuration files placed in here have to be not only non-essential but
non-host-specific, to allow /usr to be read-only and shared.
------------------------------------------------------------------------
/usr/lib : Libraries for programming and packages
|- X11 : Symbolic link to /usr/X11/lib
|- emacs : Support files for the GNU Emacs editor
|- groff : Libraries/directories for the GNU groff system
|- gcc-lib : System specific files/directories for GNU C compiler
|- terminfo : Directories for terminfo database
|- uucp : Commands for uucp
\- zoneinfo : Timezone information and configuration
The word, library, includes static data files and some internal binaries
as well (`sendmail'). `smail', if used, should be stored in /usr/bin
because it contains functionality that both administrators and users may
utilize on the command line.
------------------------------------------------------------------------
/usr/local : Local directory
|- bin : Local only binaries
|- etc : Configuration for local only binaries
|- games : Locally installed games
|- lib : Libraries for /usr/local
|- info : Local info pages
|- man : Man page hierarchy for /usr/local
|- sbin : Local only system administration
\- src : Local source code
The "local" has an often misinterpreted meaning. It is for use by the
system administrator to install software where he/she wishes that needs
to be safe from overwriting when the system software is updated. More
specifically, it is used to store anything that is sharable among a
group of machines, but not found in /usr (not default).
This directory should always be 100% empty after first installing Linux,
no exceptions to this rule should be made other than the listed
directory stubs.
Locally installed software should be placed within /usr/local rather
than /usr unless it is being installed to replace or upgrade software in
/usr or it is felt that the installed software is "important enough" to
place in /usr or in /.
------------------------------------------------------------------------
/usr/man : Manual page hierarchy
|- man1 : User programs
|- man2 : System calls
|- man3 : Library functions and subroutines
|- man4 : Devices
|- man5 : File formats
|- man6 : Games
|- man7 : Miscellaneous
|- man8 : System Administration
\- man9 : Kernel internal variables and functions
The cat page sections (cat[1-9]) containing formatted manual page
entries are also found within subdirectories of /usr/man, but are not
required nor should they be distributed in lieu of nroff source manual
pages.
Local and X Windows manual pages (if present) should be stored in
/usr/local/man and /usr/X11/man, respectively. These directories have a
similar structure to /usr/man (man[1-8], cat[1-8], empty subdirectories
being omitted).
As Linux (and UNIX) is further utilized in foreign countries and manual
pages are translated to non-English versions, there is the impending
problem that these manual pages will have to be stored somewhere else.
Some German releases of Linux have already created a manual page system
that is placed in /usr/man with the suffix "g". This is a poor solution
and will cause further problems in the long run as other languages
appear, especially other languages starting with the same letter (Greek,
Gaelic, whatever).
Therefore, all non-English manual pages sections should be stored in
subdirectories within /usr/man named according to the language that the
the contained manual pages are written in (lowercase characters), hence,
for the German manual pages:
/usr/man/german/man[1-9] and possibly /usr/man/german/cat[1-9]
Then, German-speaking Linux users can add /usr/man/german to their
MANPATH before /usr/man so that /usr/man/german manual pages are
referenced first. If a German manual page is not found for a given
command then the English version may be referenced. This setup will be
needed as the number of foreign (non-English) manual pages increases.
German is the language mentioned here since it is the only non-English
manual page system distributed with any Linux system at this time.
Other languages will probably follow and they should follow this scheme
as well. We only use German as our example because it was the first
non-English manual system to be completed.
The practice of placing non-English in subdirectories of /usr/man should
be followed as well for other manual page hierarchies, such as
/usr/local/man and /usr/X11/man.
Note: Using the language itself (/usr/man/deutsch) rather than the
English (/usr/man/german) was considered, but this was met with
disapproval from many people, including those who do not speak English
as a first language. The reasons include: simplicity, the difficulty in
displaying many languages' names in ASCII characters, and the fact that
everyone should be able to recognize their language name in English.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A description of each section follows:
man1: User programs
Manual pages that describe publicly accessible commands are contained
in this chapter. Most program documentation that a user will need to
use is located here.
man2: System calls
This section describes all of the system calls which are entries to
the Linux kernel (operating system). This section can be very useful
to programmers, but users have little need of the items in section 2.
man3: Library functions and subroutines
Section 3 describes user-level library routines. This is another
chapter that is only really of interest to programmers.
man4: Special files
Section 4 describes the special files, related driver functions, and
networking support available in the system. Typically, the device
files found in /dev.
man5: File formats
The formats for many nonintuitive data files are documented in the
section 5. This includes various include files, program output files,
and system files
man6: Games
This chapter documents games, demos, and generally trivial programs.
Different people have various notions about how essential this is.
man7: Miscellaneous
Manual pages that are difficult to classify are designated as being
section 7. The *roff and other text processing macro packages are
found here.
man8: System administration
Documentation for programs used by system administrators for system
operation and maintenance are documented here. Some of these programs
are also occasionally useful for normal users.
man9: Kernel internal variables and functions
This appears on Linux systems to document the kernel source code.
------------------------------------------------------------------------
/usr/sbin : Non-essential standard system binaries
Any non-essential system administration binaries, non-essential
networking daemons (most other than those mentioned to be in /sbin),
large system administration tools, interface programs, or anything
used only by the sysadmin that isn't essential.
Local system binaries and local administration shell scripts belong in
/usr/local/sbin.
------------------------------------------------------------------------
/usr/share : Architecture-independent data
The specifications for /usr/share will be included in a supplementary
draft to the main FSSTND draft.
------------------------------------------------------------------------
/usr/src : Source code
|
\- linux : Source code for Linus' kernel
Any non-local source code should be placed in this subdirectory, the
only thing in /usr/src that should always be placed in a certain
location is the kernel source (when present or linked in part to the
/usr/include structure). [ Author's note: Also, if you have any taste,
you'll learn to use subdirectories. Secondary note: Some people disagree
with me on this one...]
The source code for the kernel should always be in place or at least the
include files from the kernel source. Those files are located in these
directories:
/usr/src/linux/include/asm
/usr/src/linux/include/linux
/usr/include usually contains links to `asm' and `linux' in the source
directory, therefore, at least those include files should always be
distributed with installations. They should also be distributed in the
/usr/src/linux directory so there are no problems when system
administrators upgrade their kernel version for the first time.
------------------------------------------------------------------------
/var : Directories of files that _tend_ to grow or vary in size
|- adm : System logging and accounting files
|- domain : DNS files (for `named'), networking only
|- lock : Lock files
|- preserve : Used to save text edited by `vi' after crash or hang-up
|- spool : Directories for queuing work to be performed later
\- tmp : Second temporary directory
The directory for variable length files. This includes spools,
administrative files, logging files, transient files, and temporary
files.
A good reason to use /var is to make it possible to mount /usr
read-only. Everything that once went into /usr that is written to on a
temporary basis, now goes into /var. The aforementioned symbolic links,
also mentioned below in the issues and rationale section, should be
added to /usr for compatibility. This is very helpful if you are
mounting /usr through NFS or if you want a read-only /usr.
;; There is much more to /var than just this, but I am still trying to
;; figure out how to put it down...
------------------------------------------------------------------------
/var/adm : System logging and accounting files
All system logging should be written to this subdirectory and not to
/var/log. `wtmp' and `lastlog' should be stored here.
------------------------------------------------------------------------
/var/domain : DNS and `named' stuff
|- forward
\- reverse
This is only needed for systems using DNS (networking protocol for
name servers).
;; more expansion coming, this will possibly be renamed /var/named or
;; /var/bind
------------------------------------------------------------------------
/var/lock : Lock files
\- emacs : Emacs lock files
Lock files should be stored with a subdirectory of /var/lock appropriate
subdirectory such as the emacs lock file directory. This directory
*does not* replace older locations for lock files other than
/usr/spool/uucp and the serial lock files that were contained within it.
If you are the maintainer of a program that uses lock files and you wish
to add a subdirectory for lock files within /var/lock, then it is a good
idea to contact the FSSTND channel or myself to discuss placement of a
directory for your lock files.
If you are interested in being able to mount /usr read-only then you may
wish to recompile whatever package it is that uses /usr for lock files
and place them in here, again - contact me if you want to add stuff on a
permanent basis (i.e., you are a developer or a programmer of a Linux
package).
The Emacs editor's lock files should be saved in /var/lock/emacs. It is
necessary to recompile Emacs to do this or to place an appropriate
symlink where the Emacs lock file directory lies.
------------------------------------------------------------------------
/var/spool : Spooling directories (queue work, work to be done later)
|- at : at jobs
|- cron : Cron jobs
|- lpd : Printer spool directory
|- mail : Directory for user mailboxes
|- mqueue : Outgoing mail queue
\- uucp : Spool directory for uucp
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/var/spool/lpd : Printer spool directory
|- {printer name} : Spools for a specific printer
\- {printer name}.LOCK : Lock file for a specific printer
------------------------------------------------------------------------
Issues and Additional Rationale
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What is Essential?
The answer is: essential to clean, create, prepare, check, find and
mount other filesystems (possibly on remote machines). There are other
definitions, but this is a general definition that most people will at
least incorporate into their own.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Networking
Networking presented an interesting dilemma. Many people like to place
networking binaries and configuration separate from other binaries and
configuration. However, we disagree. We feel that networking is not a
"package", but an integral part of most UNIX machines. Because of this
networking should not be placed into a single directory, but
systematically placed in the appropriate directories.
/bin : anything a user will want to use that is also
considered essential (ftp, netstat, ping)
/sbin : anything only root needs and is considered
essential (arp, ifconfig, ifsetup, route)
/usr/bin : any binaries a user will want to use, but are not
essential (finger, rcp, rlogin, telnet, et al.)
/usr/sbin : any root only networking binaries that are not
essential (networking daemons, lpd, et al.)
While this may seem confusing at first (and it does take a moment to
digest), it does make sense. If you can only mount root for some reason
and you need access to networking to repair your system, you don't need
the files to be off in /usr/etc (as they often are). Files that are
needed to mount /usr in normal (and emergency situations) are placed on
the root subtree and any others are placed in /usr in order to keep the
size of root small.
Configuration files for networking similarly go into /etc and /usr/etc.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architecture-independent Structures
Many people have noted that in this draft, that there was no /usr/share.
There is now. The structure, /usr/share, typically contains
architecture-independent files such as man-pages, timezone, terminfo
information, et al. As of this time, there are no different
architectures for Linux, but with the passage of time we should see
Linux include other architectures and other UNIX systems.
One note, no program should ever reference anything in /usr/share, for
instance, a manual page program should never directly look in
/usr/share/man/man1/ls.1, but it should reference /usr/man/man1/ls.1 at
all times. Anything in /usr/share will be "pointed-to" by the use of
symlinks from other areas in the filesystem, such as /usr/man,
/usr/lib/{something}, etc.
The specifications for /usr/share are still be worked out and discussion
with on the FSSTND channel or with me is encouraged (by me).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Symbolic Links
There are a wide range of uses for symbolic links (symlinks) in every
filesystem. While symlinks are not encouraged for default setup (found
after installing Linux) in a standard such as this, they are often used
with good purpose on different systems. The point is that symlinks
should be there to keep everything where everyone else expects find it
Be prepared to accept that certain directories, even those contained on
the root directory, are still going to be symlinks. For instance, on
some systems /home will not be on the root, but symlinked to a /var
directory, or to somewhere else. /home could also have its own physical
partition, of course, and be mounted on its own.
Similarly, because /usr might be on a central fileserver mounted via
NFS, /usr/local could be symlinked to /var/local. Like /usr/emacs/lock,
this change can be justified by recalling one definition of /var:
"directories of files that vary on different systems and machines".
Sometimes systems will also link /tmp to /var/{something} if the root
partition becomes too small (or starts out too small). There are more
examples of "good" uses of symbolic links, but the entire issue boils
down to two things: packages should be able to find things where they
expect them (within reason) and symbolic links can be used to solve the
problem in many cases. However, problems also can arise from using too
many symbolic links. These problems include over-reliance on symbolic
links to solve problems, confusion resulting from overuse of symbolic
links, and the aesthetic preferences of different people.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statically linked binaries
Linux is currently running on a wide variety of systems, some single
user with small disks, some as servers in large networked environments.
Because of this variety, this standard sets no rule regarding what
binaries are static or dynamic with the following two exceptions. Both
`ln' and `sync' should have static versions in /sbin in addition to
dynamic versions in /bin since everyday users may wish to run these too.
Large Linux systems may wish to include other statically linked binaries
(sh, init, mkfs, fsck, tunefs, mount, umount, swapon, swapoff, getty,
login, etc.). The developers and/or system administrators are free to
statically/dynamically link these and other binaries as they see fit, as
long as the location of the binaries doesn't change.
Networked systems (especially those of the future which may lack floppy
drives), may want to make ifconfig, route, hostname, and other
networking utilities static as well. This is usually not needed.
------------------------------------------------------------------------
ACKNOWLEDGEMENTS
Credit for this text should be given to the FSSTND activists,
developers, users, and system administrators whose input was
essential to this standard. I also wish to thank each of the
contributors who helped me to write, compile, and compose this,
a consensus standard.
I also wish to give real credit to the Linux developers who have
seen that giving Linux a common filesystem layout is something
that be further the development of the Linux operating system.
------------------------------------------------------------------------
Contributors:
[in alphabetical order]
Drew Eckhardt <drew@kinglear.cs.colorado.edu>
Ian Jackson <ijackson@nyx.cs.du.edu>
Ian McCloghrie <ian@ucsd.edu>
Daniel Quinlan <quinlan@bucknell.edu>
Mike Sangrey <mike@sojurn.lns.pa.us>
David H. Silber <dhs@glowworm.firefly.com>
Theodore Ts'o <tytso@athena.mit.edu>
Stephen Tweedie <sct@dcs.ed.ac.uk>
------------------------------------------------------------------------