A practical guide to Fedora and Red Hat Enterprise Linux, 7th Edition (2014)

---

/etc/printcap

The printer capability database for LPD/LPR (page 556). It is not used with CUPS (Chapter 13), the Fedora/RHEL default printing system. This file describes system printers and is derived from 4.3BSD UNIX.

/etc/profile and /etc/profile.d

Contain systemwide interactive shell initialization scripts for environment and startup programs. When you log in, the shell immediately executes the commands in /etc/profile. This script executes all the commands in all the files in the /etc/profile.d directory (next) that have a filename extension of .sh. Both profile and the files in profile.d are executed in the same environment as the shell. (For information on executing a shell script in this manner, refer to the discussion of the . [dot] command on page 332.) As the comments at the beginning of profile say, if you want to make a systemwide change to users’ environments, place a script with a filename extension of .sh in profile.d. Do not modify profile because it might be replaced when the system is updated; a file you create in profile.d will not be replaced.

The system administrator can create a file with a filename extension of .sh in profile.d to establish systemwide environment parameters that individual users can override in their ~/.bash_profile (page 502) files. For example, this file can set shell variables, execute utilities, set up aliases, and take care of other housekeeping tasks. Following is an example of a file in /etc/profile.d that displays the message of the day (the /etc/motd file), sets the file-creation mask (umask; page 469), and sets the interrupt character to CONTROL-C:

# cat /etc/profile.d/simple.sh
cat /etc/motd
umask 022
stty intr '^c'

See the /etc/profile file and the files in /etc/profile.d on the local system for more complex examples.

/etc/protocols

Provides protocol numbers, aliases, and brief definitions for DARPA Internet TCP/IP protocols. Do not modify this file.

/etc/rc.d

Holds SysVinit initialization scripts and links. See page 448 for more information.

/etc/resolv.conf

The resolver (page 854) configuration file; provides access to DNS. This file is built by NetworkManager (page 637) if it is running.

The following example shows the resolv.conf file for the example.com domain. A resolv.conf file usually contains at least two lines—a search line (optional) and a nameserver line:

$ cat /etc/resolv.conf
search example.com
nameserver 10.0.0.50
nameserver 10.0.0.51

The search keyword might be followed by a maximum of six domain names. The first domain is interpreted as the host’s local domain. These names are appended one at a time to all DNS queries, shortening the time needed to query local hosts. The domains are searched in order in the process of resolving hostnames that are not fully qualified. See FQDN on page 1250.

When you put search example.com in resolv.conf, any reference to a host within the example.com domain or a subdomain (such as marketing.example.com) can use the abbreviated form of the host. For example, instead of issuing the command ping speedy.marketing.example.com, you can use ping speedy.marketing; however, a trailing period causes DNS to assume the name is complete so it appends no suffix. The following line in resolv.conf causes the marketing subdomain to be searched first, followed by sales, and finally the entire example.com domain:

search marketing.example.com sales.example.com example.com

It is a good idea to put the most frequently used domain names first to try to outguess possible conflicts. If both speedy.marketing.example.com and speedy.example.com exist, for example, the order of the search determines which one is selected when you invoke DNS. Do not overuse this feature: The longer the search path, the more network DNS requests generated, and the slower the response. Three or four names are typically sufficient.

Up to a maximum of three nameserver lines indicate which systems the local system queries to resolve hostnames to IP addresses, and vice versa. These machines are consulted in the order they appear, with a timeout between queries. The first timeout is a few seconds; each subsequent timeout is twice as long as the previous one. The preceding file causes this system to query 10.0.0.50, followed by 10.0.0.51 when the first system does not answer within a few seconds. The resolv.conf file might be automatically updated when a PPP (Point-to-Point Protocol) or DHCP (Dynamic Host Configuration Protocol) controlled interface is activated.

/etc/rpc

Maps RPC services to RPC numbers. The three columns in this file show the name of the server for the RPC program, the RPC program number, and any aliases.

