Systems Administration Chapter 5: The File Hierarchy
Page 85
Chapter
The File Hierarchy

Introduction
Why?
Like all good operating systems, UNIX allows you the privilege of storing
information indefinitely (or at least until the next disk crash) in abstract data
containers called files. The organisation, placement and usage of these files comes
under the general umbrella of the file hierarchy. As a Systems Administrator, you
will need to be very familiar with the file hierarchy. You will use it on a day to day
basis as you maintain the system, install software and manage user accounts.
At a first glance, the file hierarchy structure of a typical Linux host (we will use Linux
for the basis of our discussion) may appear to have been devised by a demented
genius who'd been remiss with their medication. Why, for example, does the root
directory contain something like:

bin etc lost+found root usr
boot home mnt sbin var
dev lib proc tmp
Why was it done like this?
Historically, the location of certain files and utilities has not always been standard (or
fixed). This has led to problems with development and upgrading between different
"distributions" of Linux [Linux is distributed from many sources; major sources
include packages from Red Hat, Debian and Mandrake]. The Linux directory
structure (or file hierarchy) was based on existing flavours of UNIX, but as it evolved,
certain inconsistencies developed. These were often small things like the location (or
placement) of certain configuration files, but it resulted in difficulties porting software
from host to host.
To combat this, a file standard was developed. This is an evolving process, to date

resulting in a fairly static model for the Linux file hierarchy. In this chapter, we will
examine how the Linux file hierarchy is structured, how each component relates to the
overall OS and why certain files are placed in certain locations.

Linux File System Standard
The location and purposes of files and directories on a Linux machine are defined by
the Linux File Hierarchy Standard. The official website for the Linux File Hierarchy
Standard is
Systems Administration Chapter 5: The File Hierarchy
Page 86
The important sections
The root of the problem
The top level of the Linux file hierarchy is referred to as the root (or /). The root
directory typically contains several other directories including:

Directory Contains
bin/
Required Boot-time binaries

boot/
Boot configuration files for the OS loader and kernel image
dev
/
Device files

etc/
System configuration files and scripts

home/
User/Sub branch directories


lib/
Main OS shared libraries and kernel modules

lost+found/
Storage directory for "recovered" files

mnt/
Temporary point to connect devices to

proc/
Pseudo directory structure containing information about the
kernel, currently running processes and resource allocation

root/
Linux (non-standard) home directory for the root user. Alternate
location being the / directory itself

sbin/
System administration binaries and tools

tmp/
Location of temporary files
usr/
Difficult to define - it contains almost everything else including
local binaries, libraries, applications and packages (including X
Windows) and intended usage varies between distributions

var/
Variable data, usually machine specific. Includes spool

directories for mail and news
Table 5.1
Major Directories
Generally, the root should not contain any additional files - it is considered bad form
to create other directories off the root, nor should any other files be placed there.
Why root?
The name “root” is based on the analogous relationship between the UNIX files
system structure and a tree! Quite simply, the file hierarchy is an inverted tree.
I can personally never visiualise an upside down tree – what this phrase really means
is that the “top” of the file heirarchy is at one point, like the root of a tree, the bottom
is spread out, like the branches of a tree. This is probably a silly analogy because if
you turn a tree upside down, you have lots of spreading roots, dirt and several
thousand very unhappy worms!
Every part of the file system eventually can be traced back to one central point, the
root. The concept of a “root” structure has now been (partially) adopted by other
operating systems such as Windows NT. However, unlike other operating systems,
UNIX doesn't have any concept of “drives”. While this will be explained in detail in
a later chapter, it is important to be aware of the following:
Systems Administration Chapter 5: The File Hierarchy
Page 87

· The file system may be spread over several
physical devices; different parts of the file hierarchy may exist on totally separate
partitions, hard disks, CD-ROMs, network file system shares, floppy disks and
other devices
· This separation is transparent to the file
system hierarchy, user and applications
· Different “parts” of the file system will be
“connected” (or mounted) at startup; other parts will be dynamically attached as
required


The remainder of this chapter examines some of the more important directory
structures in the Linux file hierarchy.
Homes for users
Every user needs a home...
The
/home
directory structure contains the home directories for most login-enabled
users (some notable exceptions being the root user and (on some systems) the
www/web user). While most small systems will contain user directories directly off
the
/home
directory (for example,
/home/jamiesob
), on larger systems it is common
to subdivide the home structure based on classes (or groups) of users, for example:

/home/admin # Administrators
/home/finance # Finance users
/home/humanres # Human Resource users
/home/mgr # Managers
/home/staff # Other people
Other homes?
/root
is the home directory for the root user. If, for some strange reason, the
/root
directory doesn't exist, then the root user will be logged in with the
/
directory - this
is actually the traditional location for root users.

