Pet – A Command Line Snippet Manager for Linux

If you manage a lot of Linux systems via command line, you must be aware of the hectic task to remember all the commands you use on daily basis. You often need to go into your system’s history and find the required commands from there. Pet is a command line based tool which makes a system administrator’s life easy. It is an easy to use snippet manager, which saves your command snippets and you can easily view and use them when needed. Command line junkies find this tool extremely important, it is completely a freeware script, the setup process is pretty simple and it runs on almost all flavors of Linux operating system as well as Mac OS. It is built using the well known Go programming language and requires some python modules like Peco and brew to work properly. It is written by Teppei Fukuda and its source code is available on Github. In this tutorial, we will discuss its prominent features, installation process, and some usage example. Stay with us, it’s going to be an interesting session.

Important Features of Pet

Here are some of the noteworthy features of this utility, it can:

• register your new command snippets pretty quickly.
• search through the local repository of command snippets.
• easily edit and run command snippets.
• use Gist (GitHub-based online code repository) to sync your snippets.

Feeling excited? Let’s get started on its installation and configuration process now.

Installing and Using Pet

We will be demonstrating the installation and usage process of Pet on Ubuntu 16.10 system, the same set of instructions should work for any older version of Ubuntu and Debian based systems. As mentioned in the introductory paragraph, it requires Peco and brew to work properly. Run following two commands respectively to install Brew and Peco on your Linux system.

sudo apt-get install linuxbrew-wrapper
sudo brew install peco

Once the pre-requisites have been properly installed, run following command to download the source file for Pet.

sudo wget https://github.com/knqyf263/pet/releases/download/v0.0.2/pet_0.0.2_linux_amd64.zip

Depending on your network speed, it should take a couple of minutes to complete the download process. Run the following mentioned command to unzip the downloaded file.

unzip pet_0.0.2_linux_amd64.zip

Once the unzip process is complete, you should be able to see an executable script, named “pet” here. Run the following command to copy this script file to proper location so it may be available for use for all users.

sudo cp pet /usr/local/bin

There you go, Pet has been configured successfully now. Run “pet” command on the terminal to verify that it is working properly. Expected output should be as depicted in the following screenshot.

Let’s demonstrate some examples, in order to add the new snippets, use the following command:

pet new

It will prompt you the two details, “Command” and “Description”. I have following command I often use on my Linux web servers to identify if my server is under DDOS attack or not.

netstat -nap | grep \:80\  | awk ‘{print $5}’ | tr “:” ” ” | awk ‘{print $1}’ | sort | uniq -c | sort -n

Below screenshot will clarify how I added this snippet to Pet.

Similarly, you can use the following command to list the currently added snippets.

pet list

You can search through added snippets using the following command:

pet search

You can easily register the previously executed commands to the pet database by edit your .zshrc file. Use vi or vim editor to open the .zshrc file and append the following lines there:

function prev() {
PREV=$(fc -lrn | head -n 1)
sh -c “pet new `printf %q “$PREV”`”
}

Now you don’t need to add each command manually to Pet, your system will automatically add all the commands you use to the snippet manager. Your daily work life is lot easy now 🙂

Sync Snippets to Gist

As mentioned in the feature list, you can sync your snippets with online Gist repository, for this purpose you must have a Github account, once you have GitHub account, you can get a GIST Token easily. Use the following command to sync your snippets to Gist, it will prompt for Token ID and you should be good to go.

 pet sync -u

Here is the sample output of this command:

 pet sync -u
Gist ID: 1P93IUdf4e06d117097en976BHY
Upload success

Similarly, you can download your snippets from Gist to your system using the following command. It is pretty useful when you want to migrate your snippet data to any other system.

pet sync

Hope you enjoyed this article, we have discussed all possible usages of Pet utility here. It is an extremely lightweight, easy to use, and stable utility which is a must-have application for any command line Linux lover. It is under continuous development and we hope to see many improvements to this application in near future. If you have any questions or feedback, fee free to let us know in the comments section of this article.

Compatibility with Older Systems RHEL 7

If an ACL has been set on any file on a given file system, that file system has the ext_attr attribute. This attribute can be seen using the following command:

# tune2fs -l filesystem-device

A file system that has acquired the ext_attr attribute can be mounted with older kernels, but those kernels do not enforce any ACLs which have been set.