/etc/services

Lists system services. The three columns in this file show the informal name of the service, the port number/protocol the service uses most frequently, and any aliases for the service. This file does not specify which services are running on the local system, nor does it map services to port numbers. The services file is used internally to map port numbers to services for display purposes; editing this file does not change which ports and protocols the local system uses.

/etc/shadow

Contains SHA2 (page 1272) or MD5 (page 1260) hashed user passwords, depending on system configuration. Each entry occupies one line composed of nine fields, separated by colons:

login-name:password:last-mod:min:max:warn:inactive:expire:flag

The login-name is the user’s username—the name that the user enters in response to the login: prompt or on a GUI login screen. The password is a hashed password that passwd puts in this file. New accounts that are not set up with a password are given a value of !, !!, or * in this field to prevent the user from logging in until you assign a password to that user (page 600).

The last-mod field indicates when the password was last modified. The min is the minimum number of days that must elapse before the password can be changed; the max is the maximum number of days before the password must be changed. The warn field specifies how much advance warning (in days) will be given to the user before the password expires. The account will be closed if the number of days between login sessions exceeds the number of days specified in the inactive field. The account will also be closed as of the date in the expire field. The last field in an entry, flag, is reserved for future use. You can use the Password Info tab in system-config-users (page 600) or chage to modify these fields.

The shadow password file must be owned by root and must not be publicly readable or writable. Setting ownership and permissions in this way makes it more difficult for someone to break into the system by identifying accounts without passwords or by using specialized programs that try to match hashed passwords.

A number of conventions exist for creating special shadow entries. An entry of *LK* or NP in the password field indicates locked or no password, respectively. No password is different from an empty password; no password implies that this is an administrative account that no one ever logs in on directly. Occasionally programs will run with the privileges of this account for system maintenance functions. These accounts are set up under the principle of least privilege (page 423).

Entries in the shadow file must appear in the same order as in the passwd file. There must be exactly one shadow entry for each passwd entry.

/etc/sysconfig

A directory containing a hierarchy of system configuration files. For more information refer to the /usr/share/doc/initscripts*/sysconfig.txt file.

/etc/sysconfig/network

Describes the network setup for the local system.

/proc

Provides a window into the Linux kernel. Through the /proc pseudofilesystem you can obtain information on any process running on the system, including its current state, memory usage, CPU usage, terminal association, parent, and group. You can extract information directly from the files in /proc. An example follows:

$ sleep 1000 &
[1] 3104
$ cd /proc/3104
$ ls -l
dr-xr-xr-x. 2 sam pubs 0 04-09 14:00 attr
-r-------- 1 sam pubs 0 04-09 14:00 auxv
-r--r--r-- 1 sam pubs 0 04-09 14:00 cgroup
--w------- 1 sam pubs 0 04-09 14:00 clear_refs
-r--r--r-- 1 sam pubs 0 04-09 14:00 cmdline
-rw-r--r-- 1 sam pubs 0 04-09 14:00 coredump_filter
-r--r--r-- 1 sam pubs 0 04-09 14:00 cpuset
lrwxrwxrwx 1 sam pubs 0 04-09 14:00 cwd -> /home/sam
-r-------- 1 sam pubs 0 04-09 14:00 environ
lrwxrwxrwx 1 sam pubs 0 04-09 14:00 exe -> /bin/sleep
dr-x------ 2 sam pubs 0 04-09 14:00 fd
...
$ cat status
Name: sleep
State: S (sleeping)
Tgid: 3104
Pid: 3104
PPid: 1503
TracerPid: 0
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 256
Groups: 4 20 24 46 105 119 122 1000
VmPeak: 3232 kB
VmSize: 3232 kB
VmLck: 0 kB
...

