The FreeBSD Directory Structure

If you have used any UNIX or UNIX-like operating system, FreeBSD's directory structure will undoubtedly look familiar to you (see Figure 12.1).

Figure 12.1. The FreeBSD filesystem, showing part of the hierarchical structure beginning at the root directory (/).

However, there are some key differences between the FreeBSD filesystem and the ones used by Linux, Solaris, and other UNIXes. For users coming from a Windows or classic Macintosh background, the directory structure can be extremely cryptic. As with much in the UNIX realm, the original reasons for such things as the quirky traditional naming scheme have been lost in the mists of time, but this chapter tries to shed a little light on the FreeBSD filesystemenough, at least, to help you become familiar with its quirks so you can comfortably use the system.

Table 12.1 lists the key elements of the FreeBSD filesystem. Issue the command ls -F / and you will see the top-level view of the FreeBSD filesystem, including the listed items and probably a few more which may vary depending on your specific installation and version of FreeBSD. In this table, as with the output of the -F flag on the ls command, directories are indicated with a following slash (/), symbolic links with an at (@) sign, and executables with an asterisk (*).

Table 12.1. Key Elements of the FreeBSD Filesystem

Directory	Purpose
bin/	Statically linked binaries (self-contained programs that do not depend on shared library modules stored separately) are contained here. These can be used even when you're doing an emergency boot and don't have access to any filesystems other than /, which might not be mounted under such circumstances. Programs in /bin are generally user-oriented programs and commands that don't affect the system in general, whereas the ones in /sbin are administrative programs that might alter the system's behavior (hence the "s" prefix).
boot/	This directory contains the kernel, which is the master executable of the system. The kernel manages all the devices and handles networking, along with a host of other tasks. See Chapter 18, "Kernel Configuration," for more information. /boot also has configuration files and executables that are used during boot.
compat@	This is a symbolic link to directory structures that provide compatibility with other operating systems, such as Linux. In many installations this directory is empty.
dev/	This is a special directory. Files in here are mostly devices, which are special file types that give programs an interface into any devices the kernel supports. /dev is actually a mount point where the device filesystem, devfs, is usually mounted.
etc/	Long ago, this was merely a directory for random files that didn't fit elsewhere. It is now where most systemwide configuration files go, including your user (password) databases and startup scripts.
home@	This is possibly a plain directory or a symbolic link to /usr/home, depending on your installation. All regular users' home directories are contained here. If you intend to have a lot of users on your system with a lot of space-consuming data, make /home into a symlink pointing to /usr/home so that the users' data goes into the /usr partition rather than the much smaller root partitionor carve out a dedicated partition for /home (see Chapter 20, "Adding Hard Disk Storage").
mnt/	An empty directory that's provided for your convenience as a mount point if you need to mount another disk.
proc/	Contains the process filesystem (procfs) and is an interface to the process table. It's used for convenience by some programs but is not essential to the operation of the system (it's usually not mounted in modern systems).
rescue/	Contains a set of hard-linked programs that provide a "mini-FreeBSD" environment during system installation and emergencies when running in standalone mode.
root/	The root user's home directory. It's not in /home for security reasons, and to ensure that it will be available during an emergency boot.
sbin/	Contains system binaries that are statically linked. These programs differ from the ones in /bin in that they generally are used to alter the system's behavior, whereas the /bin programs are simply user tools.
sys@	A link to the kernel sources (if you installed them).
tmp/	Contains temporary files. Any user can write files into this directory. If you set clear_tmp_enable="YES" in /etc/rc.conf, the contents of /tmp will be deleted at every startup.
usr/	The UNIX System Resources directory, the gateway to the rest of the system. Contains dynamically linked programs, user files, and programs you installed yourself. In upcoming chapters, you'll spend most of your time here. Subdirectories of /usr are carefully delineated according to their purpose; the most important subdirectory for you as a FreeBSD administrator will be /usr/local.
var/	Contains variable files. These include runtime files used by programs, log files, spool directories, databases, and other items that change with the normal operation of the system and its applications.

There are some important differences between the FreeBSD directory structure and that of similar operating systems, such as Linux. FreeBSD's structure is tightly controlled, and the clearest rule is this: Anything installed by the administrator goes into the directory structure under /usr/local. Although other systems might allow user-installed programs the freedom to install files wherever they want, FreeBSD maintains strict structural guidelines in its ported programs and packages to ensure that all your own installed files are kept inside the /usr/local structure (see "Introduction to Packages," in Chapter 16, "Installing Additional Software"). Although a program might, by default, put its libraries in /var/lib and its configuration files into /etc, FreeBSD patches (modifies) the installation scripts so that the files would go into /usr/local/lib and /usr/local/etc, respectively. In fact, all configuration files for any software you might install will go into /usr/local/etc. If the program installs a startup script to be launched on boot, the script is placed in /usr/local/etc/rc.d. Anything in that directory is run at boot time, after the scripts in the analogous /etc/rc.d (the base system's startup scripts) are run.

Note

The FreeBSD filesystem hierarchy is designed to conform as closely as possible to the Filesystem Hierarchy Standard (FHS), although this standard was developed in a Linux-centric manner and includes some conventions shunned by FreeBSD (such as the practice of putting web content files in /srv). A full discussion of the FHS, including explanations of many of the cryptic abbreviations, can be found at http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard.

The advantage of a structure this carefully controlled is that a FreeBSD system is relatively easy to maintain, and it's especially easy to re-create on a new machine (if you're upgrading to new hardware, for instance). Theoretically, you could copy the entire /usr/local directory tree from one machine to another, and everything would work the same on both machines. This is a risky proposition, however, and any such operation is likely to hit any number of unforeseen snagsfor example, any well-used system is likely to have been tweaked in certain subtle ways that aren't re-created if you simply transfer /usr/local to the new machine. Still, this kind of system portability is an ideal toward which FreeBSD strives.

An obvious disadvantage of FreeBSD's regimented structure, though, is that if you're trying to port a program from Linux or Solaris to FreeBSD, you might experience some pain in fixing the expected paths. For instance, if you have programs written in Python on Linux, in which the Python interpreter is installed as /usr/bin/python, the programs will not run on FreeBSD because Python is not part of the base installation and is therefore installed as /usr/local/bin/python by the ports or package system. You can easily fix this problem for one or two files by modifying their interpreter lines that specify where to find Python, but migrating an installation with hundreds of such programs can quickly become painful. In the interest of cross-platform compatibility, it may turn out to be simplest to violate FreeBSD's structural guidelines by making the symbolic link /usr/bin/python to point to /usr/local/bin/python, so that the ported program works right away.

Tip

A convenient way to get around the problem of interpreters such as Perl and Python being installed in different locations on different systems is to use an interpreter line such as #!/usr/bin/env python instead of #!/usr/local/bin/python.

You can find a more detailed description of FreeBSD's filesystem by entering man hier.