Versions of the e2fsck utility included in version 1.22 and higher of the e2fsprogs package (including the versions in Red Hat Enterprise Linux 2.1 and 4) can check a file system with the ext_attr attribute. Older versions refuse to check it.

Archiving File Systems with Acls RHEL 7

By default, the dump command now preserves ACLs during a backup operation. When archiving a file or file system with tar, use the --acls option to preserve ACLs. Similarly, when using cp to copy files with ACLs, include the --preserve=mode option to ensure that ACLs are copied across too. In addition, the -a option (equivalent to -dR --preserve=all) of cp also preserves ACLs during a backup along with other information such as timestamps, SELinux contexts, and the like. For more information about dump, tar, or cp, refer to their respective man pages.

The star utility is similar to the tar utility in that it can be used to generate archives of files; however, some of its options are different. Refer to Table 4.1, “Command Line Options for star” for a listing of more commonly used options. For all available options, refer to man star. The star package is required to use this utility.

Table 4.1. Command Line Options for star

Option	Description
-c	Creates an archive file.
-n	Do not extract the files; use in conjunction with -x to show what extracting the files does.
-r	Replaces files in the archive. The files are written to the end of the archive file, replacing any files with the same path and file name.
-t	Displays the contents of the archive file.
-u	Updates the archive file. The files are written to the end of the archive if they do not exist in the archive, or if the files are newer than the files of the same name in the archive. This option only works if the archive is a file or an unblocked tape that may backspace.
-x	Extracts the files from the archive. If used with -U and a file in the archive is older than the corresponding file on the file system, the file is not extracted.
-help	Displays the most important options.
-xhelp	Displays the least important options.
-/	Do not strip leading slashes from file names when extracting the files from an archive. By default, they are stripped when files are extracted.
-acl	When creating or extracting, archives or restores any ACLs associated with the files and directories.

Retrieving Acls RHEL 7

To determine the existing ACLs for a file or directory, use the getfacl command. In the example below, the getfacl is used to determine the existing ACLs for a file.

Example 4.4. Retrieving ACLs

# getfacl home/john/picture.png

The above command returns the following output:

# file: home/john/picture.png 
# owner: john 
# group: john 
user::rw- 
group::r-- 
other::r--

If a directory with a default ACL is specified, the default ACL is also displayed as illustrated below. For example, getfacl home/sales/ will display similar output:

# file: home/sales/ 
# owner: john 
# group: john 
user::rw- 
user:barryg:r-- 
group::r-- 
mask::r-- 
other::r-- 
default:user::rwx 
default:user:john:rwx 
default:group::r-x 
default:mask::rwx 
default:other::r-x

 

Setting Default Acls RHEL 7

To set a default ACL, add d: before the rule and specify a directory instead of a file name.

Example 4.3. Setting default ACLs

For example, to set the default ACL for the /share/ directory to read and execute for users not in the user group (an access ACL for an individual file can override it):

# setfacl -m d:o:rx /share

Access Control Lists RHEL 7

Files and directories have permission sets for the owner of the file, the group associated with the file, and all other users for the system. However, these permission sets have limitations. For example, different permissions cannot be configured for different users. Thus, Access Control Lists (ACLs) were implemented.

The Red Hat Enterprise Linux kernel provides ACL support for the ext3 file system and NFS-exported file systems. ACLs are also recognized on ext3 file systems accessed via Samba.

Along with support in the kernel, the acl package is required to implement ACLs. It contains the utilities used to add, modify, remove, and retrieve ACL information.

The cp and mv commands copy or move any ACLs associated with files and directories.

4.1. Mounting File Systems

Before using ACLs for a file or directory, the partition for the file or directory must be mounted with ACL support. If it is a local ext3 file system, it can mounted with the following command:

mount -t ext3 -o acl device-name partition

For example:

mount -t ext3 -o acl /dev/VolGroup00/LogVol02 /work

Alternatively, if the partition is listed in the /etc/fstab file, the entry for the partition can include the acl option:

LABEL=/work      /work       ext3    acl        1 2

If an ext3 file system is accessed via Samba and ACLs have been enabled for it, the ACLs are recognized because Samba has been compiled with the --with-acl-support option. No special flags are required when accessing or mounting a Samba share.

4.1.1. NFS

By default, if the file system being exported by an NFS server supports ACLs and the NFS client can read ACLs, ACLs are utilized by the client system.