In this example, bash creates a background process (PID 3104) for sleep. Next the user changes directories to the directory in /proc that has the same name as the PID of the background process (cd /proc/3104). This directory holds information about the process it is named for—the sleepprocess in the example. The ls –l command shows that some entries in this directory are links (cwd is a link to the directory the process was started from, and exe is a link to the executable file that this process is running) and some appear to be ordinary files. All appear to be empty. However, when you use cat to display one of these pseudofiles (status in the example), cat displays output. Obviously it is not an ordinary file.

You can also obtain information about the local system by examining pseudofiles in /proc. The following examples display information about the CPU and RAM (memory).

$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz
stepping : 10
microcode : 0xa0b
...
$ cat /proc/meminfo
MemTotal: 1012484 kB
MemFree: 221216 kB
Buffers: 14176 kB
Cached: 267940 kB
SwapCached: 2124 kB
Active: 215912 kB
Inactive: 412792 kB

swap

Swap space is used by the virtual memory subsystem of the kernel. When it runs low on real memory (RAM), the kernel writes memory pages from RAM to the swap space. Which pages are written and when they are written are controlled by finely tuned algorithms in the Linux kernel. When needed by running programs, the kernel brings these pages back into RAM—a technique called paging (page 1265). When a system is running very short on memory, an entire process might be paged out to disk.

Running an application that requires a large amount of virtual memory might result in the need for additional swap space. Swap space can be added and deleted from the system dynamically: If you run out of swap space, you can use mkswap to create a swap file and swapon to enable it. Normally the kernel uses a disk partition as swap space, but it can also use a file for this purpose. However, a disk partition provides much better performance than a file.

If you are creating a file as swap space, first use df to ensure the partition you are creating it in has adequate space for the file. The following commands first use dd and /dev/zero (page 505) to create an empty file (do not use cp because you might create a file with holes, which might not work) in the working directory. Next mkswap takes as an argument the name of the file created in the first step to set up the swap space. For security reasons, change the file so it cannot be read from or written to by anyone except a user with root privileges. Use swapon with the same argument to turn the swap file on; then use swapon –s to confirm the swap space is available. The final two commands turn off the swap file and remove it:

# dd if=/dev/zero of=swapfile bs=1024 count=65536
65536+0 records in
65536+0 records out
67108864 bytes (67 MB) copied, 0.40442 s, 166 MB/s
# mkswap swapfile
Setting up swapspace version 1, size = 65532 KiB
no label, UUID=49ec7f5b-1391-4b24-bd0a-a07e55752666
# chmod 600 swapfile
# swapon swapfile
# swapon -s
Filename Type Size Used Priority
/dev/dm-1 partition 2031612 0 -1
/swapfile file 65532 0 -2
# swapoff swapfile
# rm swapfile
rm: remove regular file 'swapfile'? y

/sys

A pseudofilesystem that was added in the Linux 2.6 kernel to make it easy for programs running in kernelspace, such as device drivers, to exchange information with programs running in userspace. See page 516 for more information.

/usr/libexec

Holds binary files that are not executed directly by a user.

/usr/share/magic

Most files begin with a unique identifier called a magic number. This file is a text database listing all known magic numbers on the system. When you use the file utility, it consults /usr/share/magic to determine the type of a file. Occasionally you might acquire a new tool that creates a new type of file that is unrecognized by the file utility. In this situation you need to update the /usr/share/magic file; refer to the magic man page for details. See also “magic number” on page 1259.

/var/log

Holds system log files, many of which are generated by syslogd (page 620). You can use a text display program such as less, tail, or cat, or the graphical program gnome-system-log (gnome-system-log package) to view the files in this directory. To run gnome-system-log, enter gnome-system-log from a terminal emulator or in an Enter a Command window (ALT-F2).

/var/log/messages

Contains messages from daemons, the Linux kernel, and security programs. For example, you will find filesystem full warning messages, error messages from system daemons (e.g., NFS, ntpd, printer daemons), SCSI and IDE disk error messages, and more in messages. Check/var/log/messages periodically to keep informed about important system events. Much of the information displayed on the system console is also sent to messages. If the system experiences a problem and you cannot access the console, check this file for messages about the problem. See page 620 for information on syslogd, which generates many of these messages.