There is some debate as to allowing the root user to have a special directory as their
login point - this idea encourages the root user to set up their
.profile
, use "user"
programs like
elm
,
tin
and
netscape
(programs which require a home directory in
which to place certain configuration files) and generally use the root account as a
beefed-up user account. A Systems Administrator should never use the root account
for day to day user-type interaction; the root account should only be used for system
administration purposes only.

Be aware that you must be extremely careful when allowing a user to have a home
directory in a location other than the
/home
branch. The problem occurs when you,
as a Systems Administrator, have to back-up the system - it is easy to miss a home
directory if it isn't grouped with others in a common branch (like
/home
).

Systems Administration Chapter 5: The File Hierarchy
Page 88
/usr
and
/var


And the difference is...
It is often confusing to see that
/usr
and
/var
both contain similar directories:
/usr
bin games lib lost+found src
dict include libexec sbin tmp
etc kerberos local share X11R6

/var
cache lib lost+found opt tmp
db local mail preserve www
empty lock named run yp
gdm log nis spool

It becomes even more confusing when you start examining the maze of links which
intermingle the two major branches.
Links are a way of referencing a file or directory by many names and many locations
within the file hierarchy. They are effectively like "pointers" to files - think of them as
like leaving a post-it note saying "see this file". Links will be explained in greater
detail in the next chapter.
To put it simply,
/var
is for VARiable data/files.
/usr
is for USeR accessible data,
programs and libraries. Unfortunately, history has confused things - files which

should have been placed in the
/usr
branch have been located in the
/var
branch and
vice versa. Thus to "correct" things, a series of links have been put in place. Why the
reason for the separation? Does it matter? The answer is: Yes, but No :)
“Yes” in the sense that the file standard dictates that the
/usr
branch should be able
to be mounted (another way of saying "attached" to the file hierarchy - this will be
covered in the next chapter) READ ONLY (thus can't contain variable data). The
reasons for this are historical and came about because of something called NFS
exporting.
NFS exporting is the process of one machine (a server) "exporting" its copy of the
/usr
structure (and others) to the network for other systems to use.
If several systems were "sharing" the same
/usr
structure, it would not be a good
idea for them all to be writing logs and variable data to the same area! It is also used
because minimal installations of Linux can use the
/usr
branch directly from the
CDROM (a read-only device).
However, it is "No" in the sense that:
·
/usr
is usually mounted READ-WRITE-
EXECUTE on Linux systems anyway

· In the author's experience, exporting
/usr

READ-ONLY via NFS isn't entirely successful without making some very non-
standard modifications to the file hierarchy!
The following are a few highlights of the
/var
and
/usr
directory branches:
Systems Administration Chapter 5: The File Hierarchy
Page 89
/usr/local
All software that is installed on a system after the operating system package itself
should be placed in the
/usr/local
directory. Binary files should be located in the

/usr/local/bin
(generally
/usr/local/bin
should be included in a user's
PATH

setting). By placing all installed software in this branch, it makes backups and
upgrades of the system far easier - the Systems Administrator can back-up and restore
the entire
/usr/local
system with more ease than backing-up and restoring software
packages from multiple branches (i.e.

/usr/src
,
/usr/bin
etc).

An example of a
/usr/local
directory is listed below:

bin include libpng-1.2.5 samba
doc jpeg-6b mysql sbin
etc lib mysql-max-3.23.51-pc-linux-gnu-i686 share
games libexec php4 src

As you can see, there are a few standard directories (
bin
,
lib
and
src
) as well as
some that contain installed programs and libraries.

Most distributions seem to have their own ideas about
/usr/local
. An example of a
distribution straying from the FHS is Red Hat’s intended use of the
/usr/local

directory. The FHS says that

/usr/local
should be where you store software that is
to remain safe from system software upgrades. The Official Red Hat Linux Reference
Guide states that since system upgrades from Red Hat are done safely with the
rpm

command, you do not need to protect files by putting them in
/usr/local
. Instead, it
recommends you use
/usr/local
for software that is local to your machine.
lib, include and src
Linux is a very popular platform for
C/C++
,
Java
and
Perl
program development. As
we will discuss in later chapters, Linux also allows the Systems Administrator to
actually modify and recompile the kernel. Because of this, compilers, libraries and
source directories are treated as "core" elements of the file hierarchy structure.
The
/usr
structure plays host to three important directories:
·
/usr/include

Holds most of the standard

C/C++
header files - this directory will be referred to as
the primary include directory in most Makefiles.
Makefiles are special script-like files that are processed by the make program for
the purposes of compiling, linking and building programs.
·
/usr/lib
Holds most static libraries as well as hosting subdirectories containing libraries for
other (non
C/C++
) languages including
Perl
and
TCL
. It also plays host to
configuration information for
ldconfig
(try
man ldconfig
for information on
this program).
·
/usr/src
Holds the source files for most packages installed on the system. This is
traditionally the location for the Linux source directory, for example:
linux-2.4 linux-2.4.18-14 redhat
Unlike DOS/Windows based systems, most Linux programs usually come as
source and are compiled and installed locally.