To disable ACLs on NFS shares when configuring the server, include the no_acl option in the /etc/exports file. To disable ACLs on an NFS share when mounting it on a client, mount it with the no_acl option via the command line or the /etc/fstab file

Using Command-line Tools to manage users RHEL 7

Apart from the Users settings tool described in Section 3.2, “Managing Users in a Graphical Environment”, which is designed for basic managing of users, you can use command line tools for managing users and groups that are listed in Table 3.1, “Command line utilities for managing users and groups”.

Table 3.1. Command line utilities for managing users and groups

Utilities	Description
id	Displays user and group IDs.
useradd, usermod, userdel	Standard utilities for adding, modifying, and deleting user accounts.
groupadd, groupmod, groupdel	Standard utilities for adding, modifying, and deleting groups.
gpasswd	Utility primarily used for modification of group password in the /etc/gshadow file which is used by the newgrp command.
pwck, grpck	Utilities that can be used for verification of the password, group, and associated shadow files.
pwconv, pwunconv	Utilities that can be used for the conversion of passwords to shadow passwords, or back from shadow passwords to standard passwords.
grpconv, grpunconv	Similar to the previous, these utilities can be used for conversion of shadowed information for group accounts.

3.3.1. Adding a New User

To add a new user to the system, type the following at a shell prompt as root:

useradd [options] username

…where options are command-line options as described in Table 3.2, “Common useradd command-line options”.

By default, the useradd command creates a locked user account. To unlock the account, run the following command as root to assign a password:

passwd username

Optionally, you can set a password aging policy.

Table 3.2. Common useradd command-line options

Option	Description
-c ‘comment‘	comment can be replaced with any string. This option is generally used to specify the full name of a user.
-d home_directory	Home directory to be used instead of default /home/username/.
-e date	Date for the account to be disabled in the format YYYY-MM-DD.
-f days	Number of days after the password expires until the account is disabled. If 0 is specified, the account is disabled immediately after the password expires. If -1 is specified, the account is not disabled after the password expires.
-g group_name	Group name or group number for the user’s default (primary) group. The group must exist prior to being specified here.
-G group_list	List of additional (supplementary, other than default) group names or group numbers, separated by commas, of which the user is a member. The groups must exist prior to being specified here.
-m	Create the home directory if it does not exist.
-M	Do not create the home directory.
-N	Do not create a user private group for the user.
-p password	The password encrypted with crypt.
-r	Create a system account with a UID less than 1000 and without a home directory.
-s	User’s login shell, which defaults to /bin/bash.
-u uid	User ID for the user, which must be unique and greater than 999.

The command-line options associated with the usermod command are essentially the same. Note that if you want to add a user to another supplementary group, you need to use the -a, --append option with the -G option. Otherwise the list of supplementary groups for the user will be overwritten by those specified with the usermod -G command.

 

IMPORTANT

The default range of IDs for system and normal users has been changed in Red Hat Enterprise Linux 7 from earlier releases. Previously, UID 1-499 was used for system users and values above for normal users. The default range for system users is now 1-999. This change might cause problems when migrating to Red Hat Enterprise Linux 7 with existing users having UIDs and GIDs between 500 and 999. The default ranges of UID and GID can be changed in the /etc/login.defs file.

Explaining the Process

The following steps illustrate what happens if the command useradd juan is issued on a system that has shadow passwords enabled:

1. A new line for juan is created in /etc/passwd:

   juan:x:1001:1001::/home/juan:/bin/bash

   The line has the following characteristics:
   • It begins with the user name juan.
   • There is an x for the password field indicating that the system is using shadow passwords.
   • A UID greater than 999 is created. Under Red Hat Enterprise Linux 7, UIDs below 1000 are reserved for system use and should not be assigned to users.
   • A GID greater than 999 is created. Under Red Hat Enterprise Linux 7, GIDs below 1000 are reserved for system use and should not be assigned to users.
   • The optional GECOS information is left blank. The GECOS field can be used to provide additional information about the user, such as their full name or phone number.
   • The home directory for juan is set to /home/juan/.
   • The default shell is set to /bin/bash.
2. A new line for juan is created in /etc/shadow:

   juan:!!:14798:0:99999:7:::

   The line has the following characteristics:
   • It begins with the username juan.
   • Two exclamation marks (!!) appear in the password field of the /etc/shadow file, which locks the account.

     NOTE

     If an encrypted password is passed using the -p flag, it is placed in the /etc/shadow file on the new line for the user.
   • The password is set to never expire.