/var/log/secure

Holds messages from security-related programs such as su and the sshd daemon.

File Types

Linux supports many types of files. This section discusses the following types of files:

• Ordinary files, directories, links, and inodes (next)

• LE Symbolic links (page 515)

• Device special files (page 515)

• FIFO special files (named pipes) (page 516)

• Sockets (page 517)

• Block and character devices (page 518)

• Raw devices (page 518)

Ordinary Files, Directories, Links, and Inodes

Ordinary and directory files

An ordinary file stores user data, such as textual information, programs, or images, such as a jpeg or tiff file. A directory is a standard-format disk file that stores information, including names, about ordinary files and other directory files.

Inodes

An inode is a data structure (page 1245), stored on disk, that defines a file’s existence and is identified by an inode number. Use ls with the –i option to display the inode number of a file. An inode contains critical information about a file, such as the UID of the owner, where it is physically located on the disk, access mode, and how many hard links point to it. In addition, SELinux (page 472) stores extended information about files in inodes. Directory files, not inodes, hold filename information. This setup allows an inode to be associated with more than one filename and to be pointed to from more than one directory.

When you move (mv) a file, including a directory file, within a filesystem, you change the filename portion of the directory entry associated with the inode that describes the file. You do not create a new inode. If you move a file to another filesystem, mv first creates a new inode on the destination filesystem and then deletes the original inode. You can also use mv to move a directory recursively from one filesystem to another. In this case mv copies the directory and all the files in it and deletes the original directory and its contents.

Hard links

When you make an additional hard link (ln; page 204) to a file, you add a directory entry that points to the inode that describes the file. You do not create a new inode. It is not possible to create a hard link to a directory.

When you remove (rm) a file, you delete the directory entry that describes the file. When you remove the last hard link to a file, the operating system puts all blocks the inode pointed to back in the free list (the list of blocks that are available for use on the disk) and frees the inode to be used again.

The . and .. directory entries

Every directory contains at least two entries (. and ..). The . entry is a link to the directory itself. The .. entry is a link to the parent directory. In the case of the root directory, there is no parent; the .. entry is a link to the root directory itself.

Symbolic links

Because each filesystem has a separate set of inodes, you can create hard links to a file only from within the filesystem that holds that file. To get around this limitation, Linux provides symbolic links, which are files that point to other files. Files that are linked by a symbolic link do not share an inode. As a consequence, you can create a symbolic link to a file from any filesystem. You can also create a symbolic link to a directory, device, or other special file. For more information refer to “Symbolic Links” on page 206.

Device Special Files

Device special files (also called device files and special files) represent Linux kernel routines that provide access to an operating system feature. FIFO (first in, first out) special files allow unrelated programs to exchange information. Sockets allow unrelated processes on the same or different systems to exchange information. One type of socket, the UNIX domain socket, is a special file. Symbolic links are another type of special file.

Device files

Device files include both block and character special files and represent device drivers that allow the system to communicate with peripheral devices, such as terminals, printers, and hard disks. By convention, device files appear in the /dev directory and its subdirectories. Each device file represents a device; hence, the system reads from and writes to the file to read from and write to the device it represents. The following example shows part of a listing for the /dev directory:

$ ls -l /dev
crw-rw----. 1 root video 10, 175 01-25 12:17 agpgart
crw-------. 1 root root 10, 235 01-25 12:17 autofs
drwxr-xr-x. 2 root root 640 01-25 04:17 block
drwxr-xr-x. 2 root root 80 01-25 04:17 bsg
drwxr-xr-x. 3 root root 60 01-25 04:17 bus
lrwxrwxrwx. 1 root root 3 01-25 04:17 cdrom -> sr0
drwxr-xr-x. 2 root root 2760 01-25 12:17 char
crw-------. 1 root root 5, 1 01-25 12:17 console
lrwxrwxrwx. 1 root root 11 01-25 04:17 core -> /proc/kcore
...
brw-rw----. 1 root disk 8, 0 01-25 04:17 sda
brw-rw----. 1 root disk 8, 1 01-25 12:17 sda1
brw-rw----. 1 root disk 8, 2 01-25 04:17 sda2
...

