LPI Linux Certification in a Nutshell (33 page)
Read LPI Linux Certification in a Nutshell Online
Authors: Adam Haeder; Stephen Addison Schneiter; Bruno Gomes Pessanha; James Stanger
Tags: #Reference:Computers
Finding links to a file
Finding the file pointed to by a symbolic link is
simple. The
ls -l
command displays a
convenient pointer notation, indicating just where links are
pointing:
lrwxrwxrwx 1 root root 19 Jan 4 02:43 file1 -> /file1
Going the other way and finding symbolic links to a file is
less obvious but is still relatively easy. The
-lname
option to the
find
utility locates them for you
by searching for symbolic links
containing
the original filename.
Here, the entire local filesystem is searched for
myfile
, turning up three symbolic links:
#find / -lname myfile/home/world/rootsfile
/home/finance/hisfile
/root/myslink
Remember that symbolic links could be anywhere, which includes
a remote system (if you’re sharing files), so you may not be able to
locate them all. (See
Objective 3: Perform Basic File Management
, for
additional information on the
find
command).
Since hard links aren’t really links but duplicate directory
entries, you can locate them by searching directory entries for the
inode, which is identical in all the links. Unlike symbolic links,
you are guaranteed to find all of the links since hard links cannot
cross filesystem boundaries. First, identify the inode you’re
interested in, as well as the filesystem that contains the
links:
#df file1Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda9 1981000 451115 1427473 24% /home
#ls -i file90469 file1
file1
is on the
/home
filesystem, and its inode
number is 90469. Next,
find
is used with the
-inum
option to locate all instances of inode 90469:
#find /home -inum 90469/home/world/file1
/home/finance/file1
/home/jdoe/private/.myfile1
This example turns up three links to
file1
, including one that user
jdoe
appears to be hiding!
On the Exam
You should be prepared to identify the differences between
hard and symbolic links, when each is used, and their
limitations.
Location
In 1993, the Linux community formed a project to provide a
standardized filesystem
layout for all general-purpose distributions of Linux. The
intent of this standardization was to provide advice on how to reduce the
proliferation of proprietary Linux filesystem layouts and their possible
contribution to market fragmentation.
The project released a document describing the Linux Filesystem
Standard, usually abbreviated
FSSTND, in 1994. The following year, the group began to
reduce Linux-specific content and to refine the standard to include other
Unix or Unix-like operating systems. As the FSSTND attracted broader
appeal, it was renamed the
Filesystem
Hierarchy Standard
.
Although the FHS is not a requirement of Linux developers and
distributors, the Linux community understands the importance of standards,
and all major distributions support the standard.
The full FHS specification is available at
http://www.pathname.com/fhs/
. The
information in this chapter is consistent with version 2.3 of the
specification.
To frame its recommendations, the FHS defines two
categories of data use, each with two opposing subtypes:
- Data sharing
This category defines the scope of data use in a
networked environment:- Sharable
Sharable data can be used by multiple host
systems on a network. Sharable files contain general-purpose
information, without ties to any specific host. Examples
include user data files, executable program files, and
system documentation.- Nonsharable
Data is not sharable when linked to a specific
host, such as a unique configuration file.
- Sharable
- Data modification
This category specifies how data changes:
- Variable
Data is considered variable when changed by
natural, frequent processes. Examples include user files and
system logfiles, such as
/var/log/messages
.- Static
Static data is left alone for the most part,
remaining the same from day to day or even year to year.
Examples include binary programs such as
ls
and
bash
, which
change only when the system administrator performs an
upgrade
.
- Variable
Some directories in the Linux filesystem are intended to hold
specific types of data. For example, the executable files in
/usr
are rarely changed, and thus could be defined
as
static
because they are needed by all users on a
network. Before disks were as large as they are today, the files
commonly found in
/usr
were often mounted from
remote servers to preserve local disk space. Thus, in addition to being
static,
/usr
is said to be
sharable
. Keeping files organized with respect to
these attributes can simplify file sharing, system administration, and
backup complexity, as well as reduce storage requirements. The FHS
arranges the preceding data categories into a 2 × 2 matrix, as shown
with a few example directories in
Table 7-6
.
Table 7-6. FHS datatypes
| | Sharable | Nonsharable |
|---|---|---|
Static | /usr /usr/local | /etc /boot |
Variable | /var/mail /home | /var/log /proc |
On many networks,
/usr
and
/usr/local
are mounted by individual workstations
from an NFS server. This can save a considerable amount of local storage
on the workstations. More importantly, placing these directories on
another system can make upgrades and additions much simpler. These
directories are usually shared as read-only filesystems because they are
never modified by most end users. The
/var/mail
and
/home
directories, on the other hand, are shared
but must be changed regularly by users. The
/etc
and
/boot
directories contain files that are static
in the sense that only the administrator changes them, but sharing them
is not necessary or advised, because they are local configuration files.
The
/var/log
and
/proc
directories are very dynamic but also of local interest only.
The FHS offers a significant level of detail describing
the exact locations of files, using rationale derived from the
static/variable and sharable/nonsharable definitions. However, knowledge
of the location of every file is not necessary or required for Exam 101.
This section discusses the major portions of the FHS directory hierarchy
overall, with specific example files offered as illustrations.
Although the FHS is a defining document for the Linux
filesystem, it does not follow that all directories described in the
FHS will be present in all Linux installations. Some directory
locations cited in the FHS are package-dependent or open to
customization by the vendor.
The root filesystem is located at the top of the entire directory
hierarchy. The FHS defines these goals for the root filesystem:
It must contain utilities and files sufficient to boot the
operating system, including the ability to mount other filesystems.
This includes utilities, device files, configuration, boot loader
information, and other essential start-up data.It should contain the utilities needed by the system
administrator to repair or restore a damaged system.It should be relatively small. Small partitions are less
likely to be corrupted due to a system crash or power failure than
large ones are. In addition, the root partition should contain
nonsharable data to maximize the remaining disk space for sharable
data.Software should not create files or directories in the root
filesystem.
Although a Linux system with everything in a single root partition
may be created, doing so would not meet these goals. Instead, the root
filesystem should contain only essential system directories, along with
mount points for other filesystems. Essential root filesystem
directories include:
- /bin
The
/bin
directory contains
executable system commands such as
cp, date, ln, ls,
mkdir
, and
more
. These commands
are deemed essential to system administration in case of a
problem.- /dev
Device files, necessary for accessing disks and
other devices, are stored in
/dev
. Examples include disk
partitions, such as
hda1
, and terminals, such
as
tty1
. Devices must be present at boot time
for proper mounting and configuration. The exception to this rule
is systems using
devfs
, which is a relatively
recent addition to the Linux kernel that makes
/dev
a virtual filesystem, much like
/proc
, where device-special files are created
by the kernel when drivers register devices. Use of
devfs
is currently not covered by the Level 1
Objectives.- /etc
The
/etc
directory contains
configuration information unique to the system and is required for
boot time. No binary executable programs are stored here. Prior
practice in various versions of Unix had administrative executable
programs stored in
/etc
. These have been
moved to
/sbin
under the FHS. Example files
include
passwd, hosts
, and
login.defs
.- /lib
The
/lib
directory contains
shared libraries and kernel modules, both essential for system
initialization.- /mnt
This directory is provided for the local system
administrator’s use. Generally, it is empty except for some mount
points for temporary partitions, including
cdrom
and
floppy
.- /root
The recommended default (but optional) home
directory for the
superuser is
/root
. Although
it is not absolutely essential for
/root
to
be on the root filesystem, it is customary and convenient, because
doing so keeps root’s configuration files available for system
maintenance or recovery.- /sbin
Essential utilities used for system administration
are stored in
/sbin
. Examples include
fdisk, fsck
, and
mkfs
.
The remaining top-level directories in the root filesystem are
considered nonessential for emergency procedures:
- /boot
The
/boot
directory contains
files for the boot loader (such as LILO or GRUB). Because it is
typically small, it can be left in the root filesystem. However,
it is often separated to keep the boot loader files within the
first 1,024 cylinders of a physical disk.- /home
The
/home
filesystem contains
home directories for system users. This is usually a separate
filesystem and is often the largest variable filesystem in the
hierarchy.- /opt
The
/opt
directory is intended
for the installation of software other than that packaged with the
operating system. This is often the location selected by
third-party software vendors for their products.- /tmp
The
/tmp
directory is for the
storage of temporary files. The FHS recommends (but does not
require) that its contents are deleted upon every system
boot.- /usr
The
/usr
filesystem contains a
significant hierarchy of executable programs deemed nonessential
for emergency procedures. It is usually contained in a separate
partition. It contains sharable, read-only data, and is often
mounted locally read-only and shared via NFS read-only.
/usr
is described in detail in the next
section.- /var
Like
/usr
, the
/var
filesystem contains a large hierarchy
and is usually contained in a separate partition. It holds data
that varies over time, such as logs, mail, and spools.
The
/usr
filesystem hierarchy contains
system utilities and programs that do not appear in the root
partition. For example, user programs such as
less
and
tail
are found in
/usr/bin. /usr/sbin
contains system
administration commands such as
adduser
and
traceroute
, and a number of daemons needed only
on a normally operating system. No host-specific or variable data is
stored in
/usr
. Also disallowed is the placement
of directories directly under
/usr
for large
software packages. An exception to this rule is made for X11, which
has a strong precedent for this location.
The following subdirectories may be found under
/usr
:
- /usr/X11R6
This directory contains files for XFree86. Because X is
deployed directly
under
/usr
on many Unix
systems, X breaks the rule that usually prohibits a custom
/usr
directory for a
software package.- /usr/bin
The
/usr/bin
directory is the primary
location for user commands that are not considered essential for
emergency system maintenance (and thus are stored here rather
than in
/bin
).- /usr/include
/usr/include
is the standard location
for
include
or
header
files, used for C and C++ programming.- /usr/lib
This directory contains shared libraries that support
various programs. FHS also allows the creation of
software-specific directories here. For example,
/usr/lib/perl5
contains the standard
library of Perl modules that implement programming functions in
that language.- /usr/local
/usr/local
is the top level of
another hierarchy of binary files, intended for use by the
system administrator. It contains subdirectories much like
/usr
itself, such as
/bin,
/include, /lib
, and
/sbin
. After
a fresh Linux installation, this directory contains no files but
may contain an empty directory hierarchy. Example items that may
be found here are locally created documents in
/usr/local/doc
or
/usr/local/man
, and executable scripts and
binary utilities provided by the system administrator in
/usr/local/bin
.- /usr/sbin
The
/usr/sbin
directory is the
primary location for system administration commands that are not
considered essential for emergency system maintenance (and thus
are stored here rather than in
/sbin
).- /usr/share
/usr/share
contains a hierarchy of
datafiles that are independent of, and thus can be shared among,
various hardware architectures and operating system versions.
This is in sharp contrast to architecture-dependent files such
as those in
/usr/bin
. For example, in an
enterprise that uses both i386- and Alpha-based Linux systems,
/usr/share
could be offered to all systems
via NFS. However, since the two processors are not
binary-compatible,
/usr/bin
would have two
NFS shares, one for each architecture.The information stored in
/usr/share
is static data, such as the GNU
info
system
files, dictionary files, and support files for software
packages.- /usr/src
/usr/src
is an optional directory on
all modern glibc-based systems. On older libc4- and libc5-based
systems,
/usr/src/linux
was expected to
contain a copy of the kernel source, or at least the directories
include/asm
and
include/linux
for kernel header
files.On glibc-based systems, nothing should refer to the
/usr/src/linux
directory. In fact, leaving
kernel source at that location is generally regarded as a bad
practice, since it has the potential to confuse old
software.
The
/var
filesystem contains data
such as printer spools and logfiles that vary over time. Since
variable data is always changing and growing,
/var
is usually contained in a separate partition
to prevent the root partition from filling. The following
subdirectories can be found under
/var
:
- /var/account
Some systems maintain process accounting data in this
directory.- /var/cache
/var/cache
is intended for use by
programs for the temporary storage of intermediate data, such as
the results of lengthy computations. Programs using this
directory must be capable of regenerating the cached information
at any time, which allows the system administrator to delete
files as needed. Because it holds transient data,
/var/cache
never has to be backed
up.- /var/crash
This optional directory holds crash dumps for systems that
support that feature.- /var/games
This optional directory is used to store state
information, user score data, and other transient items.- /var/lock
Lock files, used by applications to signal their existence
to other processes, are stored here. Lock files usually contain
no data.- /var/log
The
/var/log
directory is the main
repository for system logfiles, such as those created by the
syslog system. For example, the default system logfile is
/var/log/messages
.- /var/mail
This is the system mailbox, with mail files for each user.
/var/mail
is a replacement for
/var/spool/mail
and aligns FHS with many
other Unix implementations. You may find that your Linux
distribution still uses
/var/spool/mail
.- /var/opt
This directory is defined as a location for temporary
files of programs stored in
/opt
.- /var/run
/var/run
contains various files
describing the present state of the system. All such files may
be deleted at system boot time. This is the default location for
PID files, which contain the PIDs of the processes for which
they are named. For example, if the Apache web server,httpd, is running as process number
534,
/var/run/httpd.pid
will contain that
number:#
cat /var/run/httpd.pid534Such files are needed by utilities that must be able to
find a PID for a running process. Also located here is the
utmp
file, used by commands such as
who
and
last
to
display logged-in users.- /var/spool
The
/var/spool
directory contains
information that is queued for processing. Examples include
print queues, outgoing mail, and
crontab
files.- /var/state
The
/var/state
directory is intended
to contain information that helps applications preserve state
across multiple invocations or multiple instances.- /var/tmp
As with
/tmp
in the root filesystem,
/var/tmp
is used for storage of temporary
files. Unlike
/tmp
, the files in
/var/tmp
are expected to survive across
multiple system boots. The information found in
/var/tmp
could be considered more
persistent than information in
/tmp
.Although it is not specified this way in the FHS, some
distributions use
/var/tmp
as a more secure
temporary directory for use by
root
.- /var/yp
This optional directory contains the database files of the
Network Information Service (NIS), if implemented. NIS was
formerly known as
yellow pages
(not to be
confused with the big yellow book).This directory shouldn’t be confused with
/var/nis
, which is used by NIS+. Oddly,
/var/nis
is mentioned in a footnote in FHS
2.3, but it does not have an entry in the specification.