3. A new line for a group named juan is created in /etc/group:

   juan:x:1001:

   A group with the same name as a user is called a user private group. For more information on user private groups.
   The line created in /etc/group has the following characteristics:
   • It begins with the group name juan.
   • An x appears in the password field indicating that the system is using shadow group passwords.
   • The GID matches the one listed for juan‘s primary group in /etc/passwd.
4. A new line for a group named juan is created in /etc/gshadow:

   juan:!::

   The line has the following characteristics:
   • It begins with the group name juan.
   • An exclamation mark (!) appears in the password field of the /etc/gshadow file, which locks the group.
   • All other fields are blank.
5. A directory for user juan is created in the /home directory:

   ~]# ls -ld /home/juan
   drwx------. 4 juan juan 4096 Mar  3 18:23 /home/juan

   This directory is owned by user juan and group juan. It has read, write, and execute privileges only for the user juan. All other permissions are denied.
6. The files within the /etc/skel/ directory (which contain default user settings) are copied into the new /home/juan/ directory:

   ~]# ls -la /home/juan
   total 28
   drwx------. 4 juan juan 4096 Mar  3 18:23 .
   drwxr-xr-x. 5 root root 4096 Mar  3 18:23 ..
   -rw-r--r--. 1 juan juan   18 Jun 22  2010 .bash_logout
   -rw-r--r--. 1 juan juan  176 Jun 22  2010 .bash_profile
   -rw-r--r--. 1 juan juan  124 Jun 22  2010 .bashrc
   drwxr-xr-x. 4 juan juan 4096 Nov 23 15:09 .mozilla

At this point, a locked account called juan exists on the system. To activate it, the administrator must next assign a password to the account using the passwd command and, optionally, set password aging guidelines.

3.3.2. Adding a New Group

To add a new group to the system, type the following at a shell prompt as root:

groupadd [options] group_name

…where options are command-line options as described in Table 3.3, “Common groupadd command-line options”.

Table 3.3. Common groupadd command-line options

Option	Description
-f, --force	When used with -g gid and gid already exists, groupadd will choose another unique gid for the group.
-g gid	Group ID for the group, which must be unique and greater than 999.
-K, --key key=value	Override /etc/login.defs defaults.
-o, --non-unique	Allows creating groups with duplicate GID.
-p, --password password	Use this encrypted password for the new group.
-r	Create a system group with a GID less than 1000.

3.3.3. Creating Group Directories

System administrators usually like to create a group for each major project and assign people to the group when they need to access that project’s files. With this traditional scheme, file management is difficult; when someone creates a file, it is associated with the primary group to which they belong. When a single person works on multiple projects, it becomes difficult to associate the right files with the right group. However, with the UPG scheme, groups are automatically assigned to files created within a directory with the setgid bit set. The setgid bit makes managing group projects that share a common directory very simple because any files a user creates within the directory are owned by the group that owns the directory.

For example, a group of people need to work on files in the /opt/myproject/ directory. Some people are trusted to modify the contents of this directory, but not everyone.

1. As root, create the /opt/myproject/ directory by typing the following at a shell prompt:

   mkdir /opt/myproject

2. Add the myproject group to the system:

   groupadd myproject

3. Associate the contents of the /opt/myproject/ directory with the myproject group:

   chown root:myproject /opt/myproject

4. Allow users in the group to create files within the directory and set the setgid bit:

   chmod 2775 /opt/myproject

   At this point, all members of the myproject group can create and edit files in the /opt/myproject/ directory without the administrator having to change file permissions every time users write new files. To verify that the permissions have been set correctly, run the following command:

   ~]# ls -ld /opt/myproject
   drwxrwsr-x. 3 root myproject 4096 Mar  3 18:31 /opt/myproject
   

5. Add users to the myproject group:

   usermod -aG myproject username

3.3.4. Setting Default Permissions for New Files Using umask

When a process creates a file, the file has certain default permissions, for example, -rw-rw-r--. These initial permissions are partially defined by the file mode creation mask, also called file permission mask or umask. Every process has its own umask, for example, bash has umask 0022 by default. Process umask can be changed.

⁠What umask consists of

A umask consists of bits corresponding to standard file permissions. For example, for umask 0137, the digits mean that:

• 0 = no meaning, it is always 0 (umask does not affect special bits)
• 1 = for owner permissions, the execute bit is set
• 3 = for group permissions, the execute and write bits are set
• 7 = for others permissions, the execute, write, and read bits are set

Umasks can be represented in binary, octal, or symbolic notation. For example, the octal representation 0137 equals symbolic representation u=rw-,g=r--,o=---. Symbolic notation specification is the reverse of the octal notation specification: it shows the allowed permissions, not the prohibited permissions.

⁠How umask works

Umask prohibits permissions from being set for a file:

• When a bit is set in umask, it is unset in the file.
• When a bit is not set in umask, it can be set in the file, depending on other factors.

The following figure shows how umask 0137 affects creating a new file.

Figure 3.3. Applying umask when creating a file

IMPORTANT

For security reasons, a regular file cannot have execute permissions by default. Therefore, even if umask is 0000, which does not prohibit any permissions, a new regular file still does not have execute permissions. However, directories can be created with execute permissions:

[john@server tmp]$ umask 0000
[john@server tmp]$ touch file
[john@server tmp]$ mkdir directory
[john@server tmp]$ ls -lh .
total 0
drwxrwxrwx. 2 john john 40 Nov  2 13:17 directory
-rw-rw-rw-. 1 john john  0 Nov  2 13:17 file

3.3.4.1. Managing umask in Shells

For popular shells, such as bash, ksh, zsh and tcsh, umask is managed using the umask shell builtin. Processes started from shell inherit its umask.

⁠Displaying the current mask

To show the current umask in octal notation:

~]$ umask
0022

To show the current umask in symbolic notation:

~]$ umask -S
u=rwx,g=rx,o=rx

⁠Setting mask in shell using umask

To set umask for the current shell session using octal notation run:

~]$ umask octal_mask

Substitute octal_mask with four or less digits from 0 to 7. When three or less digits are provided, permissions are set as if the command contained leading zeros. For example, umask 7 translates to 0007.

⁠

Example 3.1. Setting umask Using Octal Notation

To prohibit new files from having write and execute permissions for owner and group, and from having any permissions for others:

~]$ umask 0337

Or simply:

~]$ umask 337

To set umask for the current shell session using symbolic notation:

~]$ umask -S symbolic_mask

⁠

Example 3.2. Setting umask Using Symbolic Notation

To set umask 0337 using symbolic notation:

~]$ umask -S u=r,g=r,o=

⁠Working with the default shell umask

Shells usually have a configuration file where their default umask is set. For bash, it is /etc/bashrc. To show the default bash umask:

~]$ grep -i -B 1 umask /etc/bashrc

The output shows if umask is set, either using the umask command or the UMASK variable. In the following example, umask is set to 022 using the umask command:

~]$ grep -i -B 1 umask /etc/bashrc
    # By default, we want umask to get set. This sets it for non-login shell.
--
    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
       umask 002
    else
       umask 022

To change the default umask for bash, change the umask command call or the UMASK variable assignment in /etc/bashrc. This example changes the default umask to 0227:

    if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
       umask 002
    else
       umask 227

⁠Working with the default shell umask of a specific user

By default, bash umask of a new user defaults to the one defined in /etc/bashrc.

To change bash umask for a particular user, add a call to the umask command in $HOME/.bashrc file of that user. For example, to change bash umask of user john to 0227:

john@server ~]$ echo 'umask 227' >> /home/john/.bashrc

⁠Setting default permissions for newly created home directories

To change permissions with which user home directories are created, change the UMASK variable in the /etc/login.defs file:

# The permission mask is initialized to this value. If not specified,
# the permission mask will be initialized to 022.
UMASK 077

 

Managing Users in a Graphical Environment RHEL 7

The Users utility allows you to view, modify, add, and delete local users in the graphical user interface.

3.2.1. Using the Users Settings Tool

Press the Super key to enter the Activities Overview, type Users and then press Enter. The Users settings tool appears. The Super key appears in a variety of guises, depending on the keyboard and other hardware, but often as either the Windows or Command key, and typically to the left of the Spacebar. Alternatively, you can open the Users utility from the Settings menu after clicking your user name in the top right corner of the screen.

To make changes to the user accounts, first select the Unlock button and authenticate yourself as indicated by the dialog box that appears. Note that unless you have superuser privileges, the application will prompt you to authenticate as root. To add and remove users, select the + and – button respectively. To add a user to the administrative group wheel, change the Account Type from Standard to Administrator. To edit a user’s language setting, select the language and a drop-down menu appears.