The first character of each line is always –, b, c, d, l, or p, representing the file type—ordinary (plain), block, character, directory, symbolic link, or named pipe (next), respectively. The next nine characters identify the permissions for the file, followed by the number of hard links and the names of the owner and the group. Where the number of bytes in a file would appear for an ordinary or directory file, a device file shows major and minor device numbers (page 517) separated by a comma. The rest of the line is the same as for any other ls –l listing (page 191).

udev

The udev utility manages device naming dynamically. It replaces devfs and moves the device-naming functionality from the kernel to userspace. Because devices are added to and removed from a system infrequently, the performance penalty associated with this change is minimal. The benefit of the move is that a bug in udev cannot compromise or crash the kernel.

/sys

The udev utility is part of the hotplug system (next). When a device is added to or removed from the system, the kernel creates a device name in the /sys pseudofilesystem and notifies hotplug of the event, which is received by udev. The udev utility then creates the device file, usually in the/dev directory, or removes the device file from the system. The udev utility can also rename network interfaces. See the page at www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html for more information.

Hotplug

The hotplug system allows you to plug a device into a running system and use it immediately. Although hotplug was available in the Linux 2.4 kernel, the 2.6 kernel integrates hotplug with the unified device driver model framework (the driver model core) so any bus can report an event when a device is added to or removed from the system. User software can be notified of the event so it can take appropriate action. See linux-hotplug.sourceforge.net for more information.

FIFO Special File (Named Pipe)

A FIFO special file, also called a named pipe, represents a pipe: You read from and write to the file to read from and write to the pipe. The term FIFO stands for first in, first out—the way any pipe works. In other words, the first information you put in one end is the first information that comes out the other end. When you use a pipeline on a command line to send the output of a program to the printer, the printer outputs the information in the same order that the program produced it and sent it to the pipeline.

Unless you are writing sophisticated programs, you will not be working with FIFO special files. However, programs use named pipes for interprocess communication. You can create a pipe using mkfifo:

$ mkfifo AA
$ ls -l AA
prw-rw-r--. 1 sam pubs 0 01-27 17:55 AA

The p at the left end of the output indicates the file is a pipe.

Both UNIX and Linux systems have included pipes for many generations. Without named pipes, only processes that were children of the same ancestor could use pipes to exchange information. Using named pipes, any two processes on a single system can exchange information. When one program writes to a FIFO special file, another program can read from the same file. The programs do not have to run at the same time or be aware of each other’s activity. The operating system handles all buffering and information storage. This type of communication is termed asynchronous(async) because the programs on the opposite ends of the pipe do not have to be synchronized.

Sockets

Like FIFO special files, UNIX/Linux domain sockets allow asynchronous processes that are not children of the same ancestor to exchange information. These sockets are the central mechanism of the interprocess communication that forms the basis of the networking facility. They differ from TCP/IP sockets, which are not represented in the filesystem. When you use networking utilities, pairs of cooperating sockets manage the communication between the processes on the local system and the remote system. Sockets form the basis of such utilities as ssh and scp.

Major and Minor Device Numbers

A major device number points to a driver in the kernel that works with a class of hardware devices: terminal, printer, tape drive, hard disk, and so on. In the listing of the /dev directory on page 516, all the hard disk partitions have a major device number of 8.

A minor device number identifies a particular piece of hardware within a class. Although all hard disk partitions are grouped together by their major device number, each has a different minor device number (sda1 is 1, sda2 is 2, and so on). This setup allows one piece of software (the device driver) to service all similar hardware yet still be able to distinguish among different physical units.

Block and Character Devices

This section describes typical device drivers. Because device drivers can be changed to suit a particular purpose, the descriptions in this section do not pertain to every system.

Block device

A block device is an I/O (input/output) device that has the following characteristics:

• Able to perform random access reads

• Has a specific block size

• Handles only single blocks of data at a time

• Accepts only transactions that involve whole blocks of data

• Able to have a filesystem mounted on it

• Has the Linux kernel buffer its input and output

• Appears to the operating system as a series of blocks numbered from 0 through n – 1, where n is the number of blocks on the device

Block devices commonly found on a Linux system include hard disks, USB flash drives, CDs, and DVDs.

Character device

A character device is any device that is not a block device. Examples of character devices include printers, terminals, tape drives, and modems.

The device driver for a character device determines how a program reads from and writes to that device. For example, the device driver for a terminal allows a program to read the information you type on the terminal in two ways. First, a program can read single characters from a terminal inraw mode—that is, without the driver interpreting characters. (This mode has nothing to do with the raw device described next.) Alternately, a program can read one line at a time. When a program reads one line at a time, the driver handles the erase and kill characters so the program never sees typing mistakes that have been corrected. In this case, the program reads everything from the beginning of a line to the RETURN that ends a line; the number of characters in a line can vary.

Raw Devices

Device driver programs for block devices usually have two entry points so they can be used in two ways: as block devices or as character devices. The character device form of a block device is called a raw device. A raw device is characterized by

• Direct I/O (no buffering through the Linux kernel).

• One-to-one correspondence between system calls and hardware requests.

• Device-dependent restrictions on I/O.

fsck

An example of a utility that uses a raw device is fsck. It is more efficient for fsck to operate on the disk as a raw device rather than being restricted by the fixed size of blocks in the block device interface. Because it has full knowledge of the underlying filesystem structure, fsck can operate on the raw device using the largest possible units. When a filesystem is mounted, processes normally access the disk through the block device interface, which explains why it is important to allow fsck to modify only unmounted filesystems. On a mounted filesystem, there is the danger that while fsck is rearranging the underlying structure through the raw device, another process could change a disk block using the block device, resulting in a corrupted filesystem.

Filesystems

Table 11-1 lists some types of filesystems available under Linux.

Table 11-1 Filesystems

mount: Mounts a Filesystem

The mount utility connects directory hierarchies—typically filesystems—to the Linux directory hierarchy. These directory hierarchies can be on remote and local disks, CDs, DVDs, and USB flash drives. Linux can also mount virtual filesystems that have been built inside ordinary files, filesystems built for other operating systems, and the special /proc filesystem (page 512), which maps Linux kernel information to a pseudodirectory. This section covers mounting local filesystems; refer to page 801 for information on using NFS to mount remote directory hierarchies. See/dev on page 503 for information on device names.

Mount point

The mount point for the filesystem/directory hierarchy that you are mounting is a directory in the local filesystem. This directory must exist before you can mount a filesystem; its contents disappear as long as a filesystem is mounted on it and reappear when you unmount the filesystem. See page 38 for a discussion of mount points.

Without any arguments, mount lists the mounted filesystems, showing the physical device holding each filesystem, the mount point, the type of filesystem, and any options set when each filesystem was mounted. The mount utility gets this information from the /etc/mtab file (page 508), which is a link to /proc/self/mounts. On a system running systemd page 438, mount lists so many virtual filesystems it can be difficult to find the physical filesystems. Instead you can use findmnt with the –t (––types) option to display one type of filesystem such as ext4:

$ findmnt -t ext4
TARGET SOURCE FSTYPE OPTIONS
/ /dev/mapper/fedora-root ext4 rw,relatime,seclabel,data=ordered
|––/boot /dev/sda1 ext4 rw,relatime,seclabel,data=ordered

The first entry in the preceding example shows an LV mounted by the LVM (page 44) device mapper on / (root). As explained on page 40, the /boot partition cannot reside on an LV; it is mounted on /dev/sda1.