Figure 3.1. The Users Settings Tool

When a new user is created, the account is disabled until a password is set. The Password drop-down menu, shown in Figure 3.2, “The Password Menu”, contains the options to set a password by the administrator immediately, choose a password by the user at the first login, or create a guest account with no password required to log in. You can also disable or enable an account from this menu.

⁠

Figure 3.2. The Password Menu

Introduction to users and groups RHEL 7

While users can be either people (meaning accounts tied to physical users) or accounts that exist for specific applications to use, groups are logical expressions of organization, tying users together for a common purpose. Users within a group share the same permissions to read, write, or execute files owned by that group.

Each user is associated with a unique numerical identification number called a user ID (UID). Likewise, each group is associated with a group ID (GID). A user who creates a file is also the owner and group owner of that file. The file is assigned separate read, write, and execute permissions for the owner, the group, and everyone else. The file owner can be changed only by root, and access permissions can be changed by both the root user and file owner.

Additionally, Red Hat Enterprise Linux supports access control lists (ACLs) for files and directories which allow permissions for specific users outside of the owner to be set.

Reserved User and Group IDs

Red Hat Enterprise Linux reserves user and group IDs below 1000 for system users and groups. By default, the User Manager does not display the system users. Reserved user and group IDs are documented in the setup package. To view the documentation, use this command:

cat /usr/share/doc/setup*/uidgid

The recommended practice is to assign non-reserved IDs starting at 5,000, as the reserved range can increase in the future. To make the IDs assigned to new users by default start at 5,000, change the UID_MIN and GID_MIN directives in the /etc/login.defs file:

[file contents truncated]
UID_MIN                  5000
[file contents truncated]
GID_MIN                  5000
[file contents truncated]

NOTE

For users created before you changed UID_MIN and GID_MIN directives, UIDs will still start at the default 1000.

Even with new user and group IDs beginning with 5,000, it is recommended not to raise IDs reserved by the system above 1000 to avoid conflict with systems that retain the 1000 limit.

3.1.1. User Private Groups

Red Hat Enterprise Linux uses a user private group (UPG) scheme, which makes UNIX groups easier to manage. A user private group is created whenever a new user is added to the system. It has the same name as the user for which it was created and that user is the only member of the user private group.

User private groups make it safe to set default permissions for a newly created file or directory, allowing both the user and the group of that user to make modifications to the file or directory.

The setting which determines what permissions are applied to a newly created file or directory is called a umask and is configured in the /etc/bashrc file. Traditionally on UNIX-based systems, the umask is set to 022, which allows only the user who created the file or directory to make modifications. Under this scheme, all other users, including members of the creator’s group, are not allowed to make any modifications. However, under the UPG scheme, this “group protection” is not necessary since every user has their own private group.

A list of all groups is stored in the /etc/group configuration file.

3.1.2. Shadow Passwords

In environments with multiple users, it is very important to use shadow passwords provided by the shadow-utils package to enhance the security of system authentication files. For this reason, the installation program enables shadow passwords by default.

The following is a list of the advantages shadow passwords have over the traditional way of storing passwords on UNIX-based systems:

• Shadow passwords improve system security by moving encrypted password hashes from the world-readable /etc/passwd file to /etc/shadow, which is readable only by the root user.
• Shadow passwords store information about password aging.
• Shadow passwords allow to enforce some of the security policies set in the /etc/login.defs file.

Most utilities provided by the shadow-utils package work properly whether or not shadow passwords are enabled. However, since password aging information is stored exclusively in the /etc/shadowfile, some utilities and commands do not work without first enabling shadow passwords:

• The chage utility for setting password-aging parameters.
• The gpasswd utility for administrating the /etc/group file.
• The usermod command with the -e, --expiredate or -f, --inactive option.
• The useradd command with the -e, --expiredate or -f, --inactive option.

Overview of File System Hierarchy Standard (FHS)

Red Hat Enterprise Linux uses the Filesystem Hierarchy Standard (FHS) file system structure, which defines the names, locations, and permissions for many file types and directories.

The FHS document is the authoritative reference to any FHS-compliant file system, but the standard leaves many areas undefined or extensible. This section is an overview of the standard and a description of the parts of the file system not covered by the standard.

Compliance with the standard means many things, but the two most important are compatibility with other compliant systems and the ability to mount a /usr/ partition as read-only. This second point is important because the directory contains common executables and should not be changed by users. Also, since the /usr/ directory is mounted as read-only, it can be mounted from the CD-ROM or from another machine via a read-only NFS mount.

⁠1.2.1. FHS Organization

The directories and files noted here are a small subset of those specified by the FHS document. Refer to the latest FHS document for the most complete information.

The complete standard is available online at http://www.pathname.com/fhs/.

⁠1.2.1.1. The /boot/ Directory

The /boot/ directory contains static files required to boot the system, such as the Linux kernel. These files are essential for the system to boot properly.

Warning

Do not remove the /boot/ directory. Doing so renders the system unbootable.

⁠1.2.1.2. The /dev/ Directory

The /dev/ directory contains device nodes that either represent devices that are attached to the system or virtual devices that are provided by the kernel. These device nodes are essential for the system to function properly. The udev daemon takes care of creating and removing all these device nodes in /dev/.

Devices in the /dev directory and subdirectories are either character (providing only a serial stream of input/output) or block (accessible randomly). Character devices include mouse, keyboard, modem while block devices include hard disk, floppy drive etc. If you have GNOME or KDE installed in your system, devices such as external drives or cds are automatically detected when connected (e.g via usb) or inserted (e.g via CD or DVD drive) and a popup window displaying the contents is automatically displayed. Files in the /dev directory are essential for the system to function properly.

⁠

Table 1.1. Examples of common files in the /dev

File	Description
/dev/hda	The master device on primary IDE channel.
/dev/hdb	The slave device on primary IDE channel.
/dev/tty0	The first virtual console.
/dev/tty1	The second virtual console.
/dev/sda	The first device on primary SCSI or SATA channel.
/dev/lp0	The first parallel port.

⁠1.2.1.3. The /etc/ Directory

The /etc/ directory is reserved for configuration files that are local to the machine. No binaries are to be placed in /etc/. Any binaries that were once located in /etc/ should be placed into /sbin/ or /bin/.

Examples of directories in /etc are the X11/ and skel/:

/etc
   |- X11/
   |- skel/

The /etc/X11/ directory is for X Window System configuration files, such as xorg.conf. The /etc/skel/ directory is for “skeleton” user files, which are used to populate a home directory when a user is first created. Applications also store their configuration files in this directory and may reference them when they are executed.

⁠1.2.1.4. The /lib/ Directory

The /lib/ directory should contain only those libraries needed to execute the binaries in /bin/ and /sbin/. These shared library images are particularly important for booting the system and executing commands within the root file system.

⁠1.2.1.5. The /media/ Directory

The /media/ directory contains subdirectories used as mount points for removable media such as usb storage media, DVDs, CD-ROMs, and Zip disks.

⁠1.2.1.6. The /mnt/ Directory

The /mnt/ directory is reserved for temporarily mounted file systems, such as NFS file system mounts. For all removable media, please use the /media/ directory. Automatically detected removable media will be mounted in the /media directory.

Note

The /mnt directory must not be used by installation programs.

⁠1.2.1.7. The /opt/ Directory

The /opt/ directory provides storage for most application software packages.

A package placing files in the /opt/ directory creates a directory bearing the same name as the package. This directory, in turn, holds files that otherwise would be scattered throughout the file system, giving the system administrator an easy way to determine the role of each file within a particular package.

For example, if sample is the name of a particular software package located within the /opt/ directory, then all of its files are placed in directories inside the /opt/sample/ directory, such as /opt/sample/bin/ for binaries and /opt/sample/man/ for manual pages.

Packages that encompass many different sub-packages, data files, extra fonts, clipart etc are also located in the /opt/ directory, giving that large package a way to organize itself. In this way, our sample package may have different tools that each go in their own sub-directories, such as /opt/sample/tool1/ and /opt/sample/tool2/, each of which can have their own bin/, man/, and other similar directories.

⁠1.2.1.8. The /proc/ Directory

The /proc/ directory contains special files that either extract information from or send information to the kernel. Examples include system memory, cpu information, hardware configuration etc.

Due to the great variety of data available within /proc/ and the many ways this directory can be used to communicate with the kernel, an entire chapter has been devoted to the subject.

⁠1.2.1.9. The /sbin/ Directory

The /sbin/ directory stores executables used by the root user. The executables in /sbin/ are used at boot time, for system administration and to perform system recovery operations. Of this directory, the FHS says:

/sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. Programs executed after /usr/ is known to be mounted (when there are no problems) are generally placed into /usr/sbin. Locally-installed system administration programs should be placed into /usr/local/sbin.

At a minimum, the following programs should be in /sbin/:

arp, clock,
halt, init,
fsck.*, grub,
ifconfig, mingetty,
mkfs.*, mkswap,
reboot, route,
shutdown, swapoff,
swapon

⁠1.2.1.10. The /srv/ Directory

The /srv/ directory contains site-specific data served by your system running Red Hat Enterprise Linux. This directory gives users the location of data files for a particular service, such as FTP, WWW, or CVS. Data that only pertains to a specific user should go in the /home/ directory.

⁠1.2.1.11. The /sys/ Directory

The /sys/ directory utilizes the new sysfs virtual file system specific to the 2.6 kernel. With the increased support for hot plug hardware devices in the 2.6 kernel, the /sys/ directory contains information similarly held in /proc/, but displays a hierarchical view of specific device information in regards to hot plug devices.

⁠1.2.1.12. The /usr/ Directory

The /usr/ directory is for files that can be shared across multiple machines. The /usr/ directory is often on its own partition and is mounted read-only. At a minimum, the following directories should be subdirectories of /usr/:

/usr
   |- bin/
   |- etc/
   |- games/
   |- include/
   |- kerberos/
   |- lib/
   |- libexec/
   |- local/
   |- sbin/
   |- share/
   |- src/
   |- tmp -> ../var/tmp/

Under the /usr/ directory, the bin/ subdirectory contains executables, etc/ contains system-wide configuration files, games is for games, include/ contains C header files, kerberos/ contains binaries and other Kerberos-related files, and lib/ contains object files and libraries that are not designed to be directly utilized by users or shell scripts. The libexec/ directory contains small helper programs called by other programs, sbin/ is for system administration binaries (those that do not belong in the /sbin/ directory), share/ contains files that are not architecture-specific, src/ is for source code.

⁠1.2.1.13. The /usr/local/ Directory

The FHS says:

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable among a group of hosts, but not found in /usr.

The /usr/local/ directory is similar in structure to the /usr/ directory. It has the following subdirectories, which are similar in purpose to those in the /usr/ directory:

/usr/local
	|- bin/
	|- etc/
	|- games/
	|- include/
	|- lib/
	|- libexec/
	|- sbin/
	|- share/
	|- src/

In Red Hat Enterprise Linux, the intended use for the /usr/local/ directory is slightly different from that specified by the FHS. The FHS says that /usr/local/ should be where software that is to remain safe from system software upgrades is stored. Since software upgrades can be performed safely with RPM Package Manager (RPM), it is not necessary to protect files by putting them in /usr/local/. Instead, the /usr/local/directory is used for software that is local to the machine.

For instance, if the /usr/ directory is mounted as a read-only NFS share from a remote host, it is still possible to install a package or program under the /usr/local/ directory.

⁠1.2.1.14. The /var/ Directory

Since the FHS requires Linux to mount /usr/ as read-only, any programs that write log files or need spool/ or lock/ directories should write them to the /var/ directory. The FHS states /var/ is for:

…variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.

Below are some of the directories found within the /var/ directory:

/var
   |- account/
   |- arpwatch/
   |- cache/
   |- crash/
   |- db/
   |- empty/
   |- ftp/
   |- gdm/
   |- kerberos/
   |- lib/
   |- local/
   |- lock/
   |- log/
   |- mail -> spool/mail/
   |- mailman/
   |- named/
   |- nis/
   |- opt/
   |- preserve/
   |- run/
   +- spool/
       |- at/
       |- clientmqueue/
       |- cron/
       |- cups/
       |- exim/
       |- lpd/
       |- mail/
       |- mailman/
       |- mqueue/
       |- news/
       |- postfix/
       |- repackage/
       |- rwho/
       |- samba/
       |- squid/
       |- squirrelmail/
       |- up2date/
       |- uucp
       |- uucppublic/
       |- vbox/
|- tmp/
|- tux/
|- www/
|- yp/

System log files, such as messages and lastlog, go in the /var/log/ directory. The /var/lib/rpm/ directory contains RPM system databases. Lock files go in the /var/lock/ directory, usually in directories for the program using the file. The /var/spool/ directory has subdirectories for programs in which data files are stored.